The Catalogue Says One Thing, the Customer Experiences Another: A Five-Step Reconciliation

Most service catalogues are accurate about the wrong thing. They describe teams, tiers and the vocabulary of the service desk; they rarely describe the outcomes a customer actually receives. The document is signed off, published on the intranet, and then quietly ignored by everyone who matters, because the demand arriving at the front door does not match the categories on the page.

That gap is not a documentation problem. It distorts three things on which any operating model review depends: ownership, service levels and capacity. If the catalogue says Payments Support while the customer experiences why has my supplier not been paid, the catalogue has already misplaced accountability. The five steps below are a repeatable way to test what is published against what is observed.

Why catalogues drift towards the organisation chart

Catalogues are usually produced at a moment of reorganisation. Someone needs a list of what the directorates do, and the fastest route is to transcribe the structure chart into a spreadsheet. Every later review inherits those boundaries. Add a shared service centre, a managed service contract and a digital channel, and the published list describes four organisational truths and no customer journeys at all.

Three pressures accelerate the drift: a supplier that reports against contract lines rather than outcomes; a governance forum that measures availability by system rather than by task completion; and a service desk taxonomy untouched since the last large restructure. None of these is negligent. Together they make the catalogue a record of the organisation rather than of the service.

Step one: sample demand, not categories

Take a fortnight of contact records — calls, chat, email, portal submissions, and, where it exists, the queue of work arriving through messaging tools and corridor conversations. Code a random sample of 150 to 200 items against the published catalogue and record every item that does not fit. Expect between a fifth and two-fifths to be unmappable.

Read the unmappable items together. They usually cluster into three or four themes: I cannot get an answer on an invoice query, I have been passed between two teams, the self-service form failed. Those themes are the shadow catalogue — the real services, expressed in customer language. Run this exercise with a local authority revenues and benefits team and the shadow catalogue will be about evidence and eligibility, not about systems.

Step two: trace two or three end-to-end journeys

Pick two completed requests and one that failed, then trace every touch, system and team involved. Record elapsed time at each stage and the number of handoffs. Handoffs are where operating models leak. A tidy catalogue might list two services; the journey will pass through five teams, three systems and a manual re-key.

Where handoffs cross organisational boundaries — between a council and a contractor, or a trust and an integrated care board — record the contractual interface as well as the operational one. The two are rarely aligned, and the mismatch is a recurring source of delay that nobody owns.

Step three: map the workarounds honestly

Ask practitioners what they do when the process does not work. Workarounds are not misconduct; they are design feedback. Keep a simple register for two weeks: the trigger, who performed the workaround, what it bypassed, and what would have happened without it.

Look particularly for spreadsheets, shared mailboxes and personal reminder lists. These are load-bearing elements of the operating model that no catalogue admits to. One infrastructure team keeps a known-good build list in a personal drive while the catalogue names a configuration database as the source of truth. Until that discrepancy is written down, capacity planning is fiction.

Step four: test ownership against decision rights

Ownership in a catalogue is usually a name against a service. That name rarely holds the authority the service needs. Test each service against four questions: who can change the service level, who can authorise an exception, who can commit capacity, and who is accountable when the service fails a customer.

Where a service has a name but no decision rights, it has a title rather than an owner. This is increasingly common in AI-assisted operations, where a model sets routing and prioritisation but no one has been given the authority to override it, and so nobody is answerable for the queue it produces.

Step five: redraw the boundaries and re-baseline

Redraw the catalogue around the shadow themes and the traced journeys. Aim for 15 to 25 services in a mid-sized organisation, expressed in customer terms, each with an owner holding decision rights, a defined entry point, and a small number of commitments that mean something to a customer. Not 99.9 per cent availability, but invoice query answered within two working days.

Then re-baseline the numbers. Recompute volumes from the sample, rebuild service levels against journey elapsed time rather than system uptime, and recalculate capacity using the workaround register to account for hidden effort. Circulate the revised version with a short covering note explaining what changed and why, so the next review starts from evidence rather than a spreadsheet.

What to take into the operating model review

Bring four artefacts: the unmappable sample, the journey traces, the workaround register and the decision-rights test. Together they make an argument that is difficult to dismiss, because each is drawn from the organisation's own records. They also reframe the review from a design exercise into a correction, which tends to be more productive and considerably faster.

Keeping the catalogue honest

Set a quarterly cadence: re-sample demand, re-test three journeys, and confirm that each service still has an owner with authority. The catalogue will drift again, because organisations change. The purpose of the audit is not a perfect document but a shorter distance between what is published and what customers experience — which is, in the end, the only operating model that counts.