A few months after go-live, most Odoo teams have the same problem: a list of change requests longer than anyone can work through. Sales wants an extra field on the quotation. Finance wants the invoice report laid out differently. The warehouse wants the picking screen to stop asking for a lot number on products that never had lots. Every request is reasonable. None of them is urgent on its own. Together they are a backlog nobody is actually managing.
The constraint is rarely how fast a change can be built. On a platform like Plemo, where a customization starts as a chat request, becomes a written spec you approve, and lands in a sandbox before it ever reaches production, the build step is no longer the slow part. The slow part is your own team. Someone has to describe the change precisely, someone has to read and approve the spec, and someone has to open the sandbox and confirm the result is right. That attention is finite, and protecting it is what a good ordering does.
Separate blockers from workarounds
Split the list in two. A blocker is something a person cannot do in the system at all, so the work stops or moves to a spreadsheet permanently. A workaround is something people can do, but slowly, or with a manual step outside Odoo.
Blockers usually go first, with one important exception: a workaround that twenty people repeat every day costs far more per month than a blocker that hits one person once a quarter. Count the exposure before you rank, not just the severity.
Score by frequency, not by seniority
The request that gets built first is usually the one from the most senior person who asked most recently. That is the default, and it is a bad one. Use a rough score instead: how many people are affected, how often, and how many minutes each occurrence costs. The numbers do not need to be precise. They need to be comparable, so two requests can be argued about on the same terms.
One category deserves to jump the queue regardless of score: anything that lets wrong data into the system. A missing validation, a field that accepts a free-text value where it should reference a record, a status that can be skipped. These get more expensive every month they stay open, because each month adds more records that will need cleaning later. Fix the intake, then clean the history.
Batch by module, not by department
Departments are how requests arrive. They are not how changes should be grouped. Three requests that all touch the sales order screen are cheaper as one change than as three, because the expensive part is the review round, not the code. One spec to read, one sandbox to open, one set of people pulled off their work to test.
Grouping this way also surfaces contradictions early. Two departments frequently ask for opposite things on the same screen, and it is much better to discover that while writing one spec than after both changes are live.
Check whether the request is really a process problem
A share of every backlog is not a software gap at all. Someone is asking for a new button because nobody showed them the existing one, or because a step sits with the wrong role and the system is correctly refusing to let them do it. Those requests are answered faster by configuration or a short training session than by development, and they should leave the build list entirely.
What remains after that filter is the genuine gap: behavior standard Odoo does not have and your business genuinely needs. That is the list worth spending custom development effort on, and it is usually much shorter than the original pile.
Keep the first few changes small
Whatever your scoring says, make the first two or three items small and self-contained. The goal is not throughput at the start, it is building the habit: writing a request precisely enough to be answered, reading a spec closely enough to catch a wrong assumption, and testing a sandbox with real cases instead of clicking through it once.
A team that has done that three times on small changes will handle a large one well. A team whose first change is a rewrite of the entire quotation flow will approve a spec it did not really read, and find the problem in production.
A working order
- Anything that produces wrong numbers or lets in bad data.
- Hard blockers that stop work or push it out of the system.
- High-frequency workarounds, ranked by people multiplied by frequency.
- Batches where several requests touch one module or one screen.
- Single-user preferences and cosmetic changes, last and honestly labeled as last.
Review the list every month, and delete from it
Backlogs rot quietly. A request written six months ago may describe a process that has since changed, a report someone has stopped running, or a problem an Odoo version upgrade already fixed. Deferring an item forever is worse than closing it, because a long list makes every prioritization discussion harder and hides the five things that actually matter.
Go through the list once a month. Ask of each item whether anyone would notice if it were never built. If the answer is no, close it and say so. A backlog of eight live requests you can defend beats a backlog of sixty you cannot, and it makes the next month's decision take fifteen minutes instead of an afternoon.