# A service catalog people actually use · Stilla > Many service catalogs exist on paper while requests still arrive by email and phone. URL: https://stilla.eywo.digital/en/blog/service-catalog-people-use/ Language: en Last updated: 2026-10-25 [← Back to the blog](https://stilla.eywo.digital/en/blog/) Requests13 August 2026Updated 25 October 20263 min readEywo team # A service catalog people actually use Many service catalogs exist on paper while requests still arrive by email and phone. Here is how to build one where requesters know what to fill in and fulfillers know what to do. Someone in finance needs access to an application. She emails a colleague she knows in IT, who forwards it to the team most likely to own the app. There, someone notices that her manager has not approved it. A week later she asks whether it is done. Nobody knows who has it, and nobody knows when it will be finished. We often see organizations that have a service catalog that nobody uses. People call, email and walk over to the IT desk because it feels faster. Fulfillers spend their time chasing missing details instead of doing the work, and team leads have no real picture of what sits in their queue. Both sides are frustrated: the requester waits in the dark, the fulfiller works from half a brief. ## Why catalogs stay empty Catalogs usually fail for three reasons. First, they are lists without forms. A requester clicks “New virtual server” and gets an empty text box, which is no better than an email. Second, approval is unclear. The request goes out, but nobody knows who must sign off, so it either stalls or gets approved informally with no record. Third, the catalog stops at intake. What happens next, who performs which step and by when, is invisible. If the catalog gives neither requester nor fulfiller anything more than email does, people go back to email. That is not resistance. It is reasonable behavior. ## Treat the catalog as an agreement A useful catalog is an agreement between the people who need a service and the people who deliver it. Each item should answer a few questions: - **What exactly do we need to know?** A structured form, so nobody has to follow up. - **Who has to agree?** The service owner, the team lead or the change manager, depending on the request. - **When will it be done?** A due time the requester sees up front and the fulfiller plans around. - **Which fulfillment steps follow?** The sequence of tasks and the teams that perform them. One more point is easy to miss: some requests change infrastructure. A new server, more storage or a firewall opening is not just paperwork. It should go through change management, with everything that implies. ## How Stilla handles it In Stilla the request catalog is built around those questions. Each catalog item has its own form, so the requester provides what is needed at the start. Each item can require approval from the service owner, the team lead or the change manager. Approvals land in a single “To approve” queue alongside other decisions, so approvers do not hunt through several tools. A rejection always comes with a reason, so the requester knows what to change. Every catalog item carries a due time and defined fulfillment steps. Fulfillment teams see in their own queues what is waiting for them and in which order. The workflow is configurable: states, transitions and who may perform each step reflect how your organization actually works. When a request changes infrastructure, it continues as a change. Nothing is retyped or logged twice. The change then goes through impact calculation, maintenance windows and approval like any other. The requester gets what they need, and operations stay in control. Due times and fulfillment are measured in business hours, using calendars that include public holidays. Team leads get a realistic view rather than numbers distorted by weekends. ## Start small and finish it You do not need a hundred items on day one. Pick the ten most common requests, give each a short form, a clear approver and a due time, and make them work end to end. Once requesters find that the catalog gets them an answer faster than email, they will use it without being told. Fulfillers stop chasing details, team leads see where work is stuck, and everyone goes home with a little more peace of mind. The request catalog with forms, approvals, due times and fulfillment steps is included in the Standard edition. **Stilla Standard** For organisations that want a reliable CMDB and managed ITSM processes. [Compare editions →](https://stilla.eywo.digital/en/editions/) ## More articles [CMDB·25 October 2026 ### The virtual network in the CMDB: from port group to leaf switch Between a virtual machine and the physical network sits a layer most CMDBs do not see – virtual switches, port groups and host uplinks. Yet this is exactly where it is decided which services a network change will touch. Standard3 min read](https://stilla.eywo.digital/en/blog/virtual-network-in-the-cmdb/)[Governance·25 October 2026 ### NIS2 and DORA: what operations must be able to evidence Both regulations ask the same question – do you know which services an outage hits, who is responsible for them and what changed when? Without a reliable dependency map, the answers are assembled by hand, often under time pressure. Standard3 min read](https://stilla.eywo.digital/en/blog/nis2-dora-evidence/)[Rollout·15 October 2026 ### Rolling out ITSM without a six-month project Introducing a new ITSM tool does not have to mean months of workshops and consultants. Start with one area, bring over the data you already keep in Excel, and check readiness before you go live. Standard3 min read](https://stilla.eywo.digital/en/blog/itsm-without-half-year-project/)