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.
You’ll speak to a certified consultant, not a salesperson.
ITSM in practice
Four ways ITSM implementations disappoint
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.
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.
What we do differently
- 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.
Every engagement opens with the 30-day platform review. You keep the report and the plan whether or not you work with us.
Questions we get asked
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.
Tell us what's not working
Thirty minutes, a certified consultant, and a straight answer about whether we can help with ITSM. If we can’t, we’ll say so and point you somewhere better.