User journey in ITSM
ServiceNow as a platform for transforming the service experience — governance and best practices turning resistance into structured, lasting adoption.
Context
A robust platform. Underused.
ServiceNow was implemented. The processes existed. The service catalog was structured. The governance guidelines followed the best practices of the IT service management framework. And yet, users weren't operating the system as they should — or simply weren't using it at all.
The problem wasn't the tool. It was the distance between the user and the service: templates that didn't speak to real problems, a taxonomy disconnected from the everyday vocabulary of whoever needed to open a ticket, and the diffuse perception that bypassing the portal was more efficient than using it correctly.
In a large corporate environment, that distance has a measurable cost: misclassified tickets, cascading reassignments, recurring reopenings, inflated handling times and support teams overloaded with triage that should have been resolved at the source.
“The user wasn't resisting the system. They were resisting the friction the system imposed — and were unaware of the cost that resistance created for everyone.”
The project was born of the need to invert that equation — not just technically, but through the lens of experience and governance. To make ServiceNow a portal users would choose to use, understanding why it mattered for them and for the organization.
Diagnosis
Where the friction was
The starting point was to map the real friction points in the journey — not assuming the problem a priori, but systematically identifying where behavior deviated from the expected flow and the operational consequences of that deviation.
Friction point 01
Tickets opened with the wrong templates, generating successive reassignments and prolonging resolution time, with direct impact on SLAs.
Friction point 02
Low portal adherence: users preferred direct contact by email or informal channels, bypassing the structured flow and compromising traceability and governance.
Friction point 03
Recurring reopenings — a symptom of service delivered without effective resolution, often caused by imprecise triage from the moment of opening.
Friction point 04
No match between the user's natural vocabulary and the system's taxonomy. Users couldn't name their problem in the portal's terms.
Friction point 05
Templates with excessive fields or misaligned with the real process, increasing friction at opening and contributing to abandonment or inadequate completion.
Friction point 06
A lack of awareness of the ITSM process logic: how tickets are routed, the impact of correct classification, and the role of each stage in resolution.
The diagnosis showed that friction wasn't concentrated in a single point, but distributed across the whole experience of opening and following up — from the user's initial intent through to effective resolution and a quality close.
Approach
Adoption isn't imposed. It's structured.
The core hypothesis was that sustained adoption requires simultaneous intervention across three layers. Acting on just one would produce partial, unsustainable results.
Layer 01
System
Structure, templates and automation. Making the correct path genuinely easier to follow.
Layer 02
User
Understanding, behavior and autonomy. Clarity on why the new path is better than the shortcut.
Layer 03
Process
Flow, governance and service-management best practices, aligned with the organization's requirements.
“No behavior change holds without clarity on why the new path is better than the shortcut — and without the system making that path genuinely easier to follow.”
Initiatives
The pillars of execution
Behavioral analysis and semantic mapping
The research revealed a consistent pattern: on reaching the portal, users wanted to type the problem in their own words and find the template from there, without knowing the system's taxonomy. That insight underpinned the semantic mapping — gathering the expressions and linguistic variations used to describe each category, linked directly to the corresponding templates. The result was a facilitation layer that removed the dependency on prior knowledge of the catalog structure.
Template restructuring and rationalization
A complete audit of the catalog, reviewing each template for adherence to the real process and quality of completion. Redundant fields, out-of-scope questions and steps that created friction without adding value were eliminated. The rationalization reduced opening time, lowered classification errors and increased the completeness of information delivered to the teams.
Process automation and platform integration
Mapping and automating high-volume flows — incidents and requests of varying complexity — to reduce resolution time and ensure consistency. An essential part was mapping external platforms to integrate with ServiceNow: the integration with SailPoint IdentityIQ (IIQ), for example, automated identity and access tickets, eliminating manual steps. Prioritization followed volume, criticality and SLA impact.
Education, communication and change management program
A structured internal communication and change-management program — targeted campaigns, email communications, support materials and usage guides. The strategy went beyond “how to use it”: it explained the logic of the ITSM process, the impact of correct classification on handling time, and the consequences of bypassing the flow. Making the logic visible to the end user was a condition for the behavior change to hold.
Supplier enablement
Training the supplier teams responsible for service delivery, ensuring that improvements in the opening journey were matched by the quality and consistency of the support provided. Adoption only consolidates when both ends of the journey operate with the same understanding.
Knowledge base expansion
Structuring the knowledge base as permanent journey infrastructure — not a peripheral resource, but a support layer available in any phase. Articles, technical documentation by category and self-service materials made users progressively more autonomous, reducing the dependency on direct contact with support.
Sustaining
Not a project. A process.
One of the most common risks in adoption initiatives is treating change as an event: something that happens, produces results and is closed out. The logic here was structurally different.
Continuous improvement cycle
From the first changes onward, a systematic cycle of monitoring and adjustment was established — tracking usage metrics, identifying new friction points and revising templates, automations and materials as user behavior evolved. That cycle remains active, embedded in the portal's management routine.
Sustaining turns a one-off result into operational maturity. What began as an intervention became institutionalized practice — and it's that distinction that defines a real process transformation.
Impact
What changed
satisfaction on the internal NPS, measuring users' perception of support quality and the portal experience.
A measurable increase in adherence to ServiceNow as the official channel for opening and tracking tickets.
A reduction in average handling time, with a drop in reassignment volume and reopenings due to incomplete resolution.
A reduction in tickets misclassified at opening, with improved routing accuracy and information completeness.
Beyond the quantitative indicators, the most relevant transformation was structural: the portal stopped being perceived as a bureaucratic requirement and came to be recognized as the most efficient path to solving a problem — which is, in essence, the goal of any successful adoption initiative.
Support teams with more precise triage, users with greater operational autonomy, and a service process with more predictability and traceability from opening to close.
Learnings
What the project consolidated
- i.Adoption is a design and governance problem, not just a training one. Enabling the user without simplifying the system and structuring the process produces effort with no lasting result — the three dimensions have to be integrated.
- ii.The user's language is project data, not an implementation detail. A technically correct template with unfamiliar terminology still produces friction and error. The behavioral mapping started from how the user thinks, not from how the system is organized.
- iii.Process transformation requires action on both ends of the journey. Improving the experience of those who open tickets without enabling those who receive them is intervening in half the system.
- iv.Automation without integration mapping is incomplete automation. Identifying external platforms to connect (such as SailPoint IIQ) was a condition for generating real impact, not just shifting manual work.
- v.A sustainable result requires infrastructure for listening and continuous review. The monitoring cycle ensured the improvements stayed relevant as the environment evolved.
Synthesis
Sustained adoption doesn't come from an imposed system, but from a system the user chooses to use because they understand it, and because the right path is the easiest one.
Service Design in ITSM is, in the end, the work of aligning system, user and process until governance and experience point to the same place.