What are the six outcomes of an automated order-confirmation call?

Two outcomes is not enough, and ten is too many

The tempting design is a boolean. The customer confirmed, or they did not. Ship or do not ship.

It falls apart on the first real call, because "did not confirm" hides at least four completely different situations, each of which leads to different work for a different person. A customer who said no is finished business. A customer who never answered is unfinished business. A customer who wants a different size is a sale you still have. Collapsing them into one flag means a human has to re-open every non-confirmation and work out which kind it was — which is the job you were trying to remove.

The opposite mistake is a long taxonomy. Twenty outcome codes look thorough and then nobody agrees which one applies, so in practice three get used and the rest are noise.

Nishchit writes exactly one of six outcomes onto every call, and every one of them exists because it triggers a different next action.

CONFIRMED

The customer agreed to the order as it stands: these items, this amount payable at the door, this address. Nothing to change.

The bar here matters more than the label. A confirmation is only written when agreement was actually reached — not when the customer said something that could be read as agreement, and not when the line went quiet after the agent asked. A hesitant "hmm, acha" at the end of a call the customer clearly wanted to end is not consent to a delivery, and treating it as one is how an automated system quietly starts sending parcels to people who did not want them. If the agent is not certain, the outcome is an escalation or UNRESOLVED instead. Never a confirmation.

Action: the order is ready to pack.

CANCELLED

The customer said no. They no longer want the parcel, or they never ordered it.

This is a good outcome. It is worth saying that plainly, because a dashboard that counts cancellations as failures teaches you to avoid finding them. A cancellation caught before dispatch costs you a phone call. The same cancellation discovered by a rider at the gate costs you both delivery legs, the packaging, and days of stock sitting in a van — which is the whole argument for confirming before you dispatch.

Action: release the stock, close the order.

MODIFIED

The customer still wants to buy, but not exactly this. A different size. A different colour. A corrected address. A different delivery day. One item removed from a three-item order.

This is the outcome that a press-1-to-confirm system cannot produce, and it is often the most valuable one, because it is a sale you were about to lose to a detail. The change is recorded as a structured edit — the field, the old value, the new value — not as a note somebody has to read and interpret. Your packer sees a corrected order, not a comment.

Action: apply the change, then pack.

CALLBACK

The customer asked to be called at another time. They are driving, they are at work, they are in the middle of something, or they want to check with someone at home before deciding.

A callback is not a refusal and should never be recorded as one. It is a scheduling fact. The order stays open and the call goes back into the queue for the time the customer named.

Action: re-queue for the requested time.

HUMAN

The agent decided this call needs a person, and stopped.

That decision is deliberate and it is the most important safety property of the whole system. Some things an automated agent should not attempt: a complaint about a previous order, a question about a refund, a customer who is upset, a dispute about the price, anything where being wrong is expensive and the agent's confidence is low. Rather than improvise, the agent escalates — and it hands over the recording and the transcript, so the person picking it up starts with the context instead of asking the customer to repeat themselves.

HUMAN is a feature, not a fallback. A voice agent with no escalation path will confidently answer questions it has no business answering. See what an agent must never do for the rest of that boundary.

Action: a named person calls back, with the transcript in front of them.

UNRESOLVED

The call happened but produced no decision. Nobody answered. The line dropped. The number is switched off. The audio was too poor to hear an answer. Someone picked up, said "wrong number", and hung up.

This is the honest outcome for "we do not know", and it is deliberately distinct from CANCELLED. A customer who did not answer at 11am on a Tuesday has not said no. Merging the two would make your cancellation rate look like a demand problem when it is a reachability problem — two very different things to fix.

Action: retry on the schedule you set, and if it stays unresolved, decide by policy rather than by guess.

Why the outcome is structured rather than written

Each of these is a value, not a sentence. That is the part that makes the rest of your operation possible.

A structured outcome can be filtered, counted, charted and routed. You can ask for every MODIFIED order from yesterday that has not been re-packed. You can send every CALLBACK to one person's queue. You can fire a webhook on CANCELLED and let your own system release the stock without anyone reading anything. You can watch your UNRESOLVED rate by hour of day and discover you are calling at the wrong time.

Every call also carries the material behind the decision: the recording, the turn-by-turn transcript with the detected intent, and any structured edits the customer asked for. So an outcome is auditable. If a confirmation looks wrong, you can listen to the exact moment it was decided rather than arguing about it.

The live call demo walks a real confirmation conversation turn by turn and ends on one of these six, and Features covers where the outcome goes next — the order, the dashboard, and the signed webhook.