Most Odoo customization work goes wrong at the request, not at the code. "Make the sales report better" gives whoever builds it nothing to aim at, so what comes back is a guess, and the review cycle that follows costs more than the build did. A request that names the report, the columns, the users and the decision the report is supposed to support usually gets built correctly the first time.
This matters more, not less, when AI does the building. On Plemo, a customization begins as a chat: you describe what you want, the system asks clarifying questions, and it bounds requests that are too broad to build safely. It then produces a written specification that you approve before development starts, and the finished change appears in a sandbox copy of your system before anything reaches production. Every one of those gates works better when the opening request is precise. Here is how to write one.
Start with the problem, not the feature
The most useful first sentence describes what is going wrong today. "Our warehouse team re-keys delivery quantities into a spreadsheet every evening because the picking screen does not show the customer's PO number" is a far better opening than "add a PO number field to pickings". The first explains what the change is for, which means the specification can propose a better answer than the one you had in mind. The second locks in a solution before anyone has checked whether it actually solves the problem.
State the cost as well, roughly: how many people, how often, how long it takes them. That is what decides whether the customization is worth building at all, and it gives you an honest way to judge the result later.
Name the exact place in Odoo
Odoo has many screens that look alike. "The invoice list" could be Accounting then Customer Invoices, the invoice lines inside a sales order, or a portal view your customers see. Write down the menu path you click to get there, the name of the view, and the URL if you can copy it. If the change touches a report, say whether you mean the printed PDF, the list view or the pivot.
The same discipline applies to data. If you want a new field, say where it lives (on the customer, on the order, on the order line), whether it is required, who is allowed to edit it, and what should happen to the records that already exist without it.
Say who it is for and when it runs
Two questions decide a surprising share of the design: which user groups see this, and what triggers it. A validation that fires when a salesperson confirms an order is a different piece of work from one that runs nightly across every open order. A field only managers may edit needs an access rule; a field everyone may edit does not.
If the answer is "everyone" and "always", write that down rather than leaving it out. Silence reads as uncertainty, and uncertainty turns into another round of questions before anything gets built.
Draw the boundary yourself
Good requests say what is out of scope. "The UAE company only, not the Saudi one." "Sales orders, not purchase orders." "Existing records stay as they are." Every boundary you draw yourself is a decision nobody has to come back and ask about, and it keeps the change small enough to review properly.
Large requests are not forbidden, but they are better split. "Rebuild our approval workflow" is really five or six separate changes, each of which can be specified, approved, previewed and accepted on its own. Splitting them means a mistake in one does not hold up the other five.
Answer the clarifying questions precisely
When you are asked whether the new field should appear on the printed quotation, "yes" is a complete answer and "probably, whatever makes sense" is not. Loose answers get resolved by assumption, and assumptions are exactly what you end up rejecting later at the sandbox stage. If you genuinely do not know, say so and name the person who does. Deferring a question is fine. Answering it vaguely is not.
Read the specification like a contract
The written specification is the last cheap moment to change your mind. After you approve it, changing direction means work gets redone, and on credit-based usage a redo is not free. So read it for what is missing as much as for what is wrong: if it does not mention the printed document, the printed document is not changing.
Test the sandbox with real work
The sandbox is a copy of your system, so test the change the way you actually operate: your real products, the awkward customer with three delivery addresses, the order that always breaks things. Clicking through the happy path proves the feature exists. Pushing a realistic week of work through it proves the feature is right.
The same request, rewritten
Before: "We need better credit control."
After: "When a salesperson confirms a sales order for a customer whose overdue balance exceeds their credit limit, block the confirmation and show a message naming the overdue amount. Sales managers should be able to override the block with a reason that is logged on the order. UAE company only, sales orders only, already-confirmed orders untouched. It happens a handful of times a week and finance currently catches it only after invoicing."
The second version is not better because it is more technical. It is better because every question somebody would have asked is already answered in it. That is the whole skill, and it is a business skill rather than a technical one.
One last judgment call: if what you want is bigger than a feature and closer to redesigning how a department works, that is consulting work rather than a customization request, and it deserves a proper discovery conversation first. Our custom development service covers that path.