The business is a chain of transcriptions
Most mid-sized businesses still run their commercial commitments through a set of tools that were never designed to hold them. A customer sends an order in a messaging application. Someone copies the lines into a spreadsheet. A second person copies the spreadsheet into the order system. A third reads it, notices a quantity that does not look right, and asks a fourth to check. Nobody in this chain is doing anything the organisation hired them to do. They are transccribing.
The important thing about this chain is that each step looks like work rather than like failure. The spreadsheet is filled in properly. The handover happens on time. The only symptom is that the business takes longer than it should, and that errors appear at a rate everyone has become accustomed to. Because each individual step is defensible, the aggregate is invisible.
Where the money actually goes
Four cost lines appear when you look at fragmented information closely, and none of them is labelled as a cost of fragmentation in the accounts.
- Rework. The effort spent correcting, re-entering, chasing and re-communicating information that already existed somewhere else. This is usually the largest line and the least visible, because the corrected version is what appears in the system.
- Error cost. Not the cost of making a mistake, which is a normal operating condition, but the cost of the mistakes that survive: wrong shipments, duplicate invoices, missed commitments, incorrect claims, and the compensation paid to the other party for them.
- Delay cost. The interval between a customer committing and the business being able to act on it. This cost is almost never booked anywhere, which is precisely why it is usually the argument that finally moves a decision.
- Capacity cost. The working time of experienced people spent performing transcription, so that some of their attention is available for the judgement the business actually hired them for.
A useful exercise is to pick one process — order intake, quote preparation, purchase requisition, customer complaint handling — and count the number of times the same piece of information is physically re-entered between the customer's first contact and the transaction being recorded. The number is usually higher than anyone in the room expects, and it is a number rather than an opinion, which makes it a usable starting point.
Why this is not a technology problem
The instinct is to reach for automation, and the instinct is not wrong, but it is incomplete. A workflow tool that pulls information out of a messaging application and writes it into an order system addresses the transcription. It does not address the reason the transcription exists.
The reason is usually that the organisation has never defined what an order is, in a form that any system could accept. There is no shared specification of the fields, no rule about which quantity field is authoritative, no decision about what happens when a message contains two different delivery dates, and no agreed position on when a conversation becomes a commitment. The people doing the transcription are, in effect, supplying that missing specification informally and inconsistently, in whatever way the customer happened to write.
What the first intervention should be
The order of work matters more than the choice of tool. Three steps come before any software is selected.
- Observe the actual path. Sit with the people doing the work and record where the information comes from, what they check, what they have to interpret, and which messages they treat as a commitment. This is the method described in mapping a process before you build the agent.
- Write down what an order is. Define the fields, their meanings, which system is authoritative for each one, and what the business does with the cases that do not fit. This is a business decision, not a data project, and it belongs to the commercial owner of the process.
- Establish a baseline. Measure how many transactions currently complete without intervention, how long they take, and how many are corrected. Without this number, no later claim of improvement can be checked by anyone but the team that did the work.
Only after these three steps does it make sense to ask what the technology should do. At that point the question is much sharper, and the answer is often narrower than expected: extract this structured set of fields from these sources, present them for confirmation, and write the result to this system, with the original message retained as evidence.
Where AI fits, and where it does not
The genuine difficulty in this chain is interpretation. Customers write in prose, in whatever language and format they feel like on the day, and they use abbreviations that only the account manager understands. A rigid form rejects the order; a rigid parser misreads it. This is the part where a language model earns its place, because it handles variation that a fixed set of rules cannot.
The parts where AI should not be relied on are the consequential ones. Whether a commitment is binding, whether a price is acceptable, whether an exception should be granted, whether the shipment has degraded — these are judgements with an owner, and they should stay with a person who can be accountable for them. The distinction to hold is between understanding what was said, which is what language models are good at, and deciding what to do about it, which is what a business has to own.
The measurement that settles the argument
Almost every executive discussion about this kind of work stalls because both sides are making claims that cannot be checked. The technology side describes capability. The finance side asks for a return. Neither is speaking in a form the other can verify.
There is a simpler exchange, and it is available in almost every organisation within a fortnight: a transaction count, a correction rate, a cycle time, and a rework hour count for one process, measured before anything changes. Those four numbers are unglamorous, they are hard to argue with, and they are the same numbers the business will use later to decide whether the change was worth making. The method of establishing and defending such a baseline is set out in calculating the value of enterprise AI.
The real decision in front of the executive
The decision is not whether to adopt AI. For a business running on transcription, some form of intelligent capture will arrive regardless, either built by a vendor or assembled by the team. The decision is whether that capability is commissioned deliberately, against a defined process and a measured baseline, or absorbed accidentally as another layer over the existing chain.
The second option is cheaper this quarter and considerably more expensive over the following year, because the ambiguity is not removed — it is simply distributed across more tools, each holding a different partial version of the truth, none of them authoritative. The cost of that arrangement does not appear on any line of the profit and loss account, which is exactly why it is allowed to continue.