How to report on contact drivers with an AI agent

Ask the agent to read every contact, not a sample, and classify it against a driver taxonomy a person owns. It counts, groups repeat contacts, spots new drivers, and drafts a report that links each driver to the team that can remove it. The insight lead approves the report before anyone acts on it, and each action has a named owner.

What is contact driver reporting, and who owns it?

A contact driver is the reason a customer got in touch: a late delivery, a confusing statement, a failed login, a missing refund. Reporting on drivers turns thousands of conversations into a short list of causes, ranked by volume and cost, each with someone who can fix it. Done well, it is the most useful document support produces for the rest of the business.

The head of customer experience, or an insight lead reporting to them, owns the taxonomy and the report. Each driver has an owner outside support: product, billing, logistics, fraud. Those owners accept or reject the actions. For the wider support position, see the AI support agent that knows when to say no.

What does the agent prepare, step by step?

1. Agent, depth 1: reads contacts from every channel. Tickets, chats, emails and call transcripts. Calls come through the connection described in connecting an AI agent to your contact centre telephony. Leaving one channel out skews the whole report.
2. Agent, depth 1: links repeat contacts. The same customer about the same issue within a set window counts as one driver with several contacts, not several drivers. Repeats are themselves a finding, closely tied to first-contact resolution.
3. Agent, depth 2: classifies each contact against the taxonomy, at the level of cause, not symptom. "Where is my refund?" is a symptom; "refund delayed by manual approval step" is a cause. Where it cannot tell, it says "unclassified" and keeps the example.
4. Agent, depth 2: proposes new drivers. Clusters of unclassified contacts with a common cause become candidate additions to the taxonomy.
5. Agent, depth 2: drafts the report. Volume by driver, change since last period, repeat rate, a short redacted example of each, and the owner it should go to.
6. Person, insight lead: approves. Checks the classification on a sample, accepts or rejects proposed new drivers, and signs off the report.
7. Person, each driver owner: accepts or declines the action. With a reason and a date.

What does a named person approve?

The insight lead approves three things. The taxonomy, including every new driver: an uncontrolled taxonomy grows until nothing can be compared across periods. The classification quality, by checking a sample against their own reading before the numbers go anywhere. And the report itself, including the wording of each finding, because a driver attributed to the wrong team starts an argument rather than a fix.

Driver owners approve actions on their own drivers. The agent can suggest what might reduce a driver, but it cannot commit another team to work.

Which drivers need special handling?

Some contacts are routed away from support before they become tickets. Fraud reports often go straight to a fraud team, so they can vanish from support data while still being one of the main reasons customers call. The agent should read those contacts too, as counts, even if it never sees the detail; how those reports are taken is covered in can an AI agent take a fraud report from a customer.

Self-service changes hide in the same way. Customers who change their address or contact preferences without speaking to anyone still generated demand. Contacts about failed self-service attempts are a driver worth tracking, because they show where the self-service route breaks. The related flows are in handling address and contact detail changes and can an AI agent change a customer's contact preferences.

Which controls matter, and what evidence do they leave?

Classification checked on a sample every period. Evidence: the sample, the lead's classification and the agreement rate.

Examples redacted. No names, numbers or account details in the report. Evidence: the redaction step logged for each example.

Taxonomy versioned. Every report states the taxonomy version used. Evidence: the version on the report.

Coverage stated. The report says which channels were included and how many contacts each provided. Evidence: counts by channel.

Where does it usually go wrong?

Disposition codes are reused. Staff pick codes at the end of a contact in a hurry. The agent should classify from content and can show where its reading and the code disagree.

Symptoms are reported as causes. "Billing query" is the top driver every month and nobody can act on it. Push classification down to a cause someone owns.

Volume is the only measure. A small driver that produces long, angry calls may cost more than a large driver answered in a minute. Add handling time and repeat rate.

The report has no owners. A ranked list nobody is responsible for changes nothing. Every driver above a threshold needs a named owner and a response.

New drivers wait months. The taxonomy is reviewed quarterly, so a new problem sits in "unclassified" for weeks. Let the lead accept new drivers each period.

What should you measure?

• Agreement between the agent and the insight lead on the sample.
• Unclassified contacts as a share of the total; a rising figure means the taxonomy is falling behind.
• Actions accepted by owners, and how many were completed.
• Volume change on drivers with completed actions, the test of whether the report changes anything.