Offers & methodology · AI integration
One AI use case, taken from workshop to production
A framed engagement, not a proof of concept that dies in a sandbox. You arrive with a business problem; you leave with one AI feature live inside your Odoo, the governance written down, your teams trained, and a method you can reuse for the next use case without us.
Why this shape
Most AI pilots fail for the same two reasons
They are run on a use case chosen because it was interesting rather than because it was painful, and they stop at a demo because nobody decided in advance what the system was allowed to do on its own. Both are avoidable, and both are avoided before any model is chosen.
So this offer buys one use case, end to end, with the governance settled at the start: which decisions are automated, which need approval, what is logged, where the data goes. What AI in Odoo actually is, and the ten use cases we deliver most often, are on the Odoo AI page and our AI expertise — this page is about the engagement itself.
Scope
What is included, and what is not
No price on this page: what you can hold us to is the scope. Here it is, from both ends.
Included
- a scoping workshop to choose the use case on the pain it removes, not on how impressive it sounds;
- a feasibility check against your actual data — quality first, model second;
- a governance note: automated versus approved decisions, logging, access rights, where the data is processed;
- design of the feature inside your existing Odoo workflows;
- configuration, development and model integration;
- rollout with training, documentation and monitoring in production;
- a review after real usage, with the numbers agreed at the start.
Not included
- a fleet of use cases — this engagement is deliberately one;
- model subscription costs, which are billed by the provider and depend on your volume;
- cleaning up a data foundation that is not fit for the use case: if the feasibility check says the data is not there, we stop and say so;
- guarantees on model output quality, which nobody can honestly give;
- AI on processes that are not yet stable in Odoo — automating a broken process only makes it fail faster.
The third and the last exclusion are the ones that end conversations early, and that is their purpose. An AI project on unstable processes or unusable data is a budget spent on discovering something a workshop would have told you.
How it runs
Four stages, one use case
Short enough to keep momentum, structured enough that the result survives the enthusiasm.
1. Frame the use case
Where does the manual work actually hurt? We look at volume, repetition and the cost of an error, and we pick one. The others go on a list for later.
2. Decide the boundaries
What the system may do alone, what needs a human, what is logged, and where the data is processed. Written before anything is built, because retrofitting governance is how projects get stopped by legal.
3. Build it inside Odoo
In your workflows, on your records, with the permissions you already have. Tested by the people who will use it, not by us.
4. Deploy, train, measure
Live with monitoring, documentation and training — then a review against the numbers agreed at stage one. If it did not move them, we say so.
Start your transformation
One process you would automate tomorrow if you could?
Name it. We will tell you within a call whether it is a good first use case, and what the data would have to look like.
FAQ
Frequently asked questions
Weeks rather than months, because the scope is one feature. The stage that stretches is never the build — it is the governance decision, when nobody in the room has the authority to say what the system may do on its own.
That is settled in stage two, before anything is built, and it drives the choice of model and hosting rather than the reverse. If your constraints rule out sending data to an external service, we say so at the workshop rather than at the demo.
No, and be wary of anyone who does. What we commit to is a measurable before and after on the numbers you choose at stage one, and an honest review afterwards — including the case where the gain is not worth the running cost.
Then this is not the right engagement yet. Automating a process that is still half in spreadsheets automates the spreadsheets. Start with an implementation package and come back — the use case will still be there, and the data behind it will be usable.
Cheaper, because the governance, the monitoring and the method already exist. That is the actual point of buying the first one this way rather than as a quick pilot.
Let's talk
Which process would you automate first?
Describe it in a sentence, tell us what your Odoo looks like today, and we will tell you whether it is a good first use case — or which one would be better.