There is a particular kind of excitement that comes with implementing a new IT service management platform.
The demonstrations are finished. The contract is signed. The implementation team is assembled. Suddenly there is a blank environment sitting in front of you, waiting to be built.
And the temptation is enormous: start configuring. Build the forms. Recreate the workflows. Migrate the catalog. Add the fields. Turn on the automations.
I would resist that temptation.
After years of working with service-management platforms, I have become convinced that some of the most important work happens before anyone starts configuring the tool.
A platform implementation is not really a configuration project. It is an opportunity to decide how you want service management to work.
That distinction matters.
Start with the service, not the screen
When someone asks for a new form, workflow, approval, field, or automation, my first question is rarely: how should we configure this?
My first question is: what are we actually trying to accomplish?
Those are very different conversations.
A customer might ask for another approval field when the real issue is incomplete information. A team might ask for a dashboard when the real problem is that nobody agrees on what the metric means. Someone might ask to automate a process that has never actually worked well manually.
The technology request is often only the visible part of the problem.
Before designing the solution, I want to understand who is doing the work, where they are getting stuck, what information they need, what happens next, and what outcome they are ultimately trying to achieve.
Sometimes the best requirements gathering happens by simply watching someone perform their job. That is where you discover the workarounds, duplicate steps, spreadsheets, emails, unofficial approvals, copy-and-paste processes, and little frustrations that never make it into a requirements document.
A product owner's job is to connect the service outcome, the practice design, the technical implementation, and the experience of the people actually using the platform.
Do not rebuild your old platform inside your new one
This might be the biggest lesson I would carry into another implementation.
A new ITSM platform should not automatically become a prettier version of the old ITSM platform. Yet that is often where implementations begin. We take the existing forms, workflows, custom fields, approval chains, reports, and processes and ask the new vendor: can you recreate all of this?
Usually, they can. That does not mean they should.
Every old configuration represents a decision somebody made at some point in time. Some of those decisions may still be completely valid. Others may exist because of a limitation in the previous platform, an organizational structure that no longer exists, an old audit requirement, a workaround that became permanent, a process nobody has challenged in years, or simply — because that is how we have always done it.
A platform replacement gives you permission to ask again: why do we do it this way?
My preference is to begin as close to the new platform's standard functionality as possible, then deliberately add configuration where the business need justifies it.
Customization has a cost even when the tool technically makes customization easy. Every additional rule, field, dependency, exception, workflow, and automation eventually becomes something somebody has to understand, test, troubleshoot, document, maintain, and explain.
The goal is not the most customized platform. The goal is a platform people can successfully use and sustain.
Establish ownership before configuration
Before implementation begins, I would also get very clear about decision rights.
Who owns the service-management platform? Who owns each ITSM practice? Who decides product priorities? Who determines technical feasibility? Who approves an exception to a process standard? Who decides whether something is ready for production?
Those questions can become surprisingly complicated once implementation starts.
I believe there should be a meaningful distinction between product ownership, practice ownership, and technical ownership.
The product owner should be accountable for the outcome, priority, roadmap, requirements, experience, and whether the delivered solution actually meets the need. Practice owners determine how their process should operate and what controls or standards must exist. Technical engineers and administrators determine how the solution should technically be implemented.
Those roles should work closely together, but they do not need to become the same role. That separation creates healthier decision-making and lets people operate from their strongest area of expertise.
Clean up your service catalog before you migrate it
A new ITSM platform will expose the quality of your service catalog very quickly.
Before migrating hundreds of services or request types, I would ask: who owns this service? Who fulfills it? Who can request it? Does anyone still use it? Is the name understandable to an employee who does not work in IT? Are we describing what the customer wants — or the internal team that happens to fulfill it? Can five similar requests become one dynamic experience?
This is not glamorous implementation work. It is also some of the most important work you can do.
Your portal becomes the front door to IT. If customers cannot understand the language on that front door, the technology behind it will not save the experience.
Decide what you need to measure
Reporting requirements should not be something you discover after launch.
Before configuration, I would identify the questions leadership and practice owners actually need the platform to answer. Not every report anybody has ever requested. The important questions.
For example: are customers finding what they need through self-service? Where is work waiting? Which requests are creating unnecessary effort? Are tickets reaching the correct support team? Are service targets realistic? Where are incidents repeating? Are improvements actually improving anything?
Then define the measures. A percentage without a denominator can be misleading. A service level without clear exclusions can be meaningless. A beautiful dashboard built on inconsistent data simply gives you a beautiful view of inconsistent data.
Determine the definition, source, owner, baseline, and decision each metric should support before building the dashboard.
Know your systems of record
Another conversation I would have early is: what system owns the data?
Your ITSM platform does not need to become the source of truth for everything. Applications may belong to an enterprise architecture repository. People may come from your identity platform. Devices may come from endpoint-management tools. Configuration information may live somewhere else.
The ITSM platform can consume and use enterprise information without becoming responsible for maintaining every piece of it.
This matters because duplicate ownership eventually creates duplicate data — and duplicate data eventually creates arguments about which system is correct. Define those relationships before you start building integrations.
Resist automating too early
I love automation. But I do not believe every process should be automated immediately.
First, make sure the process works. Run it. Observe it. Find the exceptions. Understand where people get confused. Then automate the stable, repeatable parts.
Automating a broken process does not fix the process. It simply allows the organization to perform the broken process faster.
Sometimes a manual pilot gives you information you could never have discovered in a design workshop. That evidence makes the eventual automation much stronger.
Define what "done" actually means
Configuration complete is not the same thing as implementation complete.
For me, something is not truly done because a developer or engineer says: it works.
It is done when the configuration works, the customer can successfully use it, the practice owner agrees the process works, support teams know what changed, knowledge exists, communications are ready, the experience has been validated, and we know how we are going to determine whether the change helped.
The technical implementation matters. But the technical implementation is only one part of the product.
My pre-configuration checklist
Before I built the first major workflow in a new ITSM environment, I would want to be able to answer these questions:
And perhaps the most important question: are we building what the organization actually needs — or simply rebuilding what it already had?
The platform is not the strategy
A great ITSM platform can enable tremendous change.
But it cannot decide what good service management should look like for your organization. That requires people. It requires discovery, judgment, governance, prioritization, experimentation, feedback, and a willingness to occasionally challenge the way things have always been done.
That is the work I would do before configuring the platform.
Because once the building begins, every decision becomes a little more expensive to undo. And I would rather spend more time asking the right questions before configuration than spend years maintaining the wrong answers afterward.
About this Field Note: The perspectives shared here are based on Nicole West's professional experience and are her own. Examples may be generalized or adapted to protect organizational confidentiality and do not represent the views, policies, or practices of any current or former employer.