Why our automations refuse to invent data

Automation is very good at producing an output every time. In customer-facing work that is not always what you want. An order update with an invented delivery date, or a supplier email that quotes the wrong reference, costs more than the time the automation saved.

On a recent order-management build for a specialist online retailer, we set one rule that shaped everything else: the system is never allowed to make up a fact to complete a message.

Hard fields and soft fields

The practical way to apply that rule is to classify every piece of data a message depends on.

• Hard fields are facts the message cannot exist without. A shipping notification needs a real tracking number. If it is missing, the draft is held and a person is told why.
• Soft fields are helpful but optional. An estimated delivery date improves an update, but if it is unknown, the sentence that carries it is simply left out rather than filled with a guess.

Our first version treated everything as hard, and it held almost every draft. Moving the right fields to soft made the system useful without making it dishonest.

Respect the other side's conventions

Suppliers had their own order numbers and had asked, in writing, to be contacted using only those references and without repeating orders they had already received. So supplier emails use the supplier's reference, the customer's name and country, and nothing that has already been sent. Automation that ignores these preferences creates work for the people it is supposed to help.

Protect history when you switch the system on

When an automation goes live on top of existing records, old data can trigger new messages. Filling in a missing tracking number on a months-old order should not email that customer as if the order had just shipped. A simple age threshold on drafts prevents the whole back catalogue from firing at once.

Test with data shaped like the real thing

Most of these rules were discovered by running the workflow against realistic records rather than tidy examples: blank cells, merged columns, two suppliers on one order. We keep those cases as automated tests, so a later change cannot quietly undo a rule that protects customers.

If you use AI to draft messages, the same principle applies. The model should only write from facts it was given, and the system should check those facts exist before anything is sent.

If your team spends its time correcting automated messages, the fix is usually in how the workflow treats missing data. See how we build automation, or start a project and we will look at yours.