Customer support metrics dictionary & governance template

A support metric is not governed because it has a name on a dashboard. It is governed when two people can calculate the same result from the same population, explain which decision it informs, identify what it leaves out, and show who approved the definition.

Use this dictionary to create that record. It is designed for support operations, analytics, workforce management, quality, finance, and leadership to complete together. Copy the whole template into a shared document or data catalog, create one definition record per metric, and link every dashboard back to the approved record.

The rule is simple: a target can change without changing the metric; a metric cannot change without a version. If the formula, population, clock, event logic, aggregation, or source changes, record the break. Do not make last quarter mean something different after the fact.

For the operating principles behind the template, start with the customer support metrics guide. Use the glossary to reconcile common terms and the benchmark library for external context only after your internal definition is stable.

---

1 — Dictionary control block

Fill this once for the complete dictionary.

Ground rules

• Every metric has one accountable business owner and one technical data owner
• Every dashboard, QBR, board pack, incentive, and vendor report uses the canonical definition or labels the difference
• Definitions are separate from targets, benchmarks, and commentary
• Counts can be reconciled to a sample of real contacts or events
• Averages are not used where a median, percentile, rate, or distribution answers the decision better
• Every efficiency metric has a customer, quality, or people guardrail
• Definition changes create a new version, effective date, impact note, and backfill decision
• Deprecated definitions remain visible so historical reports can still be interpreted

2 — Metric register

This is the index people should see first. Keep it short; the full record behind each row carries the detail.

Allowed statuses: draft, in review, approved, deprecated. A metric used for performance management or external reporting must be approved.

3 — Blank metric definition record

Duplicate this entire section once per metric. Do not delete a field because it is inconvenient; write not applicable and say why.

Identity and decision

If the business question is vague — “how are we doing?” — the metric is not ready. Name the decision: add coverage, investigate a queue, change an article, coach a behavior, revise a promise, or stop an unsafe automation.

Exact computation

Write the formula so an analyst who did not attend the meeting can implement it. “Resolved tickets divided by total tickets” is not enough until resolved, ticket, and total each have an event rule.

Population and segmentation

Do not compare blended numbers when the work is structurally different. Phone, chat, email, and persistent messaging use different clocks and capacity models. A metric that cannot be segmented by the operating unit it describes is usually a reporting artifact.

Source lineage and quality

The calculation should survive a case-level audit. Keep a small reconciliation set of real tickets or contacts with the expected result written down; rerun it after workflow, vendor, schema, or query changes.

Interpretation, guardrails, and use

A benchmark is context, not a target. Record the source year, sample, segment, and definition beside it. If those are not comparable, label the figure directional. The benchmark library is a starting point, not permission to paste an industry average into a performance plan.

Approval

4 — Reproduction and edge-case test

Complete this before approval and after every material change.

• Two people independently calculated the metric from the written record and matched
• A random case sample reconciles from dashboard to source event
• Boundary times were tested: period start/end, time-zone change, weekend, holiday, daylight-saving transition
• Reopened, merged, split, transferred, deleted, spam, test, and duplicate cases behave as specified
• Bot-only, bot-to-human, and human-only work is separated as specified
• Missing timestamps, missing survey answers, and invalid states land in a visible exception bucket
• Low-volume segments are suppressed or marked uncertain
• Historical results were compared before and after the change
• Every dashboard, export, QBR, and incentive using the old definition has an update owner
• The case-level test set and expected outputs are saved with the definition

Reconciliation record

5 — Starter specifications for six common metrics

These are starting points, not universal definitions. Copy the relevant row into a full record and replace every assumption with your own operating decision. The support metrics cheat sheet explains where each number belongs.

Customer satisfaction (CSAT)

Publish the response count and rate beside the score. Use the CSAT confidence calculator to expose sampling uncertainty; it does not correct non-response bias.

First response time

First-contact resolution (FCR)

FCR is easy to improve on paper. Review why it is the most gamed metric in support before attaching it to a target.

Average handle time (AHT)

Reopen rate

Cost per resolved contact

Use the cost-per-contact calculator to make the cost scope visible, then reconcile the result to finance. The real cost of a ticket explains why a cheap contact that returns is not cheap.

6 — Build a balanced metric portfolio

Do not fill the dictionary with every field the help desk exports. Start with the decisions the operation repeatedly makes, then select the smallest set that covers the system.

For each efficiency measure, write the guardrail on the same dashboard row. Faster pairs with solved. Cheaper pairs with correct. More automated pairs with confirmed outcome and reachable human help.

7 — Change log

Never overwrite the definition silently. Add one row for every change, including vendor migrations and “small” timestamp fixes.

Material changes that require a new version

• Formula, numerator, denominator, grain, aggregation, or population changes
• A clock starts, stops, pauses, or resets differently
• Channel, queue, customer, bot, spam, test, transfer, merge, or reopen eligibility changes
• Survey question, scale, threshold, delivery timing, or response window changes
• Source system, event, field, vendor, semantic model, or query changes
• Allocation rules change for cost or staffing
• Historical data is backfilled, corrected, or reclassified

A target change belongs in the target history, not the formula. A display rename with no computational effect can be a minor version, but record it so readers can map old reports to new language.

8 — Publication and review checklist

• Plain-English definition appears beside the number or one click away
• Dashboard links to this definition record and shows its version/effective date
• Metric owner and data owner both approved it
• Target, benchmark, and actual are labeled as three different things
• External benchmark includes source, year, segment, definition caveat, and review date
• Sample size or eligible population is visible for rates and survey measures
• Required segments and distribution views are available
• Paired guardrail appears on the same review surface
• Prohibited uses are documented before the metric reaches performance management
• Reproduction test passed and the case-level test set is saved
• Change log, next review date, and deprecation plan are complete
• The metric appears in the support QBR outline only after these checks pass

9 — Quarterly review agenda

Run this as a 45-minute working review, not a presentation.

1. Usage: Which decisions did each metric actually inform? Retire measures nobody used.
2. Reconciliation: Did quality checks, source counts, and case samples pass?
3. Behavior: Did a target create rushing, cherry-picking, premature closure, survey pressure, or work moved off-system?
4. Comparability: Did mix, channel, product, survey, workflow, vendor, or source changes create a break?
5. Coverage: Is an important customer, quality, people, or cost outcome missing while activity is over-measured?
6. Change decision: Keep, revise, deprecate, or add — with an owner and effective date.

End with a signed change list. The dictionary is useful only if it governs the reports people actually act on.

If two dashboards show the same metric name with different numbers, do not average them and do not pick the prettier one. Stop, reconcile the population and event logic, approve one definition, and label the historical break. Agreement about what a number means is part of the operating system, not reporting housekeeping.