Most Odoo customization programs do not fail on the technical side. They fail because nobody in the business is clearly responsible for deciding what gets built, in what order, and whether the result was actually right. Requests arrive from finance, sales, and the warehouse, each one urgent to the person who filed it, and the queue turns into a list of unrelated tickets with no owner attached.
This is a governance problem, not a tooling problem. Getting it right costs nothing and changes the outcome of everything downstream.
Three roles, not one
Ownership gets confusing because people collapse three different jobs into a single word. Separating them makes the rest easy:
- The requester is the person who feels the pain. A warehouse supervisor who retypes the same delivery note twice a day. An accountant reconciling something the system should be reconciling. They describe the problem, not the solution.
- The owner decides whether the request is worth doing, what it is worth doing instead of, and what "done" means. There should be exactly one owner per Odoo instance, or at most one per major area if you are large enough to justify it.
- The approver signs off on the written specification and on the preview before it reaches production. In small companies this is the same person as the owner. In larger ones it is often a process owner or a finance lead whose numbers change if the customization is wrong.
The failure mode is having many requesters, no owner, and an approver who only appears at the end, when the cost of saying no is highest.
Why "IT owns it" usually breaks down
Handing ownership to IT feels natural and works for infrastructure. It works badly for ERP customizations, because IT can evaluate feasibility but cannot judge business value. Asked to choose between a picking-flow change and a commission report, IT has no basis for the decision and will reasonably default to whoever escalated loudest. The result is a backlog ordered by volume rather than by impact.
The opposite arrangement, where every department owns its own requests, fails differently. Odoo is one system with shared master data. Two departments customizing the same document flow independently produce conflicts that only surface after both changes are live.
The workable answer is usually a single business owner who understands the operation end to end, with IT as a standing advisor on feasibility and risk.
What the owner actually does
The role is smaller than it sounds. Concretely, the owner:
- Turns a complaint into a stated business outcome, so the request can be judged rather than just processed.
- Decides sequence. Not everything is urgent, and pretending otherwise is how a backlog stops meaning anything.
- Reads and approves the written specification before development starts, which is the last cheap moment to catch a misunderstanding.
- Tests the change in a sandbox against real scenarios, including the awkward ones, before approving it for production.
- Tells the affected team it shipped, and how the process changes. Customizations that nobody announces get worked around instead of used.
That is perhaps two hours a week for most mid-sized companies. It is not a full-time job, and treating it as one is why the role often goes unfilled.
Where the platform helps, and where it does not
Plemo is built around this shape. Requests start as a conversation that asks clarifying questions and pushes back on requests that are too broad to build. Nothing is developed until a written spec is approved, and nothing reaches production until it has been reviewed in a sandbox that mirrors your instance. AI usage is metered as credits, so the cost of a change is visible before you commit to it.
What none of that does is decide priority for you. A platform can make the request legible, force the ambiguity to the surface early, and give you a safe place to look at the result. It cannot tell you that the commission report matters more this quarter than the picking flow. That judgment is the owner's, and no amount of automation substitutes for it.
Signs the model is broken
You do not need a maturity assessment. A few symptoms are enough:
- Requests are approved by whoever is available rather than whoever is accountable.
- The backlog has items older than six months that nobody will either build or close.
- Specifications are approved without being read, which shows up as rework after the sandbox review.
- Two teams discover in production that they asked for contradictory behavior.
Each of those is a symptom of an absent owner, and each is cheaper to fix by naming one than by adding process on top.
If you would rather have that ownership sit with an external team, our custom development service takes the same structure and runs it with a named consultant. Either way, the structure is the part that matters. The name on it is a detail.