We are a ServiceNow Premier Partner, so you can read this as self-interested. It is. These are also the questions we would want a customer to ask us, and the answers we would expect any good partner to give without hesitating.
1. Who will actually do the work?
Ask for names and certifications of the people who will be on your project, not the firm’s totals. Ask whether the architect who scoped the work will be on it. A proposal built by one team and delivered by another is the most common cause of the gap between what was promised and what arrived.
2. What have you delivered that looks like this?
Not “we have done ITOM”. Which customer, what scale, what went wrong and what they would do differently. A partner with real experience has stories about what went wrong. One without has a slide.
3. How much of this will be configuration and how much custom code?
The right answer leans heavily towards configuration and names each deviation. Custom code is sometimes needed. Custom code proposed to avoid a process conversation is a warning sign, and you will pay for it at every upgrade.
4. How will you handle our data?
For a CMDB or HR engagement, the data work is the engagement. Ask how they will assess data quality before building, and what they will leave behind to keep it healthy. If the answer is “we will migrate what you have”, expect what you have, with the same problems, in a new tool.
5. What does “done” look like, in writing?
Acceptance criteria per deliverable, a test approach (ask about ATF), and a definition of hypercare. Vague acceptance turns into arguments about scope at the worst possible time.
6. What happens at the next upgrade?
Everything built should upgrade cleanly. Ask how they build to make that true: scoped applications, platform defaults, source control, automated tests. Then ask what their customers’ last upgrade cost.
7. How do you work with ServiceNow itself?
Partner tier tells you something. More useful is whether ServiceNow’s own services teams have brought the partner in on complex work, whether they have products on the Store, and whether they keep pace with releases. A partner who is a release behind will design you a platform that is a release behind.
8. Where are your people, and does that matter for us?
Offshore delivery is normal and often sensible. What matters is that the people making design decisions are close to you, that the security model covers the whole team, and that any regulatory requirement for onshore or cleared staff is met and written down.
9. What are your security controls?
ISO 27001 is the baseline. Beyond the certificate, ask how they access your instance, whether they copy your data anywhere, and how they offboard access at the end. A partner with a clear trust page has answered these questions before and is not improvising.
10. What will you tell us no to?
Good partners say no. No to a custom app where a module exists. No to switching on Otto on a knowledge base that is not ready. No to a timeline that skips testing. Ask for an example from a past engagement. If they cannot think of one, they have not been saying it.
What we say when asked
Our answers are on this site: the people and certifications on the about page, the stories on customers, the controls on security and trust, and the process on each service page. If you are running a selection, send us the questions and we will answer them in writing.
