Customer service breaks for a structural reason, not a staffing one: the person answering the question cannot see what the customer bought, what was promised, or what happened last time. Put the service queue on the same records as sales, stock and invoicing and most of the problem disappears without hiring anyone.
This page covers what actually goes wrong, what changes when service shares the sales records, which parts are worth automating, and what to measure.
What is actually broken?
Context, almost always.
A customer emails about an order. The person who picks it up can see the email and nothing else. To answer, they ask someone in sales, who asks someone in the warehouse. Three people have now touched a question that one person could have answered if the information had been in front of them.
The familiar symptoms:
- Requests arrive in a shared inbox, so nobody owns one until someone claims it, and two people reply to the same customer.
- No history. The customer explains the situation again, which is the single thing customers report as most frustrating.
- Promises are invisible. A credit agreed on the phone exists only in that call.
- No view of load. Nobody can say how many open requests exist, how old they are, or which are stuck.
- Service is judged on responsiveness because resolution cannot be measured.
Hiring into that produces more people with the same blind spot.
What changes when service shares the sales records?
The question gets answered by the person who receives it.
In a connected build, the ticket sits against the customer, and the customer carries their orders, deliveries, invoices and previous tickets. The person answering can see that the order shipped on Tuesday, that an invoice is disputed, and that the same product was returned once before.
What that produces:
- Ownership on arrival. Every request becomes a ticket with an owner, a stage and an age, rather than an email someone might be handling.
- Answers without a relay. Order status, delivery date and invoice position are visible on the ticket.
- Commitments recorded. A credit or a replacement is an action against the record, not a memory.
- A real queue. Volume, age and stage are reportable, so capacity is a number rather than an impression.
- A portal where it suits. Customers can log and track their own requests, which removes the status-chasing emails that make up much of the volume.
Where does the revenue actually come from?
Two places, and it is worth being honest about the size of each.
Retention. A customer whose problem was resolved once, without repeating themselves, stays. This is the larger effect and the harder one to attribute, because you are counting something that did not happen.
Capacity released. If three people spend part of every day relaying information, removing the relay gives that time back. That is measurable and usually the first thing a business notices.
What does not follow automatically is more sales. A service system does not generate demand. It stops you losing customers you already won, and it makes the people you have more effective. Claiming more than that would be overstating it.
What is worth automating?
Routing and visibility. Not the answer.
Worth automating:
- Capture and assignment. Email, portal and web form all create tickets, routed by type or product to the right team.
- Acknowledgement. One message confirming receipt and the reference, so the customer stops wondering.
- Escalation by age. A ticket past its target surfaces to a supervisor rather than waiting to be noticed.
- Follow-up after resolution, which is also where review requests belong if you ask for them.
Not worth automating: the substance of a reply to an unhappy customer. A templated answer to a specific complaint reads as exactly what it is. Templates belong on the routine half of the volume, where the question genuinely is the same every time. More on drawing that line in AI and Automation.
What should be measured?
Resolution, not response.
Response time is easy to measure and easy to game, and it rewards sending something rather than fixing something. The more useful set:
- Time to resolution, by request type, so the slow categories are visible.
- Reopened tickets, which is the honest measure of whether the first answer worked.
- Contacts per order, which exposes a process problem upstream rather than a service problem.
- Volume by cause. If a third of tickets ask where an order is, the fix is dispatch notifications, not more service staff.
That last one matters most. The best service improvement is usually removing the reason people contacted you.
How we work
Ooda Consulting is based in Sydney at Level 6/201 Kent St and works with SMEs across Australia and New Zealand. The Australian team scopes the work and supports it afterwards, with a dedicated senior developer doing the build.
See Odoo ERP Implementation for how a build is scoped and staged, or Why do most Odoo and ERP projects blow out? for what goes wrong when it is not.
Frequently asked questions
Can Odoo run a customer service desk?
Yes. Tickets arrive from email, a web form or a customer portal, route by type or product, and sit against the customer record alongside their orders, deliveries and invoices. The point is the shared record rather than the ticket list itself.
Will a helpdesk system reduce our support volume?
Indirectly. It will not stop people contacting you, but reporting by cause shows which problems generate contact. If a third of tickets ask where an order is, dispatch notifications remove more volume than any service change would.
Can customers track their own requests?
Yes, through a portal where they can log a request and see its status. That suits businesses whose customers chase status often, and suits less where the relationship is handled by phone.
Does better customer service actually increase revenue?
It protects revenue more than it creates it. The effect is retention and released capacity. A service system does not generate demand, and anyone saying otherwise is selling something.
Should we automate responses to customers?
Automate acknowledgement, routing and escalation. Do not automate the substance of a reply to an unhappy customer, because a templated answer to a specific complaint reads as one.
What should we measure in customer service?
Time to resolution by request type, reopened tickets, and contacts per order. Response time is easy to measure and easy to game, and it rewards replying rather than fixing.
