By role
For the Service Desk and ITSM
Most of what arrives at your desk is not a fault, it is a request, and most of what is a fault arrives describing a symptom. Both problems are about context missing at the moment the ticket is created.
- On creationEnrichment happens as the ticket is raised, not when somebody picks it up.Where the context arrives
- NativeActions execute through ITSM connectors, so your process stays the system of record.How it fits your tooling
- ApprovedAccess and privilege changes run as procedures with the approval captured on the ticket.How requests are handled
- Written backWhat ran, who approved it and what was verified lands on the record automatically.What stops drifting
What actually costs you
Three things, and none of them is a tooling gap
These are the problems we hear described in the same words on almost every estate. Each one is structural rather than a failure of effort, which is why buying another point tool has not fixed them.
Reassignment is a tax nobody measures
A ticket routed wrong costs the desk twice and costs the customer the whole delay. Routing on keywords cannot know which service sits under the symptom or which team owns it this quarter, because neither fact is in the text of the ticket.
Access requests are volume, not difficulty
Day-one provisioning, privilege requests, quarterly reviews and lockouts are individually trivial and collectively enormous. They are also the requests most likely to be approved by whoever is quickest rather than whoever is accountable.
The CMDB is only as good as the last person who updated it
Configuration records drift because updating them is manual work at the end of a task nobody is measured on finishing. Every downstream decision that trusts the CMDB inherits that drift silently.
What changes
The two decisions that matter for your role
The mechanism is the same across the platform and is set out on the solution pages. What is worth your time here is how it lands on the specific work you are accountable for.
It writes into your process, it does not replace it
ServiceNow and equivalent platforms remain the system of record. The platform executes ITSM actions through native connectors, so tickets, approvals and closure notes live where your process already runs and where your reporting already reads from.
That matters more than it sounds. A tool that asks the desk to work somewhere new gets used during the trial and abandoned in month four.
Access requests with the approval on the record
Provisioning, privilege elevation and lockouts run as governed procedures rather than as manual steps. The manager approval is captured as part of the action, and the pre-check asserts the requester and the entitlement at the moment of execution rather than trusting the form.
Quarterly access reviews stop being a week of spreadsheet work, because the record of who was granted what, by whom, already exists.
See it on a real fault
Four walkthroughs from your side of the desk
Each one follows a specific fault end to end: what arrived, what was correlated, what ran and where the boundary of autonomy sat.
- Security OpsDay one, and the new starter cannot log inRead the walkthrough →
- Security OpsThe manager is asked before the access is grantedRead the walkthrough →
- Security OpsThe quarterly access review that eats a weekRead the walkthrough →
- Security OpsSentinel calls the user before it locks the accountRead the walkthrough →
Being straight with you
What we are not going to claim
Questions we get asked
Frequently asked questions
Do we have to move off ServiceNow?
No, and you should not. The platform executes ITSM actions through native connectors and treats your platform as the system of record. Incidents, approvals and closure notes stay where your process and your reporting already live.
How does routing know who owns a service?
From topology and the configuration records rather than from the words in the ticket. That is also why enrichment happens at creation: the ownership question is answerable from the estate, and answering it before assignment is what removes the reassignment loop.
Can it handle requests as well as incidents?
Yes, and requests are usually the better place to start, because they are high volume, highly repetitive and low blast radius. Access provisioning and privilege requests are common first candidates for exactly that reason.
What about requests that need judgement?
They escalate with the context attached, the same as incidents. The platform is explicitly not designed to approve its own access requests, and privilege elevation always carries a named human approver.
Bring us your highest-volume request type
Probably access provisioning, and probably one that is trivially simple and enormous in aggregate. We will walk through what running it as a governed procedure would look like and where the approval sits.