What a Sri Lankan manufacturer should ask an ERP vendor before signing
Twenty-six questions that separate a vendor who has delivered from one who has demoed - on ownership, upgrades, data, people and what they cannot do.
AI tools helped draft parts of this article. Every claim in it comes from our own implementations or from the sources linked in the text, and it was checked before publication.
An ERP selection is usually decided by a demo, and a demo is the one part of the process the vendor fully controls.
The questions below are the ones that are hard to prepare for, because the answers depend on what a vendor has actually done rather than what they can show. We have been on the receiving end of most of them, and we would rather buyers in Sri Lanka ask them of everyone, ourselves included, than pick on a slide deck.
Take them into the room. Write down the answers. The pattern across four vendors tells you more than any single reply.
Before you walk into the room
Three pieces of preparation change the quality of every answer you get, and all three are free.
Write down your five worst weeks. Not requirements. Incidents. The order that shipped late and why. The month-end that took three weeks. The stock count that did not match. The customer who was invoiced twice. These are far more useful than a requirements list, because a requirements list can be answered with a feature and an incident can only be answered with a process.
Decide who decides. Before the first demo, name the one person who can settle a disagreement between two departments. If that person does not exist, the ERP project will surface every unresolved argument in your business and stall on each one. This is the single most common cause of overrun, and it is entirely within your control.
Look at your own data honestly. Export your customer list, your product master and your supplier list, and read them. Count the duplicates. Count the records with no category. Find out when stock was last physically counted. You will discover this during migration anyway; the only question is whether you discover it before or after the go-live date has been announced.
On the demo itself
1. “Can we do this on our data?” Not a full migration. A handful of your real products, your actual chart of accounts, three of your customers with their real names and their real messy addresses. Demo data is designed to work. Yours is not, and the difference is the whole point.
2. “Show me the three things that go wrong most often in our business.” Bring your own list. For a factory it might be a style that shipped late, a fabric shortage discovered at cutting, and a costing that turned out wrong after the order was taken. Ask what the system does about each. Anything that has to be answered with a slide instead of a screen is not a feature yet.
3. “What does the system do on its own, without anyone asking it?” This separates a record-keeping system from an operational one. A blocked task escalating after three days, a wastage override requiring approval, a batch refusing to become invoices while errors are outstanding. These are the behaviours that survive a busy month. Screens that only respond do not.
4. “Show me the ugliest screen a daily user will see.” Every demo shows the dashboard. Ask for the screen a storekeeper uses forty times a day. That one determines whether the system gets used.
On what they cannot do
5. “What can this system not do that competitors can?” Every vendor has a third column. Most only show you two. A vendor who answers this cleanly is telling you they have run enough projects to know where they lose, and you will find out anyway, in month three, at a much worse moment.
6. “What was the last project that went badly, and why?” Nobody has only good ones. The answer tells you whether they diagnose or blame.
7. “Which parts of what you have shown me are in production somewhere today, and which are roadmap?” Ask it as a list, and ask for it in writing.
On the software itself
8. “Which parts of the solution are configuration, which are custom modules, and which are Studio?” Three different cost profiles and three different upgrade risks. A vendor who cannot separate them has not estimated the work - what fits Odoo out of the box and what does not is a worked example of where that boundary should fall.
9. “Are the custom modules in version control, and do they have tests?” This is a technical question with a commercial answer. Modules with tests survive upgrades. Modules without them get rewritten at your expense.
10. “What happens to each customisation at the next major version, and who pays?” The answer to the second half should be in the contract, not in the relationship.
11. “Which features would we lose on Community rather than Enterprise?” A specific list, in writing. This is often the largest recurring cost decision in the whole project, and it is frequently made by accident. What Odoo covers as an ERP is the starting point for that conversation.
12. “What is the upgrade history of your other clients?” How many are on the current major version, how many are two or more behind, and why. A client base stranded on old versions is the clearest possible signal about how the custom layer was built.
On data and ownership
13. “Is the database ours, and can we export it in full, at any time?” Ask it plainly and watch how long the answer takes.
14. “If we ended this relationship next year, what would we walk away with?” The database, the custom module source, the documentation, the configuration. Anything on that list they hesitate about is a lock-in you are agreeing to.
15. “Who has access to our production data, and under what controls?” Named roles, not “our team”.
16. “What have you assumed about our data quality?” If nothing has been assumed, migration is unpriced. It will come back as a change request at the worst point in the schedule.
On the project
17. “Who from our side do you need, and for how many hours a week?” A partner who has not thought about your people’s time has not run many projects. Your team is a real cost of the project, usually the second largest after the software.
18. “What is not included?” A proposal without an exclusions section is not a scope. Ask until you get one.
19. “What is the change process, and what is the rate?” Agreed before work starts, not negotiated the first time you need something.
20. “What would make this project fail?” The honest answers are always the same: no decision-maker on the client side, data nobody cleaned, and scope that was never written down. A vendor who names those has delivered. A vendor who says “nothing, we have a proven methodology” has not, or is not being straight.
On the people
21. “Who specifically will do this work, and what have they done before?” Not the company’s experience, the named individuals’. Sales teams and delivery teams are different people at every vendor, including the good ones. Ask to meet the person who will actually be on site.
22. “What happens when it breaks at 4pm on the day we are documenting a shipment?” This is where a local partner has a genuine, unfakeable advantage over a larger overseas vendor, and it is worth more than several rows of a feature comparison. Ask for the escalation path and the response time, and ask what happened the last time it was used.
On the commercials
23. “Show me licensing separately from services.” For Odoo, licensing is paid to Odoo, per user per month, and it recurs forever. A partner who bundles it invisibly into their fee is making it harder for you to compare, and harder for you to see the biggest recurring decision in the project, which is how many internal users you genuinely need.
24. “What does year two look like, and year three?” Support, hosting, the annual major version, and a small ongoing capacity for change. An implementation quote that does not describe ownership is half a proposal.
25. “What is your payment schedule tied to?” Milestones with acceptance criteria, or dates? Tied to dates, the incentive is to be finished on paper. Tied to acceptance, the incentive is to be finished.
26. “What happens if we are late?” Projects slip on the client side at least as often as the vendor side: a decision not made, a data set not cleaned, key people pulled onto something urgent. A partner who has an honest, pre-agreed answer for that will not be inventing one under pressure six months in.
A simple scorecard
Rather than a weighted matrix nobody revisits, score each vendor out of three on five things after every meeting:
| What you are judging | |
|---|---|
| Specificity | Do the answers contain names, numbers and things that went wrong? |
| Candour | Did they volunteer something they cannot do? |
| Depth on your process | Did they understand your worst weeks, or restate them back? |
| The delivery team | Have you met the people who will actually do the work? |
| Ownership | Data, source, documentation, exit. Answered without hesitation? |
Fill it in the same day, before the impressions blur. Four vendors scored this way separate faster than four proposals compared line by line, because proposals are written to be compared and conversations are not.
How to read the answers
Three patterns matter more than any individual reply.
Specificity. Good answers contain names, numbers, dates and things that went wrong. Weak answers contain adjectives. This holds across all twenty-six questions.
Consistency across the room. Ask the same question of the salesperson and the consultant separately. Where the two answers diverge is where the risk is.
Willingness to say no. A vendor who says yes to everything is either not listening or will bill you for the difference later. The most reliable signal in the whole process is a vendor who tells you, unprompted, about something they cannot do, because it means the rest of what they told you was probably true as well.
One last thing
Ask every vendor for a customer reference at a business of roughly your size, in roughly your industry, that went live at least eighteen months ago. Then ask that reference what they would do differently.
Eighteen months is deliberate. Anything more recent is still in the glow, and the questions that matter, such as whether the upgrade worked, whether the custom layer is maintainable and whether the vendor stayed responsive after the invoice was paid, cannot be answered before then.
If you want to see how we answer these before you ask them, our Odoo implementation process sets out the phases, and what an Odoo implementation costs covers the commercial side.
Frequently asked questions
What should I ask an ERP vendor before signing?
The questions that are hard to prepare for, because the answers depend on what a vendor has done rather than what they can show. Ask them to run the demo on a handful of your real products, your actual chart of accounts and three of your messiest customer records. Ask what the system does on its own without anyone asking it. Ask what it cannot do that competitors can, which parts are configuration, custom modules and Studio, whether the database is yours to export in full at any time, who specifically will do the work, and what would make the project fail. Ask the same questions of every vendor - the pattern across four answers tells you more than any single reply.
How should I prepare before an ERP demo?
Three things, all free. Write down your five worst weeks - incidents, not requirements: the order that shipped late, the month-end that took three weeks, the stock count that did not match, the customer invoiced twice. A requirements list can be answered with a feature; an incident can only be answered with a process. Decide who decides, naming the one person who can settle a disagreement between two departments, because a project without that surfaces every unresolved argument in the business and stalls on each one. And read your own data - export the customer, product and supplier lists and count the duplicates before the go-live date is announced rather than after.
What are the warning signs of a bad ERP vendor?
A vendor who says yes to everything is either not listening or will bill you for the difference later. Other signals: answers made of adjectives rather than names, numbers, dates and things that went wrong; a salesperson and a consultant who give different answers to the same question; a proposal with no exclusions section, which means it is not a scope; hesitation over whether the database is yours; and "nothing, we have a proven methodology" in answer to what would make this project fail. The most reliable positive signal is a vendor who tells you unprompted about something they cannot do.
What should I ask about customisation and upgrades?
Four questions, because they carry the cost of year two onwards. Which parts of the solution are configuration, which are custom modules and which are Studio - three different cost profiles and three different upgrade risks, and a vendor who cannot separate them has not estimated the work. Are the custom modules in version control and do they have tests, since modules with tests survive upgrades and modules without get rewritten at your expense. What happens to each customisation at the next major version, and who pays - which belongs in the contract rather than the relationship. And what is the upgrade history of your other clients, because a client base stranded on old versions is the clearest possible signal about how the custom layer was built.
How do I avoid being locked in to an ERP vendor?
Ask four ownership questions plainly and watch how long each answer takes. Is the database ours, and can we export it in full at any time. If we ended this relationship next year, what would we walk away with - the database, the custom module source, the documentation, the configuration. Who has access to our production data, and under what controls, named as roles rather than "our team". And what have you assumed about our data quality, because if nothing has been assumed then migration is unpriced and will return as a change request at the worst point in the schedule. Anything on that list a vendor hesitates over is a lock-in you are agreeing to.
What commercial terms should be agreed before an ERP project starts?
Licensing shown separately from services, because for Odoo licensing is paid to Odoo per user per month and recurs forever, and a partner who bundles it invisibly makes the biggest recurring decision in the project harder to see. A description of year two and year three - support, hosting, the annual major version and some ongoing capacity for change. A payment schedule tied to milestones with acceptance criteria rather than dates, since dates incentivise being finished on paper. A change process and rate agreed before work starts. And a pre-agreed answer for what happens if you are late, because projects slip on the client side at least as often as the vendor side.
How do I compare ERP vendors fairly?
Score each one out of three on five things after every meeting, the same day, before impressions blur: specificity, meaning answers containing names, numbers and things that went wrong; candour, meaning they volunteered something they cannot do; depth on your process, meaning they understood your worst weeks rather than restating them; the delivery team, meaning you have met the people who will actually do the work; and ownership of data, source, documentation and exit, answered without hesitation. Four vendors scored this way separate faster than four proposals compared line by line, because proposals are written to be compared and conversations are not.
What should I ask an ERP customer reference?
Ask every vendor for a reference at a business of roughly your size, in roughly your industry, that went live at least eighteen months ago - then ask that reference what they would do differently. The eighteen months is deliberate. Anything more recent is still in the glow, and the questions that actually matter cannot be answered before then: whether the upgrade worked, whether the custom layer is maintainable, and whether the vendor stayed responsive after the invoice was paid.