WHAT WE SEE IN THE FIELD
The support email works. The process does not.
Customers send messages to: support@company.com
- Someone opens the mailbox.
- Someone else replies.
- A third person assumes the issue has already been handled.
- Some emails are flagged.
- Others are forwarded internally.
- Urgent requests are identified because the customer writes “URGENT” in the subject line.
And when management asks: How many open issues do we have? the answer depends on who is looking at the inbox.
A shared mailbox can receive support requests, it does not automatically create a support process.
That requires ownership, prioritisation, deadlines and visibility.
This is where Odoo Helpdesk becomes useful.
FROM EMAIL TO TICKET
Customers can keep using email
Implementing Helpdesk does not mean forcing customers to learn a new communication channel.
Odoo Helpdesk can create tickets from messages sent to a team email alias. Replies remain associated with the corresponding record through Odoo's email routing logic.
So the customer experience can remain very simple:
Send an email to support@company.com.
Internally, however, the result is no longer just another message in an inbox.
It becomes a ticket with:
- Customer
- Responsible user
- Helpdesk team
- Stage
- Priority
- Tags
- Conversation history
- SLA deadlines, where applicable
That structure is what makes support manageable.
ONE INBOX DOES NOT MEAN ONE TEAM
Different requests may need different support processes
Odoo allows multiple Helpdesk teams to be configured, each with its own ticket pipeline and visibility rules.
For example:
Customer Support: Product questions, delivery issues and general assistance.
Technical Support: Incidents requiring technical investigation.
Finance Support: Invoice or payment-related requests.
Internal IT: Requests from employees rather than customers.
These teams do not necessarily need the same stages, access or assignment logic.
A technical incident might follow:
New → Diagnosis → Waiting for Customer → In Progress → Resolved
A billing request may only need:
New → In Review → Resolved
The workflow should reflect the service being delivered.
Not every support request belongs in the same pipeline.
AUTOMATIC ASSIGNMENT
A new ticket should not wait for someone to notice it
One of the weaknesses of a shared mailbox is ownership.
Who is responsible?
Often the answer is:
Whoever sees it first.
Odoo Helpdesk can automatically assign incoming tickets to team members.
In Odoo, assignment can balance tickets according to the number assigned to each user or according to the number of open tickets currently being handled. Tickets can also be dispatched based on tags and team-member expertise.
This matters because equal distribution is not necessarily the same as balanced workload.
Imagine:
- Consultant A has 20 tickets, but 18 are already closed.
- Consultant B has 12 tickets, all still open.
Simply counting total assignments could send the next request to the wrong person.
Workload-based assignment provides a different logic.
And expertise-based routing adds another possibility.
A ticket tagged: Accounting
may need one consultant.
A ticket tagged: Manufacturing
may need another.
Routing can therefore reflect the structure of the support team.
HOW WE WOULD CONFIGURE IT
Start with ticket categories and ownership
Before configuring automation, we would normally understand:
- What kinds of requests arrive?
- Which teams handle them?
- What information is required to resolve them?
- Which requests have contractual response commitments?
- Which cases require specialist knowledge?
- When is a ticket considered resolved?
- When are we waiting for the customer rather than the support team?
Only after answering those questions would we design the Helpdesk pipeline.
For example:
New: Request received but not yet analysed.
Qualified: Scope and ownership understood.
In Progress: Someone is actively working on the issue.
Waiting for Customer: Support cannot continue without customer input.
Resolved: Required action completed.
That last distinction matters.
A ticket waiting three days for customer feedback should not necessarily be interpreted in the same way as a ticket that has been sitting untouched for three days internally.
A useful Helpdesk workflow needs to represent operational reality.
PRIORITY IS NOT THE SAME AS SLA
An urgent ticket and a contractual deadline are different concepts
Odoo tickets include priority levels.
They can be marked from low priority through urgent, and higher-priority tickets are surfaced accordingly in ticket views. Priority can also form part of the criteria used by SLA policies.
But priority answers: How important is this ticket?
An SLA answers: What service commitment applies to this ticket?
Those are related, but they are not identical.
A VIP customer may have a contractual SLA even for a normal-priority request.
An urgent ticket from another customer may require immediate operational attention without having the same contractual conditions.
This is why we would avoid using priority as the only support-control mechanism.
SLA POLICIES
“We respond quickly” is not an SLA
An SLA should be measurable.
Odoo allows SLA policies to apply according to criteria such as:
- Helpdesk team
- Priority
- Tags
- Customers
and, in some configurations, related services.
The policy then defines the target stage and the allowed working time.
For example:
Standard Support
- Normal-priority request
- Target: In Progress
- Deadline: 16 working hours
Critical Incident
- Urgent priority
- Target: In Progress
- Deadline: 2 working hours
Premium Customer
- Relevant customer
- Target: Resolved
- Deadline: 8 working hours
Odoo calculates the applicable SLA deadline based on the ticket creation date and the configured working hours. If the target is achieved, the SLA is marked as satisfied. If the deadline passes before the required stage is reached, the SLA is recorded as failed.
This creates objective service measurement.
SLA DESIGN MATTERS
A bad SLA can produce perfect reporting and poor service
This is where configuration requires judgement.
Suppose the SLA says:
Ticket must reach “In Progress” within 4 hours.
A support agent can move every ticket to In Progress immediately, and SLA report looks excellent. But nothing has necessarily been solved.
The problem is not the Odoo feature, its the service definition that is weak.
We therefore need to decide what the SLA actually measures.
- Acknowledgement?
- First meaningful response?
- Start of work?
- Resolution?
Different services may need different targets.
The dashboard only becomes useful when the metric represents something the customer actually values.
EMAIL, WEBSITE FORM OR LIVE CHAT?
The intake channel should match the type of request
Odoo Helpdesk supports multiple ticket-entry channels, including email aliases, website forms and Live Chat.
Each has advantages.
Email: Low friction for customers and appropriate for most existing support relationships.
Website form: Useful when structured information is required before support can start.
Instead of receiving:
“The machine doesn't work.”
the form can ask for:
- Serial number
- Location
- Product
- Error message
- Urgency
- Attachment
- Better input can reduce triage time.
Live Chat: Useful where real-time interaction is important, with conversations capable of becoming Helpdesk tickets when further follow-up is required.
The correct answer is often not to choose one.
Different channels can feed the same controlled support process.
CUSTOMER COMMUNICATION CAN FOLLOW THE WORKFLOW
Stage changes can trigger communication
Odoo stages can have email templates associated with them.
When a ticket reaches a configured stage, a predefined email can automatically be sent to the customer.
For example:
Ticket received: “Your request has been registered.”
Waiting for Customer: “We need the following information to continue.”
Resolved: “Your request has been completed.”
This reduces repetitive communication. But I would use this carefully.
Not every stage change should send an automated message: If customers receive six generic emails while one issue moves through internal stages, automation becomes noise.
Customer communication should follow meaningful external events, not every internal workflow movement.
THE HELP CENTER
The best support ticket may be the one the customer never needs to open
Odoo Helpdesk can integrate with Knowledge, Forums and eLearning through the Help Center, providing a central place where customers can search for information and support resources.
This creates another layer of support.
Repeated questions such as:
- How do I reset my password?
- Where can I download my invoice?
- How do I configure this product?
may not require an agent every time.
If the answer is stable and repeatable, it may belong in the knowledge base.
This is not simply about reducing ticket volume, it also gives customers an immediate answer instead of making them wait for support.
The useful question becomes:
Which tickets are teaching us that documentation is missing?
That is a much more mature use of Helpdesk data.
CUSTOMER RATINGS
Closing a ticket does not tell you whether the customer thought it was handled well
Odoo Helpdesk can request customer ratings after a ticket is completed.
Ratings can be enabled at team level and triggered through an email template associated with the relevant closing stage.
This adds a dimension that operational reporting cannot provide.
You may have:
- Excellent SLA compliance.
- Fast resolution times.
- Low backlog.
- And dissatisfied customers.
Or the opposite.
Quantitative performance and perceived service quality should be looked at together.
THE MOST COMMON MISTAKE
Recreating the shared inbox inside Odoo
Imagine this setup:
- One Helpdesk team.
- One stage called “Open”.
- Everyone sees everything.
- No assignment rules.
- No SLA.
- No tags.
- No defined closing criteria.
Technically, the company is using Odoo Helpdesk, operationally, it still has a shared inbox. Only the interface changed.
A Helpdesk implementation should clarify:
- Who owns the request?
- What happens next?
- When should it happen?
- How do we know it has been resolved?
Without those answers, ticketing software alone creates very little process improvement.
ANOTHER COMMON MISTAKE
Creating too many ticket stages
The opposite problem also exists.
New - Assigned - Acknowledged - Reviewed - Analysed - Validated - Scheduled - Started - In Progress - Pending - Waiting - Testing - Ready - Resolved - Closed.
The pipeline starts representing every internal action ans support agents spend more time maintaining the workflow than solving tickets since
A stage should normally represent a meaningful change in status or responsibility.
If management makes no different decision based on two stages, they may not need to be separate.
REPORTING
Ticket volume alone is not support performance
Counting tickets is useful, but not enough.
A support manager may need to understand:
- Open ticket backlog
- Tickets by stage
- Tickets by team
- Tickets by responsible user
- Priority distribution
- SLA compliance
- Customer ratings
- Recurring ticket categories
Odoo includes SLA status analysis specifically for monitoring SLA performance across tickets and team members.
The point of reporting is not to produce more charts, rather to identify where the support process is failing.
- Are tickets waiting too long for assignment?
- Is one category generating recurring incidents?
- Is a particular team consistently missing SLA targets?
- Are customers dissatisfied despite fast resolution?
Those questions lead to process improvement.
OXALYO'S TAKE
Support should be managed as a process, not as correspondence
Email is an excellent communication channel, but a poor management system.
A strong Odoo Helpdesk setup adds structure behind the communication without necessarily making support more complicated for the customer.
The customer can still send an email.
Behind that email, Odoo can determine:
- where the ticket belongs,
- who should handle it,
- how urgent it is,
- which SLA applies,
- what stage it has reached,
- and whether the service commitment was met.
That is the difference between receiving support requests and managing customer service.
When we configure Helpdesk, we therefore start with the support model.
Then we configure Odoo around it.
FAQ: ODOO HELPDESK
Can Odoo create support tickets from email?
Yes. Helpdesk teams can use email aliases so that incoming messages automatically create tickets. Replies can remain linked to the corresponding ticket conversation.
Can Odoo automatically assign Helpdesk tickets?
Yes. Odoo Helpdesk supports automatic assignment according to workload and can also dispatch tickets according to tags and team-member expertise.
Does Odoo Helpdesk support SLAs?
Yes. SLA policies can be configured with criteria such as team, priority, tags and customer, together with target stages and working-time deadlines.
Can customers submit Odoo Helpdesk tickets through a website?
Yes. Website forms can be enabled as an intake channel for Helpdesk tickets and customised to collect the information required by the support team.
Does Odoo Helpdesk support Live Chat?
Yes. Live Chat can be used as a Helpdesk contact channel, and support conversations can be converted into tickets when additional follow-up is required.
Can Odoo automatically notify customers when a ticket changes stage?
Yes. Email templates can be associated with stages so that customer communications are triggered when tickets reach those stages.
Can Odoo measure customer satisfaction after support?
Yes. Customer Ratings can be activated on Helpdesk teams, with rating requests typically sent when tickets reach the relevant closing stage.
Can Odoo provide a customer self-service Help Center?
Yes. Odoo Helpdesk integrates with Knowledge, Forums and eLearning to provide Help Center functionality for customers and support teams.
Is your support team managing tickets or managing an inbox?
If customers contact one address but ownership, priorities, deadlines and follow-up still depend on people remembering what to do, there is probably more value available from Odoo Helpdesk.
Talk to Oxalyo about your Odoo Helpdesk setup.