Every ERP support team knows the pattern. A user reports that an invoice posted to the wrong account. Someone fixes the entry, closes the ticket, and the SLA looks fine. Next month, it happens again, to a different user.
The ticket was resolved. The problem never was.
Two different jobs
Service management frameworks such as ITIL separate two things that support teams often blur together:
- An incident is a single disruption: "this invoice is wrong". The goal is to restore normal work quickly.
- A problem is the underlying cause of one or more incidents: "the tax mapping on this product category is wrong". The goal is to remove the cause so it doesn't happen again.
When both live in one ticket, the quick fix closes the ticket and the root cause is forgotten.
A simple way to separate them
- Resolve the incident and close the ticket as normal, so the user is unblocked and the SLA reflects reality.
- If the cause isn't removed, open a problem record, linked to the incident.
- Investigate the problem separately: configuration, data, access, customisation or user training?
- Fix the root cause, test it, and record what changed.
- Link future incidents with the same symptom to the problem, so its true impact is visible.
This keeps incident metrics honest and gives problems their own owner and timeline.
Root-cause analysis in five questions
For each problem, answer:
- What exactly happened? Record, user, date, expected versus actual result.
- Since when? Did it start after a change, an upgrade or a new user?
- What type of cause? Configuration, master data, access rights, custom code, or process and training.
- Why did it happen? Keep asking "why" until you reach something you can change.
- How will we know it's fixed? A test case, and no new linked incidents for an agreed period.
Finding the problems worth fixing
Look at the last three months of tickets and group them by area and symptom. The handful of groups that keep recurring usually account for a large share of the support load. Those are your first problem records.
Report them monthly: open problems, their impact (number of linked incidents), owner and target date. That turns support from firefighting into steady improvement.
A real example. In a support team I lead, a finance team kept replying to resolved tickets with "It is resolved. Please provide RCA." The user was working again, but the ticket couldn't close until the root cause was explained. Tickets sat open for weeks, and our support figures looked worse than reality.
We changed the process. Once the user is working again, the incident closes. A linked problem record stays open for the root-cause work, with an owner. Finance gets a record they can follow, and support gets honest numbers. When we looked, dozens of tickets had been parked in an RCA status with almost no problem records behind them.
How we can help
RNXOur Odoo Support & Maintenance service separates incidents from problems as standard, with root-cause analysis on repeat issues and a monthly report on what's been fixed for good.