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

To automate WhatsApp order processing, keep the order record outside the conversation: one record per order, with a named stage, the items, the due date and the payment status, and a link back to the thread. Messaging then populates the record instead of acting as the record.

Taking orders in a messaging thread works until there are forty of them. When someone asks which orders are unpaid, the only way to answer is to open forty conversations, and two of them contradict themselves because the customer changed their mind. A thread is a transcript of how an order was agreed, and a poor record of what the order is.

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 of order automation
• What to build first
• Frequently asked questions

Key takeaways

• Build the order record first, because a messaging thread cannot be queried and holds every version of an order with no marker for the current one.
• Give every order a named stage, and move it between stages only when something specific happens, such as a payment arriving.
• Acknowledge every incoming order immediately, because silence is what causes duplicate orders.
• Send one confirmation message that restates the whole order, and send it again in full after any change.
• Review the orders grouped by stage every week, oldest first, to find the ones stuck between stages.

The thread is not the order

A record needs three properties 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 must outlive both.

So the order record is the thing to build, and the messaging is how it gets populated. Businesses that reverse this end up with a capable conversation and no clear view of what they have sold.

What the order record holds

The order record holds seven fields, and most are 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.

Teams most often leave out the link to the conversation. The link keeps the record clean while letting you check what was actually said.

Stages, and why naming them matters

An order without a stage cannot be acted on, because every question about it requires reading the thread.

Stages differ by trade, and having them matters more than their names. Most order businesses use stages like these: enquired, confirmed, paid or deposit taken, in production, ready, collected or delivered.

Two rules make stages useful.

Something specific moves each transition, such as a payment arriving or a person marking the item made. A stage that changes because somebody felt it had changed 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 instead of time removes a whole category of embarrassing errors.

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

The duplicate order

Duplicate orders hurt most and get the least design attention.

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 on whether anything notices.

Three defences work.

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 sometimes 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 3,000+ integrations, and each 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, because silence produces the duplicates that cost you.

You describe the outcome; Cody builds it, connects it, and deploys it. The Free plan covers light use. Pro costs $39 per month ($33 per month billed yearly) and Business costs $100 per month (CodeWords pricing page, 2026); details are on the pricing page.

Partial orders, which are most of them

Most real orders arrive in pieces, so the system must handle partial orders. Somebody says what they want, goes quiet, comes back with the date, then asks about a variation, then confirms.

Handling this requires the record to exist in an incomplete state. Systems built around a single form submission cannot do this.

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 should not sit in the list as if it were.

Test the record: if a customer sends one word on Friday about an order started on Tuesday, can the system say what the 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

Stock can run out between a customer asking for an item and confirming it, so two customers can be told the same last item is available.

Whether this matters depends on your trade. A bakery with limited Saturday capacity has a real problem, and a business with plentiful stock does not.

Where it matters, use the same pattern as for appointments: hold the item briefly when you offer it, release the hold if nothing comes back, and confirm on payment or acceptance. Keep the hold short, because a long hold hides capacity you could have sold.

Also check availability again at confirmation instead of trusting the check from the start of the conversation. Overselling happens in the gap between those two moments.

The confirmation that prevents arguments

Send one confirmation message when the order is confirmed, restating everything.

The message lists the items with quantities, the date and time, the total and what has been paid, where and how the order is collected or delivered, anything non-standard that was agreed, and how to change the order, including the deadline.

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

This message prevents nearly every collection-day disagreement and costs nothing.

The weekly view

A weekly review of orders by stage takes about ten minutes and delivers most of the value of having stages.

Group everything by stage, oldest first, and ask of each group whether anything is stuck. Look for enquiries with no reply, confirmed orders with no deposit, orders in production past their ready date, and items marked ready that nobody has collected.

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

Run the review on the same day each week. The list is long the first time and short once the habit is in place.

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, because money goes missing in orders sitting between stages.

Limits of order automation

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

Customers do not use your vocabulary, so the record must translate their wording instead of storing what they typed.

Duplicates cannot be eliminated. You can only make them visible quickly.

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

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

What to build first

Build the order record first, with a stage on it, even if it is a spreadsheet and the messages are still typed by hand. Every automation in this guide depends on that record.

Two habits matter most. Acknowledge every order immediately, because silence causes duplicates and duplicates are the expensive failure in this trade. And restate the whole order at every confirmation, because the costly disagreements are about what the order was.

Frequently asked questions

Why is a messaging thread a bad order record?

A thread cannot be queried, and it contains every version of the order, including the wrong ones, with no marker for which is current. It also lives in an account and on a device instead of in your business, so the order disappears if either changes.

What should the order record contain?

The record holds who ordered, what they ordered itemised in your own vocabulary, when it is due and when it was placed, the stage, what has been paid, anything non-standard that was agreed, and a link back to the conversation for context.

Why do order stages matter?

Without a stage, every question about an order requires reading the thread. With a stage, useful views such as overdue, unpaid and stuck orders appear automatically. Stages also let you tie outbound messages to the order's state instead of to the calendar.

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 instead of on sender alone, and show a possible duplicate for a person to check instead of merging it silently.

How should partial orders be handled?

Create the record at first contact in an incomplete state, track what is missing as a list, and ask only for the gaps when the customer returns. Expire stale incomplete orders after a set period so they do not sit in the list as if they were live.

What about stock running out mid-conversation?

Where capacity is limited, hold the item briefly when you offer it, release the hold if nothing comes back, and check availability again at confirmation. The second check matters because the first check can be hours old by the time the customer says yes.

What should a confirmation message say?

State the items with quantities, the date and time, the total and what has been paid, the collection or delivery arrangements, anything non-standard that was agreed, and how to change the order and until when. Send it as a message in the thread, not only as an attachment.

Should the confirmation repeat the whole order after a change?

Yes, restate the whole order after every change. A message that says only what changed is ambiguous weeks later, and collection-day disagreements are almost always about what the order was, not what changed. A full restatement settles the question for both sides.

What must reach a person?

A person must handle 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. Saying no, issuing refunds and resolving disputes all need human judgement.

Where do orders quietly go missing?

Orders go missing between stages: enquiries with no reply, confirmed orders with no deposit, and finished items nobody has been told about. None of these progresses on its own, and none is visible unless the record has a stage and someone reviews the list.

How often should the order list be reviewed?

Review the list weekly, on the same day, grouped by stage with the oldest orders first. The review takes about ten minutes once it is a habit. The first review will show a longer list of stuck orders than you expect, and the list shortens afterwards.

Related reading

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