The Zendesk Service Catalog
You can build something that looks like a Zendesk service catalog in an afternoon. Whether it is one depends on which half of the definition you care about.
What a Zendesk service catalog actually is
Worth pinning down, because the word gets used for two very different things.
A catalogue in the ITSM sense is a set of defined offerings. Each item has a description, who is entitled to request it, an approval chain, a set of fulfilment tasks with owners, a cost, and a delivery target. New starter laptop. Adobe licence. Access to the finance system.
A catalogue in the everyday sense is a menu of things you can ask for. A page with buttons.
Zendesk gives you the menu convincingly. The fulfilment machinery behind it is where the gap sits.
The distinction isn't academic. It decides whether "we have a service catalogue" means a page of links or a system that knows a request is half finished.
Building the closest thing Zendesk allows
Four pieces, in this order.
Layer approvals on top where the request needs a manager to say yes. Check the current Zendesk docs for which approval capabilities your plan includes, since this area has changed.
Zendesk against a dedicated catalogue
| Capability | Zendesk | ITSM catalogue |
|---|---|---|
| Browsable list of services | ||
| Per-item intake form | ||
| Routing and SLA per item | ||
| Manager approval | Partly | |
| Fulfilment tasks with owners | ||
| Cost and chargeback per item | ||
| Entitlement by role or department | Partly | |
| Link to the asset delivered |
The four things it will not do
Fulfilment workflow. A real catalogue item fans out into tasks: procure, image, ship, create accounts, book induction. Zendesk has one ticket with one assignee. You can create child tickets by hand or with automation, and nothing sequences them or knows the parent is incomplete until all five finish.
Cost. There's no price per item, no chargeback to a cost centre, no budget reporting. Custom fields can hold a number. Nothing does arithmetic with it.
Entitlement. You can hide a form from most people with user segments and brands, and that's visibility rather than entitlement. "Only managers in Sales may request this, and only twice a year" isn't a rule Zendesk enforces.
A link to what was delivered. No asset record, so nothing connects the laptop request to the laptop, and nothing tells you next year that the licence is unused.
Sizing it and naming it
A catalogue with sixty items is a catalogue nobody browses. Start with ten to fifteen covering the requests that genuinely arrive, and add an item only when the same request turns up often enough to deserve a form.
Name things the way an employee would say them out loud. "I need a laptop", not "Endpoint Hardware Provisioning". The point of a catalogue is that somebody who doesn't know how IT is organised can still find the right door.
Give each item a description saying what happens next and roughly how long it takes. "Your manager approves it, then two to three working days" removes more chase-up tickets than any automation, because uncertainty is what makes people follow up.
Review the list every six months and delete what nobody requests. A dead catalogue item is worse than a missing one, since it advertises a service you no longer provide and somebody will eventually request it.
When to stop approximating
Two signals, and both are cheap to spot.
The first is somebody keeping a spreadsheet alongside the tickets. That spreadsheet is the data model Zendesk is missing, and it doesn't get smaller.
The second is an auditor asking who approved a request and what it cost. If you cannot answer from the tool, you've outgrown the approximation, and something like Freshservice or a full ITSM suite is the honest next step. See Zendesk ITSM features for the wider comparison, and the employee service guide for the internal setup around it.
Frequently asked questions
Can you build catalog items in Zendesk?
Only as ticket forms. Zendesk catalog items are forms with conditional fields behind them, and a Zendesk request catalog built that way looks right to the requester while lacking fulfilment tasks underneath. The spelling Zendesk service catalogue changes nothing.
Does Zendesk have a built-in service catalog?
Not as a first-class object in the ITSM sense. Ticket forms plus a help centre category get you the intake half, and packaging changes, so check the current Zendesk docs.
How many ticket forms can I have?
Multiple forms require a plan that supports them, and there is a ceiling on the number. Check your tier before designing a catalogue with forty items.
Can I add approvals to a Zendesk catalogue request?
Yes, through native approval features on some plans, a marketplace app, or side conversations plus a status field. The last of those won't satisfy an auditor.
Can a catalogue item create several tasks?
Only if you build it. Triggers or an app can spawn child tickets, and Zendesk doesn't track the parent as incomplete until they all close.
Is a help centre category good enough as a catalogue front end?
For most teams, yes. It is searchable, it needs no developer, and it keeps the catalogue next to the articles that answer questions about it.
Catalogue requests arrive twice
An employee submits the form, then emails to check it worked. Ticket Merger merges the pair before two people start fulfilling it.
Start free trial14-day free trial. No credit card required.