“We did our research. We spoke to three partners. They all sounded good.”

That is the most common thing a founder says six months into a struggling Odoo implementation. They did speak to multiple partners. They did get proposals. They did compare pricing. What they did not have was a way to distinguish between partners who would deliver and partners who would overpromise.

Most partner evaluation processes in India come down to two things: price and the demo. Neither tells you anything useful about what happens after you sign.

This article is a list of 20 specific questions, grouped by category, with guidance on what a strong answer looks like and what a red flag answer looks like. Some of these questions will make a partner uncomfortable. That discomfort is useful information.

Use this as your interview script. Take it into every partner evaluation call. The quality of the answers will tell you more than the proposal document ever will.

Note: ochre.digital implements Odoo in India and the Middle East. These questions apply to us as much as they apply to any other partner. Ask us all of them.

Section 1 — Before the questions: what the Indian partner ecosystem actually looks like

Why Partner Evaluation Matters More Than Platform Selection in India

India has 500+ Odoo partners ranging from solo freelancers to large system integrators. Odoo’s official partner tiers (Ready, Silver, Gold) tell you something about certification and revenue, but nothing about whether the delivery team senior enough for your project complexity, whether their implementation methodology will suit your business, or whether they will still be responsive six months after go-live.

The Indian Odoo market has two recurring failure patterns: the low-cost partner who compresses discovery and delivers a technically functional but operationally misaligned system, and the large partner who wins the deal with senior people and delivers it with juniors. Both are avoidable with the right questions asked before signing.

Section 2 — Track record questions

Category 1: Track Record and Experience (Questions 1 to 5)

Track record

1

How many Odoo implementations have you completed in India, and can you show me the list on odoo.com/partners?

Partner project counts on the Odoo website are self-reported but independently visible. A partner claiming 200 implementations whose odoo.com profile shows 12 has a credibility problem immediately.

Red flag: “We have done hundreds of projects” with no verifiable count on the official partner page. Good answer: Directs you to their odoo.com profile and provides a breakdown by year and industry.

2

What percentage of your last ten projects went live on or before the agreed date?

This is the most revealing single question in any partner evaluation. A strong partner can answer immediately with a number. A weak one deflects with “every project is unique.” Both answers tell you something important.

Red flag: Any deflection, vagueness, or insistence that timelines are “always variable.” Everyone who has delivered projects on time knows what their hit rate is. Good answer: A specific percentage (say, 70 to 80%), with an honest explanation of why the other projects slipped and what was done differently afterward.

3

Can you share two or three case studies from businesses in my industry with a similar user count and operational complexity?

Generic case studies (“we implemented Odoo for a trading company”) mean nothing. Industry-specific case studies with named outcomes (reduction in reconciliation time, improvement in inventory accuracy) show that the partner has actually solved problems similar to yours.

Red flag: Only generic case studies, or case studies that describe module names rather than business outcomes. Good answer: Named case studies with client contact details available for reference calls.

4

Can I speak with two clients who went live in the last twelve months?

References from three years ago describe a different team, a different version of Odoo, and a different business. Recent references are the only ones that are relevant to your project. A partner who cannot offer recent references either does not have them or is protecting unhappy clients from your call.

Red flag: References older than 18 months, or a partner who “needs to check with the client first” before providing contact details at all. Good answer: Two or three references offered readily, with the invitation to call them without the partner present.

5

Have you handled a rescue implementation, where a client came to you after a failed implementation with another partner?

This question does two things. It reveals whether the partner has the depth to recognise and fix implementation debt. And the answer tells you what failure patterns the partner has seen up close, which is far more useful than a list of success claims.

Red flag: “We have never had a client who needed rescuing.” This is either untrue or means the partner has never been close enough to failure to learn from it. Good answer: Yes, with a specific example of what was found, what was fixed, and how long it took to stabilise.

Section 3 — Team and delivery questions

Category 2: The Delivery Team (Questions 6 to 10)

Delivery team

6

Who specifically will work on my project: names, experience levels, and Odoo certification status?

Large partner firms win deals with senior people in the room and deliver with juniors on the keyboard. Asking for names and experience before signing creates accountability. If the partner cannot name the team, the team has not been allocated.

Red flag: “We will assign the best team for your project” without naming anyone. This means you will find out who your team is after you have paid the first milestone. Good answer: Named functional consultant, named technical developer, named project manager, each with years of Odoo experience stated and certification verifiable.

7

Will the same team be available for post-go-live support, or does the project hand over to a different support team?

The people who built the system understand its design decisions. A handover to a support team who was not involved in implementation means every issue requires re-explanation of context. This is common and costly.

Red flag: “Our support team handles post-go-live” with a handover process that the delivery team is not part of. Good answer: The delivery lead remains involved in support for a defined period (usually the first 90 days), with a structured handover if the project moves to a separate support engagement.

8

What is your implementation methodology? Walk me through what happens from contract signing to go-live, phase by phase.

Partners with a real methodology can describe it in five minutes without hesitation. Partners without one use words like “agile” and “iterative” without being able to say what that means in practice for your project. The methodology determines whether the project has structure or improvisation.

Red flag: Vague references to “agile delivery” or “sprint-based approach” without a concrete phase breakdown that includes discovery, UAT, and hypercare. Good answer: A clear sequence: discovery and process mapping, configuration in staging, data migration, UAT with client team, cutover plan, go-live, hypercare window. Timelines attached to each.

9

How do you handle scope changes mid-project? Show me a sample change request process.

Every project has scope changes. How a partner handles them determines whether the project stays on budget. Partners who say “we will accommodate changes as they come” are partners who will charge you later for everything that was not explicitly written in the original scope.

Red flag: No written change request process, or reassurances that “we are flexible” without documenting how flexibility is priced. Good answer: A written change request form, a defined review and approval process, and a clear statement of how changes are priced against the original scope.

10

How much time will my internal team need to commit during implementation? Be specific per role per week.

Odoo implementations that fail often do so because the client team was not available for UAT, data validation, or decisions. A serious partner quantifies the client commitment required upfront. An optimistic partner promises a painless process and then creates bottlenecks when key people are unavailable.

Red flag: “We will handle everything, you just need to review at the end.” No ERP implementation can succeed without meaningful client involvement. Good answer: A specific estimate per role, such as accounts lead 4 hours per week during configuration, 2 days per week during UAT, operations head 2 hours per week for decision sign-offs.

Section 4 — Pricing and contract questions

Category 3: Pricing and What Is Actually Included (Questions 11 to 14)

What is explicitly not included in this proposal? List the exclusions.

This is the most important commercial question you can ask. Partners who cannot list exclusions clearly are partners who have not scoped the project honestly. The exclusions list tells you more about total cost than the quoted number does. Common exclusions: data migration, custom reports, training, post-go-live support, integrations, GST configuration.

Red flag: “Everything you need is included” without a written exclusions list. Nothing is included that is not written. Good answer: A written list of exclusions with a clear statement of how each would be priced if required.

12

How are customisation hours priced, and how will you tell me when we are approaching the limit?

Many proposals include a fixed number of customisation hours. Once exhausted, every additional requirement is billed at a separate rate. Partners who do not proactively track and communicate customisation hour consumption create budget surprises at the worst possible time, typically during UAT when the client has the least leverage.

Red flag: Customisation hours buried in the proposal with no communication mechanism for tracking consumption. Good answer: A customisation log maintained throughout the project, shared with the client weekly, with a defined escalation process when 70% of hours are consumed.

13

What does your annual maintenance contract cover, and what does it cost after year one?

AMC terms offered during the sales process are often more generous than what is available after go-live. Understanding the year-two and year-three support cost before signing prevents the common situation where a business discovers their support has become unaffordable precisely when they are most dependent on it.

Red flag: AMC pricing not available at proposal stage, or offered as a percentage of implementation cost without specifying what is included. Good answer: A written AMC document covering response SLAs per issue severity, included hours per month, exclusions, and pricing for years one through three.

14

What happens if the project exceeds the agreed timeline? Who bears that cost?

Timeline overruns are common in ERP projects. The contract should specify what triggers a timeline review, how additional cost is shared between partner and client, and what the escalation process is. Partners who do not address this in their contract are leaving the cost allocation to whoever has more leverage when the overrun happens.

Red flag: No timeline overrun clause in the contract, or a clause that assigns all overrun cost to the client regardless of cause. Good answer: A clause that distinguishes between overruns caused by client delays (client bears cost) and overruns caused by partner delays (partner absorbs cost), with a neutral dispute process.

Section 5 — India-specific compliance questions

Category 4: Indian Compliance and Localisation (Questions 15 to 17)

India compliance

15

Walk me through how you configure fiscal positions in Odoo for a business that sells both intrastate and interstate. What would you set up for my customer master records?

This is a technical question with a specific correct answer. Any competent Odoo partner implementing in India should be able to describe the intrastate and interstate fiscal position setup, how GSTIN-based state code detection works, and how it maps to CGST/SGST versus IGST on invoices. A vague or incorrect answer indicates the partner is not India-specialist, regardless of their other credentials.

Red flag: Vague answer about “GST being handled automatically by Odoo” without explaining the fiscal position mechanism. Good answer: A clear explanation of fiscal positions, customer master assignment based on GSTIN state codes, and a statement about verifying this during UAT with a batch of test invoices reviewed by the client’s CA.

16

How do you configure e-invoicing in Odoo for a business above the Rs 5 crore threshold? Which GSP do you use, and have you done the NIC portal API setup before?

E-invoicing configuration is specific and procedural. There is a correct sequence: NIC portal registration, GSP selection (BVM IT Consulting for Odoo 19), API user creation, sandbox testing, production connection. Partners who have done it before describe it fluently. Partners who have not done it before use vague language about “integration with the government portal.”

Red flag: “Odoo has built-in e-invoicing so it will work automatically.” It does not work without deliberate GSP credential configuration and testing. Good answer: A step-by-step description of the NIC API setup, which GSP they use, and confirmation that they test in the NIC sandbox before go-live.

17

How do you handle TDS configuration in Odoo, and do you involve the client’s CA in validating the setup before go-live?

TDS in Odoo requires section code mapping at the chart of accounts level, threshold alert configuration, and an understanding of TDS base (taxable value only, not GST-inclusive total). Partners who have done this correctly involve the CA in validation. Partners who have not done it correctly often learn about the mistake when the vendor’s Form 26AS does not reconcile.

Red flag: “TDS is handled through a simple configuration in settings.” TDS setup is account-level, not settings-level, and requires CA involvement to validate. Good answer: Account-level section code mapping described correctly, plus a statement that CA sign-off is part of their standard UAT checklist.

Section 6 — Post go-live and long-term questions

Category 5: After Go-Live (Questions 18 to 20)

Post go-live

18

What does your hypercare period look like? How long is it, what is included, and when does it end?

The first 90 days after go-live are the highest-risk period of any ERP project. Teams are adjusting to new workflows, edge cases are surfacing, and the instinct to revert to Excel is strong. Partners who define hypercare clearly with daily check-ins, issue resolution SLAs, and adoption metrics are partners who plan for success. Partners who go quiet after go-live create adoption failures.

Red flag: “We are available after go-live for any issues” without a defined hypercare structure, duration, or included scope. Good answer: A named hypercare period (usually 30 to 90 days), with daily check-ins in week one, weekly reviews through the period, a defined issue resolution channel, and specific adoption metrics being tracked.

19

How do you approach Odoo version upgrades for clients, and what is your upgrade pricing model?

Odoo releases a major version annually. Businesses on Odoo 17 will eventually need to move to 18, then 19. How the partner designs the system today determines how expensive and disruptive that upgrade will be. Partners who write upgrade-safe code (minimal customisation, well-documented modules, standard Odoo patterns) create manageable upgrades. Partners who write fragile custom code create upgrade crises.

Red flag: “Upgrades are a separate project we can quote when the time comes.” This means the system was not designed with upgrades in mind. Good answer: A clear upgrade philosophy: configure first, customise minimally, document all custom modules, test upgrades in staging before production. A pricing model for upgrades that is predictable rather than open-ended.

20

What do you do if my team is not adopting the system three months after go-live?

Adoption failure is the most common ERP outcome that nobody talks about in case studies. The system works technically but the team has reverted to Excel, WhatsApp, and manual processes. Partners who have thought about this have a re-training plan, a process audit, and a willingness to revisit design decisions. Partners who have not thought about it treat adoption as the client’s problem.

Red flag: “Adoption is about change management on your side.” While technically true, a partner who deflects adoption responsibility entirely has not built adoption support into their delivery model. Good answer: A specific plan: adoption metrics tracked from go-live, a 60-day review of actual versus expected usage, a re-training offer if adoption falls below a defined threshold, and a willingness to audit the system design if adoption issues are structural.

Section 7 — What to do with the answers

How to Score What You Hear

The single most important data point from any partner evaluation is not the answer to any one question. It is how the partner responds when a question makes them uncomfortable. Discomfort handled with honesty indicates a partner worth trusting. Discomfort handled with deflection or overselling indicates a partner worth avoiding.

Ask These Questions of Us Too

“A partner who cannot answer these questions clearly is not ready to implement your ERP.”

ochre.digital implements Odoo for Indian and Middle East businesses across manufacturing, trading, distribution, and services. We wrote these questions because we have seen what happens when they are not asked. We have built our practice around being able to answer all twenty of them clearly, with evidence.

If you are evaluating partners and would like to put these questions to us, book a session. We will answer every one of them before asking anything about your budget.

Ready to evaluate ochre.digital against these 20 questions?

Book a 30-minute session. Bring the questions. We will answer them first, then ask about your business. After understanding your operational requirements we will come back with a demonstration specific to your situation.