SERVICENOW ITSM
ServiceNow ITSM, implemented so people actually use it
ITSM is where almost every ServiceNow journey starts, and where most of the disappointment accumulates. The platform is rarely the problem. The way incident, change and the service catalogue get modelled in the first eight weeks is.
What ITSM covers
- Incident Management
- Intake, categorisation, assignment rules, major-incident handling, and the reporting that tells you whether first-line is actually resolving anything.
- Problem Management
- The process everyone buys and nobody runs. Known error records, root-cause workflow, and the link back to incident that makes it worth the effort.
- Change Management
- Standard, normal and emergency. Change models, risk scoring, CAB agenda automation, and change windows that development teams will not route around.
- Request & Service Catalogue
- Catalogue items written in the requester’s language, variable sets, order guides, and multi-stage fulfilment that does not need a human to chase it.
- Knowledge Management
- Article lifecycle, ownership, review cycles, and surfacing knowledge inside the incident form where an agent will actually read it.
- Service Level Management
- SLA, OLA and underpinning-contract definitions that match what you signed, with pause conditions that survive an audit.
- Virtual Agent & Service Portal
- Deflection that resolves rather than deflects, and a portal the business can navigate without training.
Where the work actually lands
Incident, request and change are what your service desk lives in eight hours a day. Whether they are usable is decided by modelling choices made in the first eight weeks.
WHERE IT GOES WRONG
What we see on ITSM instances that stalled
- The catalogue was written by IT, for IT
Sixty items named after internal systems, grouped by the team that owns them. Requesters cannot find anything, so they email. The fix is not more items — it is fewer, renamed around the outcome the person wants.
- Change became a queue, so teams routed around it
A weekly CAB that approves everything late teaches delivery teams to raise the record after the fact. Standard change models and pre-approved templates are what actually reduce risk, because they get used.
- Custom fields everywhere, reporting nowhere
Each team asked for two extra fields on the incident form. Two years later there is no cross-team reporting, the form takes ninety seconds to load, and every upgrade needs regression testing.
- Problem management exists only on the org chart
Problem records get opened and never closed because nobody owns the outcome and no time is allocated. It is better to run problem management on three services properly than on everything nominally.
AI ON THIS MODULE
Where AI lands first in ITSM
ITSM is where most organisations switch AI on, because the volume is here. It is also where a weak knowledge base shows up fastest.
- Now Assist for Incident
- Summarising long incident threads for the next agent, and drafting resolution notes. Useful immediately; accurate only if your work notes are.
- Now Assist in Virtual Agent
- Deflection that resolves rather than deflects. It answers from your knowledge base, so article quality is the ceiling on performance.
- AI Agent Studio on request fulfilment
- Agents that complete catalogue requests end to end. They can only fulfil what is actually modelled as a catalogue item.
- Change risk assistance
- Generated risk summaries for CAB. Worth having once change records reflect what really happened rather than being written afterwards.
Before you switch it on. The honest sequence: fix the knowledge base and the catalogue, then switch on Now Assist. Doing it the other way round produces confident wrong answers and a credibility problem you then have to undo.
How we approach ITSM
Model the process before configuring it
We agree the states, the ownership and the exit criteria on paper first. Configuration after that is quick; configuration before it is rework.
Rewrite the catalogue around outcomes
Item names in business language, grouped by what someone is trying to achieve. Usually this halves the item count.
Keep it upgradeable
Out-of-the-box where out-of-the-box works. Every deviation gets written down with the reason, so the next upgrade is a decision and not an archaeology project.
Hand it over properly
Your admins get the update sets, the design decisions and the reasoning. We are not trying to become a dependency.
ITSM, asked and answered
How long does an ITSM implementation take?
A focused incident, request and change rollout for a mid-sized organisation is typically a matter of months rather than weeks, and the variables are almost never technical — they are how quickly your process owners can make decisions, and how much legacy data you want migrated. We give you a duration and a price in the platform review, before you commit to anything.
Can you fix an ITSM implementation someone else did?
That is most of our work. We start by reading the instance rather than the documentation — update sets, custom tables, form layouts, the reporting nobody trusts — and tell you what is worth keeping.
Do we have to move to the Employee Center portal?
No. It is usually a good idea eventually, but it is a separate decision from getting ITSM right, and doing both at once is how timelines double.
Will this survive the next ServiceNow upgrade?
That is largely determined by how much you customised versus configured. We keep deviations documented and minimal, which is what makes upgrades routine.
NEXT STEP
Start with a 30-day platform review
One month, a fixed scope, and a written verdict on what your ITSM implementation needs — which you keep whether or not you continue with us.