Back Office / Source date:

Service Catalogs: Defining What the Back Office Actually Delivers

Explicit catalogs with service levels ended scope disputes and made costing defensible.

Illustration of a requester turning a paper Add a supplier catalogue page with service-level, cost-basis and exclusions fields.

Almost every shared services organisation has a service catalog. Very few have one that anyone uses, and the reason is consistent: the document was written by the people who deliver the work, it lists activities rather than services, it has no unit of consumption, no price, and no exclusions. What that produces is a brochure. A service catalog design that actually changes behaviour is a different artefact altogether, closer to a price list than to a description of what the team does all day. The distinction matters because a catalogue is not documentation. It is the instrument through which a service function manages demand, and demand, not efficiency, is what determines whether a back office is expensive.

Six fields, and most catalogues have two

A usable service entry answers six questions, and the failure is almost always in the middle four. What the service is, in the requester's language. Not "vendor master maintenance" but "add a new supplier so you can raise a purchase order". If the business cannot find the service using the words they would naturally use, the catalogue does not exist as far as they are concerned. Who may request it. Role, not name, and it determines the approval path. The unit of consumption. Per invoice, per new hire, per report, per ticket, per entity per month. Without a unit there is no volume, no cost per unit, no trend and no basis for any conversation about growth. The service level, measured from the moment the requester submits. Not from when the request reaches the correct queue after being misrouted twice. Requesters experience elapsed time, and a service level that starts halfway through the process is a measurement of the provider's convenience. The cost per unit. Even where nothing is charged. A service with no price is a service with no constraint on demand. What is excluded. The single most valuable field, and the one most often absent. Exclusions are where scope creep is prevented, and writing them is uncomfortable precisely because it makes disagreements explicit early rather than late.

Test the service entry with the requesterQualitative field checks from the article; no cost, duration or consumption benchmark is supplied.
Entry fieldQuestion the entry answers
Service nameCan the requester find the service in their own words?
Requester roleWho may ask, and which approval path applies?
Consumption unitWhat counts as one unit of the service?
Service levelWhat elapsed time is measured from submission?
Unit costWhat cost basis is visible, whether billed or shown?
ExclusionsWhat is outside scope and where should it go?

Qualitative summary of this article's source text, not a measured outcome or performance estimate.

Chargeback, showback, or neither

There are three ways to attach money to a catalogue and they behave very differently. Full chargeback, where business units pay real internal money for consumption, changes behaviour fastest and generates the most conflict. It invites gaming, produces arguments about allocation at every month end, and encourages business units to seek external alternatives, sometimes legitimately. Showback, where consumption and cost are reported but not billed, captures most of the behavioural benefit at a fraction of the political cost. When a division sees that it generated four hundred and twelve expense-report corrections last quarter against a peer's ninety, the conversation happens without anyone having to invoice anyone. Blind allocation, spreading cost by headcount or revenue, is the most common and the least useful. It guarantees that the heaviest consumers are subsidised by the lightest and that nobody's behaviour changes. For most organisations building their first catalogue, showback with credible unit costs is the right starting point, with chargeback reserved for services where demand genuinely needs a price to restrain it.

The catalogue is a demand instrument

This is the part that gets lost. Once volumes are visible by service and by requesting unit, the useful questions become available: why does one division raise five times as many manual journal requests as another of the same size; why are twenty per cent of new supplier requests withdrawn before completion; which service generates the most rework and what is upstream of it. None of those questions can be asked from a document that says the finance team "maintains master data". All of them can be asked from a catalogue with units and volumes, and they are worth more than any efficiency programme you could run against the same processes.

Practical Guidance for a Service Catalog Design

  • Start with the twenty services that generate eighty per cent of volume. A complete catalogue of two hundred entries takes a year and is obsolete on publication.
  • Write every entry in the requester's words. Test it by asking someone from the business to find three services without help.
  • Give every service a unit of consumption before you give it a price. Volume data is useful immediately; pricing can follow once you trust the counts.
  • Publish exclusions explicitly. What the service does not cover, and where the requester should go instead.
  • Measure service levels from submission. Include routing and clarification time. It is the number the requester already believes.
  • Start with showback, not chargeback. Visibility does most of the work and creates a fraction of the arguments.
  • Review the catalogue quarterly against actual demand. Services nobody requests should be retired; recurring requests that fit nothing should become entries.
  • Route exceptions through the catalogue rather than around it. An urgent request from a senior person is a service level, not an absence of process. Record it as one.

The Regional Angle

For Gulf groups the service catalogue has acquired a second life this year, and it is not an operational one. Shared services centres here almost always serve legally separate entities: a Dubai holding structure, mainland operating companies, several free zone entities, a Saudi subsidiary, sometimes an Egyptian or Indian delivery arm. Every service the centre provides to those entities is an intercompany transaction, and 2019 is the year that stopped being a bookkeeping detail. Two developments converged. Saudi Arabia issued transfer pricing bylaws earlier this year, bringing formal documentation requirements to a market that had not previously had them. And the UAE introduced economic substance requirements this spring in response to international commitments, putting the question of what activity actually occurs in which entity firmly on the agenda. Both regimes ask a version of the same question: what services were provided, to whom, on what basis, and is the charge defensible. A shared services function with a catalogue containing services, units, volumes and unit costs can answer that in an afternoon. One with a management allocation spread by headcount cannot answer it at all, and the tax adviser will say so. Value added tax sharpens the point further. Intercompany service charges between separate taxable persons are generally supplies, and where entities are not in the same tax group, they carry tax and require proper documentation. That makes the catalogue's unit prices a tax-relevant record rather than an internal management convenience. Groups that built their catalogue before 2018 should revisit it with the tax team present; the entries may be operationally sound and fiscally awkward. There is a structural constraint worth checking too. Free zone entities operate under licensed activity scopes, and a centre established in a zone may not be licensed to provide the full range of services it is in practice providing to mainland affiliates. That is a licensing question rather than a catalogue question, but the catalogue is how it becomes visible, which is one reason some groups quietly resist writing one. Finally, two practical regional notes. Publish the catalogue in Arabic as well as English where the requester population is mixed, because a catalogue people cannot read is a catalogue people phone instead. And design deliberately for the request that arrives by phone from someone senior. It will happen, it is not going to stop happening, and the choice is between logging it as an expedited service with a recorded approver or pretending the process was followed.

The objection worth taking seriously

The objection is that service catalogues are bureaucracy that service functions build for themselves. They consume months of workshops, they produce a document that is out of date within two quarters, and their main observable effect is that getting a supplier set up now requires a form where previously it required a phone call. The business experiences the catalogue as a new obstacle and routes around it, which is how shadow processes get built. The harder version attacks internal markets directly. Chargeback simulates a market without the thing that makes markets work, which is the option to buy elsewhere. Business units cannot take their payroll processing to a competitor, so the internal price is not a price; it is an allocation with a story attached. What it reliably produces is gaming: batching requests to reduce counts, reclassifying work to cheaper service lines, arguing about cost drivers at every month end, and in the worst cases, hiring shadow finance staff in the division to avoid a charge that the group is paying for anyway. A fake market can be worse than an honest overhead. Both criticisms are fair against the way catalogues are usually implemented, and both are avoidable. Keep the catalogue small enough to maintain, write it for requesters rather than for the operating model, and use showback rather than chargeback unless there is a specific demand problem that needs a price to solve it. The test of whether it is bureaucracy is straightforward: if the catalogue only produces reporting, it is. If it is generating conversations about why demand looks the way it does, and if the answers are changing things upstream in the business, then it is doing the job, and the document is just where the job happens to be written down.

Common Questions

How detailed should the catalogue be?

Twenty to forty services for a typical mid-market shared services function. Detailed enough that each entry has a genuine unit of consumption, coarse enough that a person can read the whole thing. Catalogues with hundreds of entries are inventories of tasks, not services.

Do we need a ticketing system first?

No, but you need a way to count. A catalogue without volume data cannot answer any of the questions that justify it. A shared mailbox with a tagging discipline is enough to start; the tooling can follow once the definitions are stable.

Who owns the catalogue?

The service provider drafts it, the business signs it off. A catalogue ratified only by the function that wrote it has no authority when someone disputes a service level or an exclusion.

What should we expect over the next twelve months?

Expect intercompany service charges to attract far more scrutiny across the Gulf as the new substance and transfer pricing requirements bed in, which makes documented services and defensible unit costs a compliance asset rather than an administrative luxury. Expect self-service portals to keep pushing catalogues towards a consumer shape, searchable and status-tracked. And expect automation programmes to keep exposing catalogues that describe activities instead of services, because you cannot automate a service you have not defined.


Service Catalog Design — we define the twenty services that carry your volume, attach units and costs that survive a tax review, and turn the catalogue into a demand conversation instead of a brochure.

Continue reading

Talk to OPS

Start with the operating problem.