Ticket triage design patterns: what actually determines priority versus what should

Ask most MSPs how tickets get prioritized and the honest answer is some blend of who complained loudest, who called instead of emailed, and what's been sitting longest — none of which is the same thing as what's actually most consequential if it stays broken. That gap between 'what determines priority in practice' and 'what should determine it' is one of the most common sources of client dissatisfaction that has nothing to do with technical quality, because a client whose genuinely urgent problem sat behind three loud-but-minor tickets doesn't experience your technical competence, they experience your queue design.

What actually determines priority in most systems

• Contact channel — a phone call jumps a queue that an identical email sits quietly in, regardless of actual severity
• Recency and squeaky-wheel effect — a client who follows up twice moves ahead of one who submitted once and waited patiently, even if the second ticket is worse
• Whoever's available — the tech who happens to be free picks up the next ticket in the queue rather than the most urgent one across the whole board
• Vague severity labels self-assigned by whoever filed the ticket, which tend to cluster at 'urgent' regardless of actual impact because there's no cost to overstating it

What should actually determine it

• Business impact of the underlying asset — a down file server for a twenty-person office outranks a slow printer for one person, independent of who called about it
• Blast radius — one ticket about an issue affecting a whole site outranks ten tickets about ten individually minor issues
• Whether the same signal already exists as a monitoring alert with objective severity, versus a self-reported description with no independent corroboration
• SLA exposure specific to that client's contract, which is knowable in advance and shouldn't depend on who happens to be watching the queue

A queue ordered by who complained loudest optimizes for the wrong metric perfectly. It just optimizes for volume, not consequence.

The reason this connects to how Nexus keeps one tenant-isolated record for monitoring and ticketing instead of two systems bridged by a sync job is that an alert-generated ticket carries objective signal — severity, affected asset, business context — that a self-reported ticket often doesn't, and a design that can't tell the two apart at the point of prioritization is stuck defaulting to loudness. Getting this right doesn't require an AI layer at all; it requires the queue design to actually weight impact over volume, which is a decision you can make in your process today, independent of any tooling, by simply asking what data your priority field is actually built from.