Want help applying this guide?Ask the DripTell team
A customer can be waiting even when your dashboard says the message was routed. To measure that wait honestly, count every eligible minute between an actionable request arriving and a named person or capable automation explicitly accepting responsibility. If ownership disappears later, start the clock again until the next owner accepts.
Do not treat a queue name, round-robin attempt, notification, or automated greeting as accepted ownership. Those events may move work, but they do not prove that someone can act on it. This distinction turns an unassigned count into an operating measure you can improve.
Separate arrival from accepted ownership
Three moments often get collapsed into one. The message enters the system. A routing rule points it at a team. Then an eligible agent accepts it. Only the third moment creates accountable ownership.
- 1Request arrivesStart when the message becomes actionable in the service queue.
- 2Queue receives itKeep the clock running while only a team or rule owns the route.
- 3Person acceptsStop the first interval when an eligible owner explicitly accepts the work.
- 4Ownership clearsRestart the clock if the request loses its owner before another accepts it.
- 5Outcome is checkedRead assignment speed beside response, resolution, reopen, and repeat contact.
A useful initial measure is time to first accepted owner:
first accepted owner time = first acceptance timestamp - actionable arrival timestamp
The word actionable matters. A spam message, delivery receipt, or duplicate webhook should not enter the denominator. A genuine customer request should, even if it arrives after hours. You may report business-time and elapsed-time views separately, but preserve both rather than erasing the customer’s night or weekend wait.
Microsoft’s current voice analytics documentation defines average speed to answer as the queue wait until a representative accepts. It reports that separately from handle time and notes that average wait can include each session within a conversation. The boundary is useful: acceptance is different from the work that follows.
A team inbox should therefore preserve creation, routing, acceptance, clearing, reassignment, reply, and resolution as separate events. A current assignee field is not enough because it overwrites the history you need.
Build an event record before a dashboard
For each conversation, keep a stable issue identifier and an ordered ownership log. Record the actionable arrival time, queue offered, proposed owner, acceptance, owner cleared, next acceptance, first useful reply, resolution, and reopen. Include the reason when ownership changes.
Suppose a billing request arrives at 08:02. A rule places it in the billing queue at 08:03. Sam accepts it at 08:11. The initial unassigned time is nine minutes, not one. If Sam clears ownership at 08:20 and Noor accepts at 08:27, the same issue gains another seven unassigned minutes. Total unassigned time is sixteen minutes.
That record also prevents an easy reporting error. If you inspect only the final owner, the conversation looks continuously assigned. An event log shows the gap the customer actually experienced. Workflow automation can help route and notify, but the measurement should still require a recorded acceptance or verified automated completion.
Use more than one assignment metric
An average answers too little. A few very old conversations can disappear inside a busy queue, while a median can look healthy even when a small tail is being neglected.
| Measure | What it answers | Common mistake | Review action |
|---|---|---|---|
| Median first assignment time | What does a typical new request experience | Treating the queue offer as acceptance | Compare like queues and hours |
| Ninetieth percentile first assignment time | How slow is the long end of normal work | Reporting only the average | Inspect routing and capacity in the affected segment |
| Unassigned threshold breach rate | What share waited beyond the team promise | Changing the denominator after the fact | Freeze the eligible arrival cohort |
| Total unassigned minutes | How much ownerless time accumulated across all gaps | Counting only the first gap | Reconstruct every clear and accept event |
| Oldest currently unassigned request | Which live customer needs attention now | Looking only at completed work | Assign an owner and record the cause |
Microsoft’s official queue report exposes both unassigned work items and the longest queue wait before assignment. That oldest-item view matters because a live tail needs action, not a better monthly average.
Keep cohort and snapshot views separate
Use a fixed arrival cohort to evaluate performance. For example, take every eligible request created last week and follow each until first accepted ownership. Keep unanswered and still-unassigned requests in the cohort with their wait censored at the report cutoff; do not drop them because the event has not finished.
Use a separate live snapshot for control. It should show the current unassigned count, the oldest wait, the queue, channel, issue type, required skill, and whether an eligible owner is available. Snapshots answer who needs help now. Cohorts answer how the operating system performed.
Diagnose the gap without blaming agents
Break assignment delay down by channel, queue, shift, language, issue type, priority, and routing rule. Then inspect the actual cause. The work may require a skill nobody on duty has. A rule may point at an inactive team. Capacity limits may be correct but understaffed. An agent may reject work without a fallback. A handoff may clear the old owner before the new one accepts.
The remedy must follow the evidence. A target cannot repair an invalid skill map, and more staff cannot repair a broken route. A practical support operating model keeps one accepted owner while specialists contribute, with the next action in the customer record.
For automation, define the same boundary. If an AI assistant can safely complete the customer’s task and produces a verified outcome, it can be the capable owner. If it detects a handoff condition, human assignment time starts at that condition, not when the original message arrived and not when the bot sends a holding reply.
Protect the customer outcome
Faster assignment is useful only if it leads to useful work. Review it beside time to first meaningful response, full resolution time, reopened cases, repeat contact, transfer depth, and customer feedback. Watch for accepted conversations that receive no action and for rapid reassignments that simply move the wait.
Start with one queue and a fixed week of arrivals. Reconstruct the events, publish the median, long tail, threshold breaches, total ownerless minutes, and oldest live request. Then repair the largest evidenced cause. If you need assignment, routing, records, and outcome checks in one operating flow, talk to DripTell.
Frequently Asked Questions
What counts as an unassigned customer conversation
It is an eligible customer request that does not currently have a named person or capable automation that has explicitly accepted responsibility. A queue, notification, or proposed assignee alone does not prove ownership.
How do you calculate time to first assignment
Subtract the actionable arrival timestamp from the first accepted-owner timestamp. Keep business-time and total elapsed-time views if useful, and retain still-unassigned requests at the reporting cutoff.
Should automatic routing stop the assignment clock
Only when the automation can safely complete the task and its acceptance is recorded. If it merely classifies, greets, or offers work to a human queue, keep the ownership clock running.
Which unassigned metric should a manager watch live
Watch the current unassigned count and the oldest unassigned request together. The count shows volume; the oldest item exposes the customer most likely to be hidden by an average.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy