Order processing: the record has to be somewhere other than the thread

Taking orders in a messaging thread works beautifully until there are forty of them. Then somebody asks which orders are unpaid, and the only way to answer is to open forty conversations and read each one, and two of them contradict themselves because the customer changed their mind halfway down.

The thread is a transcript of how an order was agreed. It is a poor record of what the order is. Everything that makes order automation work follows from separating those two things, and almost everything that goes wrong follows from not having done it.

What we'll cover

• The thread is not the order
• What the order record holds
• Stages, and why naming them matters
• The duplicate order
• Building it with CodeWords
• Partial orders, which are most of them
• Stock, and the gap between asking and paying
• The confirmation that prevents arguments
• The weekly view
• What has to reach a person
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

The thread is not the order

Three properties a record needs that a conversation does not have.

It can be queried. "Which orders are due Friday and unpaid?" is a question about a list. A thread cannot answer it and neither can forty threads.

It has one current version. A conversation contains every version of the order including the wrong ones, in sequence, with no marker saying which is current.

It survives the channel. Threads live in accounts and on devices. An order you need for your accounts has to outlive both.

So the order record is the thing to build, and the messaging is how it gets populated. Businesses that get this the wrong way round end up with a very capable conversation and no idea what they have sold.

What the order record holds

Short, and most of it is obvious once written down.

Who, in a form that survives a phone number changing.

What, itemised, in your own vocabulary rather than the customer's phrasing.

When it is due, and when it was placed.

What stage it is at, which is the field everything else depends on.

What has been paid and what is outstanding.

Anything agreed that is not standard, including changes, with dates.

A link back to the conversation, so the context is retrievable without living there.

That last one is the piece people leave out, and it is what lets you keep the record clean while still being able to answer what was actually said.

Stages, and why naming them matters

An order without a stage is an order nobody can act on, because every question about it requires reading.

The stages differ by trade and the naming matters less than having them. For most order businesses something like: enquired, confirmed, paid or deposit taken, in production, ready, collected or delivered.

Two rules make stages useful rather than decorative.

Something specific moves each transition. A payment arriving, a person marking it made. If a stage changes because somebody felt it had, it will be wrong.

The stage decides what messages are allowed. A reminder to collect should be impossible on an order that is not ready. Tying outbound messages to stage rather than to time removes an entire category of embarrassment.

Once stages exist, the useful views appear for free: what is overdue, what is unpaid, what is stuck.

The duplicate order

The failure that hurts most and gets designed for least.

A customer sends their order. Nothing comes back quickly. They send it again. Now there are two, or there is one and a half, and whether that becomes two cakes depends entirely on whether anything noticed.

Three defences.

Acknowledge immediately. Most duplicates are caused by silence. A fast confirmation removes the reason to resend.

Match on content, not just on sender. The same items, the same date, from the same person, within a short window, is one order until somebody says otherwise.

Make an accidental second order visible rather than silently merging it. Ask. Customers do occasionally want two.

The same logic applies to your own outbound side: if a confirmation can be sent twice because a process ran twice, customers will believe they have two orders.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: what an order record holds, the stages, what moves an order between them, and what has to reach you.
3. Authorize the connections to wherever orders are recorded, your payment provider, and your WhatsApp Business Platform account.
4. Describe the exceptions: a possible duplicate, an incomplete order somebody has returned to, something you cannot fulfil, anything touching money.
5. Acknowledge every incoming order immediately, since silence is what produces the duplicates that cost you.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Partial orders, which are most of them

Real orders arrive in pieces. Somebody says what they want, goes quiet, comes back with the date, then asks about a variation, then confirms.

Handling that requires the record to exist in an incomplete state, which sounds obvious and is exactly what implementations built around a single submission cannot do.

Create the record at first contact, incomplete, with what you have.

Track what is missing as a list rather than a state of the conversation.

Ask for what is missing when they return, not for everything.

Have a rule for stale incomplete orders. A half-order from three weeks ago is not live, and it should not sit in the list pretending to be.

A useful test: if a customer sends one word on Friday about something started on Tuesday, can the system say what that word refers to. If the only answer is reading the thread, the record is not doing its job.

Stock, and the gap between asking and paying

Between somebody asking for something and confirming it, availability can change. Two customers can be told the same last item is available.

Whether that matters depends on your trade. A bakery with capacity constraints on a Saturday has a real problem; a business with plentiful stock does not.

Where it matters, the pattern is the same as for appointments: hold it briefly at the point of offering, release the hold if nothing comes back, confirm properly on payment or acceptance. Keep the hold short, since a long one hides capacity you could have sold.

And check availability again at confirmation rather than trusting the check from the start of the conversation. The gap between those two moments is where the overselling happens.

The confirmation that prevents arguments

One message, sent when the order is confirmed, restating everything.

Items with quantities, the date and time, the total and what has been paid, where and how it is collected or delivered, anything non-standard that was agreed, and how to change it including until when.

Send it as a message rather than only as an attachment, so it is readable in the thread without opening anything, and send it again if the order changes. Restate the whole order each time rather than just the change, because "changed to six" is ambiguous a fortnight later and a full restatement is not.

This message is where nearly every collection-day disagreement is prevented, and it costs nothing.

The weekly view

Once stages exist, one habit extracts most of the value from them, and it takes about ten minutes.

Look at everything grouped by stage, oldest first, and ask of each group whether anything is stuck. Enquiries with no reply. Confirmed orders with no deposit. Orders sitting in production past when they should have been ready. Things marked ready that nobody has collected.

Each of those is an order that will not progress on its own and that nobody is currently thinking about. In most small order businesses the money lost is not in the orders that went wrong loudly, it is in these: a quote nobody followed up, a deposit nobody chased, a finished item nobody mentioned.

Do it on the same day each week. The list is short once you are in the habit, and it is long the first time, which is the point.

What has to reach a person

Anything you cannot fulfil. Capacity, stock, a date you cannot make. Saying no is a person's job.

Anything about money beyond taking a stated payment. Discounts, refunds, disputes.

Anything unusual in the request, including requirements you do not normally handle.

A complaint, immediately and with no automated acknowledgement.

Anything where the record and the customer disagree. That conversation needs somebody who can look at both.

Making it survive

The record is the source of truth, never the thread.

Check the stage before any outbound message.

Deduplicate on content within a short window.

Expire stale incomplete orders rather than leaving them in the list.

Review the stuck list weekly, since orders sitting between stages are where money quietly goes missing.

Limits worth knowing about

Automation does not add capacity, and an order system that takes more than you can make is worse than a slower one.

Customers will not use your vocabulary, so the record has to translate rather than store what they typed.

Duplicates cannot be eliminated, only made visible quickly.

A messaging platform is not an order system, whatever it can export.

The record is only as good as its stages, and stages that change because somebody felt they should will be wrong.

What to build first

The order record, with a stage on it, even if it is a spreadsheet and the messages are still typed by hand. Every automation here is a function of that record, and almost none of them work without it.

Two habits make the difference. Acknowledge every order immediately, because silence is what causes duplicates and duplicates are the expensive failure in this trade. And restate the whole order at every confirmation, since the disagreements that cost you are always about what the order was.

Frequently asked questions

Why is a messaging thread a bad order record?

It cannot be queried, it contains every version of the order including the wrong ones with no marker for which is current, and it lives in an account and on a device rather than in your business.

What should the order record contain?

Who, what itemised in your own vocabulary, when it is due and when it was placed, the stage, what has been paid, anything non-standard agreed, and a link back to the conversation.

Why do order stages matter?

Without a stage, every question about an order requires reading it. With one, the useful views appear for free, and outbound messages can be tied to stage rather than to time.

How do duplicate orders happen?

A customer sends an order, hears nothing, and sends it again. Acknowledge immediately, match on content within a short window rather than on sender alone, and surface a possible duplicate rather than merging silently.

How should partial orders be handled?

Create the record at first contact in an incomplete state, track what is missing as a list, ask only for the gaps when the customer returns, and expire stale incomplete orders.

What about stock running out mid-conversation?

Where capacity is genuinely constrained, hold briefly at the point of offering, release if nothing comes back, and check availability again at confirmation rather than trusting the earlier check.

What should a confirmation message say?

Items with quantities, date and time, total and what has been paid, collection or delivery arrangements, anything non-standard agreed, and how to change it and until when.

Should the confirmation repeat the whole order after a change?

Yes. A message saying only what changed is ambiguous weeks later, and collection-day disagreements are almost always about what the order was rather than what changed.

What must reach a person?

Anything you cannot fulfil, anything about money beyond taking a stated payment, unusual requirements, complaints, and any case where the record and the customer disagree.

Where do orders quietly go missing?

Between stages. Enquiries with no reply, confirmed orders with no deposit, finished items nobody has been told about. None of these progresses on its own and none is visible without a stage on the record.

How often should the order list be reviewed?

Weekly, on the same day, grouped by stage with the oldest first. It takes about ten minutes once it is a habit, and the first time you do it the list will be considerably longer than expected.

Related reading

• The cutoff on changes
• Keeping a price list true
• The edge cases that actually matter