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 Eywo Stratum handles it
In Eywo Stratum 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.
Eywo Stratum Standard
For organisations that want a reliable CMDB and managed ITSM processes.