Effort estimation for triage

Triage queues fail in predictable ways when effort is invisible. A lead ranks by severity, customer impact, or SLA clock, then discovers that two of the top five items each need a multi-day investigation while three lower-ranked items would clear in under an hour. The queue looks rational on paper and still starves throughput.

Effort estimation for triage closes that gap. An LLM reads the request description and, when available, similar resolved cases, then returns a structured effort signal per item. Staff keep ownership of ranking. The model does not reorder the board, assign owners, or decide what ships today. It surfaces how hard each item is likely to be so priority is a conscious trade-off between urgency and cost of resolution.

(./multi-factor-priority-scoring.md)

Useful estimates need a minimum of context. The primary input is the request description: symptoms, affected systems, who is blocked, and any constraints the reporter already knows. Secondary input is similar-case history: past tickets with comparable symptoms, systems, or resolution patterns, including how long those cases actually took and what work types they required (investigation, change, coordination, wait on vendor).

The model should return effort in a form triage can use without debate over prose. A practical shape includes:

• An effort band (for example low / medium / high, or hour-scale buckets your team already uses)
• A short rationale tied to concrete signals in the description or history
• Confidence, expressed plainly when evidence is strong versus thin
• Empty or withheld output when inputs are insufficient (see below)

Avoid asking the model for a false-precision number of minutes when the description is a paragraph of vague symptoms. Bands calibrated to how your team plans the day beat fake precision.

When similar resolved cases exist, the estimate should lean on that history rather than inventing effort from first principles. When they do not, the estimate should say so and stay conservative or empty rather than inventing a confident band.

(./historical-duration-calibration.md)

Empty output is a feature, not a failure mode. If the request description is a one-line stub, a screenshot with no narrative, or a status like "broken again" with no system or impact detail, the model should not invent an effort band. The same rule applies when similar-case history is missing or the nearest matches are weak (different product area, different failure mode, or outcomes that do not map to the current ask).

Thin input that still gets a polished estimate trains leads to trust numbers that are not grounded. Prefer:

• No effort band
• A short reason: description too sparse, or no usable similar cases
• A prompt for the minimum fields needed before re-estimation (affected service, blast radius, reproduction steps, or known workaround)

Staff can still rank those items using severity and SLA alone. They simply know effort was not estimated yet, which is more honest than a medium band with no evidence.

The daily workflow stays simple. Pull the open triage set. Run estimation on items that have enough description (or after a quick enrichment pass). Review the returned bands and rationales. Then rank with effort visible alongside impact, risk, and commitments you already track.

Typical decisions the estimate supports:

• Protecting a few low-effort, high-impact clears so the queue does not become all deep investigations
• Pairing a high-effort item with a named owner and time box instead of leaving it parked at the top forever
• Splitting or clarifying items whose estimate jumped because the description mixed several unrelated asks
• Deferring ranking of items that returned empty until reporters fill the missing context

The lead still decides order. If a high-effort incident is burning a major customer, it can stay first. The point is that the cost of that choice is visible, not that effort automatically demotes hard work.

(./dependency-chain-identification.md)

Several failure modes show up quickly if the system is left unchecked.

Description gaming and optimism. Reporters learn that short descriptions yield empty estimates or soft bands, and understate complexity. Counter by requiring a minimum description quality before an item is eligible for ranking, and by logging when estimates were empty versus filled.

History bias. Similar-case matching can pull long-tail outliers or cases resolved under different tooling and staffing. Prefer recent, same-queue matches, and surface the match set so a lead can reject bad analogues.

Effort dominating the queue. If staff treat high effort as automatic deprioritization, important hard work never starts. Keep ranking human. Present effort as one factor next to impact and risk, not as a sort key that runs unattended.

False precision. Hour-level estimates from thin text create planning theater. Prefer coarse bands until calibration against actual durations is stable.

Silent model success on garbage. Never auto-fill a band when the description or similar-case set fails a minimum evidence check. Empty output plus a reason scales better than confident wrong estimates.

Start with one triage queue and a shared effort vocabulary your team already understands. Define the empty-output rules before you define the bands. Wire estimation after intake enrichment, not before, so most items have a usable description. Review a sample of estimates weekly: compare band to actual resolution shape, check that empty cases really were thin, and adjust match criteria when similar-case history keeps pulling the wrong neighbours.

Success looks operational, not flashy: fewer days where the top of the queue is all multi-day work by accident, clearer conversations about why a hard item stayed first, and no effort number attached to tickets that never had enough text or history to support one. The model estimates; the triage lead still ranks.