Case study / IT Service Management
The platform was configured correctly. The process was wrong.
A ServiceNow estate that had been implemented faithfully against the processes it was given was redesigned around the work teams actually perform — journeys simplified before configuration, then governed through one shared backlog and a release cadence the internal team could sustain.
- 01
- shared platform backlog, replacing four queues
- 46%
- fewer steps in the redesigned request journey
- 12 → 2
- documented workarounds outside the platform
Situation
The context
Four years of implementation had produced a platform that did exactly what it had been asked to do. The processes it enforced had been inherited rather than designed, so the teams using it had built a parallel set of spreadsheets and chat channels to get work done, and the platform recorded the outcome afterwards.
People were not avoiding the platform. They were routing around a process the platform had been asked to enforce.
The first task was not configuration. It was to observe how the work is actually performed — including the workarounds, which are usually the most honest description of what the process should have been.
Intervention
The intervention
Three journeys were redesigned from observed practice before anything was configured, the four competing change queues were consolidated into one governed backlog, and the internal team was brought into the design work so the platform did not become a dependency on us.
Observation
Work traced as performed, workarounds included
Journey design
Request, incident and change simplified before build
Platform governance
One backlog, one release cadence, named owners
Enablement
Internal team designing alongside, then owning
Delivery path
Design before configuration, and adoption before the next journey.
Each journey had to be in use and holding up before the next one started. That deliberately slowed delivery, and it is why the second and third journeys took less time than the first.
Weeks 01–04
Observe
Sat with the teams performing the work, recorded the journeys as actually executed, and catalogued the workarounds and what each of them was compensating for.
Decision gateCurrent-state journeys agreed by the teams performing themWeeks 05–10
Design
Redesigned the request journey around the observed work, agreed the target for incident and change, and established the platform governance model and backlog.
Decision gateJourney design and governance model approvedWeeks 11–24
Build and adopt
Configured and released one journey at a time, each followed by an adoption period in which the workaround it replaced was formally retired.
Decision gateAdoption evidence per journey before the next beginsWeeks 25–30
Handover
Transferred backlog ownership, release cadence and design authority to the internal team, with Aevis moving to a review role.
Decision gateInternal team running a release unaided
Operating shift
Configuration follows design. It cannot substitute for it.
The engagement changed what the platform was asked to enforce, and who decides that. These are the practical shifts the case study is designed to make visible.
FromInherited process automated
→ToObserved work designed for
The workarounds were treated as evidence of the real process rather than as non-compliance to be trained out.
FromFour competing queues
→ToOne governed backlog
Platform change became a prioritisation conversation with named owners instead of four teams each convinced they were first.
FromChange when a project funded it
→ToA sustained release cadence
The platform could improve continuously, which is what stops the next four years accumulating the same debt.
FromSupplier-held design authority
→ToInternal team owning the platform
Enablement was a delivery objective, so the engagement could end without the capability leaving with it.
Evidence record
A result with its provenance attached.
The published story keeps the result, the supporting artefact and its limit together.
- 01
- shared platform backlog, replacing four queues
- 46%
- fewer steps in the redesigned request journey
- 12 → 2
- documented workarounds outside the platform
Evidence attached
- Current-state journey record, including catalogued workarounds
- Redesigned journey definitions with step counts
- Platform governance model and shared backlog
- Adoption evidence and workaround retirement record
Capabilities involved
- ITSM platform implementation
- Workflow and service-catalogue design
- Configuration management
- Platform governance
- Adoption and enablement
- Release management
- Nature of the work
- Automation only — platform workflow automation. No AI model was used in triage, routing or approval during the measureme
- Baseline
- Step counts in the request journey as executed before redesign, the four separate change queues in operation, and the twelve workarounds catalogued during observation.
- Data sources
- The client’s ServiceNow instance, its change and release records, and the observation record produced during the first phase.
- Human-control point
- Journey designs were approved by the client’s service owner and the teams performing the work; the platform backlog was prioritised by the client-chaired governance forum from the design gate onward.
- Technology used
- The client’s existing ServiceNow platform, configured during the engagement. The licences and the instance are the client’s.
- Measured result
- The redesigned request journey completed in 46% fewer steps; four change queues were consolidated into one backlog; ten of twelve catalogued workarounds were formally retired.
- Evaluation period
- The adoption period following each release, and a combined review twelve weeks after handover.
How to read these figures
Bring your context
Is your platform recording work that happens somewhere else?
Tell us where the spreadsheets and the chat channels are. They are usually the most accurate description of the process you actually need. We will start with your environment and be precise about which experience transfers.
- Response
- One working day, Monday to Friday