The oldest case deserves attention, but it is not always first. Priority combines impact, deadline, and ability to act.
Define backlog correctly
Backlog is the set of conversations that still require action. Include unassigned, active, waiting for the team, and waiting for the customer—but do not mix those states. An organised queue exposes summary, status, customer, and an SLA or goal, as Atlassian documentation describes.
Before prioritising, remove duplicates, spam, and incorrectly closed work. Confirm that “waiting for customer” has a follow-up date and internal dependencies have owners. A backlog inflated by poor states produces poor decisions.
Priority matrix
| Criterion | Question |
|---|---|
| Risk | Is safety, data, fraud, reputation, or vulnerability involved? |
| Commitment | Is there an SLA, promised date, or imminent event? |
| Impact | How many people, orders, or operations are affected? |
| Age | How long has the next action been waiting? |
| Dependency | Can the team act now or is a third party required? |
| Effort | Can a short action remove uncertainty or unblock work? |
A daily four-block ritual
- Handle risk and breached commitments.
- Assign new and unassigned work.
- Unblock dependencies and confirm owners.
- Review the aging tail to prevent silent abandonment.
- Every item has a state, priority, and next action
- The reason for priority is visible
- Waiting items have a follow-up date
- Reopened work returns with an owner
- Managers see inflow, outflow, and net change
- Old cases receive review, not only a label
Connect priority to capacity
If arrivals continuously exceed resolutions, queue sorting cannot remove the deficit. Compare created, solved, reopened, and unsolved work; Zendesk documentation treats these as distinct sets. Connect backlog to first response time, operational metrics, and routing. The goal is not to reach zero at any cost, but to prevent harm and make trade-offs explicit.
Turn this guide into an operating routine
Start with a small, observable pilot for “Customer service backlog: prioritise beyond oldest first”. Select one team, one channel, and a defined period. Record the baseline: volume, queue age, ownership, exceptions, and complaints connected to the process. Then write a short rule, name the decision owner for ambiguous cases, and document how to return to the previous flow if something fails. This design prevents an unmeasured broad rollout and creates a fair before-and-after comparison.
- An operating objective stated as one verifiable sentence
- An execution owner and a supervisor for the review
- A conversation sample covering normal cases and exceptions
- Start date, duration, and a fallback rule
- A primary metric, a safety indicator, and event sources
- A final decision: keep, adjust, expand, or retire
During the pilot, review real conversations rather than trusting the dashboard alone. Confirm that state, owner, history, and next action match what the customer experienced. Separate process failure, tool limitation, integration failure, and execution error; each cause requires a different correction. At the end, publish the approved rule where the team works, retire old instructions, and schedule another review. The desired result is not only a better number. It is an operation that can explain why performance changed and reproduce the improvement without depending on one particular person.