Multi-factor priority scoring

A triage lead who ranks the morning queue by urgency alone will still miss items that matter more to the business. A low-urgency ticket from a high-ARR account near its SLA clock can outrank a noisy P1 that has plenty of time left. Queue depth on a shared skill group can push a medium item ahead of a similar one sitting in a quieter lane. Single-field sorts hide those tradeoffs.

Multi-factor priority scoring treats ranking as a scored decision, not a manual sort. An ML model reads the fields available on each item, combines urgency, customer ARR, SLA proximity, and queue depth into one comparable score, and returns a ranked list. Staff still choose what to pull next. The model proposes order; it does not claim the work.

This page is for the operations triage lead who owns queue quality: fewer surprises at the SLA wall, clearer handoffs to agents, and a repeatable way to explain why item A sat above item B when someone asks.

The model scores open queue items that already carry the inputs needed for a fair comparison. Typical inputs:

• Urgency from the ticket or incident priority field (or an equivalent severity code your ops schema uses).
• Customer ARR (or a stable commercial tier proxy) so revenue-sensitive work is visible without burying smaller accounts.
• SLA proximity as time remaining to the next contractual target, not a binary breach flag alone.
• Queue depth for the skill, team, or work type that would own the item, so backlog pressure affects rank.

The score is a relative rank within the active queue window, not a global business priority forever. It is meant for the triage board you work from today: what to review first, what to hold, and what looks mislabeled before assignment.

The model does not:

• Assign ownership, change priority fields on the source system, or page anyone.
• Re-open closed items or invent missing commercial data.
• Override a staff decision once someone has set the working order for a shift or wave.

Related context that improves judgment sits beside the score, not inside it as a silent override. helps a lead interpret ARR and tier without conflating them with urgency. helps when two high-scoring items need a capacity check before you commit a scarce specialist.

1. Select the queue scope. Limit to the queues, products, or regions the lead owns for that window (for example, the next SLA-critical slice of the day).
2. Validate required fields. For each candidate item, confirm urgency, customer (ARR or approved proxy), and SLA timing fields are present and usable. Missing required inputs mean that item is not scored (see empty output below).
3. Score and rank. The model produces a priority score per eligible item and sorts descending so the highest-ranked work appears first.
4. Present the ranked list with factors. Each row should show the composite score and the contributing factors (urgency, ARR, SLA proximity, queue depth) so the lead can spot oddities: a high score driven only by queue depth, or an SLA-near item with weak urgency that still deserves early attention.
5. Staff set working order. The triage lead (or on-call lead) confirms, reorders, or holds items. That confirmed order is what agents pull from. The model output is advisory ranking, not the work queue itself.
6. Refresh on cadence. Re-score when the queue changes materially (new high-ARR arrivals, SLA clocks crossing thresholds, depth spikes). Do not treat a morning snapshot as truth for an evening shift without a refresh rule.

Quality here means the ranked list is explainable and stable enough to use under load. If two similar items flip-flop every refresh with no field change, treat that as a model or feature-hygiene issue before you trust the board for the day.

The model ranks items. Staff set the working order.

That separation matters when the score is right on paper and wrong for the shift:

• A top-ranked item may need a specialist who is offline; the lead parks it and promotes the next eligible item.
• Two high scores may share one scarce skill; the lead sequences them after checking effort and capacity.
• A compliance hold, customer-requested freeze, or known duplicate can demote an item that the model cannot see.

Document the rule in the triage runbook: scores refresh automatically; working order changes only when a named role confirms. Agents should not pull solely from the raw model sort when a confirmed board exists. When no confirmation has happened yet (start of shift), the ranked list is the starting proposal, not permission to auto-assign.

Audit trails should record both the model rank at decision time and the staff-set order. That split is what you use in post-incident reviews when someone asks whether the queue was “wrong” or whether the override was justified.

Return empty output (no ranked list, no implied default order) when any field required to score is missing for the candidate set you intended to rank:

• Urgency is absent, null, or not mappable to the model’s severity scale.
• Customer identity is present but ARR (or the approved commercial proxy the model was trained or calibrated on) is missing.
• SLA target or due timing needed for proximity is missing, so proximity cannot be computed.

Do not invent zeros, “unknown” mid-tier ARR, or a synthetic SLA clock to force a score. Partial queues are worse than an empty result: they look complete and hide the unscored risk.

Practical handling for the triage lead:

• Show which items were excluded and which required field failed (urgency, customer commercial, or SLA).
• Route excluded items to a data-fix or enrichment path before they re-enter scoring.
• If the entire scoped queue fails validation, keep the previous staff-confirmed working order (if any) and block new model-driven ranking until fields are complete. Do not fall back to urgency-only sort under the same “multi-factor” label.

Empty output is a quality control signal: the ranking surface refuses to pretend precision when the inputs cannot support it.

Before you rely on multi-factor scores in production triage:

• Field ownership. Urgency, ARR source, SLA clocks, and queue-depth definitions have named owners. Stale ARR or clock skew shows up as bad ranks, not as a model mystery.
• Factor visibility. Leads can see why an item ranked high; opaque scores get ignored or blindly trusted, both of which hurt quality.
• Override etiquette. Short reason codes for demotions and holds (capacity, duplicate, customer hold, data gap) keep reviews honest.
• Refresh policy. Tie re-score triggers to SLA proximity bands and inbound volume, not to every keystroke.
• Coupling to sibling signals. Use when proximity alone understates risk, and keep effort estimates out of the score unless your design explicitly includes them; otherwise use as a capacity gate after ranking.

The earned outcome is a ranked priority list that reflects urgency, commercial weight, SLA pressure, and backlog depth together, while the triage lead remains accountable for the working order agents actually follow.