Should a failed bot attempt followed by a person count as one contact or two?

Two, if the measure is meant to describe the customer's experience. They had to try twice to get one answer, and a convention that hides the first attempt turns the measure into a description of your own architecture rather than of anything that happened to them.

Why does the convention matter so much?

Because it is the only thing standing between an honest measure and a flattering one, and it can be changed in a reporting configuration without touching any system. Fixing it before deployment is what keeps the before-and-after comparison worth drawing at all, and afterwards nobody will believe it.

Is it still worth measuring?

Yes, more than most of its neighbours, because once the counting convention is fixed it cannot be improved by a configuration change. A team genuinely raising it is answering properly the first time, which is difficult, valuable and very hard to fake.

Glossary

First contact resolution

Whether somebody's problem was settled the first time they got in touch, a long-standing measure whose basic unit has quietly stopped being obvious.

In plain terms

Did the customer get sorted the first time they asked. It used to be obvious what one time meant, because it was a phone call. Now one enquiry might pass through a chat window, an email and a person, and somebody has to decide whether that was one contact or three.

Why it matters

Because it is the measure customers would choose if asked, and the one automation is most likely to distort without anybody noticing. The distortion is not in the arithmetic but in the unit, so the number stays plausible while quietly describing something else.

How it works

The measure predates the tools by decades and was built around a phone call, where a contact had an obvious beginning and end. Everything difficult about it now comes from that unit dissolving rather than from anything about the calculation.

Automation genuinely improves it for straightforward enquiries. Instant answers at any hour settle simple things in one pass that used to wait for a queue, and that improvement is real rather than an artefact of how it is counted.

It also creates a new pattern the measure was never designed for: the customer who tried the automation, got nowhere, and then contacted a person. Counted as two contacts that is a failure; counted as one it is a success, and both conventions are in use.

Whichever convention you pick, pick it before deploying. Changing it afterwards makes the before-and-after comparison meaningless, and the temptation to change it is strongest at exactly the moment the comparison is being drawn.

The convention that survives scrutiny counts from the customer's side. They experienced one problem and one attempt to get it fixed, and whether that involved one system or three is a fact about your architecture rather than about their day.

It rewards the right behaviour when it is honest, which is why it is worth protecting. A team improving genuine first contact resolution is doing the difficult work of answering properly the first time, and that is not achievable by any configuration change.

One enquiry, two ways to count it

This is the cleanest example in support measurement of a number changing meaning without changing method. Neither column involves anybody misrepresenting anything, both can be documented and defended, and the difference between them is large enough to decide whether a deployment is judged a success. What makes the left-hand column dangerous is not that it flatters, but that it flatters in a way that correlates with the thing you are trying to evaluate: the more enquiries the automation attempts and fails, the more first attempts get excluded, so the measure improves as the system performs worse. That is the specific property to watch for in any metric, and it is worth stating as a general test rather than a support one. Ask what the number does when the system fails more often. If the answer is that it goes up, the definition is wrong and no amount of careful collection will fix it.

Seen in the wild

An enquiry that touched an assistant, then an email, then a person, counted as one thing or three.
Sierra
Simple questions genuinely settled at once, at hours when nobody was on shift.
Tidio Lyro
An agent finding the answer first time because the material behind it was current.
Guru

Common misconceptions

People assume

It means the same thing it did before automation.

In fact

Its unit was a phone call with an obvious start and end. An enquiry now spreads across systems, so what counts as one contact has become a convention somebody chooses rather than something anybody observes.

People assume

Automation improves it.

In fact

It improves the straightforward cases genuinely, and it creates the failed-then-escalated pattern the measure was never built for. Whether that pattern reads as a success or a failure depends entirely on a counting convention.

Questions

Should a failed bot attempt followed by a person count as one contact or two?: Two, if the measure is meant to describe the customer's experience. They had to try twice to get one answer, and a convention that hides the first attempt turns the measure into a description of your own architecture rather than of anything that happened to them.
Why does the convention matter so much?: Because it is the only thing standing between an honest measure and a flattering one, and it can be changed in a reporting configuration without touching any system. Fixing it before deployment is what keeps the before-and-after comparison worth drawing at all, and afterwards nobody will believe it.
Is it still worth measuring?: Yes, more than most of its neighbours, because once the counting convention is fixed it cannot be improved by a configuration change. A team genuinely raising it is answering properly the first time, which is difficult, valuable and very hard to fake.