Odoo Helpdesk Implementation
Tickets, SLA, escalations, knowledge.
Multichannel helpdesk with SLA policies, escalations, team rotations, knowledge base, and customer portal.
Odoo Helpdesk is an Enterprise application. There is no Helpdesk app in Community, and that single fact settles most helpdesk projects before anything else is discussed. What the licence buys is a ticket model living in the same database as the sale order, the delivery and the invoice, so an agent can see what the customer bought, what shipped late and what is still unpaid without leaving the ticket or asking another department.
The work in a helpdesk build is not the kanban board. It is the stage model, the SLA policies and the email path. Stages describe how the team actually works, SLA policies decide what counts as late, and the alias and catchall configuration decides whether a customer reply lands on the existing ticket or opens a second one. Those three decisions carry the project. Everything after them is data entry and training.
Cost follows the user model. Agents are internal Odoo users billed per user rather than per app, so a desk that also runs Field Service, Knowledge and Timesheets pays no more for those than a desk that only answers email. Customers who raise and follow tickets through the portal are portal users and are not billed at all, whatever the number of them. The sizing question is how many people answer tickets, not how many tickets arrive or how many customers you serve, and that is usually a smaller figure than the first headcount a support manager gives you.
Who Odoo Helpdesk is for
- → B2B suppliers working to contractual response and resolution times, where missing a target has a commercial consequence and somebody has to prove afterwards that the target was met.
- → Companies already running Odoo Sales and Inventory, where a complaint has to end in a return, a repair order or a credit note rather than in an email thread nobody can find later.
- → IT and equipment service providers billing support against a contract or a block of prepaid hours, since time logged on a ticket can flow through a sale order to an invoice.
- → Manufacturers and distributors handling warranty claims on serialised goods, where the lot number on the ticket has to match what was actually delivered to that customer.
- → Not for organisations committed to Odoo Community with no route to Enterprise, because the app is simply absent and rebuilding it in Project gives you tasks without an SLA engine.
- → Not for high volume contact centres needing call queueing, IVR, skills based routing and supervisor wallboards. None of that is in standard Odoo, and the VoIP app places and logs calls against records rather than distributing inbound calls across available agents.
Key features
- ✓ SLA policies & escalations
- ✓ Team rotations
- ✓ Knowledge base
- ✓ Customer portal
- ✓ Email-to-ticket
- ✓ CSAT surveys
What Odoo Helpdesk actually does
Teams carry almost every setting
A helpdesk team is the unit that holds the email alias, the member list, the SLA policies, the after sales options, the help center and whether the portal is open. Stages belong to teams and can be shared by several, which is convenient until two teams need different closing rules on the same stage. Assignment is chosen per team as manual, random or balanced, where balanced hands the next ticket to the member with the fewest open ones. Auto assignment looks only at the team's member list, so getting a ticket to the one person who knows that product is a manual move or an automation rule you write yourself.
SLA policies and how a deadline is actually calculated
An SLA policy says that tickets matching a set of criteria, such as priority, tag, ticket type, customer or company, must reach a named stage within a number of working hours or days. One policy carries one target stage and one duration, so a contract promising a one hour response and a next working day fix is two policies, and the ticket then tracks both with a separate status for each. The countdown runs against a working schedule rather than the wall clock, and stages can be excluded from the count, which is how the clock stops while you wait for the customer to reply. Policies belong to a team, so the same contractual promise has to be built again on every team that serves that customer.
The routes a ticket arrives by
Four channels cover most deployments. An email alias per team turns a support address into tickets and threads later replies onto the same record. A website form gives structured fields instead of free text. The customer portal lets a signed in contact raise and follow tickets. Live Chat, which is a Community app in its own right, gains a chat command once Helpdesk is installed that converts the conversation into a ticket with the transcript in the chatter. Tickets can also arrive over the API or from an automation rule fired on another record, which is how a late delivery or a failed payment becomes a ticket without anyone typing it.
After sales actions that reach the rest of Odoo
Each after sales option enabled on a team turns a ticket into a real transaction rather than a note. Refund raises a credit note against the original invoice. Return creates an incoming picking so goods come back into stock properly. Repair opens a repair order. Onsite intervention creates a Field Service task with the address and customer already filled in. Coupons issue a discount code as a goodwill gesture. Every one of them stays linked to the ticket, so the trail is one record. The targets themselves straddle the editions, Repairs and Inventory being Community apps and Field Service being Enterprise, which matters only for working out what else the licence has to cover.
Support time, logged and billed
With Timesheets switched on for a team, agents log hours directly on the ticket. If the team is also set to bill that time, the ticket links to a sale order line and the hours reach an invoice through ordinary service invoicing. Prepaid blocks of hours work the same way, with the balance visible on the order. Teams that never invoice support still gain from logging, because recorded hours are the only honest measure of what a fixed price contract costs to serve.
A help center customers can use without you
A team can publish a help center built from three optional pieces: Knowledge articles for procedures and answers, a website forum for public questions, and eLearning courses for onboarding material. Agents can pull a published article into a reply rather than retyping it. Articles that are not published stay internal, so the runbook the agent follows and the answer the customer reads can live in the same tree without the internal version reaching the portal.
Ratings and the reports that settle arguments
A rating request can be sent when a ticket reaches a chosen stage, and the customer answers with a happy, neutral or unhappy face plus a comment. Those become rating records, the same structure Project uses, so satisfaction reporting needs no build. Standard analysis covers tickets, SLA status and ratings, sliced by team, agent, stage, tag and period. SLA status analysis is the report to put in front of a customer who insists you are always late.
How we configure Odoo Helpdesk
Fix the team structure before touching stages
The team boundary is the expensive decision to reverse, because the alias, the SLA policies, the reporting and the member list all hang off it. Teams by product line work where the skills differ. Teams by region work where the working calendar and the language differ. Teams per customer almost never work, since the count keeps growing and each one needs its own alias and policies. Write the routing rule down first, then build the smallest number of teams that satisfies it.
Wire the email path, then test the reply
Odoo 17 moved the alias domain and its catchall out of system parameters into an alias domain record reached from the general settings, so start there, then point an incoming mail server at the mailbox and give each team its alias. On a self hosted server the mailbox must not rewrite headers, because reply threading depends on the message id and the reply address. Test three things before go live: a new mail creating a ticket, a customer reply landing on that same ticket, and an out of office auto reply failing to create a second one.
Model stages around the SLA clock
Stages that exist only to look busy make the SLA meaningless. Keep the set small and identify the stages where the ball is genuinely with the customer, because those are the ones to exclude from SLA counting. Decide which stage means first response and which means resolved, since those are what the policies will target. Fold the closed stages so the kanban stays readable, and agree in writing who may move a ticket backwards and what that does to the clock.
Build the working schedule and the holidays
A four hour SLA means nothing until the system knows which four hours. The working schedule driving the calculation has to match the real week, Sunday to Thursday across most of the Gulf, and it has to carry public holidays or targets will expire over Eid while the office is shut. Desks covering several countries need a schedule per calendar and a clear rule about which one applies. Contracts promising cover around the clock need a schedule that says exactly that.
Open the portal to the right contacts
Portal access is granted from the contact record. What that contact then sees follows the customer on the ticket and the company the contact sits under, so a client with five site managers can end up with each person seeing everything their company raised or only their own tickets, depending on how those contacts are structured. Log in as a real portal user and check it rather than assuming. The switch that lets customers close their own tickets sits on the team and is worth deciding now. Read your stage names as a customer would, because the portal shows them, and rename anything awkward on a client screen before launch.
Agree what happens to the old tickets
Importing history is heavier than it looks. Ticket bodies belong in the chatter as messages and attachments as their own records, and the creation date is a technical field the import screen will not set, so keeping real timestamps means loading through the API or accepting that every migrated ticket was created on cutover day. SLA history cannot be recalculated afterwards, which means migrated tickets distort any comparison of before and after. Many projects import open tickets only and keep the old system readable for a year.
Where Odoo Helpdesk projects go wrong
Budgeting for Helpdesk on Community
The app is Enterprise only, and the discovery usually lands after the project has been priced. Three routes are honest. Buy Enterprise for the agents, which is per user and often smaller than feared once customers sit on the free portal. Build the desk in Project on Community, accepting that the SLA engine and the after sales actions do not come with it, though stages, timesheets, portal sharing and customer ratings do. Or take a third party helpdesk module from the app store, which covers part of the gap, varies in quality and becomes a migration cost at every version. Pick the route at kickoff, not during user testing.
Two tickets for every conversation
Duplicate tickets are the most common go live complaint and they are almost always the mail path. A forwarding rule that rewrites the sender breaks the customer match, a mailbox with its own auto responder answers the alias and creates a fresh ticket, and an agent replying from Outlook instead of the chatter starts a parallel thread the system cannot see. Fix the forwarding, then stop agents replying outside Odoo. The second half is training, not configuration.
Log note against send message
The chatter offers both and only one of them is private. A message reaches the followers of the ticket, which includes the portal customer once they are following it. Internal opinion typed as a message is then visible on the customer portal, permanently, with a timestamp against it. This causes more embarrassment than any technical defect on a helpdesk project. Train the distinction on day one and check the follower list on tickets created from inbound mail.
SLA policies that nobody can read
Two failures repeat. The first is overlap: four policies matching every ticket produces a status list an agent stops reading and a report nobody trusts. The second is timing, because a policy written after go live never backfills tickets that are already closed and only reaches open ones as they are next updated, so the first weeks of SLA reporting are not comparable with later ones. Start with one or two policies that match the contracts you actually signed, and add more only when a real dispute needs the evidence.
Paying a licence for your customers
Client contacts given internal user accounts, usually to skip a portal invitation, are billed like employees. On a desk serving fifty companies with three contacts each, that is a large monthly line for people who read their own tickets and nothing else. Portal users cost nothing and see what they should see. The audit is quick: list the internal users, check which ones map to an employee record, and convert the rest before the next renewal.
Assuming escalation is a feature
There is no escalation matrix in the product. A breached SLA changes the status on the ticket and appears in reporting, but it does not notify a manager, reassign the work or telephone anybody. Escalation has to be assembled from stages, automation rules that notify or reassign, and scheduled activities with named owners. Define what escalation means in the contract you signed, then build that, rather than waiting for a switch labelled escalate to appear in the settings.
What it works with
- + Sales and Subscriptions, so an agent can check what the customer bought and whether the support contract is still running
- + Timesheets and Project, for logging support hours and turning them into a billable line
- + Field Service, so an onsite intervention raised from a ticket becomes a scheduled task with a worksheet
- + Repairs and Inventory, for warranty returns, spare parts and the serial number history of the delivered unit
- + Accounting, for the credit note that a refund action raises against the original invoice
- + Knowledge, Forum and eLearning, which together make up the customer facing help center, with Knowledge on Enterprise and the other two available in Community
- + Live Chat, where an agent turns a conversation into a ticket without retyping anything the visitor already said
- + Automation rules for stage driven notification and reassignment, and Studio where the desk needs custom ticket fields without a developer
Odoo Helpdesk by country
Saudi Arabia (KSA)
The working schedule behind every SLA has to be Sunday to Thursday on Riyadh time, or every Friday ticket reports late and the numbers stop meaning anything. Ramadan shortens the working day and the Eid dates move each year, so the calendar is maintained annually rather than set once. Arabic leads on the portal, the mail templates and the rating request, which puts right to left layout on the pre launch checklist. Ticket attachments carry personal data covered by the Personal Data Protection Law, so retention becomes a configured rule instead of an afterthought.
United Arab Emirates
The public sector week is Monday to Friday with a short Friday and most private employers followed, while Saudi and Qatar stayed on Sunday to Thursday, so one Gulf SLA calendar copied across a regional rollout is wrong in at least one country. Support sells here as an annual maintenance contract, and the VAT falls on the invoice for the year rather than on each ticket, so drawing down prepaid hours is not a taxable event and the support product should not be configured as though it were. Free zone and mainland entities invoice separately, which usually means separate teams, aliases and sequences even when the same agents answer both.
Pakistan
Sales tax on services is provincial, so support billed out of tickets answers to the Sindh Revenue Board in Karachi and the Punjab Revenue Authority in Lahore at different rates, with Islamabad Capital Territory administered federally, and one support product carrying a single tax default will be wrong somewhere. Corporate customers withhold tax on service payments, so the cash received against a support invoice is less than the figure printed on it, and reconciliation has to expect that gap instead of chasing it as a short payment. Confirm whether the invoicing entity is inside the current FBR digital invoicing scope before promising anything about how those invoices are issued.
India
Support is a service, so place of supply decides IGST against CGST and SGST, and a ticket billed to a customer's branch in another state is not the same invoice as one billed to head office. The support product needs its own service accounting code rather than borrowing an HSN from a goods line, because the rate and the return both key off it. Above the e-invoicing turnover threshold the invoice needs an IRN back from the portal before it reaches the customer, so a desk that bills weekly from closed tickets has to leave room in the run for that call to fail and be retried.
Turkey
Ticket attachments, chatter messages and portal uploads held in the Odoo filestore are personal data under KVKK, and the clarification text has to sit where that data is collected, which means the portal ticket form and not only the privacy page. A consumer complaint can be taken to a district or provincial arbitration committee, which asks the seller for its account of what happened and when, so the ticket history and its timestamps are the evidence and a desk that closes tickets with no notes has nothing to file. Invoices raised from billable tickets then split between e-Fatura and e-Arsiv depending on whether the counterparty is registered.
Germany
Public holidays are set per Bundesland, so a team covering Bavaria and Hamburg cannot run one national SLA calendar without promising cover on a day half the desk is off. Agent level reporting on response time and rating is performance monitoring under section 87 of the Works Constitution Act, so a company with a works council settles the terms in writing before those dashboards are published with names on them. Buyers also want the data processing agreement covering ticket content before signing, and where the desk is outsourced that agreement has to name the hosting arrangement, not only the consultancy.
United Kingdom
A UK GDPR erasure request has to reach the ticket chatter and its attachments, not only the contact record, so agree who executes it and how it is evidenced before the first one arrives. Support contracts here are usually backed by service credits, which makes the SLA status report the document a credit claim is argued from, so the stage names in Odoo and the definitions in the signed contract have to say the same thing. Public sector buyers ask whether the customer portal meets the accessibility regulations, and that question arrives inside the tender rather than after it.
France
French consumer law bars a premium rate number for after sales and complaint handling, so the contact details published on the portal and inside ticket emails need checking against it. Customer facing templates, the portal and the stage names a customer can see are expected in French under the rules on commercial content. The invoice behind a billable ticket falls inside the electronic invoicing reform, where every business has to be able to receive electronic invoices from September 2026 with issuing phased in behind that, while the ticket and its chatter stay outside it.
Odoo Helpdesk FAQs
Is Odoo Helpdesk available in Community?
No, and there is no Community edition of it to install. Helpdesk arrives with an Enterprise subscription, which is billed per internal user rather than per app, and self hosting does not avoid that because Enterprise code needs a valid subscription. Check the plan as well as the edition. On Odoo Online, Studio, the external API and multi company sit above the entry level plan, and helpdesk builds tend to need at least one of the three.
How is Helpdesk different from running support in Project?
They look alike on a kanban board and diverge underneath. A task belongs to a project, so customer visibility is handled project by project and a customer with work in four projects is four separate grants. A ticket carries its customer on the record itself, and the portal follows from that one field. Reporting splits the same way: ticket analysis counts tickets by customer, team and SLA status, while task analysis counts work inside a project. The practical test is whether you need a stored status per policy per record and a report you can hand to a customer in a dispute. If you do, Project will not get you there without a build.
Does an SLA measure first response, or only that a ticket reached a stage?
Only the stage. A policy asks whether the ticket reached a named stage inside the target, so a first response target is in practice a target for reaching whatever stage you have agreed means responded. It is not read from the timestamp of the first outgoing message. A desk promising a one hour first response therefore needs a stage the agent moves the ticket into when replying, because an agent who answers without moving it reports as late while the customer is perfectly satisfied.
What happens to the SLA if a ticket's priority or team changes later?
Policies are matched against the ticket as it currently stands, so raising the priority on day three can attach a stricter policy that was never in play when the ticket arrived. The deadline is then counted in working hours from when the ticket was created, not from the moment the priority changed, which is how a ticket can report as breached the instant it is escalated. Decide whether that is the behaviour you want before writing policies keyed on priority.
Can one team take mail on more than one address?
A team carries one alias, so two support addresses mean either two teams or a mail rule that redirects both into the same alias. Redirection is the cheaper answer and the more fragile one: set up badly it delivers every ticket under the forwarding mailbox rather than the person who wrote in, and the customer link is what the portal listing, the customer based SLA matching and the per customer reporting all hang on. If the two addresses need different policies, different members or separate reporting anyway, build two teams and leave it there.
Do agents need Sales, Inventory and Accounting rights for the after sales actions?
Yes, for the action to finish. Enabling the option on the team puts the button on the ticket, but a refund still writes a credit note and a return still creates a picking, and the agent's own access rights decide whether that write is permitted. Two workable answers: give agents the minimum rights on the target apps, or let the ticket raise the request and have the team that owns the process complete it, with the link kept on the ticket. Finance usually prefers the second.
Can different customers have different SLA targets?
Yes. A policy matches on the customer, the company, a tag, the ticket type or the priority, so gold and silver tiers are normally a tag on the ticket or a list of customers on the policy. The catch is when that tag gets applied. A ticket arriving by email carries no tag, so it has to be set by an automation rule keyed on the sender, and a mail from an address Odoo cannot match to a contact has no customer either, which means it matches no customer based policy until an agent fixes it. Policies also belong to a team, so a customer served by two teams needs the same policy built on both.
Can we handle support over WhatsApp?
WhatsApp is a separate Enterprise application with a Meta business account behind it, not another inbox inside a helpdesk team, and inbound messages do not turn themselves into tickets. Meta also governs the conversation: outbound templates need approval, and free form replies are only allowed inside the window that opens when the customer writes to you. If WhatsApp is a real support channel in your market, scope and price it as its own piece of work.
Will the portal and the notification emails appear in the customer's language?
The portal screens and the mail templates render in the language set on the contact, provided that language is installed and the template has been translated, which covers the labels, the buttons and the date format. What is not translated is anything a person typed: the subject, the description, the agent's reply. Bilingual desks solve that with agents who write in the customer's language, not with a setting.
Can one database serve several brands or legal entities?
Yes. Teams belong to a company, so each entity gets its own teams, aliases, stages and SLA policies, and record rules keep the ticket lists apart. Agents working across entities need the right companies enabled on their user record. Branding does not follow the company automatically, so the mail templates, the portal and the help center each need checking per brand before launch.