Support Triage Question Set¶
Triage question set — instantiates Cooperative Communication Repair
A structured set of triage questions that pulls the specific missing facts out of a vague request and routes it to an owner, so support exchanges become actionable instead of looping.
A Support Triage Question Set is a structured, branching set of questions purpose-built for inbound requests — support tickets, service calls, help lines — that extracts the specific facts a resolver needs and, in the same pass, routes the request to whoever owns the fix. Its one defining idea is that it is domain-specialized elicitation plus routing: unlike a general asking tool, it knows exactly which fields the downstream resolver requires (environment, reproduction, impact, location) and it maps the answers to an owning team and a next step. A vague request — "it's broken," "there's a problem" — cannot be acted on, and a generic "can you tell me more?" invites another vague reply. The triage set replaces both with a categorized interrogation whose every branch elicits a decision-relevant field and ends in an assignment.
Example¶
A city's 311 service line takes a call: "there's a problem on my street." Nothing about that is actionable — no crew can be dispatched, no department owns it yet. The 311 triage question set kicks in. First it categorizes: is this a pothole, a streetlight, water, sanitation, or noise? "Streetlight." That branch then elicits exactly the fields the streetlight crew needs to work: the nearest cross-streets, the pole number if visible, whether it's fully out or flickering, whether it's a safety hazard (a dark crosswalk), and a callback number. Each answer is a field the resolver would otherwise have to chase.
The completed intake routes automatically: category "streetlight" plus location maps to the transportation department's lighting crew, with a work order that already contains everything needed to dispatch. What arrived as "there's a problem on my street" leaves as an owned, actionable ticket — no callback, no second loop. The caller's vague report was repaired not by asking them to be clearer in general, but by asking the specific questions whose answers a streetlight repair requires, and by handing the result to the team that owns it.
How it works¶
- Categorize first, then branch. An opening question sorts the request into a type; each type opens the specific field-eliciting branch its resolver needs.
- Elicit decision-relevant fields. Every branch asks only for what changes the resolution — environment, reproduction, impact, location — not open-ended "more detail."
- Gate on completeness. A request cannot advance until the fields its category requires are filled, so nothing actionable slips through half-specified.
- Route to an owner. A mapping rule turns the category and answers into an assignment: the owning team and the next step.
The distinguishing discipline is that the questions are resolver-derived: each one exists because some downstream owner cannot act without its answer.
Tuning parameters¶
- Set depth — how many questions per branch. Deeper intake yields fully-actionable tickets but frustrates users with long forms; shallower is fast but pushes work back to the resolver.
- Branching granularity — how finely categories split. Fine branches route precisely but grow a brittle tree; coarse ones are robust but dump ambiguous requests on a general queue.
- Mandatory-field strictness — whether missing fields hard-block or soft-warn. Hard gates guarantee actionable tickets but strand users who can't answer; soft gates are forgiving but let thin tickets through.
- Routing precision — how specifically answers map to an owner. Precise routing lands work on the right team fast but misfires on edge cases; loose routing is safe but adds a hand-off hop.
When it helps, and when it misleads¶
The triage set is the right tool at the front door of high-volume operational support, where the same categories of request recur, the fields each resolver needs are known, and the cost of an unrouted or under-specified ticket is a callback loop multiplied across thousands of intakes. It is, at heart, a disciplined application of the journalistic five Ws — who, what, when, where, why — turned into a routing engine.[n1]
Its failure modes come from rigidity. A fixed set frustrates the user whose problem doesn't fit any branch, forcing a real issue through a wrong category or off the rails entirely. Over time forms accrete fields nobody downstream actually uses — form bloat that taxes every user to serve a resolver who left years ago. And keyword-driven routing can confidently send a ticket to the wrong owner, adding the very hop it was meant to remove. The guarding discipline is to keep an escape hatch to a human for the atypical case, and to periodically verify that every field collected still changes some resolution — pruning the ones that don't.
How it implements the components¶
clarification_request— its body is a structured set of these, specialized to the support domain: categorized, field-targeted questions rather than open-ended asks.violated_expectation_diagnosis— the branching sorts which kind of gap the request has — missing environment, missing reproduction, missing impact — which is what determines both the follow-up and the route.repair_owner— the routing rule assigns the owning team and the next-step owner, so the repaired request lands on someone accountable for resolving it.
It does not frame the ask for tone and rapport in a general way (repair_frame, intent_marker — Clarification Script, its nearest twin) or verify that the eventual resolution was understood (shared_understanding_check — Readback / Teach-Back). A Clarification Script standardizes the cooperative tone of any ask; this triage set extracts and routes the domain-specific facts a resolver needs.
Related¶
- Instantiates: Cooperative Communication Repair — it applies the repair logic at the front door of operational support, turning vague requests into owned, actionable ones.
- Sibling mechanisms: Clarification Script · Documentation Review for Cooperative Expectations · Evidence Linking · Meeting Repair Move · Readback / Teach-Back · Relevance Reframing · Sufficiency Calibration Checklist · Clarification Protocol
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: Support Triage Question Set is defined in the frozen evidence as: A structured set of triage questions that pulls the specific missing facts out of a vague request and routes it to an owner, so support exchanges become actionable instead of looping. Its operative deployed or enacted form is therefore Decision, Gate & Allocation.
Nearest alternative: Structure, Architecture & Configuration — Structure, Architecture & Configuration can support this mechanism, but the evidence centers the concrete operation described above rather than the alternative family's defining operation.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: A standard question set prioritizing support cases is a service-operations triage tool.
Related originating lineages:
- Communication & Media Studies — Communication and media research supplies a parallel or contributing lineage for the mechanism's defining operation: a structured set of triage questions that pulls the specific missing facts out of a vague request and routes it to an owner, so support exchanges become actionable instead of looping.
- Medicine & Healthcare — Clinical triage supplies the urgency-and-severity lineage.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: a structured set of triage questions that pulls the specific missing facts out of a vague request and routes it to an owner, so support exchanges become actionable instead of looping.
Review resolution: The blind reviewers agree that organizational_management is the primary origin and differ only on alternate origin disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain convergent because the combined evidence shows independent disciplinary development. The broader reach of universal records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] The five Ws (who, what, when, where, why — often with an added how) are the classic completeness check of journalism and incident reporting: a report is not actionable until each is answered. A support triage question set operationalizes them as branch-specific fields and adds a routing rule on top. ↩