Want help applying this guide?Ask the DripTell team
At 10 on Monday morning, a supervisor sees that Lena owns nine open cases while Tariq owns five. The easy response is to send the next case to Tariq. But his five include an account recovery, a damaged shipment that needs a carrier decision, and a customer waiting for a specialist. Lena's nine are mostly address corrections. The counts are accurate. The workload picture is not.
Measure customer support case complexity from observable work, not from an agent's impression or the number of open cases. Keep effort, customer risk, specialist dependency, and follow-up separate. Then use broad complexity bands for routing and capacity, and test those bands against actual work and customer outcomes. A complexity label should improve a decision. It should never become a hidden performance score.
A case count hides the work
Complexity is not the same as priority. A password reset can be urgent and straightforward. A low-priority billing question can require three systems, a policy exception, and a finance approval. Age is different again. An old case may be waiting on the customer, while a new case may already need several teams.
- Name the decisionChoose the routing, capacity, or coverage choice the measure must improve.
- Code visible workRecord evidence, decision authority, dependencies, and follow-up separately.
- Calibrate reviewersResolve disagreements by improving the coding guide and examples.
- Attach an actionGive each broad band a clear capacity, skill, or review consequence.
- Review the missesStudy overestimates and underestimates without ranking employees.
Start by naming the decision you want the measure to support. A support operation may need to route work, set concurrent limits, plan specialist coverage, or explain why two queues with equal arrivals need different staffing. One model does not need to serve every decision.
Keep the unit stable. Measure one unresolved customer need, even when it moves between channels or creates internal tasks. Counting every message, transfer, or subtask as a new complex case rewards fragmentation. A shared inbox should preserve the customer, owner, history, and related work so reviewers can see one journey.
Describe complexity with evidence
Choose a small set of observable drivers. Four are usually enough for a first study. Evidence load is what must be checked. Decision load is the authority and judgment required. Dependency load is work another person or system must complete. Continuity load is the follow-up needed to keep the promise intact.
| Observable driver | What to record | What not to assume | Operational use |
|---|---|---|---|
| Evidence load | Systems, documents, identity checks, and disputed facts reviewed | A long conversation is automatically difficult | Investigation time and access needs |
| Decision load | Policy branch, exception, material harm, or approval authority | High priority always means high complexity | Skill and authority matching |
| Dependency load | Specialist, supplier, carrier, or engineering action required | A transfer has solved the need | Coordination and ownership risk |
| Continuity load | Promises, deadlines, channel changes, and follow-up events | Silence means no work remains | Follow-up capacity and handover quality |
Record these dimensions separately before combining anything. A short fraud concern can carry high decision risk but little handling time. A long product explanation can consume effort without needing special authority. One total score would hide that distinction.
Microsoft's current capacity profile documentation shows that a classification rule can attach a capacity profile to a work item and that assignment then checks matching available capacity. That is useful product evidence for differentiated work limits. It is not proof that every business should copy one vendor's configuration or that software can discover complexity without a clear operating definition.
Build broad bands from real cases
Take a recent sample from each meaningful queue and time period. Include completed cases, unresolved cases, escalations, repeat contacts, and cases that looked easy at arrival but changed later. Excluding failures makes the model look cleaner and less useful.
Write a short coding guide with examples for each driver. Let two reviewers code the same small subset independently. When they disagree, improve the definition rather than averaging their opinions. If reviewers cannot apply a rule consistently, routing automation will not make it more trustworthy.
Use broad bands such as standard, involved, and controlled specialist work. The names matter less than the actions attached to them. Standard work may fit normal concurrent capacity. Involved work may reduce the next assignment or reserve more follow-up time. Controlled specialist work may require specific authority, a named owner, and a review point.
Do not force equal numbers into each band. The distribution should reflect the work. Compare each band with median active work, elapsed time, transfers, repeat contact, missed promises, and verified resolution. If a supposedly simple band regularly produces long waits or reopened cases, the coding rule is missing something.
Connect the band to a decision
A complexity measure is valuable only when it changes a safe operational choice. It can refine conversation capacity, support fair workload balancing, or identify when skills based routing needs an exact match rather than a preference.
Microsoft's current assignment guidance describes assignment using skills, presence, and capacity, with configurable prioritization for work items. Keep those concerns distinct in your own policy. Priority answers which need should move first. Skill answers who can safely act. Capacity answers who can take more work. Complexity estimates how much and what kind of work this need is likely to require.
Let the owner correct a band when new evidence appears, but record the reason and time. Otherwise every difficult case quietly becomes complex after the fact and the model cannot be tested. Preserve the original band, the revised band, and the event that changed it.
Review the model without blaming agents
Do not compare agents by raw complex-case totals. People with specialist skills will attract harder work. New staff may receive protected assignments. Some queues inherit upstream failures. The measure describes work, not personal worth.
Review false positives and false negatives monthly. A false positive reserves more capacity than the case needed. A false negative overloads an owner or sends the case through avoidable transfers. Use inbox reports to find the periods and cohorts, then read the underlying case history.
DripTell can keep the conversation, ownership, internal context, and routing evidence together. The important part is the operating rule around that evidence. Begin with a few observable drivers, connect each band to one decision, and keep revising when real cases prove the model wrong.
Frequently Asked Questions
What makes a customer support case complex
A case is complex when observable work requires more evidence, judgment, authority, coordination, or follow-up. Message length and urgency alone are poor substitutes.
Should every complex case get high priority
No. Priority controls order. Complexity describes the kind and amount of work. A routine security action may be urgent, while a complicated analysis may safely wait.
Can artificial intelligence score case complexity
It can suggest a band after the team defines reliable evidence and tests the result. Keep human review for low-confidence, high-risk, and changing cases. Do not use an unexplained score for employment decisions.
How often should the model be reviewed
Review it whenever products, policies, channels, or routing change, and on a regular sample such as monthly. Watch for bands that no longer predict effort, dependencies, or customer outcomes.
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