ServiceNow is often blamed for organizational inefficiencies, but the platform primarily exposes existing process flaws rather than causing them. Success requires rigorous process design, including outcome definition and stress-testing workflows against real-world scenarios. Without a solid foundation, automation simply amplifies operational dysfunction across the enterprise.
Organizations should prioritize process interrogation and frontline feedback over theoretical mapping before technical implementation. By identifying friction points through data audits and shadowing actual work, teams can redesign workflows to ensure the platform supports intended outcomes. Effective ITSM depends on intentional process ownership rather than relying on technology alone.
Let me guess. You went live on ServiceNow. Stakeholders were excited. Leadership was sold on the promise. And now, a few months in, someone in a meeting says the words that make every ITSM practitioner’s eye twitch:
“ServiceNow is slow.”
No. ServiceNow isn’t slow. Your process is slow. And the platform just made it impossible to hide that fact anymore.
The Tool Is Not the Problem
Here’s what I’ve seen across industries—banking, manufacturing, consulting—over 25 years of ITSM work: organizations spend hundreds of thousands of dollars implementing a world-class platform, and then they pour a broken process into it like concrete into a cracked foundation.
The cracks don’t disappear. They just become load-bearing.
ServiceNow is one of the most powerful ITSM platforms ever built. It can automate, orchestrate, integrate, and report on virtually every aspect of your IT operations. But it cannot—and I cannot stress this enough—fix a process you never designed.
The platform exposes your process. It doesn’t replace the thinking that should have gone into it.
Measure Twice, Cut Once
In High School, I had an amazing shop teacher. He had a saying I didn’t fully appreciate until I was three painful ITSM process implementations deep: measure twice, cut once.
That philosophy is the heartbeat of good process design.
In carpentry, the material is wood. In ITSM, the material is time, workflow, and human behavior. Cut wrong once, and you’re not just wasting wood—you’re wasting months of adoption effort, burning out your service desk staff, and eroding trust in a platform that was supposed to make things better.
Before you build a single workflow in ServiceNow, you need to answer some hard questions:
- Who owns this process end-to-end? Not who approves it—who owns it.
- What triggers this process? And what should trigger it versus what does trigger it right now?
- Where does work actually get stuck? Not where people say it gets stuck—where do tickets sit with no activity for 48+ hours?
- What decisions are humans making that could be defined? And what decisions require human judgment that will never be automatable?
These aren’t ServiceNow questions. These are process questions. And until you answer them, no amount of configuration will save you.
“But We Mapped Our Process Before Go-Live”
Good. Did you stress-test it?
There’s a difference between mapping what you think happens and documenting what actually happens. In my experience, the gap between those two things is where most ServiceNow implementations quietly die.
I’ve walked into organizations where the Change Management process on paper was clean, logical, and well-documented. The actual Change process? Change requests being approved in under 90 seconds—not because they were simple, but because nobody wanted to be the one who slowed things down. ServiceNow faithfully automated that dysfunction at scale.
Process mapping without process interrogation is just pretty documentation.
Good workflow design requires you to sit with the people doing the work. Watch them work. Ask why seven times. Push on the exceptions. Because the exceptions aren’t exceptions—they’re the real process.
What “Measure Twice” Looks Like in ITSM
Before you open a single flow designer canvas, here’s the discipline that separates implementations that stick from ones that get reworked in Year 2:
1. Define your desired outcomes first, not your desired features.
Don’t start with “we want auto-assignment.” Start with “we want 80% of P2 incidents resolved within 4 hours.” The feature follows the outcome—not the other way around.
2. Follow the ticket, not the org chart.
Most process maps reflect the hierarchy of who has authority. What you need is a map of how work actually travels—across teams, handoffs, wait states, and approvals. Shadow the ticket from open to close. You’ll find waste you didn’t know existed.
3. Name every handoff and own every SLA.
A handoff without an owner is a delay waiting to happen. Every time a ticket moves from one team or state to another, someone needs to own the clock. If you can’t assign ownership to a handoff, you haven’t finished designing the process.
4. Design for failure paths, not just happy paths.
Most workflows are designed assuming everything goes right. Real processes fail—tickets get mis-categorized, approvers are out of office, integrations break. Your process design needs to account for failure states before you build them in ServiceNow, or you’ll be patching them reactively while your service desk drowns.
5. Pilot before you scale.
Take one process. Run it through your design rigorously. Implement it in ServiceNow. Run it in production for 60 days. Then look at your data. What’s working? What’s breaking? Where are the exceptions piling up? Then scale it.
The Techno-Magic Myth
I’ve sat in rooms with executives who are somewhat convinced that once ServiceNow is live, the platform will figure it out. That AI and automation will compensate for every gap in process thinking. That the platform is smart enough to work around human process failure.
I understand where that comes from. ServiceNow markets itself boldly, and it should—it’s an exceptional platform. But even the best platform in the world is an amplifier, not a problem-solver.
Give it a clean signal—a well-designed, intentional process—and it will amplify that signal beautifully.
Give it noise—ambiguous ownership, undefined escalation paths, inconsistent categorization—and it will amplify that noise at enterprise scale.
The platform doesn’t know your business. You do. That knowledge has to come first.
Where to Start If You’re Already Live
If you’re reading this post-implementation and recognizing your organization in these words, don’t panic. This is fixable. But it requires honesty about where you are.
Start here:
Pull your aging reports. Where are tickets sitting? Long dwell times in specific states tell you exactly where your process is broken.
Run a queue audit. How old is the oldest ticket in each queue? What’s the average age? If you don’t know, your queues are managing you—you’re not managing them.
Interview your frontline staff, not your managers. The people doing the work know where the bottlenecks are. They’ve been working around them for months. Buy them coffee. Listen.
Identify your top 3 friction points. Don’t boil the ocean. Pick the three places where work slows down most reliably and design those out of your process before touching anything else.
Then go back into ServiceNow and build that—the improved process, not the old one with a fresh coat of workflow paint.
The Bottom Line
ServiceNow is a solid instrument. Like any instrument, it requires an operator who knows what they’re doing before they pick it up.
The carpenters who measure twice don’t do it because they’re slow. They do it because they’ve learned—usually the hard way—that the cost of cutting wrong is always higher than the cost of thinking first.
Invest time in your process design. Map it, interrogate it, stress-test it, own every handoff. Then build it in ServiceNow.
G.I.G.O. (Garbage-in-Garbage-out): Because the platform will do exactly what you tell it to do. Make sure you’re telling it the right thing.