Last month an Odoo partner in Cairo pulled up an inventory report with the client's CFO on the call. Five million pounds of finished sofas and raw fabric was sitting in a location called supplier_need_maintenance — and nobody on the operations team could name the person responsible for it. The partner had implemented the maintenance workflow two years ago. The flow was correct on paper: raw → outbound → need_maintenance → burn_scrap. What the client was actually running, today, was raw → burn_scrap direct. Two operation types in the middle had been quietly abandoned. The client's stock controller had been clicking past them for nine months.
The pain Odoo partners actually live with
Scope drift after go-live is the failure mode nobody warns first-time partners about. It is not a kickoff problem. It is what happens in month seven, twelve, eighteen, when the client's team has rotated, their original PM is now running a different ERP project, and the user training that justified ten implementation hours has been forgotten by a stock controller who learned the system by watching one colleague. The Odoo configuration is correct. The user behavior is not. The partner is the only one who can tell the difference, and the partner does not live in the client's warehouse.
The original Odoo Functional Consultant LinkedIn group has been debating this same pattern for three years now. The MENA partner channel, where roughly 470 partners share the same client archetypes, all see it: an implementation reaches steady-state, the client says everything is fine, and twelve months later an inventory audit surfaces a multi-million-EGP black hole in a stock location nobody is watching. The contract was for implementation. Maintenance retainers, when they exist at all, get billed against tickets — and tickets only get opened when somebody notices something is broken.
Why meeting tools don't catch this
Otter and Granola will give the partner a transcript of the call where the CFO asked the question. Fathom will summarize it. Fireflies will tag action items. None of them will tell the partner, six months later, what was actually decided about how pick_components and manufacturing operation types were supposed to be used after the production line shut down. None of them will surface the contradiction between what the operations lead said in month two ("we'll archive those operation types when production stops") and what the stock controller is doing in month fourteen (still using them, on muscle memory).
The gap is not transcription. The gap is that meeting summaries are unverified statements about what someone said, and an unverified statement about what someone said is not a decision a partner can rely on six months later. A partner who acts on an unverified summary — files a ticket, drafts an SOW change, opens an Odoo SH PR — is exposed in exactly the same way the client's CFO is exposed when the stock controller acts on muscle memory. There is no human attestation that the recall is correct.
What the verified-facts model changes
Knowcap captures the meeting the same way Otter does. Then it extracts every decision, every risk, every task, every load-bearing fact, and routes them to a named human who confirms each one before the fact enters the knowledge graph. There is no "confirm all" button — that would delete the whole point. The partner's PM clicks through extracted claims after a forty-seven-minute call and confirms seven of them in about four minutes. Each confirmed claim now carries provenance: the meeting it came from, the timestamp it was spoken, the person who confirmed it. Six months later, when the operations lead is gone and the stock controller is improvising, the partner can run a query against the graph: "What did we decide about operation type usage post-production-shutdown?" The answer comes back with the meeting, the speaker, the timestamp, and the named human who signed off.
The same partner who lived through the 5M EGP drift scenario above ran exactly this query in a follow-up session. The original decision — archive pick_components, manufacturing, store_finished_product after production stops — was captured in a meeting in late 2025. It was never executed in production. The partner now has a record showing the decision existed, who confirmed it, and that operations never closed the loop. That record is the difference between billing a discovery engagement to find the drift and writing it off as the client's problem.
What this looks like in practice for Odoo partners
Concretely: every implementation kickoff, every client check-in, every change-request call gets recorded into a Knowcap project tied to the partner's client. Memory categories are pre-tuned for Odoo work — risks include integration failures and scope drift, decisions include module activations and operation-type policy, tasks include user-permission changes and stock-location audits, persons includes the client's named stock controller and warehouse manager so the graph can build a sentiment arc on the people whose adherence determines whether the implementation survives.
The PM confirms claims weekly, in batches of four or five minutes each. Within ninety days the partner has a verified record of every operational policy decision the client made, with the named signatory. Within six months the partner can offer the client a quarterly drift audit as a billable retainer: query the graph for decisions older than ninety days, sample fifteen percent of them against the client's actual Odoo configuration, surface the drift, and bill the remediation as a separate engagement. The 5M EGP black hole becomes a six-figure retainer instead of a customer-relationship problem.
The Odoo SH PR path closes the loop. Knowcap's verified-fact substrate connects to the partner's GitHub. A confirmed decision about an operation-type change can auto-draft an Odoo SH PR with the attestation chain attached: the meeting, the speaker, the confirming human, the date. The partner reviews the PR rather than writing it. The audit trail satisfies the client's internal compliance team and the partner's own quality system.
FAQ
How is this different from putting decisions in Notion or ClickUp?
Notion and ClickUp store text. They do not extract claims, they do not anchor those claims to a recording timestamp, and they do not require a named human to attest. A PM typing meeting notes is themselves the unverified source; Knowcap routes the AI's extraction back to a named human before the claim enters the knowledge graph. Six months later, when the PM has moved on, the verified-fact record is what survives — not the freeform Notion page nobody updated.
Does it work for Arabic-speaking client meetings?
Yes. Knowcap's transcription handles mixed Arabic-English meetings, which is the default mode in MENA partner-client calls. Verified facts can be exported as bilingual artifacts for client-facing SOW deltas and decision logs, which is mandatory for Saudi and Egyptian engagements. Arabic ASR is not perfect — independent benchmarks show meaningful word-error rates on spontaneous dialect speech — so the verification layer is doubly important: a named human confirms the claim, not the raw transcript.
What if the client does not want to be recorded?
Recording is partner-side. The PM records their own implementation calls for their own quality system, the same way audit firms record their fieldwork. The client does not need a Knowcap account. The verified-fact graph belongs to the partner and serves the partner's downstream agent actions — SOW change tracking, Odoo SH PR drafting, quarterly drift audits.
How does this connect to billing more hours?
Drift audits are billable. Today the average MENA Odoo partner discovers drift only when the client surfaces a problem, by which point the conversation is defensive. With a verified-fact graph, the partner runs proactive quarterly audits as a retainer line item — sample decisions against live configuration, surface the gap, scope the remediation, bill the engagement. The 5M EGP case above became roughly forty billable consulting hours.
What is the minimum implementation to get value?
One pilot client, three months of recorded calls, and the PM committing to four minutes of claim confirmation per recorded hour. After ninety days the partner has enough verified history to run the first drift query and produce a billable finding. The pilot pays for itself before the second client is onboarded.
A partner who can prove what was decided six months ago, against the person who decided it, with the meeting in evidence — that partner does not eat the scope change.