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.

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.