Training users so the work stays on Odoo after go-live
Why teams drift back to Excel a month after go-live, and how role-based training prevents it, with adoption indicators you can measure.
Go-live day usually goes well. The data is migrated, the first invoices are posted, and everyone is relieved. The real test comes about a month later, when the project team has stepped back. That’s when a spreadsheet starts circulating again “just to double-check the stock”, quotations get prepared in Word because it feels faster, and the system slowly becomes a place where data is entered after the fact instead of where the work happens.
This drift is rarely a software problem. It’s a training problem, and it can be prevented. This guide explains why it happens, how we structure training by role, and which indicators tell you whether the work is really staying on Odoo.
Why teams drift back to Excel
People return to Excel when it’s the place where they feel competent. The causes are almost always some mix of the following:
- Training was a demo, not practice. Users watched someone click through screens, but never did their own work themselves before go-live.
- Training was generic. A storekeeper sat through the accounting session and learned nothing about receiving goods with lots and expiry dates.
- Training came too early. Sessions held weeks before go-live are forgotten by the time the system is live.
- The exceptions were never covered. Users can create a sales order, but nobody showed them how to handle a partial delivery or a customer return, so the first exception goes back to a spreadsheet.
- There’s nobody to ask. When a question has no quick answer inside the company, the old way wins.
- Managers still ask for the old reports. If the weekly meeting runs on an Excel file, the team will keep producing it.
Each of these has a fix, and none of them requires changing the system.
Train by role, not by app
A typical training plan is organized by Odoo app: a session on Sales, a session on Inventory, a session on Accounting. That suits the system, not the people. A sales rep doesn’t need to know Sales; they need to know their day. We organize training around roles instead, and each role sees only the screens and steps it actually uses.
| Role | What they practise | Odoo apps involved |
|---|---|---|
| Sales rep | Quotations from the price list, confirming orders, checking stock availability, following up on unpaid invoices | CRM, Sales |
| Storekeeper | Receiving goods, picking and delivering, lots and expiry dates, partial deliveries and returns, inventory adjustments | Inventory, Barcode |
| Purchasing officer | Requests for quotation, purchase orders, reordering rules, matching vendor bills to receipts | Purchase, Inventory |
| Accountant | Customer invoices and e-invoices, vendor bills, payments, bank reconciliation, month-end entries | Accounting |
| Manager | Dashboards, reports, approvals, finding the answer to their own questions without asking for a file | Reporting views across the apps they oversee |
The table is an example. Your roles come from the processes documented during the gap analysis, and the content of each session follows those processes step by step.
Key users first
Before training end users, we train one or two key users per department in more depth: the exceptions, the configuration they’re allowed to change, and how to diagnose the common mistakes. Key users become the first person colleagues ask, which solves the “nobody to ask” problem from day one. They also help run the end-user sessions, so the training is delivered in the department’s own vocabulary.
How the sessions run
On your own data, in a test copy
Every session runs on a test copy of your database, with your products, your customers and your price lists. Users perform their own tasks, on their own screens, while the trainer helps. Practising on demo data with generic products makes the real system feel unfamiliar on the first morning. This is one more reason clean master data matters before training starts.
Close to go-live
End-user training belongs in the last one to two weeks before go-live. Earlier than that, people forget. Later than that, they meet the system for the first time under pressure. Key-user training can start earlier, since key users also take part in testing.
Cover the exceptions, not only the happy path
For each role, list the five or six situations that break the normal flow: a customer return, a cancelled invoice, a delivery that arrives short, a price that needs approval. Practise each one. The first exception after go-live decides whether the user trusts the system or reaches for the spreadsheet.
Leave short written procedures behind
A one-page procedure per task, with the menu path and the steps, is more useful than a long manual. Keep them where people work: in a shared folder, or in the Knowledge app if you use Odoo Enterprise. Odoo’s own free eLearning tutorials are a useful complement for general navigation, but they can’t show your configuration.
Measure adoption in the system
Attendance sheets tell you who sat in the room, not who uses the system. Adoption shows up in the data itself, and most of it can be checked inside Odoo with standard filters and reports.
| Indicator | Where to check it | Warning sign |
|---|---|---|
| Active users | The latest login of each user in Settings, Users | A licensed user who hasn’t logged in for a week |
| Documents created at the source | Sales orders, receipts and invoices grouped by creator | One person entering everything on behalf of a department |
| Timeliness | Gap between a document’s date and when it was created in the system | Deliveries or invoices recorded days after they happened |
| Stock accuracy | Inventory adjustments after each count | Large or repeated adjustments in the same locations |
| Reports used | Which reports managers bring to meetings | The weekly meeting still runs on an exported spreadsheet |
| Questions asked | Requests logged with key users or support | The same question from the same role, week after week |
Review these indicators weekly for the first month, then monthly. Each warning sign points to a specific fix: a refresher for one role, a missing procedure, or a report that should be built in Odoo so the spreadsheet is no longer needed.
The manager’s part
The single strongest signal to a team is what management asks for. When the general manager opens the sales report in Odoo during the weekly meeting, instead of asking for a file, the spreadsheet loses its purpose. When a delivery isn’t recorded in the system, it should be treated as not done. Training gives people the skill; management makes the system the only place where the work counts.
After the first month
Adoption isn’t finished at the end of the first month. New hires join, roles change, and new apps get added in later phases. Plan a short refresher every few months, train new staff by role from their first week, and keep the key users current. A support agreement with a regular usage review keeps this from depending on memory.
As an official Odoo Learning Partner, we train end users, key users and system administrators, at our office, at your company or online. Book training for your team, or see which course fits each business area in the module explorer.
Key takeaways
- Teams return to Excel where they feel competent; the fix is practice, not more features.
- Train by role, on your own data, in the last one to two weeks before go-live.
- Train key users first, so every department has someone to ask from day one.
- Practise the exceptions, because the first one decides whether users trust the system.
- Measure adoption in the data: active users, documents created at the source, timeliness and stock accuracy.
- Management makes it stick by asking for reports from Odoo and setting a firm end date for the old way.
