The After-Sales Queue: Rank Tickets by Impact, Not Arrival Time

Rank after-sales tickets by a composite impact score built from four factors — contract value, customer downtime, contractual response commitments, and the likelihood the same fault hits other customers — not by the order they arrived. Chronological sorting looks fair, but it spends your most expensive resource (your best technician's time) on your lowest-impact requests, purely because they landed at 8 a.m.

Why "oldest first" breaks down in after-sales

Chronological order makes sense when requests are broadly similar. In after-sales they never are. A refresher training request for a new user and a fault that has halted a production line can arrive in the same minute. A time-based rule treats them identically — and the technician, being human, starts with the easy one to bring the queue counter down.

Worse, the impact is invisible. The customer with the large contract rarely complains straight away. They wait until renewal, and then they don't renew.

The four factors behind the impact score

• Revenue: annual contract value, or total purchases over the past twelve months.
• Downtime: is the customer fully stopped, partially operating, or unaffected?
• Contractual commitment: is there a response time written into the contract, and how much of it is left?
• Recurrence risk: does the fault sit in a release or batch other customers also use? If so, fixing it today prevents ten tickets tomorrow.

Turning the factors into a number a technician reads in two seconds

Give each factor just three possible values: 0, 1, and 3. Don't build a ten-point scale — no two people will ever agree on what a 6 means.

The total runs from 0 to 12. Anything above 7 is handled today; 4–7 within 48 hours; everything below enters the normal rotation. Display the score as a single column at the top of the technician's list — not buried in a separate report.

Keep the queues separate

Critical faults, training requests, and change requests are three queues, not one. They demand different skills and carry different time promises. Merging them means your most capable technician spends the morning explaining a login screen. Split the queues first, then sort within each one by score.

Triage in practice: a hypothetical Sunday morning of twenty tickets

Suppose twenty tickets arrive before 9 a.m. Sorted chronologically, the team opens with two training requests and three billing queries. Sorted by score, only two tickets clear 7: a large-contract customer who is fully down, and a fault in a release used by eleven other customers. The first goes to your strongest technician, the second to the product team, and the remaining fifteen drop into the normal rotation — with none of them missing its promised window.

Make overriding the queue the privilege of exactly one person — the service manager — and make it conditional on a written reason logged in the ticket. That single rule kills informal queue-jumping: the phone call from a sales rep to a technician he knows, pushing a zero-impact ticket to the front. A written reason doesn't prevent exceptions; it makes them visible and reviewable at month end.

What to review monthly

• The share of tickets handled out of score order, and the reasons given.
• Average time to close for tickets scoring above 7 versus those below 4.
• The number of repeat tickets tracing back to the same root cause — a decline proves the recurrence factor is doing its job.

Start tomorrow by applying the scoring table to today's queue by hand. If the weightings hold up after two weeks, make it a calculated field in your ticketing system.