Ask every partner the same questions about discovery, the named team, change control, customization limits and ownership after go-live before you sign. A polished proposal can still hide a vague plan, a team you never meet, and a customization approach that makes every platform upgrade costly. The questions below help you test those points, and the red flags show when an answer should slow the decision down.
Start with how the partner runs discovery
Ask the partner to describe the first four weeks of a project in detail. A strong answer covers stakeholder interviews, a review of current processes and the reasons behind them, and a ranked list of requirements that the business has signed off. If the answer is a workshop schedule with no named output, the build will probably start before anyone agrees what success looks like. A complete plan usually begins with the ServiceNow implementation approach, so compare each proposal against the same steps.
Ask how requirements get prioritized when two departments want conflicting outcomes. The partner should describe a decision route with a named business owner. A promise to accommodate everyone in the first release is a warning sign.
Check who will actually do the work
Proposals often name senior people who attend the sales meetings, then staff the project with others. Ask for the names and roles of the people who will configure the platform day to day, and ask which areas each one has delivered in production. Find out whether they are employees or subcontractors, and whether a team member can be replaced without stopping the project.
Ask for a reference from a client with a similar scope. The useful question for that client is what the partner did when something went wrong, not whether the project finished.
Ask how governance and change control will work
Every ServiceNow project changes along the way. What separates a controlled project from a drifting one is the change process: who can raise a change, who estimates its cost and schedule impact, who approves it, and where the decision is recorded. Ask the partner to show a change request from a past engagement with client details removed. If they cannot describe one, changes are probably handled by email and memory.
Look closely at customization policy and upgrade safety
Customization is where many implementations quietly become expensive to run. Ask how the partner decides between configuring standard functionality and writing custom code. A good answer names the test they apply, such as whether the platform already has a supported way to meet the requirement, and what they do when it does not. If a requirement truly needs a custom application, the partner should show how it will be built, documented and tested, which is the territory of custom application development.
Upgrades depend on your release, the plugins you run and the licences you hold. Ask the partner to explain the upgrade impact for your specific instance rather than giving a general reassurance, and check the answer against your own instance before you accept it.
Agree knowledge transfer and ownership before go-live
Ask who will own the platform after launch and what the handover includes. The minimum is documentation of configuration decisions, a list of custom components with their purpose, admin training for named staff, and a written support hand-off. Agree who holds admin access and which environment changes are made in. Training is often treated as an afterthought, and the user adoption and training work should be written into the scope rather than added at the end.
Support terms need the same care. Ask about response expectations, what is excluded and how change requests are priced after launch. If you are still deciding between building the platform with a partner and paying for ongoing help, the guide to project consulting or managed support is a useful starting point.
Recognize the red flags in a proposal
Some warning signs appear again and again in weak proposals:
- Agile or DevOps claims with no sprint cadence, release plan or named product owner
- A fixed price for a scope that has not been discovered yet
- Staff described only by job title, with no names or track record
- Data migration and integration treated as a few lines in the estimate
- Unlimited customization offered to meet every request
- No plan for training the people who run the platform after go-live
For the failure modes behind these signs, see common ServiceNow implementation pitfalls. If a proposal hits several of them, treat that as a reason to ask harder questions before deciding, not as a minor detail to negotiate later.
Frequently asked questions
How many partners should I compare before choosing one?
A short shortlist is usually enough for most buyers. Fewer makes it hard to see what is normal, and more often produces a comparison too broad to act on. Send every partner the same written scope brief so the proposals can be compared line by line.
Should I ask for a fixed price?
A fixed price only makes sense once discovery has defined the scope. Before that, ask for a discovery phase at a fixed cost, followed by a build estimate with the assumptions written out. A partner who fixes a price for an undefined scope is either padding the number or planning to recover margin through change requests.
Should the same partner implement and support the platform?
Not always. One partner knows the design decisions, which helps. The downside is that you may depend on one firm for every change. Decide which risk you prefer and write the handover terms into the contract either way.
How can I check a partner’s work before signing?
Ask for a short technical review of a sample configuration or proof of concept in a non-production instance, if your budget allows it. Confirm which plugins, licences and release features the design depends on against your own instance, not against the proposal.