Tiered Service Catalog¶
Artifact — instantiates Stratified Treatment
Documents the service levels, response times, supports, thresholds, and responsibilities associated with each stratum.
Tiered Service Catalog is the published artifact that packages tiered treatment into a browsable, accountable document: for each service tier it names the response times, the supports included, the thresholds that apply, and who is responsible for what — and it names the baseline every tier is guaranteed regardless. Its defining feature is that it documents the tiers rather than computing who lands in one or checking whether they work. It is the reference both operators and recipients point to when they ask "what does this tier actually get?" — the treatment policy made legible and committed to paper, with a floor written in so no tier can fall off the map.
Example¶
An internal IT organization supports a large company and publishes a service catalog. It offers three support tiers: Platinum (24/7 coverage, 15-minute response target, a named engineer), Gold (business-hours coverage, one-hour response), and Silver (next-business-day response, self-service first). For each tier the catalog spells out the response and resolution targets, the supports included, eligibility, and the responsibilities on both sides — what IT commits to and what the requesting team must provide. Beneath all three sits a floor every employee is guaranteed no matter their tier: security patching, account recovery, and a three-business-day backstop for any unrouted request.
The payoff is that a team choosing or being assigned a tier knows exactly what it is buying, disputes are settled by reading the catalog rather than by escalation, and the written floor keeps the lowest tier from silently degrading into no service at all. The catalog does not decide who gets Platinum or measure whether the targets are hit — it declares, precisely, what each tier means. The specifics are illustrative.
How it works¶
- Define each tier as a bundle. For every tier, document the service levels, response times, included supports, applicable thresholds, and the responsibilities on each side.
- State eligibility, not assignment. The catalog says who qualifies for a tier; the act of placing a customer is left to a separate routing mechanism.
- Write in the floor. A universal baseline that applies across all tiers is stated explicitly, so "lowest tier" never means "nothing."
- Publish and control the version. It is a customer-facing commitment; it must be current, unambiguous, and the same document everyone reads.
Tuning parameters¶
- Tier count — more tiers fit demand more finely but complicate the catalog and blur the differences; fewer are clear but coarse.
- Contrast between tiers — a large gap in commitments makes the tiers meaningful but can make lower tiers feel thin; a small gap is equitable but may not justify the tiering.
- Floor generosity — a higher universal floor protects everyone but consumes capacity that could differentiate the upper tiers; a thin floor frees capacity but risks baseline erosion.
- Publication scope — publishing full detail builds trust and accountability but locks in commitments; keeping detail internal preserves flexibility but invites disputes.
When it helps, and when it misleads¶
Its strength is transparency and accountability: it turns "what does this tier get" from a negotiation into a document, and the written floor is the archetype's main guard against abandonment of low-intensity strata. A committed, versioned catalog is what lets a tiered system be explained and audited at all.
Its failure mode is the gap between the documented target and the lived experience — the watermelon SLA, green on the dashboard and red for the customer, where the response-time target is technically met while the underlying need goes unresolved.[n1] A catalog can look scrupulously fair while the service rots, because the artifact commits to metrics, not to outcomes. Tiers documented as neutral service levels can also harden into status markers. The discipline that guards against this is to pair the catalog with an independent outcome check — which this artifact deliberately does not perform — and to write the floor generously enough that the bottom tier stays real.
How it implements the components¶
stratum_definition— it documents each tier: who is eligible, what the tier includes, and the responsibilities that attach to it, making the strata administrable.treatment_policy— it fixes the per-tier bundle of service levels, response times, and supports, committing the treatment each tier receives to paper.minimum_service_floor— it writes in the universal baseline every tier is guaranteed, so no tier falls below a defensible minimum.
It documents; it does not route or watch. It does not own the assignment_rule that decides which customer lands in which tier — that is Segmented Customer Treatment Rules or Risk Stratification Protocol; it does not run the monitoring_feedback or test the outcome_equivalence_standard that would reveal whether the documented targets deliver fair outcomes — that is Fairness Audit by Stratum; and it does not carry the scheduled reclassification_rule that moves cases between tiers over time — that is Case Management Tiers.
Related¶
- Instantiates: Stratified Treatment — Tiered Service Catalog is the published artifact that packages and commits each stratum's treatment, with a floor.
- Sibling mechanisms: Case Management Tiers · Clinical Risk Banding · Fairness Audit by Stratum · Risk Stratification Protocol · Segmented Customer Treatment Rules · Stratum-Specific Threshold Schedule · Vulnerability-Based Support Workflow
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Tiered Service Catalog is defined in the frozen evidence as: Documents the service levels, response times, supports, thresholds, and responsibilities associated with each stratum. Its operative deployed or enacted form is therefore Rule, Policy & Commitment.
Nearest alternative: Representation, Specification & Plan — Representation, Specification & Plan 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: The defining operation is: Documents the service levels, response times, supports, thresholds, and responsibilities associated with each stratum. In the organizational_management lineage, that operation is specifically evidenced by authoritative or primary work that documents a service catalog with defined support levels, service hours, ticket routing, response commitments, and escalation. This makes organizational_management the best historical origin, while the retained alternates document contributing methods and later applications rather than being mistaken for coequal origins.
Related originating lineages:
- Operations Research — Operations research, optimization, and queueing analysis supplies a parallel or contributing lineage for the mechanism's defining operation: documents the service levels, response times, supports, thresholds, and responsibilities associated with each stratum.
- Public Administration & Policy — public_administration_policy supplies a historically relevant parallel or contributing practice for the defining operation—Documents the service levels, response times, supports, thresholds, and responsibilities associated with each stratum—but the evidence does not make it the best primary lineage.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: documents the service levels, response times, supports, thresholds, and responsibilities associated with each stratum.
Review resolution: The blind reviewers disagree on primary lineage (public_administration_policy versus organizational_management), so I adjudicated the mechanism rather than inheriting either label. The defining operation is: Documents the service levels, response times, supports, thresholds, and responsibilities associated with each stratum. In the organizational_management lineage, that operation is specifically evidenced by authoritative or primary work that documents a service catalog with defined support levels, service hours, ticket routing, response commitments, and escalation. This makes organizational_management the best historical origin, while the retained alternates document contributing methods and later applications rather than being mistaken for coequal origins. The cited UK Digital Marketplace: tiered service-desk support directly supports the mechanism-specific operation and its disciplinary lineage. I retain all independently explained historical alternates without a numeric cap. origin_mode=single_lineage records how the mechanism arose; domain_reach=universal separately records how broadly it can now be applied.
Attribution caveat: The taxonomy has no service-management domain. organizational_management is the closest primary home, with public administration and computer science retained for public and IT service implementations.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] A watermelon SLA is industry shorthand for a service-level agreement that reports green (targets met) while the customer's actual experience is red — the metric is satisfied but the outcome is not. It names the failure of committing to measurable targets that a customer can meet on paper without delivering the service that mattered. ↩