Counting the turn where a call dies splits voice-agent failure into two spikes

Average handling time is a mean over durations, and the two failures described in the dev.to post land on opposite sides of it. A caller who quits at turn one or two leaves a very short call in the sample ^[6]. A caller who explains the problem, gives an account number, answers two clarifying questions and then hits a wall has spent about two minutes before leaving ^[7][8]. Adding more of the first kind pulls the mean down ^[22]. So the dashboard gets better as the early spike grows, and speed is the number the post says teams blame first ^[2].

Count one number per call and the shape changes. Plotting the turn at which the call died across a few hundred real calls tends to produce two spikes and not a slope, according to the post ^[5]. The early one is a caller deciding they have reached a machine ^[6]. Part of that is attributed to a greeting promising more than the agent can do: the caller then tests it immediately with the hardest thing they have ^[6]. The mid-call spike is the one that becomes a complaint, and the author calls it "entirely a design decision rather than a technology limit" ^[8][21].

The scoping rule is mechanical. For each intent, write the exact final sentence the agent says when it goes well; if you cannot write that sentence without a conditional, the intent is not ready for the agent to own ^[13]. That test works because a closing sentence needs a system the agent can read from or write to, and a fact it can state afterwards ^[11]. Where is my order has one ^[11]. A refund outside policy does not, because the resolution sits in somebody's judgement ^[12].

The author wrote: "My opinion, and it is an opinion rather than a measurement, is that most voice agent projects fail at scoping and then spend their budget on engineering" ^[9]. The usual question, per the same post, is what the model can handle, and the answer is a lot ^[10].

Then there is build order. The transfer path goes first, before a single intent is wired up ^[16]. The warm transfer writes a short structured summary plus the raw transcript into the ticket or CRM record before the call moves, so the agent picking up is reading instead of asking ^[17]. That needs a telephony platform that can attach data to a transferred call, and the post says fix that before anything else because everything downstream depends on it ^[18]. The escape list is four behaviours: saying agent, saying representative, pressing zero, or repeating twice, all routing out immediately with no retention attempt and no "I can help with that" in between ^[19]. A caller who reaches a person in fifteen seconds with the account number and problem already passed has had a decent experience even though the automation failed; a caller who starts again from the beginning is worse off than if nothing had been deployed ^[15].

The handoff is treated as an edge case in most projects the author has seen ^[14]. The evidence for all of this is one practitioner's listening: "I have looked at enough of those recordings to be fairly confident about where the damage happens, and it is almost never where the team expects," the author wrote ^[24]. The post does not publish the distribution or the call counts. For the two spikes to appear in your own recordings, your greeting has to promise more than the agent delivers and your intent list has to contain at least one intent whose good ending needs a conditional. Both are checkable in an afternoon.

The third day-one item is a rule for what happens out of hours, when there is nobody to transfer to ^[20].