Begin with a question a team can act on
Avoid a long list of “good” metrics with no decision attached. These are useful questions:
| Dashboard signal | Zendesk’s definition or scope | Question to investigate |
|---|---|---|
| Total conversations | Conversations handled by AI agents | Did traffic, channel mix, or contact reasons change? |
| Assisted escalations | AI contributed before a human completed the resolution | Is this an intended guardrail, a missing source, or a weak procedure? |
| Automated resolutions | A meaningful response or use case met Zendesk’s automation criteria | Which use cases and knowledge sources are producing them? |
| BSAT | 4–5 ratings divided by all ratings given | Are low scores concentrated in a contact reason, source, language, or channel? |
Zendesk further separates automated outcomes into contained and verified resolutions. Its reporting-change announcement dates the new calculation to May 18, 2026: contained resolutions have no human involvement or follow-up, while verified resolutions have additional signals that the outcome was complete and satisfactory. The reported automated-resolution rate includes both, but Zendesk says billing applies only to verified resolutions. An increase across that definition change is not, by itself, evidence that your configuration improved. Analytics should narrow the investigation; they should not decide the fix by themselves.
Investigate the mismatch, not just the headline number
Suppose the Overview tab shows high assisted escalations while the Knowledge sources report shows an article with frequent escalation after use. Pull a small, representative sample of those conversations. Zendesk defines the knowledge-source table’s usage as the share of AI-generated replies using an article; its escalation and automated-resolution columns are the shares of those article-using conversations that later escalated or counted as automated resolutions. Tag the sample with request type, needed information, handoff reason, and whether a human ultimately answered from an existing policy.
If humans repeatedly use a policy the agent cannot access, that is a source-coverage problem. If the policy says the case must be escalated, the handoff is doing its job. If the request is unclear, the answer may be better clarification rather than a broader knowledge source. The Reporting dashboard also has Contact reasons and Conversation journey tabs; Zendesk says the latter can reveal single-step and multi-step paths, including paths that end in assisted escalation. Use that path evidence before changing a procedure.
Make one change and test the same case
The most reliable improvement is small: approve one source, clarify one standing instruction, or adjust one procedure boundary. Re-run the original cases plus a nearby exception. Record whether the response used the intended information, whether it still stopped at the right boundary, and whether the handoff included useful context.
This matters because a better resolution rate alone can hide a regression. A support team should preserve cases that must escalate, such as account-access or policy-exception requests, and judge success against both automation and safe outcomes.
Inspect activity, sources, and rules in one workspace
With eesel, the dashboard and CLI refer to the same teammate and workspace. The dashboard gives a support lead the visual view; the CLI gives a teammate, a script, Claude Code, Codex, or Cursor JSON to inspect. Use Node.js 18.17+ and npx @eesel/cli if you do not want a global install.
For the high-handoff investigation, ask a coding agent to summarize a sample of the eesel teammate's recent activity, separating intentional escalations from apparent missing-information cases. It can read JSON from these commands and produce a table of cases for a support lead to check:
npx @eesel/cli activity --agent "Zendesk support"
npx @eesel/cli integrations download list --agent "Zendesk support"
For example, repeated setup questions may end in handoffs because a new installation guide is absent from the downloaded sources. The coding agent can flag that gap and read instructions to check whether escalation is intentional. The support owner decides whether adding the guide is appropriate; the coding agent can then help upload the approved file and use chat to ask a representative installation question. Review connected action permissions before testing, and use --dry-run to preview writes. Inspect the new activity and the affected ticket before concluding the gap is fixed. Do not present this sample as a full analytics export or equate eesel outcomes with Zendesk's billing definitions.
Give analytics an owner
Name one owner for each review cadence and one owner for each source or procedure. That does not mean the owner must fix every problem; it means the team knows who decides whether a metric indicates a knowledge gap, a safe handoff, or a different support issue.
Make Zendesk AI analytics useful
The eesel Activity list shows Zendesk conversations and their statuses, with teammate chat beside the list.
eesel can work alongside the Zendesk dashboard your team already uses. Inspect the source behind a metric, test one bounded improvement, and let the support owner approve the result before expanding automation. Try eesel.
Frequently asked questions
What should Zendesk AI agent analytics measure?
Start with the outcome, handoff, customer experience, and contact-reason patterns that map to a real support decision.
Is a high resolution rate always good?
No. Pair it with quality checks and escalation patterns. A metric is a prompt to inspect cases, not a verdict.
What does a high handoff rate mean?
It may indicate missing knowledge, an intentional safety boundary, a procedure gap, or a change in the type of contacts received.
How often should a team review AI analytics?
Review after meaningful changes and on a regular operating cadence that has a named owner.
Article by
Kurnia Kharisma Agung Samiadjie
Kurnia is a software engineer and writer at eesel AI with two years of SEO experience, writing about AI tools, helpdesk software, and customer support. He pairs a developer's understanding of how these products are built with search-driven research into what actually ranks and resonates with the people searching for them.
