What an Odoo support agreement should include
Response times, priorities, development hours and periodic reviews, and what you should never accept in a support contract.
Go-live is the start of your life with Odoo, not the end of the project. The first months bring questions nobody thought to ask during training, a report finance needs by Thursday, and the occasional issue that stops invoices from going out. How quickly and how well those get handled depends largely on one document: the support agreement.
Many support contracts are written to be signed, not read. This article walks through what a useful Odoo support agreement contains, how the common structures work, and the clauses we would advise you to push back on, whoever your partner is.
What support actually covers
Start by being clear about the kinds of work the agreement is meant to cover, because they behave very differently:
- Incidents: something that worked yesterday does not work today. An error on validating a delivery, an e-invoice rejected by the tax authority, a scheduled action that stopped running.
- How-to questions: the system works, but a user does not know how to do something in it. These are the most frequent requests in the first months, and the best signal of where training needs reinforcing.
- Configuration changes: a new warehouse, a new tax, a change to an approval rule, a new user with the right access.
- Development: a new report, a change to a custom module, an integration with another system.
- Maintenance: updates, module compatibility checks, and preparation for the next version upgrade.
A good agreement names each of these and says how it is handled. A weak one says "support" and leaves the rest to interpretation, which usually means to the first disagreement.
Response times and priority levels
The core of any support agreement is a table of priority levels, each with a definition, a response time and a target for resolution or a workaround. The definitions matter more than the numbers: if "critical" is not defined in terms of business impact, every request becomes critical and none of them are.
The table below shows a typical structure. The values are illustrative only, to show the shape; real values depend on your operations, your working hours and the plan you choose.
| Priority | Typical definition | Example response target | Example target for a workaround |
|---|---|---|---|
| Critical | The system or a core process is down for everyone, with no workaround: you cannot invoice, ship or pay | Within 1 working hour | Same working day |
| High | A core process is impaired for many users, or a legal deadline is at risk | Within 4 working hours | Within 2 working days |
| Normal | A problem with a workaround, or a problem affecting a single user | Within 1 working day | Agreed case by case |
| Low | How-to questions, cosmetic issues, small improvement requests | Within 2 working days | Planned into a regular release |
Read the response targets carefully. "Response" usually means a person has acknowledged and started working on the request, not that it is fixed. That is reasonable, because nobody can promise a fix time for an issue they have not yet diagnosed. But the agreement should also commit to regular updates on open critical issues, and to a workaround target where one is possible.
Check also what "working hours" means. If your warehouse runs on Saturdays and your partner works Sunday to Thursday, a critical stop on Saturday morning needs an explicit answer in the contract.
Development hours
Most agreements include a bank of hours, monthly or annual, for configuration changes and small developments. This is where the most misunderstandings happen, so the agreement should answer these questions plainly:
- What consumes hours? Bug fixes on work the partner delivered should not. Fixing their own defects is part of the original project, usually under a warranty period.
- How are hours estimated and approved? Any request above a small threshold should come with an estimate that you approve before work starts.
- Do unused hours roll over? Some agreements carry them for a limited period, others do not. Either can be fair, as long as it is written down.
- What happens above the bank? Extra hours should be billed at a rate stated in the agreement, not a rate quoted at the time of need.
- Who owns the code? Custom modules written for you should be yours, kept in a repository you can access.
Periodic reviews
The support agreements that work best include a regular review, often monthly at first and quarterly once things settle. It is a short meeting with your key users and the partner's consultant, built around a few questions:
- Which requests came up most often, and do any of them point to a training gap or a configuration fix?
- Were the response targets met, and where not, why?
- Which features are paid for but not used, and is that a training or a design issue?
- What is coming next: new branches, new regulations, a version upgrade?
Many repeated tickets are training needs in disguise. A review that spots them early saves hours from the bank and frustration for your users. This is why we link support closely with ongoing training for your team.
What you should not accept
Some clauses look harmless and cost you later. We would push back on all of these, whoever the partner is.
- No access to your own code or database. You should be able to obtain a full backup and the source of every custom module at any time. Anything else is lock-in.
- Defects billed as development. Errors in the partner's own work should be fixed without consuming your hours, at least during the warranty period.
- Vague exclusions. "Third-party issues" and "data problems" are reasonable exclusions only when they are defined. Otherwise they can cover almost anything.
- A single point of contact with no backup. If one consultant is the only person who knows your system, holidays become outages.
- Automatic renewal at an unstated price. Renewal terms and any price change should be written in the agreement.
- No exit plan. The agreement should say how handover works if you change partner: documentation, code, credentials and a reasonable notice period.
Odoo's own support and partner support
If you use Odoo Enterprise, your subscription includes support from Odoo for the standard software: bugs in standard modules, and version upgrades of your database. It does not cover custom modules, configuration specific to your business, or training your users. That is what a partner support agreement is for. A good agreement makes the boundary clear, and the partner should handle the coordination with Odoo when an issue sits on their side. We explain the wider difference between editions in Odoo Community vs Enterprise.
You can see how we structure our own plans on our support services, or ask us for a support proposal and compare it against this checklist.
Key takeaways
- Name each kind of work the agreement covers: incidents, questions, configuration, development and maintenance.
- Priority definitions based on business impact matter more than the response numbers.
- Development hours need written rules: what consumes them, how they are approved and how they are reported.
- Periodic reviews turn repeated tickets into training and configuration fixes.
- Never give up access to your own data and code, and agree the exit process before you need it.
