The Beliefs Beneath the Model: A Practical Assumption Register for Service Operations

Service operating models rarely fail because a process map is missing. They fail because a belief embedded in the model was never tested after go-live. The design may be documented, governed and audited, while the assumptions underneath it remain informal, inherited and increasingly stale. An assumption register makes those beliefs visible, assigns them an owner and forces a decision: keep, test or retire.

Why assumptions need their own governance artefact

A risk register records things that may go wrong. An issue log records things that already have. An assumption register records things that must be true for the operating model to work as intended. That distinction matters. If a service assumes that most customers will use digital channels, that suppliers will respond within two working days, or that team leaders can absorb first-line escalations without additional capacity, those are beliefs about how the world behaves. They are not decisions, and they are not risks until they are tested and found wanting.

Most operating models carry assumptions from their business case into their steady state without a review gate. The assumptions were plausible at design stage. They may even have been true during pilot. But demand mix shifts, supplier performance drifts, staff turnover changes skills coverage and customer tolerance for delay moves with the wider service environment. The model stays fixed while the beliefs beneath it expire.

A three-state classification that supports action

A useful register does not merely list assumptions. It classifies each one in a way that prompts governance action. Three states are sufficient for a first audit.

Evidence-backed. The assumption has been tested within the current review cycle using operational data, observation or a controlled sample. The evidence is recent enough to reflect current demand, staffing and supplier conditions. This does not make the assumption permanently true, but it means the organisation can rely on it for now.

Expired. The assumption was once tested or was credible at design stage, but the evidence is old, the operating conditions have changed, or the original test no longer reflects the current service. Expired assumptions are not failures. They are maintenance items. The danger is leaving them in place because no one notices that the supporting evidence has aged out.

Politically protected. The assumption is difficult to challenge because it supports a savings target, a preferred strategy, a senior sponsor's public commitment or a supplier relationship. This is the most sensitive category. It does not imply bad faith. It simply recognises that some beliefs are shielded from ordinary scrutiny. The register should mark them clearly so that governance can decide whether to test them privately, commission external evidence or accept the risk explicitly.

What to record for each assumption

A practical register can be kept in a spreadsheet or a governance module. Each entry should include a falsifiable statement, the part of the operating model it affects, the owner, the date last tested, the classification, the evidence source, the consequence if false and the next test date. Falsifiable matters. 'Customers prefer digital' is too vague. 'At least 60 per cent of routine repair requests will be made through the portal within two quarters of launch' can be tested.

The register should also record where the assumption is embedded. An assumption about supplier responsiveness may sit inside an SLA schedule. An assumption about staff skills may sit inside a workforce plan. An assumption about customer tolerance for delay may sit inside a queue design or a complaints policy. Linking each belief to its operational consequence makes the register useful to operations leads rather than merely compliance-friendly.

Worked example: the channel shift that protected itself

Consider a UK local authority revenues and benefits service. At go-live, the model assumed that 65 per cent of council tax contacts would move to the web form within two quarters, allowing telephone capacity to fall from 18 full-time equivalent advisers to 12. The web SLA was set at five working days; the telephone SLA remained at two working days. The assumption was embedded in the capacity plan, the channel strategy and the savings target.

Eighteen months later, digital take-up was high for simple balance enquiries, but complex discount and arrears cases continued to arrive by telephone. A reason-code sample showed that only 19 per cent of complex cases originated online. The reduced telephone team was handling a demand mix it had not been resourced for. Queue times rose, the two-day telephone SLA became unstable and advisers began escalating cases informally to team leaders to protect service standards. Those escalations were not in the designed model, so they consumed management capacity without appearing in the capacity plan.

The assumption was not merely expired. It was politically protected because channel shift underpinned a savings programme. No one wanted to reopen the capacity decision. The register classified it as politically protected, recorded the consequence if false and commissioned a four-week test using contact reason codes, repeat-contact analysis and queue observation. The test found that simple transactions had migrated, but complex cases had not. The corrective action was not a wholesale reversal. The service restored four telephone lines, segmented the SLA by contact complexity and introduced a callback route for cases that required document checks.

Prioritising the first tests

The first audit should not attempt to test everything. Prioritise assumptions using three factors: consequence if false, uncertainty and political sensitivity. An assumption that affects statutory deadlines, safety, vulnerable customers or supplier penalties deserves earlier attention than one that affects a internal report. An assumption with no recent evidence is more urgent than one supported by last quarter's data. An assumption that no one is willing to challenge deserves a governed test even if its operational consequence appears modest.

A simple scoring model is enough: consequence from one to five, uncertainty from one to five and protection from one to three. The highest scores form the first test batch. Tests should be proportionate. Many assumptions can be examined through a two-week data extract, a queue observation session or a structured review of supplier response logs. The point is not academic certainty. The point is to replace inherited belief with current evidence before the next change programme builds on it.

Making the register part of the operating rhythm

An assumption register only changes behaviour if it enters existing governance. Add it to service reviews, change gate approvals and post-implementation reviews. Require every significant change programme to state which assumptions it relies on and which have been tested in the past twelve months. Give each assumption an owner who is close enough to operations to notice drift, but senior enough to commission a test.

The register should sit alongside the risk register, not inside it. Risks describe exposure. Assumptions describe the conditions on which the model depends. When an assumption is tested and fails, it may become a risk, an issue or a design change. That transition is the value of the register: it turns quiet belief into an explicit management decision.

Service operating models age quietly. An assumption register makes the ageing visible before it shows up as a missed SLA, an overloaded queue or an escalation route that no one designed.