Want help applying this guide?Ask the DripTell team
On Monday morning, the support lead sees 420 open conversations. By Friday, the team has resolved more cases than usual, yet the counter reads 447. The natural conclusion is that people are working too slowly. That may be wrong. A growing backlog is a balance problem first.
To understand the change, reconstruct what entered and left the open-work population. New requests matter, but so do reopened issues, transfers, merges, deletions, and status changes. If those events are missing or counted inconsistently, a polished dashboard can still tell the wrong story.
A backlog count is a snapshot
A backlog is the set of customer issues still unresolved at a defined moment. The definition needs four boundaries: the channels included, the queues included, the statuses considered open, and the time zone used for the snapshot. Keep those boundaries fixed when comparing one period with another.
The closing count should reconcile with the opening count. Start with opening open work. Add true new issues, reopened issues, and any work transferred into the chosen scope. Subtract durable resolutions, audited merges or deletions, and work transferred out. The result should equal closing open work.
Transfers disappear from the equation when the scope is the whole company, because one team's exit is another team's entry. They matter when the scope is a region, queue, or specialist team.
This is different from measuring backlog age. Age reveals whether old cases are being hidden inside a stable total. Flow reconciliation explains why the total itself moved.
Reconcile movement before judging the team
Choose one daily cutoff and export the event history, not only the current ticket table. Group events into entries, exits, and scope adjustments. Then compare the calculated close with the actual snapshot. An unexplained difference is a measurement defect to investigate, not a rounding error to ignore.
- Freeze the scopeKeep the included channels, queues, statuses, cutoff, and time zone unchanged.
- Count every entrySeparate true new issues, reopened issues, and transfers into the chosen scope.
- Count every exitSeparate durable resolutions, audited data changes, and transfers out of scope.
- Reconcile the closeCompare the calculated closing balance with the actual open-work snapshot.
- Trace the differenceConnect every material gap to an event, identity rule, or reporting change.
Microsoft's customer service summary dashboard defines incoming cases as cases created for customers and active cases as cases currently open. It also supports filters for time, channel, queue, and representative. Those definitions are a useful base, but your event ledger must add reopens and audited scope changes.
The following operating sequence keeps that check repeatable:
- Freeze the scope, cutoff, time zone, and open-status definition.
- Count true new issues and reopened issues separately.
- Count durable resolutions, audited merges, and deletions separately.
- Reconcile the calculated closing count with the actual snapshot.
- Trace every material difference to an event or a reporting rule.
Keep one issue identity
A customer may send an email, reply on WhatsApp, and call about the same broken delivery. Counting three channel records as three new issues inflates demand. Merging them later can then create a false burst of productivity. Give the underlying problem one stable identity and preserve the channel events beneath it.
Reopens require the same discipline. A solved record that returns because the original problem persists is an entry into open work, but not new demand. Track its original issue identity, resolution event, return time, and reason. Microsoft's routing analytics overview explains that reassignment can create a new conversation and close the old one while the underlying case remains the same. That distinction prevents internal movement from becoming false customer demand.
Do not reward deletion or merging as agent output. Those events may be valid data hygiene, but they need their own audit trail and reason. Likewise, do not count a move between internal queues as a customer issue resolved. A reopen-rate review helps reveal exits that did not hold.
Read the pattern by segment
Once the total reconciles, split the flow by channel, language, issue type, priority, customer tier, region, and owning queue. Use the same issue identity across every cut. A company-wide average can hide one product defect creating demand while another queue quietly improves.
| Observed pattern | Likely explanation | Evidence to check | First decision |
|---|---|---|---|
| Entries rise while exits stay level | A demand spike or duplicate intake | Issue types, channels, campaign dates, duplicate rate | Remove the cause or add short-term intake capacity |
| Exits rise but closing backlog barely changes | Reopens or fragile resolutions | Return reasons, time to reopen, repeat contacts | Improve resolution quality before chasing more closures |
| Total stays level while old work grows | Easy cases leave while complex cases stall | Age bands, blockers, specialist ownership | Protect capacity for the old tail |
| One queue grows while another shrinks | Routing or scope transfer | Assignment history and transfer matrix | Correct routing before changing staffing |
| History changes after export | Deletion, merge, or reporting drift | Audit log, status rules, extraction time | Repair the measurement control |
Compare arrivals with a support-volume forecast, but do not treat a forecast miss as the diagnosis. Ask which issue type changed and whether the change is controllable. Compare durable exits with resolution time to see whether faster handling actually produces lasting outcomes.
Turn the diagnosis into one decision
Every weekly review should end with one named constraint and one owner. If demand rose because a release broke password recovery, fix the release path. If reopens rose, review resolution quality. If one specialist queue accumulated old cases, reserve specialist capacity. If reconciliation fails, repair the event model before setting productivity targets.
Avoid asking every agent to work faster when the evidence points elsewhere. Avoidable contact, weak routing, missing authority, repeated customer effort, and reporting drift require different decisions.
A shared operating record can help. DripTell can keep channel history, ownership, notes, and status changes together so the team can preserve issue identity and inspect the events behind the count. The purpose is not another attractive total; it is enough evidence to decide what to change. A support workflow should make those events reviewable without losing the customer's context.
When the cause is known and the queue still needs recovery, use a deliberate backlog-clearing plan. Separate that intervention from routine capacity so today's recovery effort does not create tomorrow's incoming problem.
Frequently Asked Questions
How do you calculate customer support backlog growth
Subtract the opening open-work count from the closing open-work count for a fixed scope and cutoff. Then reconcile the difference with true new issues, reopens, durable resolutions, audited merges or deletions, and transfers across the scope boundary.
Should reopened cases count as new tickets
No. They should count as entries back into open work, while retaining the original issue identity. Reporting them separately prevents repeat failure from being mistaken for fresh demand.
Can a team close more cases and still grow the backlog
Yes. The backlog grows whenever total valid entries exceed durable exits. It can also appear to grow when scope, status rules, or duplicate handling changes.
How often should backlog movement be reconciled
Daily reconciliation is useful for volatile queues. A weekly decision review can then examine stable segments, causes, and actions. Always preserve the same cutoff and time zone so comparisons remain meaningful.
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