ODOO SLA RESPONSE TIMES | SERPA ODOO ERP FOR AFRICA

A finance manager raises an Urgent ticket after month-end posting stops. The board asks whether the ERP provider has a four-hour response commitment, but the contract only refers to Odoo support. Those are not the same commitment.

An Odoo SLA can measure first action, resolution or another service stage. It can also distinguish a payroll-blocking incident from a how-to question. What it cannot do by itself is create a 24/7 human support obligation. That obligation needs to be written into the partner agreement, with named coverage hours and escalation routes.

At Serpa, we treat Odoo support and maintenance as an operating commitment that must be defined before go-live, not a generic line in an implementation proposal. As of October 2026, Odoo’s own Enterprise Subscription Agreement says it will make reasonable efforts to fix reported bugs and start handling them within two business days. That is not a guaranteed resolution deadline, and it is not universal 24/7 support.

What an Odoo SLA actually measures

An SLA is a measurable target attached to a support ticket. In Odoo Helpdesk, a policy can apply according to the support team, priority, tags, customer or services. The policy then sets a stage the ticket should reach within the team’s working hours.

That distinction matters because a target such as In Progress measures a first action. A target such as Solved measures resolution. Calling both a “response SLA” creates avoidable disputes during an outage.

| Commercial question | Correct Odoo Helpdesk configuration | Why it matters | | Has somebody acknowledged the incident? | Set the SLA target to In Progress, or an equivalent acknowledgement stage | This creates a measurable first-response target. | | Has the issue been fixed or an agreed workaround supplied? | Set a separate SLA target to Solved | Resolution can depend on investigation, third parties or a software fix. | | Does a priority case receive a shorter target? | Create a policy that explicitly matches that priority | Marking a ticket Urgent alone does not shorten its deadline. | | Is the support desk open outside office hours? | Use a working-hours calendar that reflects the contracted coverage | The SLA clock follows the configured calendar. |   Odoo calculates SLA time from ticket creation using the policy’s working-hours calendar. Stages excluded from SLA calculation do not count. If several policies match, Helpdesk displays the earliest deadline first. A missed target remains marked red even if the ticket is completed later, which preserves an auditable record of the breach.

That record is useful for a COO reviewing service quality. It is also useful for the support team because it separates an actual missed commitment from a ticket that was paused while waiting for approved information from the customer.

Odoo priority levels, and the configuration that people miss

Odoo Helpdesk provides four priority levels: Low, Medium, High and Urgent. They are represented by zero to three stars. New tickets default to Low priority.

The common mistake is assuming that three stars automatically trigger a faster engineer response. They do not. The priority has to be included as a criterion in an SLA policy with its own deadline.

Set priority by business impact, not by job title

We recommend defining priority in terms the operations team can apply at 02:00, without waiting for an IT director to interpret the problem.

| Priority | Example business impact | Recommended contractual treatment | | Low | A user needs guidance on an existing standard feature, with a workaround available | Handle during agreed business hours. | | Medium | A department cannot complete a routine process, but the wider business can continue | Set a measured first-action target in contracted support hours. | | High | A core process such as invoicing, stock confirmation or approval is materially impaired for multiple users | Define an accelerated first-action target and named escalation contacts. | | Urgent | Production operations are halted, financial posting is blocked at a critical close, or a material security incident is suspected | Define an emergency channel, coverage period and escalation path in the support contract. |   The labels are less important than the evidence required to assign them. A useful ticket form asks what process is blocked, how many users are affected, whether a workaround exists, when the failure started, and whether a deadline is at risk. Those questions let the support lead classify impact consistently.

If your organisation has fewer than two business-critical processes running outside normal office hours, do not buy broad 24/7 coverage by default. Price an after-hours emergency service for defined Urgent incidents instead. The right answer depends on shift operations, cross-border trading hours, month-end requirements and the cost of downtime.

Worked example: a manufacturer with a night shift

Take a manufacturer with 180 staff, a night shift and a US$1.2 million monthly output value. At 21:30, barcode confirmations stop reaching Odoo, so finished goods cannot be receipted and dispatch planning begins to queue. A generic “we will respond quickly” clause does not tell the plant manager who to call or whether the clock is running.

The company should define this as Urgent only where production or dispatch is genuinely stopped, provide a 24/7 emergency contact, and set a first-action SLA to In Progress. It should retain a separate Solved target because restoring an integration may require investigation after acknowledgement. If it had treated every warehouse query as Urgent, the emergency rota would soon lose credibility and cost more than the risk it was meant to manage.

What Odoo’s standard support commitment covers

Odoo’s Enterprise Subscription Agreement, Version 13 dated 24 September 2026, states that Odoo will make reasonable efforts to fix reported software bugs and start handling them within two business days. This is a handling commitment for reported bugs, not a promise to resolve every incident within two business days.

Enterprise customers can submit unlimited tickets for guidance on standard features and for bugs. Development, customisation and unclear requests may require a separate service agreement at Odoo SA’s discretion. That boundary should be visible in your support model because many production incidents sit at the boundary between a standard feature, configuration, custom code and an external integration.

Odoo states that tickets may be raised through its web form, listed help phone numbers or an Odoo Partner channel, subject to local opening hours. Do not describe this as a universal Odoo 24/7 service. A partner can contract stronger coverage, but that commitment belongs in the partner’s agreement and service schedule.

Odoo Cloud separately describes a 99.9% monthly platform uptime objective, excluding planned maintenance. That equates to up to 45 minutes of unplanned downtime in a month. It is an operational objective, not a legally binding availability guarantee, and it does not measure the availability of people to investigate an issue.

Define 24/7 support before the first incident

“24/7 support” can mean a monitored phone line, a staffed service desk, an engineer on call, or a contracted response target for only the most severe incidents. These models have different costs and outcomes. The phrase is not sufficient on its own.

Use this step-by-step checklist when agreeing Odoo support and maintenance:

1.       List the systems in scope. Include Odoo standard modules, localised configurations, custom modules, integrations, cloud hosting and user devices. A support provider cannot reasonably own an issue outside the agreed scope.

2.       Define the service window. State the time zone, ordinary support hours, public-holiday treatment and after-hours coverage. African groups operating across several countries should use a single stated reference time and identify local exceptions.

3.       Define the emergency channel. Specify whether Urgent incidents are raised by phone, portal, email or all three. A ticket portal alone may be inadequate during a total access failure.

4.       Set separate first-action and resolution targets. Configure In Progress for acknowledgement and Solved for resolution or an agreed workaround. This prevents a provider from meeting a “response” target only when the issue is already fixed.

5.       Map each priority to evidence. Require impact, affected users, error details, start time and workaround status. This gives the support desk enough information to triage without repeated back-and-forth.

6.       Agree exclusions and dependencies. Identify customer approvals, third-party services, connectivity, unsupported customisations and planned maintenance. These do not remove accountability, but they make the SLA auditable.

7.       Test the escalation path. Run an after-hours incident drill before go-live and record actual timing. An untested emergency number is not an operational control.

Worked example: a multi-entity distribution group

Take a distribution group with five legal entities and central finance, processing a US$6 million month-end close. A posting error appears in one entity at 16:40 on the final working day, but the finance team marks it Urgent without confirming whether other entities are affected. The service desk spends 45 minutes establishing facts that the ticket form should have captured.

The group should configure a High first-action SLA for single-entity close blockers and reserve Urgent for failures affecting consolidated reporting or several entities. It should require the entity name, journal, posting date, error reference and whether a rollback has been attempted. The cost is mainly process discipline, while the gain is a cleaner incident trail and less time lost deciding who owns the next action.

Support reporting that a board can use

A monthly Helpdesk dashboard should not lead with ticket volume. Volume can rise after improved user adoption or a new rollout. Lead with measurements that show whether the support model is protecting operations.

| Measure | What to review | Why it matters | | SLA attainment by priority | First-action and Solved targets separately | This exposes whether acknowledgement is strong while resolution is weak. | | Breached tickets | Reason, owner, affected process and elapsed time | A red SLA marker provides an auditable starting point for root-cause review. | | Reopened tickets | Incidents returned after being marked Solved | High reopen rates can indicate premature closure or inadequate testing. | | Tickets by root cause | Standard Odoo, configuration, customisation, integration or user guidance | This informs maintenance budgets and implementation backlog priorities. | | After-hours incidents | Count, severity and actual business impact | This tests whether 24/7 cover is justified by operating risk. |   For a multi-entity group, report these measures by company and operating unit as well as centrally. A unified Odoo ERP view is valuable, but support performance can look acceptable in aggregate while one entity repeatedly misses critical deadlines.

Frequently Asked Questions

Does Odoo guarantee a response within two business days?

Odoo’s Enterprise Subscription Agreement says Odoo will make reasonable efforts to start handling reported bugs within two business days, as of October 2026. It does not guarantee a fix, a resolution time or 24/7 human response.

Does Urgent priority automatically create a shorter SLA?

No. Odoo Helpdesk supports Low, Medium, High and Urgent priority levels, but an Urgent ticket receives a different deadline only when an SLA policy is configured to match that priority.

Is Odoo Cloud 99.9% uptime the same as 24/7 support?

No. Odoo Cloud’s 99.9% monthly uptime objective concerns platform availability and excludes planned maintenance. It is separate from a support team’s human response and resolution commitments.

Can an Odoo Partner provide 24/7 support?

A partner may contract 24/7 coverage, but the agreement should specify the emergency channel, eligible severity levels, working-hours calendar, first-action targets, resolution approach and exclusions. Odoo’s published terms refer to ticket availability subject to local opening hours.

Official documentation consulted: Odoo Enterprise Subscription Agreement, Version 13, effective 24 September 2026; Odoo 18 Helpdesk documentation on receiving tickets and SLA policies; Odoo Cloud SLA page, accessed 8 October 2026.

Request a Consultation to define an Odoo SLA and support model that matches your operating hours, critical processes and governance requirements.