A Custom Odoo Screen for the Way Your Team Works
Half your team avoids the ERP because its screens were never built for their job. The fix isn't more training — it's a smaller screen.
Your company bought Odoo. Finance lives in it. The warehouse uses it, more or less. And then there is everybody else — drivers, field sales, technicians, store supervisors — who opened it once, decided it was not for them, and went back to WhatsApp and a spreadsheet.
The work still reaches Odoo eventually. It reaches it because someone at the office types it in the next morning. You bought a system of record and ended up running a system of re-typing.
Why capable software goes unused
Odoo's screens are built to serve every kind of business, so they carry every field any business might need. A delivery order form is a good example: dozens of fields, most of them irrelevant to a driver standing at a customer's gate in the rain, holding a phone in one hand.
That is not a badly designed screen. It is a general screen. The person doing one specific job needs about three of those fields and none of the menus.
Two common responses don't solve it:
- More training. Turnover means you pay for it again every year, and the problem was never skill — it was fit.
- Rebuilding Odoo's own screens. Deep customization is expensive to build, more expensive to maintain, and turns every version upgrade into a project. Worse, those screens are shared: what you simplify for one team, you complicate for another.
A third option: keep Odoo standard, add a small screen on top
There is a middle path most businesses never consider. Odoo stays standard and stays the single source of truth. On top of it you put a small, purpose-built interface for one role doing one job — and what that person enters lands in Odoo immediately, with nobody re-keying it later.
A useful rule of thumb: one role, one job, one screen. If the screen needs a manual, it has grown too big.
The fair objection is: how does a tap on a driver's phone become a real entry in Odoo, if nobody opens Odoo? That connection is the whole problem, and it is the part we built a product for — more on that below.
A scenario: the distributor with twelve drivers
Picture a distribution company supplying around 300 outlets across Jabodetabek. Twelve drivers, three admin staff, Odoo already running for inventory and accounting.
How the day works now. Each morning the admin prints delivery notes. Drivers run their routes. Customers sign on paper. Short deliveries and returns get scribbled in the margin. The paperwork comes back at six in the evening, or the next morning if the route ran long. An admin keys it into Odoo the following day. The invoice goes out a day or two after that. A returned carton nobody wrote down surfaces at month-end, when nobody can remember it.
The cost of that is not the admin's time. It is that the invoice date slips by two or three days on every delivery, the stock figure is wrong for most of the working day, and a disputed delivery is one person's word against another's.
What the custom screen looks like. On the driver's phone, a single page:
- Today's stops, in route order.
- Tap a stop: customer name, items, quantities.
- Mark it delivered in full, partial (adjust the quantity, pick a reason), or not delivered (pick a reason).
- Take a photo of the signed note.
- Submit.
No menus, no accounting vocabulary, no navigation to learn. A new driver is productive on their first route.
What happens underneath. The moment the driver taps submit, the app hands the delivery to ODXProxy, and ODXProxy records it in Odoo. Stock adjusts. The photo attaches to the record. A partial delivery flags the sales admin the same hour instead of next month. The invoice can be raised that afternoon.
| Before | After |
|---|---|
| Delivery recorded next day, by an admin | Recorded at the customer's gate, by the person who did it |
| Invoice waits for the paperwork to come back | Invoice can be raised the same day |
| Stock is accurate once a day, briefly | Stock is accurate through the day |
| A dispute is word against word | A dispute is a photo with a timestamp |
| The admin's morning is spent typing yesterday | The admin's morning is spent on exceptions |
Notice the second-order effect. Nobody had to be persuaded to "adopt the ERP". The driver adopted a screen with one button. ERP adoption happened as a side effect.
Where else this pattern fits
The delivery case is the easiest to picture, but the shape repeats across an organization:
| Role | The one job | What the screen holds |
|---|---|---|
| Field sales | Take an order at the outlet | Customer, products, quantity, confirm |
| Warehouse receiving | Confirm what the supplier actually delivered | PO, quantity received, damages, photo |
| Service technician | Close out a job | Job, parts used, hours, customer signature |
| Store supervisor | Daily count on fast movers | Ten SKUs, count, submit |
| Management | One number, first thing | Today's sales, receivables, cash position |
| Your customer | Check their own order | Order status, delivery documents, invoices |
That last row is worth pausing on. A customer-facing screen removes a whole category of phone calls your admin team currently answers by looking things up in Odoo on the customer's behalf.
How to tell a workflow is a good candidate
Look for these signals:
- It happens often — daily, or many times a day.
- It is done by people away from a desk, outside the finance team.
- It needs only a handful of fields.
- It currently lives in WhatsApp, on paper, or in a spreadsheet.
- Somebody else types the result into Odoo afterwards. This is the strongest signal of all, and the easiest one to check.
The reverse also holds. If a workflow involves judgement, approvals, or accounting decisions, leave it in Odoo where the controls and the audit trail already are. Purpose-built screens are for capturing and looking up work, not for setting policy.
The piece that makes this buildable: ODXProxy
A small screen is the easy half. The hard half is the connection between that screen and your ERP — and that half is what decides whether this is a good idea or a liability. Any application that writes into Odoo is touching the most sensitive system you own.
That is the problem ODXProxy solves, and it is why we built it. It is a gateway that sits between these small applications and your Odoo — a Keyklik product, running at odxproxy.io. The driver's phone never touches your database. It talks to the gateway; the gateway checks what the app is allowed to do, records that it happened, and passes it to Odoo. Nothing is installed inside Odoo: no modules, no altered screens, nothing to redo at the next upgrade.
Four properties matter from a business standpoint:
- Controlled. Each application gets its own key and a narrow permission, not the run of your database. Only a short, fixed list of operations is allowed through — look something up, record it, update specific fields. The driver app can record deliveries; it cannot read payroll or change price lists. Lose a phone, or part ways with an outside vendor, and you switch off that one key without touching anything else.
- Traceable. Every entry carries its trail — which application, which user, at what time. When a figure looks wrong next month, you are reading a record instead of reconstructing a story.
- Quick to build against. Whoever builds the screen — your own developer or a vendor — does not start from scratch. ODXProxy provides ready-made connectors for the platforms these screens are actually built on: iOS, Android, the browser, and the common back-end languages. That is the difference between one role's screen taking a few weeks and it turning into a project.
- Flexible. The screen can be a phone app, a browser page, or a customer portal, built in whatever technology fits the job. One gateway serves all of them, and Odoo stays standard underneath.
That last point has the biggest long-term value. Because your core Odoo was never modified, your upgrade path stays intact. Custom fit on the outside, standard system on the inside — which is the opposite of how most ERP customization ends up.
What to ask before you build one
Whoever builds it, ask three questions and expect specific answers:
- Exactly what can this application do to our data — and what can it not do?
- If a number looks wrong next month, can we trace where it came from?
- When we upgrade Odoo, what breaks?
If the answer to the third question is "we'll have to rework it," you are being offered a customization, not an interface.
Those three questions are exactly the ones ODXProxy was designed to answer — and they are worth putting to any vendor, ourselves included.
Next step
Put one question to your team: what do you type into Odoo that somebody else already wrote down somewhere else? Every honest answer is a candidate.
Take the highest-volume one and give that role a single screen. One workflow is enough to show what the difference feels like — and enough to prove the case before you spend on the next one.
Want to give your team an interface that fits how they actually work? Read more about ODXProxy, see our integration services, or contact the Keyklik team.
Note (DYOR — Do Your Own Research): This article is general information, not legal, accounting, or tax advice. Requirements around electronic records, digital proof of delivery, data protection, and invoicing documentation differ by industry and business structure, and change over time. If your workflow touches invoicing or tax documents, verify against official sources (DJP at pajak.go.id and Coretax, plus the Odoo documentation) and consult your own accountant, legal advisor, and IT security advisor before rolling anything out.