Differentiated Support Plan¶
Support configuration — instantiates Satiation-Aware Allocation
A plan that varies support amount or type according to remaining need and expected marginal usefulness.
A Differentiated Support Plan is a configuration artifact: a standing map that assigns each member of a known recipient set a distinct support intensity and support type based on how far each still is from a satisfactory state. Its defining move is heterogeneity across a whole roster at once — rather than deciding a single next unit, it lays out "this account gets a named specialist, that one gets self-serve, this one gets a quarterly check-in" so that the scarce high-touch capacity lands where a further unit changes the most. It differs from a formula by being a curated tier map with a support modality attached to each recipient, and it is refreshed periodically rather than run continuously.
Example¶
A B2B software company has one team of twelve senior onboarding engineers and 400 enterprise accounts. Treating all 400 equally would spread the engineers into uselessness. The customer-operations lead builds a Differentiated Support Plan: every account is scored on remaining onboarding gap (integration depth achieved vs. contracted scope) and on how much a specialist hour would move that gap. Accounts already fully integrated get automated health-check emails only. Accounts stuck at 30% with a specialist likely to unblock them get a named engineer and weekly sessions. Mid-range accounts get a shared pooled queue. The plan is a single sheet: 400 rows, each tagged with a support tier and modality, reviewed each quarter. When an account crosses into "fully live," it drops to the automated tier and frees a specialist for a still-blocked one.
How it works¶
- Enumerate the set. Fix the roster of recipients or uses eligible for differentiated support; excluded ones cannot win a place in the plan.
- Read each satisfaction state. Score every member on how far it sits from its target — covered, mid-gap, or badly stuck.
- Estimate marginal usefulness per member. Judge what one more unit of each support type would change for that recipient, not just how needy it looks.
- Assign tier and modality. Write the plan: each recipient gets an intensity and a form of support (specialist, pooled, self-serve), concentrating scarce high-touch capacity on high-marginal-gap members.
Tuning parameters¶
- Number of tiers — two coarse bands vs. a fine gradient; more tiers target better but multiply administrative and fairness-explanation cost.
- Modality menu — how many kinds of support the plan can assign; a richer menu fits needs better but complicates staffing and comparison.
- Re-plan cadence — quarterly vs. monthly refresh; frequent updates track changing gaps but destabilize the recipient's assigned contact.
- Gap-vs-usefulness weighting — how much the tier follows raw remaining need vs. expected responsiveness to help; leaning on responsiveness lifts outcomes but can strand the hard-to-help.
- Floor tier — whether the lowest tier is genuine support or near-abandonment; a real floor protects everyone but consumes capacity.
When it helps, and when it misleads¶
Its strength is turning a flat "everyone gets the same" into a deliberate, defensible map of who gets what and why, so scarce intensive capacity is not diluted across the already-satisfied. Making the tier and the modality explicit lets a team justify the shape of its support portfolio.
Its failure mode is creaming[n1]: because tiers can quietly follow expected responsiveness, the plan drifts toward accounts that are easy to move and away from the stuck-and-costly ones whose gap is largest — exactly inverting the intent. A classic misuse is a "success"-optimized plan that concentrates on near-wins to flatter completion metrics while chronic cases are parked in the neglect tier. The guarding discipline is to audit the plan for who lands in the bottom tier and to keep a protected minimum of real support there — a check on the plan, not a recomputation of it.
How it implements the components¶
recipient_or_use_set— the plan is built on an explicit enumerated roster; the tiering only exists relative to that fixed set.satisfaction_state_indicator— each member is scored on remaining gap to target, which drives its placement.marginal_need_estimate— tier assignment weighs what one more unit of each support type would change per recipient.allocation_rule— the plan itself is the rule: the mapping from state to assigned intensity and modality.
It does NOT implement feedback_update_loop — the continuous re-diagnose-and-reroute loop after each interaction belongs to Personalized Learning Support; this plan is a periodically refreshed configuration, not a live loop.
Related¶
- Instantiates: Satiation-Aware Allocation — configures differentiated support intensity across a fixed recipient set by remaining need.
- Sibling mechanisms: Case Review Panel · Humanitarian Aid Prioritization · Need-Based Aid Allocation · Personalized Learning Support · Progressive Resource Allocation · Public-Service Resource Targeting · Sliding-Scale Subsidy · Triage by Marginal Benefit
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: Differentiated Support Plan operates as a case-specific gate, selection, routing, prioritization, or resource disposition because it a plan that varies support amount or type according to remaining need and expected marginal usefulness.
Independent corroboration: The frozen evidence defines Differentiated Support Plan as 'A plan that varies support amount or type according to remaining need and expected marginal usefulness', so its operative form is Decision, Gate & Allocation.
Nearest alternative: Representation, Specification & Plan — The plan makes bounded tier and modality assignments from need and marginal usefulness; its written form records the result.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Public Administration & Policy
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Public-service case management established tiered support plans that allocate scarce intervention intensity by assessed need and expected benefit.
Related originating lineages:
- Education & Pedagogy — Differentiated instruction established curated support modalities and periodic reassignment across a known learner roster.
Review resolution: Public-service case management established tiered support plans that allocate scarce intervention intensity by assessed need and expected benefit. Public-service case planning is primary and education is a constitutive alternate; portfolio management is later applicability rather than a co-origin.
Attribution caveat: The generic roster-level plan synthesizes individualized public-service and educational support practices.
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] Creaming (or cream-skimming) — the tendency of a support system judged on outcomes to concentrate on the easiest-to-help cases and shed the hardest, because they improve the visible numbers per unit of effort. It is the standard hazard whenever tiering follows expected responsiveness rather than depth of need. ↩