Why KeyCRM (and sometimes NetHunt) for an online store
Most e-commerce pain is not a “bad sales pipeline” but a desync between channels. Orders come in from Rozetka, Prom, Epicentr, OLX, Etsy, the website and messengers, each channel has its own dashboard, the same customer is duplicated under different contacts, and the manager merges everything together by hand. KeyCRM removes this at the data-model level: the system’s central object is the order, not the deal as in a B2B CRM. All channels become sources of a single order flow in one processing queue, with one status flow and a lower total cost of ownership. That is why for retail e-commerce we recommend KeyCRM by default, rather than a general CRM onto which marketplaces have to be bolted on the side.
The exception is when the center of gravity of the business is not order processing but working with the base: attribute-based segmentation, reactivation of dormant customers, bonuses and birthdays, flexible analytics. Here KeyCRM’s order-centric model becomes cramped, and we take NetHunt — for its flexible object model for segments and Looker Studio BI. This is exactly the request for which we implemented NetHunt at a retail clothing and footwear brand with a base of around 23,000 customers, where the priorities were reactivation and a bonus program, not marketplace orders. The key integration for every other store is logistics and fiscalization. Nova Poshta, Ukrposhta and Meest generate the waybill straight from the order record with bulk generation; payments (LiqPay, WayForPay, Fondy, Monobank, NovaPay) and software PRROs (Checkbox, Vchasno.Kasa; Cashalot — via custom work) are connected as part of the implementation. Beyond that, we keep fiscalization under control as a practice: a daily notifier for non-fiscalized orders and a weekly settings audit, because it is exactly the desync between sources that turns into fines.
A word on “quickly on Make” is worth saying separately. KeyCRM has no native Make or Zapier module, so every no-code scenario effectively becomes a custom HTTP integration that has to be built and maintained. We put this into the estimate honestly at the start, rather than revising the scope mid-project — and where the built-in inventory accounting falls short (serial numbers, batches, FIFO), the question is not closed with the word “impossible” either: it is possible, with custom work, through an integration with 1C/BAS, and we design the boundary between systems during discovery. On migrations we move large catalogs — 5,000+ SKU — with data preserved, so switching to a new system does not mean losing product history.