ReleaseMONITIC 2026.07 — Synapse Control Plane is live: topology, blast radius & AI-driven RCASee what's new
Feature

ITIL request fulfillment that separates requests from fires

An incident is something broken. A request is something needed. Most helpdesks flatten both into one undifferentiated ticket queue, so "the VPN is down" and "please provision a laptop for Monday's new starter" compete for the same triage attention and get measured by the same clock. Monitic implements ITIL request fulfillment as its own discipline: a configurable service catalog, request workflows that run separately from incident workflows, and handling that adapts to who is asking. Requests stop masquerading as emergencies, and emergencies stop drowning in paperwork.

A service catalog that defines the path, not just the form

Free-text requests are unstructured work: every "can I get access to..." email needs a human to interpret it, route it, and remember what the process was last time. A service catalog replaces interpretation with definition. In Monitic, each catalog item — a new-starter laptop, a software license, an access grant — carries its own request workflow, so the moment a request is raised, the fulfillment path is already decided. The requester knows what to expect; the technician knows what to do; the manager knows where every open request stands. That is the ITIL-aligned model without the binder of process documents that usually comes with it.

Request workflows distinct from incident workflows

Because requests and incidents are structurally different record types in Monitic, they get different lifecycles. An incident moves through diagnosis and resolution against an urgency-driven clock; a request moves through defined fulfillment stages. Your team can report on each stream honestly — request throughput is not inflated by outages, and incident response metrics are not diluted by routine provisioning. When a request does need timing commitments, SLA management applies per-priority targets to it just as it does to incidents, and ticket automation handles the routing and assignment steps that never needed a human.

Requester-type-aware handling: internal work vs. billable work

The same request means different things depending on who raised it. When internal personnel ask for a laptop, that is internal IT work. When a customer of an MSP asks for the same thing, that is billable service delivery. Monitic's request fulfillment is requester-type-aware: it distinguishes internal personnel from billable customer work at the point of intake, so the downstream handling — and the commercial record — follows automatically. For service providers, fulfilled requests flow into billing and contracts, where delivered work connects to the client's contract, invoices, and ledger without a separate reconciliation exercise at month end.

Works with

  • Ticketing — the incident side of the desk, with live device context on every ticket.
  • SLA management — per-priority targets applied to requests and incidents alike.
  • Billing and contracts — turn fulfilled customer requests into invoiced work.
  • Automation — scripts and deployments that execute the fulfillment steps themselves.

Start your free 14-day trial or get a demo

Put requests on rails and keep incidents on the clock. Start free trial or get a demo — the full platform, free for 14 days.

← Back to Service Desk

FAQ

Frequently asked questions

How is a request different from an incident in Monitic?

They are separate record types with separate workflows. Incidents follow a diagnosis-and-resolution lifecycle; requests follow defined fulfillment stages from the service catalog. Reporting, queues, and timing commitments stay distinct, which keeps both sets of metrics honest.

Can we define our own catalog items and workflows?

Yes. The service catalog is configurable — you define the request items your organization actually offers and the fulfillment workflow behind each one. There is no fixed vendor catalog to work around.

How does Monitic know whether a request is internal or billable?

Handling is requester-type-aware. Requests from internal personnel are treated as internal IT work; requests raised on behalf of a customer are treated as billable service delivery and can flow into the billing layer with contracts, invoices, and ledgers.

Is request fulfillment an extra module?

No. It ships inside the service desk, which is part of the platform. Per-endpoint plans with no per-technician fees — see pricing.

Ready when you are

See Monitic on your own fleet

Full-featured 14-day trial · no credit card · your real fleet in the console on day one.