Every ERP sales team is ready for the questions buyers usually ask. Does it handle multiple warehouses? Does it connect to our e-commerce store? What is the price per user? Those answers are rehearsed, and they are usually true.
The questions that decide whether your project goes well are different. They are about who will actually do the work, what the system will cost after year one, what you are responsible for, and what happens when something goes wrong. Most buyers never ask them, not because the answers are hidden, but because nobody told them to ask.
Our principal advisor spent close to a decade on the vendor side of ERP implementations, writing and presenting the proposals. This list comes from that side of the table.
What is an ERP vendor?
An ERP vendor is the software company that makes the system, or the partner that sells and implements it on their behalf. Often they are two different companies: one owns the software, and a local partner configures it, moves your data and trains your team. Ask the questions below of both, and find out early which one you will actually sign with.
The ten questions, in short
- Can you run the demo on our scenarios, with our kind of data?
- What did you configure or build to show us that?
- Who exactly will work on our project, and what happens if they leave?
- Can we speak to a client like us, including one whose project struggled?
- What will this cost over five years, not just the first year?
- What usually causes change orders on projects like ours?
- What are we responsible for, and what happens to the price if we fall short?
- What does support look like after go-live, and will upgrades break what you build for us?
- If we leave, how do we get our data out, and what does that cost?
- Is anyone advising us being paid by you?
Each one is explained below: why it matters, and what a good answer sounds like.
Questions about the demo
1. Can you run the demo on our scenarios, with our kind of data?
A standard demo is built to show the product at its best. It follows a clean order through a clean process with clean data. Your business has exceptions, partial shipments, special pricing and the customer who always pays late. Write down five or six real situations from your business and ask every vendor to show those, in the same order.
A good answer: "Send us the scenarios and we will prepare." A weak one: "Our standard demo covers all of that." We have seen a team watch three polished demos and come away with no way to choose, because every demo followed the vendor's script instead of theirs.
2. What did you configure or build to show us that?
Some of what you see in a demo works the moment the system is installed. Some of it needs setup. Some of it needs custom work, and some of it was built just for the demo. All four look identical on screen. Ask which is which for anything that matters to you, because setup and custom work cost time and money, and custom work can make every future upgrade harder.
A good answer separates the four clearly. A weak one says "the system supports that" and moves on. Supporting something and committing to make it work in your business are two different promises.
Questions about the people
3. Who exactly will work on our project, and what happens if they leave?
The people who sell the system are rarely the people who implement it. Ask for the names and roles of the consultants who will do the work, how many projects like yours they have done, and how much of their week your project will get. Ask to meet the project lead before you sign.
Then ask what happens if one of them leaves halfway through: who replaces them, how the knowledge is handed over, and who pays for the new person to get up to speed. A good answer names people and a plan. A weak one is "we have a deep bench".
4. Can we speak to a client like us, including one whose project struggled?
Every vendor has happy references. They are real, and they are chosen. Ask for a client of similar size and industry who went live recently, and then ask for one whose project ran into trouble. Every vendor has those too. What you want to hear is how the trouble was handled and whether the client would buy again.
A good answer gives you both and lets you call them without a salesperson on the line. A weak one offers only the success stories.
Questions about the money
5. What will this cost over five years, not just the first year?
The first-year price is the one you will be shown. Ask for the total over five years: licences or subscriptions, the yearly increase at renewal, support, hosting, add-on modules, extra users as you grow, and the implementation itself. Then ask whether the renewal increase is capped in the contract.
A good answer is a written five-year figure with the assumptions listed. A weak one is a year-one price and "renewals are in line with the market".
6. What usually causes change orders on projects like ours?
Change orders are the extra charges that appear once the project is under way, when something turns out to be out of scope. Every implementation team knows where they usually come from: messy data, processes nobody wrote down, reports nobody asked for until the end. Ask them to tell you.
A good answer is a specific list, and often some advice on how to avoid each one. A weak one is "it depends" or "we will sort that out in discovery". Vague requirements are the backdoor every change order walks through, so the honest answer to this question is worth more than most of the demo.
7. What are we responsible for, and what happens to the price if we fall short?
Every proposal rests on assumptions about you: that your data is clean, that your processes are documented, that your people will be available. Each assumption that turns out not to be true becomes a change order. Ask the vendor to list them, to estimate how many hours your own people will need to give the project by role, and to put in writing what happens to the price if an assumption does not hold.
The proposal also covers only the vendor's part of the work. Much of the rest, from data clean-up to training, lands on you, whether the proposal mentions it or not.
Questions about life after go-live
8. What does support look like after go-live, and will upgrades break what you build for us?
Go-live is when your team starts using the system for real, and when most questions arrive. Ask who answers the phone, how fast, what is included in the support fee and what is billed by the hour. Ask how long the implementation team stays involved after go-live.
Then ask about upgrades. Cloud systems update on the software company's schedule, and anything custom built for you has to keep working each time. A good answer explains who tests your setup before each update and who pays to fix what breaks. A weak one is "upgrades are seamless".
9. If we leave, how do we get our data out, and what does that cost?
Nobody likes to talk about leaving while they are buying. Ask anyway. Who owns your data? In what format can you export it, all of it, including history? Is there a fee? What notice does the contract require, and what happens to your access the day it ends?
A good answer is short, specific and already in the standard contract. If the answer is complicated, it is better to find out now than when you need it.
The question about independence
10. Is anyone advising us being paid by you?
Some consultants and advisors earn referral fees or commissions from the software companies they recommend. That does not make their advice wrong, but you should know about it before you rely on it. Ask the vendor directly whether they pay anyone involved in your decision, and ask your advisors the same question.
For the record: we sell no software, take no referral fees, and are paid the same whatever you choose.
How to tell a good answer from a polished one
A good answer is specific: names, numbers, examples. It is written down, and the vendor is willing to put it in the contract. And it includes the downside: what can go wrong and what happens then.
A polished answer sounds confident and commits to nothing. Listen for these phrases:
- "That is standard."
- "The system supports that."
- "It depends."
- "We will work that out in discovery."
- "Don't worry, we do this all the time."
None of these is a lie. Each of them leaves the decision for later, after you have signed, when you have less leverage to push back.
Ask every vendor the same questions
These questions work best as a written list sent to every vendor on your shortlist, with the answers compared side by side. That turns a series of sales meetings into a fair comparison, on your terms instead of theirs.
How a vendor answers also tells you how they will behave when something goes wrong on the project. A team that is open about change orders and difficult references before you sign is likely to be open when a problem comes up after. A team that dodges now will dodge later.
Before you start, make sure the business itself is ready: the best answers in the world will not help if you cannot say what you need the new system to do.
Where we fit
We sit on your side of the table. In ERP selection we write down what your business needs, ask every vendor the same questions, and compare the answers with you. When a proposal is already on your desk, an ERP proposal review reads it line by line before you sign. Either way, the decision stays yours.
Common questions
When should we ask an ERP vendor these questions?
Ask the demo questions before the demos, so every vendor shows the same scenarios. Ask the rest before you narrow the list to a final choice, and get the answers in writing. Anything that matters should end up in the contract, not just in an email.
Is it rude to ask a vendor these questions?
No. Good vendors expect them, and some will be glad you asked, because a buyer who understands the risks is easier to work with. If a vendor gets defensive about a reasonable question before you sign, that tells you something about what working with them will be like.
Should we ask the software company or the implementation partner?
Both, if they are different companies. The software company can answer for the product, licensing, upgrades and data. The partner can answer for the team, the timeline, change orders and support. Make sure you know which one you are signing with, and which one is accountable for each answer.
What if we have already signed?
Then the same questions are still worth asking now, while the project is young: who is on the team, what you are responsible for, and what usually causes change orders. If the project is already in trouble, an independent review can show where it stands and what to do next.
Facing this now?
ERP Selection
Help choosing the right system, from an advisor with nothing to sell you.