An employee walks up and says: "I need a laptop". Without request fulfillment such a ticket goes by email and bounces around for days before someone picks it up and delivers. With request fulfillment, it lands in the service catalog, goes through manager approval and is delivered per a set procedure. Request fulfillment is the process that standardizes IT service delivery instead of handling it ad hoc. In this article I show what an IT service catalog is, how to build one and how to grow self-service adoption so fewer requests land directly with technicians.
Request vs Incident - why it is a different category and why it matters
This is where most companies break down. They have incident management working, but all requests land in the same backlog as incidents - and get lost there because SLAs and processes differ.
Incident: The network is down. The printer will not print. The ERP system is offline. The user cannot work. Reactive, someone is upset, MTTR counts in hours.
Request: A new employee needs a laptop. I want a new Visio license. I need access to the marketing team's SharePoint. The user wants something, proactive, fulfillment time is days, not hours.
Consequences of mixing requests with incidents:
- The request waits as an incident - priority turns into chaos
- SLA for the request 5 days vs incident 2 hours - which one do you keep?
- Analytics do not distinguish requests from incidents
- Technicians work "ad hoc" without procedure
Service Portfolio vs Service Catalog - what is offered vs what is available
Service Portfolio: EVERYTHING IT can theoretically offer. Includes:
- Pipeline: planned services (new CRM in Q4)
- Live: services available now (Active Directory, Office365, Jira, VPN)
- Retired: withdrawn services (old Exchange server, StarOffice)
Service Catalog: a subset of the Portfolio - only services available NOW that the user can order. For the employee, the catalog is what they see. For the IT manager, the portfolio is strategy.
Example: The IT Portfolio contains "Custom development" as a potential service. But Custom development is not in the Catalog because you do not have capacity. Someone in marketing looks for a custom dashboard - checks the Catalog, does not find it, asks IT if it is possible, the answer is "NO". Instead they can be offered a ready Tableau license.
Most common requests - what employees usually order in IT
The categories below are a typical picture of IT orders - the order and share differ between companies. To learn your own distribution, classify historical tickets.
1. Provisioning
A new Active Directory account, email, system access. The first day of a new employee is usually several requests at once.
- Time: 1 day (if automated)
- Character: procedural, repeatable
- Best practice: workflow automation
2. Hardware
New laptop, monitor, keyboard. RAM upgrade. Replacement of damaged devices.
- Time: a few days (usually on order)
- Character: budget + procurement
- Best practice: catalog with model specs
3. Software licenses
New Office, Visio, Slack, JetBrains IDE, Adobe Creative Suite license.
- Time: 1-2 days (waiting for key/download)
- Character: approval + compliance verification
- Best practice: catalog with guidance on when to buy
4. Access and permissions
Access to team SharePoint, a database, a Jira project, a network folder.
- Time: from a few hours (if approval is fast)
- Character: technical + compliance
- Best practice: manager approval + audit trail
How to build the service catalog - a practical structure
The catalog cannot be stitched together from nothing. It has to grow out of the real requests you actually receive.
- Audit: take the last 6 months of tickets, classify them as requests vs incidents (perhaps 40/60). Group requests by category. Show top 10 categories.
- Consolidation: from the top 10 categories, turn each into a "catalog service". For example, instead of 15 separate "I need an account" tickets, build one "New Employee Onboarding" service with a form.
- Request template: for each catalog service, create a form with fields. For example, for "New Laptop":
- Employee name
- Department
- Laptop model (dropdown: Dell XPS 13, Lenovo ThinkPad, Apple MacBook)
- OS preference (Windows / Mac / Linux)
- Add-ons (second monitor, docking station)
- Workflow: who approves? Employee's manager? IT Lead? Finance (for budget)? Set the approval workflow for each service.
- Fulfillment: what happens after approval? For "New Laptop": who does it? Who communicates with the employee? Is it a technician assignment or automated handoff to procurement?
The catalog in ManageEngine SDP is the Service Catalog module. Sign in at Admin > Service Catalog and add services.
Request fulfillment workflow - 5 steps from order to delivery
Step 1: Request submission - the employee enters a request via the self-service portal or email. The request has an ID (SR-1234) and status "New".
Step 2: Routing & validation - the system checks whether the request is complete (all fields filled?). The router checks whether the request matches a process/workflow (is it in the catalog?). The request changes status to "Assigned".
Step 3: Approval - depends on the service. For "new laptop" - manager required. For "SharePoint access" - team lead required. The request waits for approval, the employee waits (SR-1234 status: Approval). After approval - status "Approved".
Step 4: Fulfillment - the IT team does the work. Procure laptop, install software, set up account, etc. If routine, it can be automated (workflow rules). Request status: "In Progress".
Step 5: Closure & verification - the employee confirms they got what they ordered. Does the laptop turn on? Does the account work? The request status changes to "Closed". Metric: time from New to Closed = fulfillment time (avg 2-5 days).
Self-service portal - how to grow adoption and cut emails
Motivate people to use the portal instead of email. How?
- Awareness campaign: email + poster + 2-minute video showing how to submit a request in the portal. Show that it is faster than email.
- Portal UX must be great: 2-3 clicks to submit, not 10. The portal must have a "find service" search (for example, "laptop" and show laptops to order).
- Feedback loop: after a request is approved, send a notification right away. After fulfillment, send a notification. The employee sees - my request is in transit.
- Gamification (optional): "This month 45% of employees used the portal. That saved 20 hours of IT time. Keep it up!"
- Disable alternative submission paths: after launching the portal, do not accept helpdesk emails - forward them to the portal. Forces adoption.
Request fulfillment metrics - what to track
KPI #1: Request fulfillment time - average time from order submission to closure. Measure it separately for each category (folder access has different time than hardware order) and set targets appropriate to the service type.
KPI #2: Self-service adoption rate - share of orders submitted via the portal instead of email or phone. Track the trend - it should grow over time. Set the target individually, based on the starting point.
KPI #3: Request volume per employee per month - number of orders per employee per month. Set your own baseline from historical data. A very high value may mean incidents are being misclassified as requests.
KPI #4: Approval rate and escalations - share of orders passing approval without escalation. A low score signals that approval is a bottleneck.
KPI #5: Requester satisfaction - after closing an order, send a short survey ("Was the order delivered as expected?"). Monitor the result over time.
FAQ
What is the difference between a Service Catalog and an IT Portfolio?
The Service Portfolio is all IT services you offer (or plan to offer), regardless of state (pipeline, live, retired). The Service Catalog is a subset of the Portfolio: only services available now, ready to order. The Catalog is what the user sees. The Portfolio is IT planning (business).
How many requests is a "normal" number in a company?
There is no single universal value: request volume depends on industry, employee turnover and IT process maturity. The best approach is to set your own baseline by classifying historical tickets into requests and incidents. If there are very few requests despite high ticket volume, request fulfillment is probably poorly defined or employees do not know about it.
Is a request the same as an incident?
No. Incident = something broke (restoring a service). Request = someone wants something new (provisioning a service). A request has a different workflow, different SLAs (not MTTR but fulfillment time), different metrics. In ManageEngine SDP these are different modules (Incident Management vs Request Management).
How do you motivate people to use the self-service portal instead of email?
1) The portal must be known - email campaign and posters, 2) the portal must be easy (a few clicks to place an order), 3) the portal must be fast (short approval time), 4) communicate real effects measured in your company, e.g. a rising share of orders via portal and shrinking fulfillment time, 5) encourage with regular summaries of benefits.
What are the main IT requests?
The most common categories are: new user accounts and provisioning, hardware (laptop, monitor), software licenses, and access/permissions to systems. Password reset is typically worth automating in the self-service portal. The exact share of categories differs between companies - it pays to know your own distribution by classifying historical tickets.
Related articles
IT self-service portal - rollout and adoption strategy Knowledge Base in helpdesk - how to reduce recurring tickets Incident management in manufacturing - severities and prioritiesWant to build an IT service catalog for your company?
Rotech Group runs an audit of IT orders, builds the service catalog in ManageEngine SDP, configures the self-service portal and trains the team. Together we set measurable targets to shorten fulfillment time.
Book a consultation →