Odoo functional consultant
Owns process, configuration, app selection, specifications and reporting. Talks to your operations team. Decides what the system should do.
A functional consultant is the person who decides how your business is represented inside Odoo: which process stays, which changes, which apps you need, and what has to be specified before a developer touches anything.
Get this role wrong and you pay developers to build around a process nobody agreed on.
Businesses our functional consultants work with
An Odoo functional consultant translates how a business operates into how Odoo is configured. They analyse the current process, design the Odoo workflow, select the applications and features, write functional specifications, configure the system, classify the gaps that configuration cannot close, and define the data, reporting and validation needs. They do not write code — they decide what, if anything, needs writing.
The functional specification is the deliverable. If an engagement produces no written spec, there is nothing for a developer to build against and nothing for you to hold anyone to.
Seven stages. The order matters: skipping straight to configuration is how businesses end up with an Odoo that mirrors their old spreadsheets.
Walking the real flow with the people who do it — order to cash, procure to pay, plan to produce — rather than reading a process document nobody follows.
Deciding how that flow should run inside Odoo, including where your process should change because the standard path is better than the habit.
Which applications are genuinely in phase one, which wait, and which features inside them force an Enterprise licence.
Written, in business language, covering expected behaviour, edge cases and acceptance criteria. This is what a developer builds against and what you sign off.
Settings, pricelists, approval rules, access rights, stages, reporting filters. Everything that can be done without code is done here.
For each remaining gap: configure differently, buy an app, change the process, or build. Each option costed, with its upgrade consequence stated.
What has to migrate, what the reports must show, and what the system should refuse to let users do. Validation rules prevent most recurring data errors.
Three roles that are regularly confused, which is why projects hire the wrong one and wonder why decisions stall.
Owns process, configuration, app selection, specifications and reporting. Talks to your operations team. Decides what the system should do.
Owns code: custom modules, integrations, reports, migrations. Builds against a specification. Decides how it is built. See hire an Odoo developer.
Works above the product: whether an ERP is the right answer, which platform, how it is phased, how the business case holds together. See Odoo ERP consultant.
Most of our functional work is not greenfield. It is businesses already on Odoo where something is not right.
We follow one real transaction end to end through the system before touching any setting. Half the time the reported problem is a symptom of a decision made at go-live that nobody has revisited — a costing method, a warehouse step, an approval rule.
A written list of everything your process needs that the system does not currently deliver, each one classified as configuration, app purchase, process change or development, with a cost against it. You can act on it with us or with anyone else.
Our functional consultants sit on the same projects as the technical team, so a configuration recommendation always carries its development consequence, and a build decision always carries its process consequence.
Product behaviour follows Odoo’s documentation; the method is from our own projects.
Describe what actually happens in your business today and we will tell you how it should run in Odoo — and which parts genuinely need building.