New · Release 2026.04, Multi-tenant audit exports & SLA dashboards now liveSee changelog →
IT service management
Service catalog and service requests for IT teams
Publish a catalog of IT services and let users raise service requests against them, with approval flow — ITSM structure without a separate ticketing tool.
Support tickets · 23 open
7 urgent
TKT-2841 · Production DB slowSLA 2h left
Assigned to Rohan · Critical
TKT-2840 · VPN access for new hireSLA 1d left
Awaiting owner approval
TKT-2838 · Email forwarding setupResolved 14m
Auto-resolved by knowledge base
Product proof
Already live in the product
Backed by app modules
Running in production today: the ITSM service catalog and service request workflow.
Protected app route: /itsm
How it works
Built around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
Published service catalog
Service request intake
Approval workflow
Tenant-scoped and audited
Workflow
What teams can do here
Step 1
Define catalog items
Step 2
Users raise requests
Step 3
Route for approval
Step 4
Fulfil and track
How it works
How it works
01
Publish requestable services
Create catalog items with a name, description, category and icon. Each item carries a dynamic request form defined as a JSON field schema — you choose the fields (name, label, type, required, options) users must fill in, so a "New laptop" request and a "VPN access" request each collect exactly what fulfilment needs.
02
Set approval and a fulfilment SLA per item
Toggle approval_required on any item and set fulfillment_sla_hours (defaults to 24). When a request comes in against an item that needs approval, it is automatically routed to Pending Approval instead of straight into fulfilment.
03
Users raise service requests
Every request is auto-numbered (SR-00001, SR-00002…) and scoped to the organisation. It captures who raised it (requested_by), who it is for (requested_for), the submitted form_data and a priority (urgent / high / medium / low).
04
Approve, then fulfil against the clock
Approve, reject and fulfil are admin-only actions — the requester cannot approve their own request. On creation the fulfilment SLA due time is stamped from the catalog item; if a request is fulfilled after that deadline it is flagged sla_breached.
05
Track the queue
A stats endpoint returns totals, open requests, SLA breaches and a by-status breakdown, and the request list exports to CSV for reporting.
Example
A worked example
Say a 300-person company hires six people a month, and every onboarding used to start with a vague email to IT. The team publishes an "Employee Onboarding" catalog item whose form asks for department, start date and required software, with approval required and an 8-hour fulfilment SLA. A hiring manager raises SR-00042; because approval is required it lands in Pending Approval, and an IT admin signs it off — the manager cannot self-approve. The desk completes it in hour nine, so the request is auto-flagged as an SLA breach, and the miss shows up in the by-status stats the next morning instead of vanishing.
FAQ
Frequently asked questions
How is a service request different from a support ticket?
A service request is a request for something new (access, hardware, software) raised against a published catalog item, with its own fulfilment SLA and optional approval step. A support ticket/incident is something that is broken. They are separate models — service requests live in the ITSM catalog backend, incidents in the ticketing backend.
Can each catalog item ask for different information?
Yes. Every catalog item has its own dynamic form defined by a field schema, so a "guest Wi-Fi access" item and a "monitor replacement" item present entirely different fields. The user's answers are stored as structured form_data on the request.
Who can approve a request?
Only administrators. The approve, reject and fulfil actions are gated to admin permissions, and the same person who raised a request cannot push it through approval themselves.
What happens to the SLA if approval takes a while?
The fulfilment SLA due time is set from the catalog item when the request is created. When the request is finally fulfilled the system compares the completion time against that deadline and marks sla_breached if it is late, so slow approvals are visible in the breach count.
Is the catalog shared across all our tenants or private to us?
Catalog items and requests are organisation-scoped. Each tenant defines and sees only its own catalog and its own requests.
Can we report on request volumes?
A stats endpoint gives totals, open count, SLA-breached count and a status breakdown, and the service-request list supports CSV export for offline analysis.
Give every "can I get…" request a form and a deadline
Publish catalog items with their own dynamic forms, approval gates and fulfilment SLAs — auto-numbered requests, admin-only sign-off and a breach count that keeps the queue honest.