Should the new voice agent take customer orders, or should the team keep typing them?<\/p>\n
It is the wrong question, and it produces a poor answer in either direction, because it treats the input channel as the thing being decided. The question to ask comes one step later: once the customer has spoken, what happens to what the system heard?<\/p>\n
Voice demos are impressive, and the capability in them is real. The system handles an accent, survives an interruption, pulls a date out of a half-finished sentence, and answers before the person has finished thinking.<\/p>\n
What a demo rarely exposes is the downstream cost of a wrong capture, because nothing in it is being filed, relied on tomorrow, or disputed next month. The capture is judged in the moment it happens and then discarded.<\/p>\n
Production runs the opposite way round. The capture becomes a delivery address, a quantity, a promised date, a line the next person reads on a Tuesday morning. It gets judged later, by someone who was not in the conversation, usually at the point where something has already gone wrong.<\/p>\n
So recognition quality is not enough to buy on. A system can capture speech accurately and still be wrong for the task, while the same system, with the right confirmation step, may fit it well.<\/p>\n
Before captured speech becomes a record or triggers the next action, the system repeats back the consequential part and asks the person to confirm or correct it.<\/p>\n
It repeats the consequential part and no more. A read-back restates the quantity, the address, the date, or any other element whose error would carry a cost and change what happens next, and then it stops. Reading the whole utterance back can bury those fields inside material that does not need confirmation.<\/p>\n
The read-back is a mechanism and does not itself become a record. What survives it is the confirmed capture; the read-back’s only job is to put a person in front of what the system heard while it is still cheap to fix.<\/p>\n
What follows is an anonymised composite. No real customer, no real reference, and the figures in it exist to show a decision, not to report a result.<\/p>\n
A parts distributor takes reorders by phone. Three things happen inside a single call: the customer says which product, says how many, and asks when it will arrive. Those look like one conversation, and their consequences are different.<\/p>\n
The product and the quantity become a picking instruction that a warehouse acts on overnight. Wrong here means the wrong pallet on a truck at 6am, a customer without stock, and a return to arrange. The mistake surfaces only after it has cost something. That capture needs confirming before it lands.<\/p>\n
The delivery question is answered back to the customer while they are still on the line. If the answer does not match what the customer meant, they are still present to challenge it and the exchange can be corrected before the call ends.<\/p>\n
For that question there is little distance between the possible error and the person able to correct it, so a separate read-back may add little. Both tasks ran in one call, on one channel, through one voice system, and they have different requirements. The channel was identical in both, and the consequence was different.<\/p>\n
Ask them in order, of the task and not of the channel.<\/p>\n
First, what is being captured. Second, what it becomes: is it consumed in the moment and gone, or does it turn into a record someone will later rely on, quote or dispute, or does it trigger an action that runs unwatched? Third, given that answer, what confirmation belongs in front of it.<\/p>\n
Voice can still feed a durable record, provided the raw voice capture does not become authoritative without a confirmation matched to what the capture will do. That match is a real design decision with a range: a one-line read-back for a quantity; a read-back plus a written copy sent to the customer for a delivery address; a person on the line before anything gets cancelled.<\/p>\n
There is another boundary before confirmation: whether the information should be captured at all. Payment details, credentials, sensitive personal information, or anything the business has no reason to retain should stay out of a transcript, however easy voice makes the capture. The first design decision can be to exclude or discard a field, and only then to confirm one.<\/p>\n
And some captures should escalate instead of landing. If a correction changes the nature of the request, the customer disputes what was recorded, or the next action carries consequences the automated path is not authorised to take, the correct output is a handoff to a person, and the system should not attempt the transcription again.<\/p>\n
Read the other way, the same three questions describe plenty of typed workflows that need the same treatment. A form that submits straight into a system with no read-back has the identical gap, and it is easier to miss there, because the customer typed it themselves and everyone assumes that settles the matter.<\/p>\n
Most of these conversations move. A call becomes a messaging thread, an email, or a colleague picking it up later.<\/p>\n
Carry forward what the customer confirmed, and leave behind the raw transcript that happened to capture it. A transcript holds everything that was said, including the false start, the correction, and the version the system misheard before it was fixed. Whoever reads it next has to work out which version was final, which is the same uncertainty the read-back was installed to remove, arriving one channel later.<\/p>\n
Take one task your team currently handles by voice and put the three questions to it. If the second answer is that something durable or consequential comes out of the conversation, decide what must be confirmed before that output becomes authoritative. You may find that the problem was the step missing after capture, and that it was never voice.<\/p>\n
Before you bolt on another tool, it is worth knowing whether your business runs on systems or on you. I put together a free 2-minute assessment that gives you a straight read on exactly that, and the first thing to fix. Take the free assessment<\/a>.<\/p>\n