A service request catalogue for an agency

"Can you add tracking for the new landing page?" That request has at least four possible meanings, each with a different cost, and finding out which one is meant takes a round trip, a clarifying call, and usually a second round trip when the answer turns out to depend on something nobody mentioned.

The multiplier is the problem. Not the clarification itself, which is fifteen minutes, but the fact that it happens for every request, from every client, forever, and it is entirely avoidable for the requests you have already handled dozens of times.

A service catalogue is the fix, and it is a much simpler artefact than the term suggests. Atlassian describes it as an organized list of all the services your team offers, with clear request options and expectations, and is explicit about the motivating pain: requests that are out of scope for your specialty or meant for another team, where losing a few minutes puts you behind for the rest of the day.

In an agency the mis-routing is usually internal rather than cross-team. A tagging request lands with the person who does ads, sits for two days, and moves. That delay is invisible in every system you have, because the clock in most trackers starts when somebody picks it up.

The single most common way a catalogue fails is that it is written in the language of the people delivering the work. "Container configuration change" is precise and nobody outside the team will ever select it.

Atlassian's Cloud documentation gives three rules for naming request types that are worth copying verbatim. Think about how your customer would write the request, so Purchase a new monitor rather than Submit a hardware request. Break request types into smaller chunks. And avoid specialist terminology, using I need access rather than Deploy SSH key.

Translated into agency work, that means the catalogue entry is "Track a new form on the site", not "GA4 event implementation". It means "Add a new location to reporting", not "Extend the dimension table". The internal name can be whatever you like. The name the client sees has to be the sentence they would have typed anyway.

The second rule, breaking things into smaller chunks, does more work than it looks like. "Reporting change" is one entry and unestimable. "Add a metric to an existing dashboard", "Add a new dashboard page" and "Change how an existing metric is calculated" are three entries with wildly different costs and completely different risk profiles, and separating them is most of the value of the exercise.

The excludes column is the one that makes the catalogue commercially useful and the one most teams omit. An entry without exclusions is a blank cheque, because the natural reading of "track a new form" expands until it means whatever the requester needs, including the cross-domain complication nobody mentioned.

The distinction between the request rows and the incident rows is not cosmetic. Atlassian's Cloud documentation routes requests into work categories including service requests, incidents, problems and changes, and notes that request types sort requests into the correct queue and category automatically. The reason to keep them separate is that an incident interrupts and a request queues, and blurring them means either everything interrupts or nothing does.

The last row is the load-bearing one. Without it, the catalogue becomes a description of what is free, and everything not on it gets absorbed anyway. With it, the catalogue is a boundary. That boundary is what stops the drift described in scoping a retainer so it does not erode.

The catalogue only pays for itself once each entry carries a typical effort figure, and the figure has to come from history rather than from estimation. Look back at the last twenty of each type and take the median.

Use the median, not the mean, and record the spread separately. A request type with a median of two hours and a range from one to fourteen is not really one request type, it is two or three collapsed together, and the fourteen-hour cases share something you have not yet named. Finding that shared property is the highest-value output of the whole exercise, because it becomes a new catalogue entry with its own honest number.

Then stop estimating those requests. A catalogued request gets the catalogue number, and the variance averages out across a month. The time saved is not really the estimation, which is minutes. It is the negotiation, which is not.

This is also where the catalogue starts telling you things about the account. Atlassian's guidance on catalogue metrics notes that usage data shows which services are in demand based on the volume of tickets, which for an agency means you can finally see the shape of a retainer rather than just its total. A client whose requests are 70 percent "something looks wrong" is not buying analytics work, they are buying reassurance about a system that does not warrant it, and that is a different conversation and probably a different fix.

Volume by entry is also the input to automation decisions, because the entries worth automating are the frequent cheap ones rather than the rare expensive ones. Which is which is the subject of where automation pays in agency delivery.

A catalogue that contradicts the statement of work creates a conflict that will be resolved in the client's favour, because they will point at the more generous document and they will be right to.

So reconcile them explicitly. The statement of work names what is included. The catalogue names how it is requested and what a typical instance costs. Where an entry is not in the contract, it needs a stated commercial treatment: billed separately, drawn from a pool of hours, or scoped as a change. Anything left ambiguous defaults to free.

It is worth putting the catalogue in front of the client rather than keeping it internal. It reads as clarity rather than restriction, particularly the excludes column, because most clients have been burned by an agency that said yes to everything and delivered late. A menu with honest boundaries is a better sales artefact than a promise of unlimited flexibility.

The connection to scoping runs both ways. A catalogue built from history is the best possible input to the assumptions and exclusions sections of the next engagement, which is the mechanism described in scoping a fixed-fee statement of work and the reusable structure that statement of work scoping produces.

Start with six entries, not thirty. Six covers most of the volume, they can be written in an afternoon, and a catalogue that is used is worth more than a complete one that is not. Add an entry each time a request arrives twice, and let it grow from evidence rather than from imagination.