CRM for an Online Store: Managing Customers and Orders

While a store handles 5-10 orders a day, a spreadsheet and the manager's memory are enough. At 50 orders you start losing leads, calling the same customer twice and losing any sense of where the revenue comes from. A CRM for an online store is not «one more app», it is the place where orders, purchase history and all customer communication live.

Order tracking: statuses, owners and deadlines

The backbone of any online store CRM is the order status pipeline. A minimal working set looks like this: new, confirmed, picking, shipped, delivered, paid, returned, cancelled. Every status needs an owner and a time limit. If an order sits in «new» for more than two hours, the system should flag it or hand it to another manager.

The second must-have is a change history. You need to see who moved an order to cancelled and when, what comment they left and whether the customer was called. Without it, resolving disputes turns into arguing. Change logs also reveal the real bottlenecks: it often turns out that the gap between payment and shipping is not the 4 hours everyone assumed but a day and a half.

Partial orders and stock reservation deserve separate thought. If one of three items is out of stock, the manager needs a convenient way to split the order rather than rewrite it by hand. Details like this save a few minutes per order, and at 1000 orders a month that adds up to dozens of working hours.

Customer base: one card instead of five sources

A typical store problem: a customer writes on Instagram, then calls, then places an order on the site. As a result there are three separate records in the system and no manager sees the full picture. The customer base has to merge these contacts by phone or email into a single card with all orders, requests and comments.

It helps to keep more than contacts in the customer card: total spend, number of orders, last purchase date, average order value, return rate. The manager sees this before starting the conversation and acts accordingly. A customer with ten orders and zero returns can get a shipment without prepayment; a new one from a region with frequent unclaimed parcels is better offered payment upfront.

Segmentation is built on top of these fields, and that is where repeat sales begin. The working segments are simple: bought once more than 90 days ago, bought three or more times, purchased a specific category, left an order unpaid. Each segment needs its own scenario: a reminder about a consumable that should have run out by now, or early access to a new collection. Bringing back an existing buyer usually costs several times less than acquiring a new one through ads, and a segmented base is the only way to do it systematically.

Sales analytics: average check, repeat purchases, top products

The minimum set of reports that actually drives decisions: average check by month, share of repeat customers, top 20 products by revenue and by margin, parcel redemption rate, conversion from new order to paid. The last two numbers are critical for the Ukrainian market: the difference between 70 and 90 percent redemption changes profitability more than any ad campaign.

It matters to break revenue down by channel and by manager. It often turns out that the channel with the most orders has the lowest average check and the most returns, while a supposedly «weak» channel brings in most of the margin. Without this kind of sales analytics the budget is allocated blindly.

Reports must be available to the owner without asking a developer. A handful of self-updating dashboards plus an export to a spreadsheet for deeper analysis is enough. If getting a number requires messaging someone in chat, nobody will use it.

Automatic notifications for customers and the team

Automatic notifications take the dullest part of the job off the managers. The customer gets order confirmation, a tracking number, a payment reminder and a message when the parcel arrives at the pickup point. This works best in Telegram and Viber: delivery is cheaper than SMS and open rates are higher. A single reminder the day before storage expires noticeably raises the redemption rate.

Internal notifications matter just as much. The team chat gets a signal about a high-value order, about a request nobody picked up within 30 minutes, about a product whose stock dropped below threshold. These messages must be targeted: if there are too many, the team stops reacting within a week.

Technically, every notification should be built on templates with order data substituted in, not written by hand in the code. Then a content manager can change the wording without a developer. Always provide a fallback channel: if the customer has no Telegram, the message goes out by SMS or email. One more detail people often forget is quiet hours. A message sent at two in the morning annoys more than it helps, so the notification queue is better held until morning.

Automating repeat sales and winning customers back

The most expensive customer is the one you brought in through ads once and never brought back. A CRM for an online store closes this gap with automated scenarios. Abandoned cart: the person added an item but did not pay - an hour later a reminder goes out, a day later an offer with a small discount. Repeat purchase of consumables: if a customer bought a month's worth of dog food, on day 25 the system sends a reminder to order more on its own. This is not «mailouts for the sake of mailouts» but precise triggers tied to the buyer's real behaviour.

The second layer is reactivating «sleeping» customers. The system notices on its own that a regular buyer has not ordered for 60-90 days and launches a chain: first a useful message, then a personal offer in their favourite category. All of this runs on segments from the customer base and needs no manual work from a manager. The key rule is moderation: overly frequent mailouts lead to unsubscribes faster than to sales, so the system controls the frequency and the reason automatically rather than leaving it to an operator's mood.

How much a CRM for an online store costs

The cost of a CRM is made up not of a «licence» but of three things: how many non-standard processes you have, how many integrations you need and how much data has to be migrated from the old system. A store with one warehouse, ordinary shipping and simple payments will cost noticeably less than a project with dropshipping from several suppliers, size grids and operations in two countries. That is why any honest estimate starts with a list of your processes and integrations, not with an abstract price «for a system».

Off-the-shelf CRMs have a low entry threshold but charge a monthly fee per user and often a surcharge for the modules you need, so costs grow together with the team. A custom system is more expensive upfront but has no monthly rent per seat and belongs entirely to you along with the data. A practical benchmark: if an off-the-shelf solution covers 80% of your scenarios without costly customization - take it; if there is a lot of specificity and the customization costs as much as half a custom system - it is cheaper to build your own. At Devlly we work out exactly this fork honestly and build the system for a specific store.

Choosing and setting up: off-the-shelf or a custom system

Off-the-shelf CRMs cover the standard scenario quickly and cost predictably. They fit if your processes resemble those of most stores: one warehouse, ordinary shipping, a simple payment scheme. Problems start where there is specificity: made-to-order production, dropshipping from several suppliers, goods with size grids or serial numbers, operating in two countries with different rules.

Before choosing, it helps to list the mandatory integrations: website or marketplace, delivery services, payment provider, accounting, messengers, inventory. If a needed integration has no ready module in the off-the-shelf CRM, you will pay for customization anyway, often more than your own logic would have cost from the start. Check separately whether you can export your customer and order data in a readable format: if the data is locked inside the service, any future migration will cost months of work.

Setting up any system is best started with one process, not all of them at once. First move order tracking and the customer base over, let the team work with it for two or three weeks, collect feedback, and only then add analytics, notifications and segmentation. At Devlly we build such systems for a specific store: we map the real processes, ship a working first version and grow it around what already delivers results.