Want help applying this guide?Ask the DripTell team
A customer is waiting, the system offers the conversation to a teammate, and nothing useful happens. The teammate may have declined because the work was a poor match. They may also have missed the alert until it expired. Those outcomes look similar to the customer, but they point to different fixes. Measure rejected assignments and timed-out assignments separately before combining them into one view of offers that were not accepted.
A rejection and a timeout mean different things
An assignment rejection is an active decision. A teammate sees an offered session and declines it. A timeout is passive. The offer reaches its limit without an acceptance or rejection. Microsoft’s current session metrics documentation treats sessions as assignment-level records and notes that one customer conversation can create more sessions when it moves to another representative. That distinction matters. Counting only conversations can hide several failed offers inside one eventual reply.
- 1Define the offerCount only genuine assignment attempts with a stable event boundary.
- 2Record one outcomeKeep accepted, rejected, timed out and withdrawn results distinct.
- 3Calculate separatelyShow rejection and timeout rates beside counts and acceptance delay.
- 4Segment the evidenceCompare queue, shift, skill, channel, transfer and workload conditions.
- 5Change and retestFix one routing or operating condition and protect the fallback queue.
The same documentation defines rejection rate as rejected sessions divided by incoming sessions, and timeout rate as timed-out sessions divided by incoming sessions. Microsoft’s real-time user group report uses total assigned sessions as the denominator for both rates. Pick one denominator that represents genuine offers in your own data, document it, and keep it stable.
Do not read either outcome as proof of poor effort. A rejection may protect the customer from an agent who lacks the right skill, permission, language, or capacity. A timeout may reveal a stale availability state, an inaudible alert, a disconnected device, or an offer window that is unrealistic for the work. The event is evidence. It is not yet a verdict.
Count offers before blaming the queue
Start with the assignment offer, not the final conversation owner. Give every offer a stable event identifier and connect it to the conversation, queue, intended teammate, channel, skill rule, capacity state, offer time, and outcome time. Record one terminal result such as accepted, rejected, timed out, withdrawn, or cancelled. Keep withdrawn offers separate when the customer leaves or a supervisor reroutes the work before the teammate can decide.
Calculate three views for the same period:
- Rejection rate equals rejected offers divided by all genuine offers.
- Timeout rate equals timed-out offers divided by all genuine offers.
- Not-accepted offer rate equals rejected plus timed-out offers divided by all genuine offers.
The combined rate is useful for queue health, but it must never replace the two underlying rates. Ten rejected offers tell a different story from ten silent expiries. Review counts beside percentages as well. A small overnight queue can show a dramatic rate from only two events.
Teams using a shared inbox should also track time from the first offer to an accepted owner. If failed offers immediately return to a safe queue, the customer may experience only a short delay. If they disappear from working views, the same percentage becomes much more serious. The related guide to unassigned conversation time covers the gaps before and between accepted owners.
| Pattern in the data | Question to investigate | Evidence to check | Practical response |
|---|---|---|---|
| Rejections rise while timeouts stay stable | Is the work reaching people who know they cannot take it | Skill match, permissions, capacity, reason codes | Correct eligibility or capacity rules |
| Timeouts rise while rejections stay stable | Are alerts reaching people marked available | Presence history, device delivery, offer window | Repair presence or notification delivery |
| Both rise in one shift or queue | Is demand exceeding usable capacity | Arrival volume, active work, staffing, routing rules | Adjust coverage and fallback ownership |
| Failures cluster after transfers | Is each transfer creating a viable new offer | Transfer path, target queue, context, acceptance time | Simplify the path and preserve context |
Read the pattern by reason
A single company-wide average is rarely actionable. Segment the rates by queue, channel, hour, shift, skill, offer type, transfer status, and workload at the moment of the offer. Compare like with like. A voice offer that needs an immediate answer should not be judged against an asynchronous message that can wait in a working queue.
Reason codes help only when they reflect real operating choices. Keep the list short enough to use. Capacity reached, wrong skill, unavailable language, permission missing, technical alert failure, and customer already handled are more useful than a generic other option. Pair codes with event evidence instead of asking people to remember what happened at the end of a busy day.
Look for sequences, not just totals. Rejection followed by immediate acceptance may show healthy self-protection. Rejection followed by three timeouts may show a bad eligibility pool. Repeated offers to the same unavailable person point to stale presence or a broken cooldown. A conversation assignment guide and clear assignment rules make those expectations visible before the metric is used in a review.
Avoid ranking individuals from the rate alone. Someone handling specialist work may reject more because the router sends them broad offers. Someone else may time out because notifications fail on one device. Review samples, schedules, capacity settings, and actual customer outcomes before drawing a performance conclusion.
Fix the operating condition
Choose the smallest change that matches the evidence. If rejections come from wrong-skill offers, repair eligibility rules. If timeouts appear when people are marked available during breaks or meetings, correct presence handling. If busy agents receive new work before their current capacity clears, revise the capacity model. If failed offers do not return to a monitored queue, add an explicit fallback owner through workflow automation.
Test one change for a defined period. Watch rejection rate, timeout rate, time to accepted owner, first useful response, customer abandonment, and reopened work together. A lower rejection rate is not an improvement if people accept work they cannot actually progress. A lower timeout rate is not an improvement if the alert window is extended while customers wait longer.
Use inbox reporting to keep the definitions and segments visible to the people running the queue. DripTell can support assignment, ownership, automation, and reporting in one operating view, but the rule still belongs to the team. The useful goal is not zero rejection. It is a queue where every declined or missed offer has a known reason, returns safely, and reaches a capable owner without making the customer chase the business.
Frequently Asked Questions
What is a customer service assignment rejection rate
It is the share of genuine assignment offers that teammates actively decline. Use the same documented offer denominator across periods, and keep rejected offers separate from timeouts.
Should every rejected assignment count against an agent
No. A rejection can be correct when capacity, permission, language, or skill does not match. Investigate the routing decision and customer outcome before treating it as a performance issue.
What should happen after an assignment times out
The work should return to a monitored queue or named fallback immediately. Then record the timeout, protect the customer’s place, and check presence, notification delivery, workload, and the offer window.
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