Чому KeyCRM (а іноді NetHunt) для інтернет-магазину
Більшість e-commerce-болю — це не «погана воронка продажів», а розсинхрон між каналами. Замовлення приходять із Rozetka, Prom, Епіцентру, OLX, Etsy, сайту й месенджерів, кожен канал має власний кабінет, той самий клієнт дублюється під різними контактами, а менеджер вручну зводить усе докупи. KeyCRM знімає це на рівні моделі даних: центральний об’єкт системи — замовлення, а не угода, як у B2B-CRM. Усі канали стають джерелами одного потоку замовлень в єдиній черзі обробки, з одним статус-флоу й нижчою сукупною вартістю володіння. Тому для роздрібного e-commerce ми за замовчуванням рекомендуємо KeyCRM, а не загальну CRM, до якої маркетплейси доводиться «прикручувати» збоку.
Виняток — коли центр ваги бізнесу не в обробці замовлень, а в роботі з базою: атрибутивна сегментація, реактивація сплячих клієнтів, бонуси й дні народження, гнучка аналітика. Тут order-centric модель KeyCRM стає тісною, і ми беремо NetHunt — за гнучку обʼєктну модель під сегменти й Looker Studio BI. Саме за таким запитом ми впроваджували NetHunt у роздрібний бренд одягу й взуття з базою близько 23 000 клієнтів, де пріоритетом були реактивація й бонусна програма, а не маркетплейс-замовлення. Ключова інтеграція решти магазинів — логістика й фіскалізація. Нова Пошта, Укрпошта й Meest формують ТТН прямо з картки замовлення з масовою генерацією; оплати (LiqPay, WayForPay, Fondy, Monobank, NovaPay) і програмні РРО (Checkbox, Вчасно.Каса; Cashalot — через кастом) підключаються як частина впровадження. Понад це ми тримаємо фіскалізацію під контролем як практику: щоденний нотифікатор нефіскалізованих замовлень і щотижневий аудит налаштувань, бо саме розсинхрон джерел перетворюється на штрафи.
Окремо варто сказати про «швидко на Make». У KeyCRM немає нативного модуля Make чи Zapier, тож кожен no-code-сценарій фактично стає кастомною HTTP-інтеграцією, яку треба будувати й супроводжувати. Ми закладаємо це в кошторис чесно на старті, а не переглядаємо обсяг посеред проєкту — і там, де вбудованого товарного обліку не вистачає (серійні номери, партії, FIFO), питання теж не закривається словом «неможливо»: це можливо з доробкою через інтеграцію з 1С/BAS, а межу між системами ми проєктуємо на discovery. На міграціях переносимо великі каталоги — 5 000+ SKU — зі збереженням даних, тож перехід на нову систему не означає втрату історії товарів.