Training your team on Dolibarr: making adoption stick after go-live

Why a well-configured Dolibarr ends up as a spreadsheet

The project ends, the modules are active, the document templates are ready. Three weeks later, the salesperson keeps quotes in a spreadsheet, the administrative assistant holds a list of invoices to chase in a separate file, and the workshop manager notes stock on paper. This is not ill will. Under pressure, everyone falls back on the habit they master. A spreadsheet is familiar, immediate and carries no risk of picking the wrong menu. Dolibarr takes effort until the reflexes are in place. So training is not just showing screens. It must make the new gesture simpler than the old one, for each person, on their real tasks. Once duplicates take hold, the data diverges, nobody trusts the ERP any more, and you are back to square one. Treat adoption as a phase of the project, with an owner, a schedule and success criteria, rather than a formality at the end.

Train by profile, not by module

A general two-hour session covering every function leaves no mark. Split it by role instead. The salesperson needs to create a third party, price a quote, turn it into an order and find a customer's history. The administrative assistant handles invoicing, payments and reminders. The purchasing manager handles suppliers, orders and receipts. Management views, validates and steers. For each profile, write a list of five to ten daily tasks, then train only on those. Use real data: a real customer, a real quote in progress, not an abstract sample set. Access rights follow the same logic. A user who sees only the useful menus gets lost less. If you want outside support, our training service follows this job-based approach, using your own documents as material.

Prepare before the first session

A good session is prepared. The venue matters less than the state of the instance: if participants log in to an empty or unstable environment, confidence collapses within the first fifteen minutes. Plan for an internal contact too, someone comfortable with the tool, who will be the first port of call for colleagues. This relay stops every question from going to the integrator and anchors the knowledge in your company.

• Load the real third parties, products and price lists before the session, so everyone finds their own data.
• Create one account per person with the rights of their role, and test each login the day before.
• Name an internal contact and free up some of their time to answer colleagues.
• Prepare a one-page sheet per profile, with the daily tasks in the order they come up.
• Limit each session to one profile and a short duration, followed by an exercise on a real case.

Support the first weeks

What matters most happens right after the training. Set a clear switchover date: from that day, no quote or invoice outside Dolibarr. Companies that let both systems coexist keep both for a long time. During the first weeks, hold a short, regular meeting, for example fifteen minutes at the start of the week, where everyone raises their blockers. Write them down. Many come from the configuration, not the user: a useless field, a poorly suited quote template, a misunderstood status. Fix them quickly, because each friction removed takes away a reason to go back to the spreadsheet. The internal contact keeps a list of frequent questions that becomes the basis of your cheat sheet. If the team gets stuck on a technical point, responsive support keeps the blockage short and stops the temptation to work around the tool from setting in.

Remove the crutches that keep spreadsheets alive

A spreadsheet survives as long as it provides a service Dolibarr does not yet provide. Ask your teams: what does this file do that the ERP does not? The answer is often precise. A tracking view of pending quotes, a monthly export in the format management wants, a reminder for unpaid invoices. Each of these needs can usually be met in Dolibarr, through a saved filter, a custom list or a dashboard. For real gaps, a suitable module can fill the need, for example DolicraftDashboard, which is free and lets each user build their home page with the indicators that matter to them. Once the need is covered, archive the file as read-only and tell the team. Removing the old tool only makes sense after its function has been replaced. Doing it the other way round creates resentment and hidden copies.

Measure that Dolibarr is really used

Without measurement, adoption stays an impression. Choose a few simple signals you can observe in Dolibarr itself. Are documents created in the tool, and by whom? Do quotes move to signed status and then to an order, or do they stay stuck as drafts? Are invoices matched with payments? Do customer records show recent events in the agenda? Also compare what you find in the ERP with what accounting receives: a gap points to data entered elsewhere. Complete this with a direct conversation with each profile, because a number does not tell you why someone avoids a screen. Set a review meeting a few weeks after the switchover, then a second one later, and each time decide on one or two actions: extra training, a setting, a right to adjust. Adoption is measured over time, not on launch day.

Plan your next session

Start small. This week, list your user profiles and, for each, the five tasks that come up every day. Name an internal contact and choose the date after which spreadsheets no longer receive new data. These three decisions weigh more than any course material. If your deployment is already several months old and workarounds have set in, a usage audit can identify what is blocking, screen by screen. Dolicraft can train your teams on their own data and extend the support after go-live. To discuss your situation, use our contact page and tell us how many profiles are involved and which tools your teams still use alongside Dolibarr.