Дві різні системи, а не дві версії однієї
Порівнювати NetHunt і KeyCRM «в лоб» — помилка по суті. Це не дві реалізації однієї ідеї, а два різні ядра під різні бізнес-моделі. NetHunt побудований навколо запису у власній папці: угода, контакт, компанія чи довільна сутність зі звʼязками між папками — це конструктор, на якому будується і класична B2B-угода, і нестандартний операційний процес (учні, платежі, кандидати, проєкти, заявки) поверх нативних задач і сценаріїв автоматизації. KeyCRM побудований навколо замовлення: потоку з маркетплейсів, чатів і сайту в єдиній черзі обробки. Перше питання, на яке варто відповісти, — не «яка CRM краща», а «що для вас є центральним обʼєктом: процес чи угода, які ви ведете тижнями, чи замовлення, яке треба швидко прийняти, упакувати й відправити».
Звідси випливає вся решта відмінностей. KeyCRM створювалась як хаб для e-commerce, тому маркетплейси, синхронізація залишків, ПРРО та Нова Пошта — її домашня територія: ТТН генеруються з картки замовлення масово, повернення розпізнаються автоматично, фіскальний чек виставляється при оплаті. У NetHunt цього шару немає принципово, бо роздрібна обробка замовлень із маркетплейсів лежить поза його профілем. Дзеркально працює й Gmail: NetHunt живе прямо в інтерфейсі пошти, автоматично прикріплюючи листи до записів і підтягуючи Calendar, Drive та Meet — для команди, що веде угоди й процеси листуванням, це той рівень нативності, якого побудована навколо замовлень KeyCRM дати не може. Жорстка умова з боку NetHunt — уся команда має бути на Gmail/Google Workspace: синхронізація пошти з Outlook чи IMAP не працює.
Окремо варто дивитися на економіку, бо цінові моделі теж дзеркальні. NetHunt тарифікує за користувача, і потреба в папках, сценаріях автоматизації та API штовхає план до старших тарифів — рахунок росте від розміру команди. KeyCRM робить користувачів безплатними й бере плату за обсяг: замовлення, картки, повідомлення месенджерів. Тому той самий бізнес отримає протилежні висновки залежно від профілю: велика команда з помірним потоком угод і процесів дешевше обходиться на моделі оплати KeyCRM, а магазин на 10+ операторах із десятками тисяч замовлень — навпаки. Жодних конкретних цифр на цьому етапі ми не називаємо: бюджет рахуємо після знайомства й брифу (discovery — перший етап робіт, на якому детально розбираємо ваші процеси) під реальний профіль навантаження.
На практиці WDP ці системи рідко мігрують одна в одну — частіше вони працюють у парі. Прямого перенесення «1-в-1» не існує: структура замовлень KeyCRM (замовлення, товари, ТТН) не має відповідника в папковій моделі NetHunt, а воронки угод, операційні папки й Gmail-листи NetHunt не лягають на побудоване навколо замовлень ядро KeyCRM. Що реально переноситься в обох напрямках — контакти, компанії та базові поля через CSV або API; історія замовлень при переході в NetHunt втрачає сенс, а email-історія NetHunt при переході в KeyCRM не має куди лягти. Тому наше типове рішення — не міграція, а зв’язка двох систем: KeyCRM закриває роздрібний потік замовлень і логістику, NetHunt — B2B-продажі, спілкування поштою та операційні процеси на папках, а між ними налаштовується синхронізація контактів і подій через API.