Three Handle Times and One COO
Lumen Health's contact centre runs 600 agents across voice, chat, email, and SMS on Omni-Channel. Three numbers circulate in weekly meetings: the executive dashboard shows average handle time of 8:12 and first contact resolution of 71%; the operations report shows AHT of 5:40; the telephony vendor invoice ties to talk time only. CSAT is 4.3 out of 5 but drops about 0.6 points for contacts that touch three or more cases. The executive dashboard refreshes nightly from a CRM Analytics dataset while supervisors use live standard Lightning reports. Channel mix shifted sharply when SMS launched: SMS is now 34% of volume and is handled by agents who also take chats. The COO wants one number she can trust, with the case-level evidence behind it, by the next board meeting.
1. Explain the drivers of the discrepancy and publish a working definition for each contested metric.
Read the worked answer
You have three different denominators, two different clocks, and two different populations.
Drivers
- Channel mix. A blended AHT across voice, chat, email, and SMS is a weighted average, not a metric. Voice (talk plus hold plus wrap) is structurally higher than chat, and SMS behaves differently again. If SMS grew to 34% between the two comparison periods, any blended comparison is meaningless.
- What is included. The vendor invoice ties to talk time only, excluding hold, wrap-up, and after-call work. Operations' 5:40 likely excludes wrap-up; the 8:12 likely includes it. Nothing is wrong with either - they are answers to different questions.
- Clock. Business-hours case duration versus wall-clock telephony averages will never reconcile.
- Unit of analysis. Case-level versus contact-level. One call can create three cases - and your CSAT dip suggests it is happening. Averaging per case understates effort per contact.
- Freshness. Nightly dataset versus live reports means the two dashboards describe different populations near period boundaries.
Definitions to publish (name, source object, formula, inclusions, clock, grain):
- Handle time: per interaction, from telephony and transcript/AgentWork records, including hold and wrap-up, reported per channel then blended using a stated channel mix.
- Contacts per case and repeat contact within 7 days.
- First contact resolution: label it a proxy - case closed on first contact, no reopen, no new case within 7 days. True FCR needs customer confirmation.
- CSAT: shown with response rate and sample size per channel, never as a bare average.
2. Recommend a reporting architecture that makes the executive and supervisor numbers reconcile.
Read the worked answer
Pick a system of record per audience, then make everything else read from it.
- Standard reports for operational, live lists - my open cases, queue backlog, today's breaches. Supervisors need row-level, fresh, actionable data; latency here is a defect.
- CRM Analytics for anything the executive sees, modelled at a defined grain (interaction, case, day) with documented transformations. The value is that the calculation lives once in the dataset, not in a hundred report formulas that drift.
- Snapshot what is mutable. Case age, owner, and milestone state are overwritten over time. Historical reporting on them needs case history, milestone records, and scheduled snapshots; without snapshots, last month's board number changes after the fact and you lose the argument permanently.
- State the refresh on the dashboard ('data through 02:00 today') and run a nightly reconciliation that applies the same definition to a sample day of live data. If they differ, the pipeline is the bug, not the metric.
- One channel taxonomy used by routing, reporting, and the dataset. SMS handled by chat agents must still appear as SMS, otherwise every channel-level conclusion is contaminated.
- Deliver the COO's ask literally: one number, its definition in a footnote, and a drill path to case-level rows.
Judgement to defend: resist letting CRM Analytics become the operational tool (latency), and resist letting live reports become the executive tool (row scope and overwritten state).
3. Supervisors report different totals from the same report. How do you handle access and row-scope issues without fragmenting the reporting model?
Read the worked answer
Row differences are almost always visibility, not logic. Diagnose in this order.
- Case OWD and role hierarchy. A supervisor over one region sees one region's rows in a live report. An executive consuming a nightly dataset may see everything because the dataset was built with different or elevated access. Same query, different row set - and both are behaving correctly.
- Report run-as and folder access. If reports run as the viewer, two people looking at the same report legitimately get different totals. Decide per report which behaviour is intended; for executive metrics, use a documented elevated run-as with a stated business justification rather than quietly widening sharing.
- CRM Analytics security is separate from Salesforce sharing: dataset sharing and row-level security predicates must mirror the intended audience, or everyone sees everything in the dashboard.
- Intraday drift. A case reassigned at 14:00 shows under the old owner in the dataset until tomorrow's sync. Supervisors comparing live to snapshot will always see this; say so on the dashboard.
- Make scope explicit on the artefact: row scope (e.g. EMEA only), data-through timestamp, and run-as policy in the footer of every report and dashboard.
Then institutionalise the reconciliation: a single 'numbers disagree' checklist whose first question is 'what is your row scope and what is your data-through time?' Most disputes end there. Only after scope is matched do you investigate formula or pipeline differences - and if a genuine formula difference survives that, fix it in the dataset rather than in the report.