/services/odoo-implementation
Odoo implementation, delivered on the date we agreed.
End-to-end delivery for mid-market teams — process mapping, configuration, data, training and a phased go-live, run by the consultant who scoped it.
- 98% go-live on the planned date
- 5 median modules in phase one
- 180+ implementations delivered
Facts. - 98% · go-live on the planned date - 5 · median modules in phase one - 180+ · implementations delivered
/the-problem
Implementations fail on process, not software.
Odoo will do what you configure it to do. That is the whole difficulty. A configuration is a set of decisions about how your business runs, and if those decisions have never been written down, the implementation becomes the place where they get made — badly, at speed, by whoever is in the room.
The pattern is consistent. Two departments describe the same process differently and neither knows it. A workflow that exists because one person has always done it that way survives into the new system unexamined. A phase-one scope grows by a module a fortnight because each addition sounds small on its own.
So we map the gap between how you operate and what Odoo does natively, in writing, before anything is configured. You approve that document. It becomes the scope, and the scope is what the date is built on — which is why the date holds.
/what-that-buys-you
What that buys you
- Current-state process mapping across every in-scope function
- A written gap analysis: what Odoo does natively, what needs configuring, what needs building
- Module configuration with your master data, not demo data
- Data migration and reconciliation from the systems you're leaving
- Role-based training, recorded, with written SOPs
- A phased go-live plan with a defined rollback point
- Thirty days of hypercare after launch
- Scope agreed in writing before a date is committed to
- No configuration built on an assumption nobody checked
- Master data cleaned before it becomes a live problem
- Users trained on your processes, not on a generic Odoo course
- A go-live you can stop, rather than one you have to survive
- Documentation good enough that your team owns it afterwards
/how-we-run-it
Six stages. The durations are indicative, the sequence is not.
A twelve-week phase one for a single-company deployment of five modules. Multi-company, multi-currency or heavy manufacturing extends the middle, not the ends.
-
01
Discovery
Workshops with the people who do the work, not only the people who own it. Current-state processes captured as they actually run.
1–2 weeks
-
02
Gap analysis
Every process mapped against native Odoo. Three verdicts per gap: configure, build, or change the process. You sign this off.
1–2 weeks
-
03
Configuration
Modules built to the approved gap analysis, using your master data. Weekly demo on the real system.
3–4 weeks
-
04
Data & integration
Migration, cleansing, reconciliation. Any third-party connections built and error-handled.
2–3 weeks
-
05
Training & UAT
Role-based sessions, recorded. Your team runs the test scripts, not us — the point is whether they can.
2 weeks
-
06
Go-live & hypercare
Phased cutover with a defined rollback point. Named consultant on hand daily for the first month.
1 week + 30 days
/what-you-get
Four artefacts you keep.
Everything below is handed over in your repository and your document store, not ours. If you replace us the day after go-live, nothing about the system becomes unknowable.
The gap analysis
Every process, its Odoo answer, and the decision behind it. The single most useful document you will own about your own operation.
/02Configuration record
Every setting that isn't a default, and why it isn't.
/03Custom code, in your repository
Commented, with its own README. Never in ours only.
/04Training pack
Recorded sessions plus written SOPs per role, so the next hire doesn't need us.
/where-this-fits
What comes before this, and what comes after.
Implementation is the middle of the work, not the start of it. Consulting decides whether Odoo is the right answer at all; migration brings your history across; integration connects what you're keeping; training and support carry it afterwards.
/questions
Asked on every first call.
-
A single-company phase one of five modules runs about twelve weeks from discovery to go-live. What moves that number is rarely Odoo — it's how much process work has to happen first, how clean your master data is, and how many people have to approve the gap analysis.
-
You can. We will tell you not to. Every module added to phase one adds master data to clean, a team to train and a dependency to the critical path. Our on-date go-lives median five modules; the ones that slipped averaged nine. Phase two is four weeks after go-live, not four years.
-
One process owner per in-scope function, available for workshops and UAT — realistically a day a week during discovery and two during testing. And one decision-maker who can sign off the gap analysis without convening a committee. Implementations stall on that second one more often than the first.
-
We say so, in writing, and you have paid for a document that saved you an implementation. It is rare, but it happens — most often where a business has one genuinely unusual core process that a specialist system already handles well.
-
Depends on what you need, and we'll model both. Enterprise carries the accounting localisations, full manufacturing and the upgrade service. Community suits teams with in-house Python capability and a tolerance for maintaining their own upgrades. We have no commercial reason to push you either way — see licensing and hosting.
/next
Bring us the process, not the wishlist.
Thirty minutes, no slides. We will tell you straight if Odoo is not the answer.