There is a point in almost every early conversation where you can start to see how the rest of the program is likely to unfold, and it rarely comes from anything formal like a requirements document or an RFP response. It tends to surface more subtly, usually in the kinds of questions people ask once the conversation moves past the surface and into something a little more honest.
One of the first signals often comes in the form of a simple question that carries more weight than it appears on the surface: Why are we doing this?
Depending on who is asking, that question can mean a few different things. Sometimes it comes from someone who was not part of the original decision and is trying to understand how they fit into it.
Other times, it comes from someone who has been through enough transformation efforts to know that intent and outcome do not always line up. And occasionally, it comes from someone who already senses that the answer may not be as clear as it should be.
When that question is still lingering well into a program, it usually points to something deeper than a lack of alignment. It suggests that while the organization may be aligned around the idea of change, it has not fully committed to the outcome, and that gap has a way of showing up in ways that slow everything down.
Not long after that, you tend to hear a different kind of reassurance, often delivered with confidence: our solution and processes work perfectly today.
In a narrow sense, that is almost always true. The current system does function; the processes do move work from one step to the next, and the people involved know how to navigate it.
What is less visible in that statement is the amount of effort required to keep it functioning that way, whether that is manual intervention, workarounds that have become second nature, or knowledge that lives with a small number of people rather than in the system itself.
From a distance, it can look stable. Up close, it often looks like a system that requires constant attention just to maintain that sense of stability, which is usually where the conversation begins to shift from defending the current state to examining it more closely.
That is also where a very practical suggestion tends to emerge, and it makes intuitive sense in the moment: let’s reverse engineer our current processes into ServiceNow.
On the surface, it feels like the safest path forward. If something works today, the instinct is to recreate it on a more modern platform and preserve what people are already comfortable with. The challenge is that this approach tends to carry forward the same limitations that prompted the change in the first place, only now they’re embedded in a new solution.
This is the point where the conversation has to become a little more candid, because the comparison most teams are trying to make is not a clean one. This is not an apples-to-apples transition, and treating it that way can quietly limit what the platform is capable of delivering.
The organizations that ultimately get the most value out of ServiceNow tend to approach this moment differently. Rather than trying to preserve everything as it exists today, they are willing to step back and acknowledge that some aspects of the current model are going to need to change to take advantage of what the platform can do.
That kind of shift does not require a complete overhaul, but it does require a level of honesty that can be difficult to reach early on, especially in environments where the current system has been in place for a long time.
At some point, usually after a few of these conversations, the real inflection point emerges. Someone is willing to say, in a straightforward and practical way, that there is a problem worth solving.
Not as an indictment of what has been built, and not as a dramatic turning point, but simply as an acknowledgment that the current way of working has limits, and those limits are the reason this conversation exists at all.
Until that moment happens, many programs remain in a kind of holding pattern. There is genuine interest, there is investment, and there is often visible progress, but there is also a persistent friction that shows up in delayed decisions, revisited requirements, and a tendency to fall back on familiar ways of working whenever uncertainty creeps in.
From a sales perspective, those signals are easy to recognize because they tend to appear early and remain consistent unless they are addressed directly. What is interesting is that none of this is really driven by the platform itself.
ServiceNow is flexible enough to support a wide range of operating models, which means the real question is less about what the technology can do and more about whether the organization is ready to evolve how it operates.
The conversations that lead to the strongest outcomes tend to take a different shape. They move away from defending the current state and toward understanding it, creating space for people to question assumptions without turning the discussion into a critique of past decisions. As that shift takes hold, the tone of the program begins to change in a noticeable way.
Clarity starts to replace hesitation, decisions carry more weight, data is accurate and understood, and the platform begins to feel less like a disruption and more like an opportunity to work differently in ways that are more sustainable over time.
From the outside, that can look like a smoother implementation. From the inside, it usually comes down to something much simpler. Everyone involved reached a shared understanding early on about what needed to change, and they were willing to follow through on it.