how-to, master-data, enhancement requests, process ownership. Typically lives in the business itself.
security and reliability of the solution. The team that operates the controls.
servers, storage, network. May sit with application team or with a vendor.
This is the companion piece to the support model workshop article — the same substance, presented as a structured walk-through rather than as a workshop guide. Read either; they're two angles on one thing.
The support model describes how support needs are fulfilled for a service: which functions are required, what each function does, who provides it, and how the functions relate to each other. Written down, it fits on a page. Built well, it answers the only question that matters at three a.m.: who picks up?
Three links in the chain.
// The functional link
Also called the business link. Where the first line typically sits. Users come here with how-to questions, master-data issues, enhancement requests, and process-ownership concerns. The functions are usually provided by teams inside the business itself.
// The application link
Where the accountability for the solution's security and reliability rests. Typically provided by the IT service operations function. The people who operate the controls live here.
// The infrastructure link
Where the components — servers, storage, network — are supported. May be the same team as the application link, may be a vendor, may be a managed-service provider. The diagram is a map of functions, not of organisational charts.
Why two iterations.
The support model is best built in two passes:
- Logical. What functions are required? How do they relate to each other? What are the escalation paths? Drawn as a diagram with tiers (1st, 2nd, 3rd line).
- Physical. Who actually performs each function? How? When? Where? Drawn as an annotated version of the logical diagram, with names, contracts and rotas attached.
The logical model captures the architecture. The physical model captures the staffing. Most engagements can produce a useful logical model in one workshop and a draft physical model in the second.
What a finished support model contains.
- A one-page diagram showing all three links and the connections between them.
- Named owners for each function (or named teams if owners rotate).
- Severity definitions and escalation paths.
- A pager rota and a major-incident playbook.
- Service-level commitments for first response and resolution, sized to severity.
- A review cadence — quarterly, usually — for the model itself.
The valuable output is not the diagram. It is the alignment the diagram required to produce.
And a warning.
A support model produced by one person at a desk is almost always wrong. Not because the person is incompetent — because the model needs to be a contract between the people who'll run it, and a contract written by one party isn't a contract. The workshop format exists specifically to make the model a shared output, not a delivered one. If you find yourself producing one alone, stop and find the room.