Implementing ServiceNow is a significant investment in your organization’s future. However, the true value of this powerful platform can only be realized when your team effectively adopts and utilizes its features and functionalities. Oblytech’s User Adoption & Training services help your employees adopt ServiceNow, so the transition goes smoothly and use keeps growing over time.
We begin by understanding your team’s current skill levels, workflows, and pain points. This helps us tailor our training and support programs to meet your specific needs.
We provide comprehensive onboarding and role-based training to ensure that your team members have the knowledge and skills they need to use ServiceNow effectively in their specific roles.
We develop customized training programs that focus on the specific ServiceNow modules and functionalities relevant to your organization. Our training is interactive, engaging, and designed to cater to different learning styles.
We implement change management strategies to address any resistance to change and ensure a smooth transition to ServiceNow. This includes communication plans, stakeholder engagement, and ongoing support.
We offer ongoing training and support resources, including webinars, workshops, and online tutorials, to help your team stay up-to-date with ServiceNow’s evolving capabilities.
We incorporate gamification elements and incentives into our training programs to make learning fun and engaging, encouraging active participation and knowledge retention.
The decision most sponsors face is not whether people will be trained. It is whether the training is scheduled early enough to change what happens on the day the new workflow goes live. A ServiceNow release that arrives before the people who will use it know which screen to open, which request type to pick and who to call when a record looks wrong often produces the same result: requests drift back to email, the service desk absorbs the confusion, and the project is judged a failure even when the configuration works.
Adoption work therefore belongs on the critical path of the release, with its own owner, its own dates and its own exit criteria. A useful test before the go-live date is whether each user group can name the three tasks it will perform most often and can complete each one in a practice environment without help.
The live page describes role-based training, change communication and continuing resources. Those are the right categories. What a buyer should look for is how they are sequenced against the build. Training material written from a configuration that is still changing will be wrong by the time it is delivered, so the working rule in most programs is that content is drafted from the approved design, checked against a stable build, and frozen at least a short period before release.
Anything that changes after the freeze goes into a release note rather than being pushed into a rewritten course.
A single generic course fails for a practical reason. The people who raise requests, the people who approve them, the people who fulfill them and the people who run reports each touch different parts of the platform, and each group forgets what it does not use every day.
Training that teaches everything at equal depth gives every group too much of the wrong material. The better approach is to build preparation around the roles that actually carry the process, then add a short orientation for everyone else.
| User group | What they do most often | What goes wrong without preparation | Evidence that adoption is working |
|---|---|---|---|
| Requesters across the business | Raise a request, check its status, answer a follow-up | Email and chat requests continue alongside the portal | Most new requests arrive through the portal channel |
| Fulfilment staff | Pick up tasks, update them, close them with a clear resolution | Tasks are closed with vague notes, so the knowledge is lost | Resolution notes contain enough detail to reuse |
| Approvers | Approve or reject requests within a defined time | Approvals stall in personal inboxes or are granted without review | Approval queues stay within the agreed waiting period |
| Managers and team leads | Review queues, reassign work, read reports | Reports are built by hand because the standard views are unknown | Queue reviews run from platform views, not spreadsheets |
| Super users | Answer colleagues’ questions and flag defects | Questions reach the project team directly and stop being answered locally | Most first-line questions are resolved inside the business unit |
The table is a planning aid rather than a curriculum. It tells a sponsor where to spend preparation time. Requesters usually need the least time and the most reassurance. Approvers need a short guide to what they are being asked to judge and how the platform shows them the context. Super users need the most depth, because they become the second line of help once the project team steps back.
Adoption is hard to see from inside a project because the failures happen outside the system. A requester who sends an email instead of opening a case leaves no record. A fulfillment team that keeps a parallel spreadsheet produces work that looks complete in the platform but cannot be audited.
The useful signals are therefore indirect. Look at the proportion of requests arriving through each channel, the number of requests reopened after closure, the number of tasks reassigned within a short period of creation, and the number of records that have a resolution note shorter than a sentence.
Each of these can be read from standard reporting, though the baseline needs to be recorded before the change so that improvement can be shown against something real.
A common mistake is to treat a high completion rate for a training module as evidence of adoption. Completion shows attendance. It does not show that a person can raise a correct request on a busy Monday morning. A better check is a short observed task: ask a sample of users to complete a common action without help and note where they stop.
The stopping points are the content that needs revision, and they are usually more useful than any survey score.
Most adoption programs are designed as if the project team will remain available for months. In practice the team moves to the next release, and the business is left with whatever ownership was agreed at the start. The gap is closed by naming owners before go-live rather than after.
A workable arrangement assigns a content owner who keeps the guides current when the configuration changes, a super user lead in each major business unit who triages local questions, and a platform owner who decides which changes reach users and when.
Without these three roles, guidance drifts out of date within a single release cycle, and the first answer a user receives is often the wrong one.
Release communication is part of the same ownership model. Users stop reading notices that arrive too often or that describe changes they cannot see. A short, specific note that says what changed, which tasks are affected and what the user should do differently is more effective than a long bulletin.
Some programs also keep a small set of recorded walkthroughs for the tasks that change most frequently, so that updating a single recording is cheaper than rewriting a course.
Training cannot repair a process that was wrong to begin with. If approvals are unclear because the business has not decided who should approve a given spend, a guide will describe a confusing step more clearly but will not make it sensible.
The same applies to access problems, where users are trained on a screen they are not permitted to open, and to licensing questions that determine which users can perform which actions. These are real constraints, and they should be raised before the training schedule is fixed, because the training will otherwise teach people to do something they cannot do.
Organizational questions about roles, reporting lines and policy sit outside a training scope even when they are discovered during it.
The boundary also works in the other direction. A training engagement is not a substitute for a change management plan that addresses why people might resist the new process. The two should be linked, with the training covering the mechanics and the change plan covering motivation, sponsorship and the consequences of continuing with old habits.
A buyer who asks for one of these and assumes the other is included should clarify the split in writing.
Simplicity of the screen is rarely the issue. The difficulty usually lies in the rules behind the screen: which request type applies, which approval is required, what a status change triggers and who receives the notification. People who understand the rules tend to adapt quickly to a simple layout. People who do not understand them will struggle with a clean screen as much as a crowded one.
Enough means each user group can complete its core tasks unaided in a practice environment. The amount of time that takes depends on how much the work changes for that group. A group whose tasks are unchanged needs a short orientation. A group whose approvals move from email to the platform needs practice with the specific steps it will repeat.
Recording is useful for orientation and for new starters, provided each recording is tied to a version of the process and is replaced when that process changes. A recording that describes a previous configuration is worse than no recording, because it teaches the wrong steps with apparent authority.
Refusal is usually a signal about the process, the access or the incentives. Before training harder, check whether the team can complete the task at all, whether the new route is slower than the old one for the work it covers, and whether its managers are asking for the old outputs. Training that ignores these causes rarely changes behavior.
Discuss your user adoption and training requirements, and use the questions above as a checklist when the scope of the preparation work is set.
A ServiceNow adoption partner is worth hiring when it drafts training from the approved design, prepares each user group for its own tasks, and measures whether people finish real work in the platform after release. Attendance and course completion do not prove adoption; observed task completion and channel use do.
Enablement and adoption are related but separate jobs. Enablement gives people knowledge: guides, sessions and a practice environment. Adoption is the change in behaviour that follows, and it depends on things training cannot supply, such as a sponsor who retires the old email route and a queue owner who checks the new queue every day.
A digital adoption platform, meaning an in-application overlay that shows step-by-step prompts, can help with narrow, repeated tasks such as completing a catalog form. It does not replace role-based preparation, and it adds one more product to run. Decide first what the overlay would explain. If the answer is a confusing form, fixing the form usually costs less than annotating it.
When you compare adoption providers, ask for evidence on these points:
Adoption work sits beside other delivery work and cannot repair it. If the process itself is unclear, start with change management advisory. If the front door is the problem, review the Employee Center and self-service design first, because training cannot fix a portal that sends people to the wrong form.
Enablement is the knowledge people receive: guides, sessions and practice. Adoption is the lasting change in how they work. A team can be fully enabled and still send requests by email if nobody owns the new channel or closes the old one.
Not by default. An overlay suits a small number of repeated, error-prone tasks. If the problem is unclear process, poor forms or missing knowledge, fix those first, because prompts on top of a confusing screen only explain the confusion.
Start when the design is approved. Material is drafted from that design, and the sponsor needs to name owners and record baseline measures before the build ends. Starting after testing leaves too little time to freeze content and prepare super users.
Adoption after a ServiceNow go-live is a short run of checks over the first few weeks, and the first check is whether the old request route has actually closed. Rollouts stall when email, spreadsheets and a side inbox stay open as a safety net, because the new process never becomes the default and nobody can say which route is authoritative.
In most implementations the sequence has four steps. Each one has a named owner and a date agreed before go-live.
The second step is where this often goes wrong. Teams treat every redirected request as user error, when the old route was often faster for one specific job, such as an urgent change to a shared record, and the new form has no equivalent. Log those cases. They describe a gap in the design, and training cannot close a design gap.
Keep the fallback for urgent items open for a fixed period, log every use and close it once the log stops growing. An open-ended fallback is a common reason the new process stays second. The person who sets the cut-off should also own the fallback log, so that the decision to keep it open is visible to the sponsor rather than left to individual managers.
Who answers questions in those weeks is the same question covered by the platform operating model and governance work, and the rhythm for pushing changes to users after go-live belongs to change governance and release management. Settle both before the first redirected request arrives.
Treat adoption, training and help desk cover as separate pieces, each with its own owner and its own line in the contract. Adoption and training are project work with a finish line, usually set around the go-live date. Help desk cover is a running service with hours, queues and response targets.
When an offer bundles them, ask which part is priced as a project and which part is priced as a service, because the two stop at different times.
Before you compare offers, put this question to each provider.
| Element | Adoption and training | Help desk cover |
|---|---|---|
| Typical end point | A set date after go-live | Runs for the life of the contract |
| Main output | Role-based guides, sessions and observed task checks | Logged tickets, resolution notes and queue reports |
| Success signal | Users complete their core tasks without help | Requests are resolved within the agreed targets |
| Common failure | Material drafted from an early design | The same questions answered again with no fix |
A common mistake is buying help desk cover to solve an adoption problem. A desk can answer every question about a new request form for months while the old email route stays open, because nobody owns its closure. In most implementations the test is simple: if the same question arrives every week after the cut-off, the gap often sits in training or in the form, and more desk hours can hide it.
If the questions fall away and the tickets are about faults, the desk is doing its proper job. The scope of that cover is set out in help desk support for users after go-live.
Scope also splits between a project partner and a running partner. The trade-off between those two routes is covered in the guide to choosing between ServiceNow consulting and managed support. If you expect the platform to keep changing, someone must own it after the project team leaves, and that is a different job from either one. Ongoing application management is the nearest fit for that ownership.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.