Support Tier Model¶
Operating model — instantiates Tiered Escalation
Arranges support into competence tiers where a case starts at the lowest tier that can resolve it and rises only when that tier is genuinely out of depth.
The Support Tier Model is the standing shape of a help organization: a ladder of tiers that differ in real capability — front-line generalists (T1), product specialists (T2), engineering (T3) — with one governing default, that every case begins and stays at the lowest tier that can resolve it safely. Its defining idea is that the ladder is not a conveyor belt. What keeps it from decaying into one is an enablement loop that pushes competence downward: each thing a higher tier resolves is written back into the lower tier's playbook and training so that, over time, the lowest-competent boundary keeps rising. The model owns the tiers and the default; it deliberately says nothing about when a specific case trips upward or what travels with it — those are other mechanisms' jobs.
Example¶
A B2B SaaS company runs a three-tier support desk. T1 agents answer account, billing, and how-to questions from a knowledge base. T2 specialists own the fiddly integration cases — webhook configs, API auth, data-mapping. T3 is engineering, reached only for genuine defects. The model's rule is explicit: resolve at T1 unless the case needs product internals T1 isn't trained on. When a new payments integration ships, T1's escalation rate spikes to 40% — every integration question goes up. Rather than tighten a trigger, the team runs the enablement loop: every T2 resolution of an integration case is distilled into a T1 runbook entry and a fifteen-minute training clip. Two quarters later T1 resolves the same class of case directly, escalation falls to ~22%, and T2 is freed for the truly novel cases. The ladder held its shape because its floor was raised, not because agents were told to escalate less.
How it works¶
- Define tiers by capability, not title. Each tier must differ in tools, access, or training that actually change what it can resolve — otherwise it is rank, not a handling level.
- Set the lowest-competent default. State the class of case each tier is expected to own outright, so "start low" is a rule an agent can apply, not a vibe.
- Run the downward enablement loop. Systematically convert higher-tier resolutions into lower-tier capability (playbooks, macros, training), so the boundary of "what T1 can competently own" moves outward release over release.
It does not specify the upward trigger or the handoff packet; a case leaves its tier when a separate criterion fires, and travels on a separate protocol.
Tuning parameters¶
- Tier count and depth — more tiers protect scarce expertise but add handoff loss and status friction; too few overload the top or strand the bottom.
- Lowest-competent threshold — how much a given tier is expected to own before escalating; raising it deflects load downward but risks under-resolution if enablement lags.
- Enablement cadence — how quickly higher-tier learnings flow back down; a fast loop keeps the floor rising, a slow one lets the ladder ossify into pure routing.
- Specialist vs. generalist breadth — wide generalist tiers resolve more first-contact but go shallower; narrow specialist tiers go deep but fragment ownership.
When it helps, and when it misleads¶
Its strength is that it gives every case a home and shields expensive expertise from routine load, while the enablement loop makes the whole structure learn rather than merely sort. Its failure mode is a ladder whose loop has been neglected: the tiers ossify, T1 becomes a routing layer that resolves nothing, and cases bounce between levels — the "escalation ping-pong" the archetype warns about. The classic misuse is measuring T1 on deflection or handle-time alone, which quietly rewards false closes and premature escalation; the tier structure then optimizes for moving cases, not solving them. The guarding discipline is to pair a resolution metric with a reopen/bounce metric and to treat every escalation as an enablement signal, in the spirit of shift-left support — resolving each class of issue at the earliest, lowest tier that can own it.[n1]
How it implements the components¶
tier_structure— it is the ladder: the set of tiers, each defined by a distinct handling capability.lowest_competent_level_rule— the governing default that a case begins and remains at the lowest tier that can resolve it, made concrete as each tier's owned case-class.training_and_enablement_loop— the downward writeback that turns higher-tier resolutions into lower-tier competence so the floor keeps rising.
It does not implement issue_classification or escalation_criteria — deciding when a case must leave its tier is Incident Severity Matrix's job; nor handoff_protocol or escalation_path, which On-Call Runbook Escalation supplies.
Related¶
- Instantiates: Tiered Escalation — supplies the standing tier structure the rest of the escalation machinery routes across.
- Sibling mechanisms: Incident Severity Matrix · Clinical Referral Pathway · Appeal Process · Management Escalation Review · Emergency Command Levels · On-Call Runbook Escalation · Approval Matrix
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Support Tier Model is defined in the frozen evidence as: Arranges support into competence tiers where a case starts at the lowest tier that can resolve it and rises only when that tier is genuinely out of depth. Its operative deployed or enacted form is therefore Representation, Specification & Plan.
Nearest alternative: Control, Automation & Runtime — Control, Automation & Runtime 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; medium confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: Tiered support is an established service-management structure matching expertise and cost to case difficulty.
Related originating lineages:
- Education & Pedagogy — Education, assessment, and instructional practice supplies a parallel or contributing lineage for the mechanism's defining operation: arranges support into competence tiers where a case starts at the lowest tier that can resolve it and rises only when that tier is genuinely out of depth.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: arranges support into competence tiers where a case starts at the lowest tier that can resolve it and rises only when that tier is genuinely out of depth.
Review resolution: The blind reviewers agree that organizational_management is the primary origin and differ only on alternate origin disagreement, encyclopedia synthesis disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain single_lineage because the combined evidence shows one traceable formative lineage. 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; high confidence.
Notes¶
The tier model is inert without its enablement loop. A ladder of levels with no downward learning is exactly the org chart the archetype's non-examples reject — it stores and routes cases but never changes where the competent boundary sits. The loop is what makes this a Tiered Escalation mechanism rather than a support bureaucracy.
[n1] Shift-left support is the practice of resolving each class of issue at the earliest and lowest-cost tier that can competently own it — pushing knowledge, tooling, and self-service down the ladder rather than routing cases up. It is the operating intuition behind the enablement loop. ↩