Where a WhatsApp order flow breaks, and what to put in its place

The order arrives at eight in the morning: one kilogramme of dates, delivered to Bab Ezzouar, cash on delivery. By six in the evening it sits forty messages up the thread, behind a price question, a photo of a receipt, and a customer asking whether the parcel left. Someone packs it late, or does not pack it at all, and the first sign of the problem is a phone call two days later.

Nothing in that story is a software failure. A message thread was asked to do the job of a record.

A conversation is not a ledger

WhatsApp stores messages in the order they were sent. A shop needs four things a thread cannot give it: a list of open orders, a status that only moves forward, a person accountable for each one, and a total that includes delivery. Everything else — the search, the follow-up, the month's numbers — is built on those four.

The usual breaking point is between twenty and thirty orders a day. Below that, one person can hold the day in their head. Above it, the shop loses orders not because anyone is careless, but because there are more open loops than one head can track. It does not degrade gradually; it fails on one evening when two parcels go out wrong and nobody can say which.

The four failures that cost money

1. The order that never gets packed. The message exists, so the sale is real to the customer, but no one owns it. The fix is not a reminder — it is a status that stays pending until a person marks it otherwise, visible to everyone at the start of the shift.

2. The order confirmed twice. Two people read the same thread, both reply, and the customer receives two promises. Often it ends with a second parcel and a refund conversation. One order, one row, one person allowed to confirm.

3. The address that is a sentence. "Same place as last time" is a reasonable thing to say to a shop you buy from every month, and a terrible thing to store. The address has to be attached to the customer's record, not left in the history for someone to scroll back to.

4. The parcel that comes back. Cash on delivery means the shop carries the risk of a customer who changes their mind at the door. The courier still charges for the trip, and the return leg is often charged too, so a refused parcel can cost more than the margin on two delivered ones. Worse, nothing in the thread remembers that this number refused twice before.

Why the spreadsheet stops being enough

A shared spreadsheet is the right first step and the wrong resting place. It fails mechanically: the file is the concurrency model. Two people editing on two phones produce one saved version, and the other person's row disappears without a warning. Add a third editor and the shop stops trusting the file.

Question	WhatsApp thread	Shared spreadsheet	Order record
Where is order 412?	scroll and guess	find the row, if you remember the name	search by phone
Who confirmed it?	maybe visible	last editor wins	stamped with a name
Delivery price at entry	looked up or guessed	typed by hand	read from the rate table
Two people, two phones	duplicate replies	last save overwrites	one row, one change
Refused parcels per number	memory	a list someone maintains	counted automatically
Works with a weak signal	yes	sometimes	depends on the build

The minimum order record

Before choosing software, write down what one order must contain. In a shop shipping across wilayas, this is the floor:

• the customer's phone number, used as the key;
• name, wilaya, commune, and an address in words;
• items with quantity and unit price;
• the delivery price, taken from a table rather than typed;
• the total, and whether it is cash on delivery or already paid;
• one status: pending, confirmed, packed, dispatched, delivered, refused, cancelled;
• who entered it, and when;
• a note field for the things that do not fit anywhere else.

The phone number as the key matters more than it looks. In this market a customer is a phone number, ordering from the same WhatsApp account for years while the address changes — and that is what makes a refusal history possible at all.

Delivery price is a lookup, not a judgement

Shipping from Laghouat to Tamanrasset and to Djelfa are different prices, different enough to erase the margin on a small order. Add weight bands, a volumetric rule for bulky parcels, and the return fee, and "what does delivery cost to this wilaya" stops being a question a person should answer from memory at eleven at night.

The fix is a rate table with all 58 wilayas and the courier's bands, entered once, editable in one screen. When a tariff changes, one table changes instead of forty quotes. It is the least interesting thing to build and the first the team notices: it removes the wait while someone checks.

Confirm before dispatch, and keep score

A short call before the parcel leaves — is the address right, will you be there, is the amount correct — costs a minute and prevents a share of the returns. The call is the cheapest quality check in the flow, because it happens while the parcel is still in the shop.

The second half is memory. Every refusal should be recorded against the phone number, so the shop can see that this customer has refused twice and can ask for a deposit or ask them to collect from the agency. The point is not punishment but to stop treating a repeated, predictable loss as bad luck.

What to build, in what order

Order matters: building all of it at once is how these projects die.

1. The order record and its statuses, with an entry screen usable one-handed on a phone.
2. The rate table, so the price is never typed.
3. The confirmation and dispatch messages, sent from the record rather than typed by hand.
4. The refusal log, so repeated losses become visible before the next dispatch.
5. The reports: what sold, what came back, which wilaya is losing money.

Steps one and two are the whole system for most shops; the rest can wait until it is in daily use.

Where this advice stops

Under ten orders a day, with one person packing and answering, WhatsApp and a notebook are cheaper than any tool, and the discipline of a written list is worth more than software. If the team will not enter orders, no amount of screens will fix it: name one person as order entry, and let everyone else send the messages to that person.

An order record also does not fix a product problem, a courier who does not call ahead, or a customer who cannot be reached. And if the shop sells over a counter as well as by delivery, the order record has to draw on the same stock as the till — otherwise you will sell the last item twice. That is a stock question, not a form.

We build the order-and-dispatch side of this: the record, the statuses, the rate table, and the small reports that tell a shop which wilaya is costing it money. It is not a large system, and it should not be.