The demo worked. The operation still does not trust it.
What does AI enablement actually mean?
AI enablement is the decision work before a custom model, an automation queue, or a governance layer. It starts from the operation: which judgement repeats often enough to encode, what “wrong” looks like, who owns the exception, and whether a rule or a human review gate is the cheaper answer than an LLM.
Most AI conversations arrive as a feature pitch: a chatbot, a scoring model, a document extractor. The hard part sits earlier. The decision already happens in the ERP or beside it. Nobody has measured how often it fails. There is no fallback when the model is slow or unavailable. Logging was left for “phase two.” Six weeks after go-live the team has quietly stopped using it.
We treat enablement as a diagnosis with honest exits: encode the judgement into custom AI solutions, put the unglamorous half into workflow automation, instrument governance so failures surface, or do not buy AI at all and fix the process. Selling the model before the diagnosis is how demos become shelfware.
Does any of this sound familiar?
Leadership wants “AI in the ERP” but cannot name the decision it would change next month.
A pilot scored well in a controlled set; nobody defined what wrong looks like in production.
The team still runs a spreadsheet beside the official output because they do not trust the model.
There is no documented answer for when the model is unavailable or times out.
An earlier vendor left a feature live with no owner, no logs, and no review gate.
Quotes compare model brands and token prices, not evaluation harnesses or write-back into the system of record.
If you recognised three of these, you do not need a cleverer model. You need a decision that the operation can survive.
What enablement looked like when it had to hold.
VitaOne · AI-assisted practitioner workflows
A health and wellness operator came after a previous partner. Enablement meant deciding which practitioner judgements could be assisted, how structured outputs write back into Odoo, and where the clinician stays in the loop. The delivery sits on Custom Solutions; the decision work came first.
Read the VitaOne case study →Blood-test data mapping
Laboratory output normalised into structures the practitioner workflow consumes. Mapping and validation first; the clinical reading stays with the clinician. Enablement here was knowing what not to automate.
What an enablement engagement decides, and what it does not.
In the decision
- Which operational judgements are worth encoding, and which are not.
- What must already be true in the ERP or workflow (data, owners, write-back paths).
- A written recommendation: custom model, workflow automation, governance-only, or no AI.
- A risk register for wrong answers, latency, and unavailability.
- Clear fences so delivery quotes are not reopening the strategy fight mid-build.
Not in the decision
We will tell you not to buy the demo.
We build AI into systems that already carry payroll, inventory, and invoices. The interesting question was never whether the model is clever. It is what happens when it is wrong, slow, or unavailable, and whether anyone finds out before the customer does.
That stance is why enablement sits as a Solution page. The Service pages assume you already know you need custom models, workflow automation, or governance. This page is for the buyer who only knows the operation is stuck and someone said “AI.”
How we work is on How we work. Engagement shapes are on Engagement models.
How an enablement read runs.
-
01
Situation call
Which decision is stuck, how often it runs, what a bad answer costs, and whether something is already live and unwatched. If production AI is already failing users, we route to Rescue before enablement theatre.
-
02
Decision inventory
Map the judgements that repeat. Separate process failures from places a model could help. Name owners for exceptions.
-
03
Options on paper
Encode (custom), automate the path (workflow), instrument only (governance), install a published module where it fits, or do not buy AI. Each option carries what you give up.
-
04
Recommended path
One primary recommendation and the conditions under which we would change it. Delivery work is scoped only after this lands.
-
05
Hand-off into Services or stop
You keep the write-up. If you stay with us, the next page is the matching AI Service (or Rescue), not a vague “phase two model.”
Questions we get first.
Is this the same as AI Custom Solutions?
No. Custom Solutions is the delivery of models and LLM workflows wired into the system of record. This page is the decision work that says whether that delivery (or workflow, governance, or no AI) is the right first step. When the path is a custom build, we send you to AI Custom Solutions.
We already bought a model that nobody uses. Start here?
If it is live and failing trust or operations, start at Rescue & Stabilization. Enablement on top of an unwatched feature is how you get a second shelfware project.
Will you always recommend an LLM?
No. Often the honest answer is a rule, a queue, and an exception report. We will say that instead of selling the more expensive thing.
Do you have AI products we can install today?
Three Entrivis AI modules are on the Odoo Apps Store for v19 (prompts, LLM hub, Insight Hub Pro), under the same author profile as our other apps. Existence only on this page: no prices or download counts. Browse from the AI & Automation hub.
What does this cost?
A fixed-scope read after the situation call, priced in writing before work starts. Delivery projects are separate quotes after the recommendation.
Can our existing AI vendor stay involved?
Yes when that is the right long-term ownership. We are not interested in a fight over the account. We are interested in whether the operation can trust the answer when it is wrong.
Get a clear path before the next demo.
Tell us which decision is stuck. We will say encode, automate, govern, or do not buy AI, and which Service page (if any) comes next.