AI Voice Bot

Large-scale outbound voice campaigns that verify and update customer contact information straight into Odoo Contacts and CRM — a business is still open, the right person answers, the phone and email on file are still correct — without a human dialing a single number.

Every screenshot below was captured from this module running with its own demo data. Nothing is a mockup. Where a screen looks sparse — three campaigns, nine calls — that is the real size of the demo, not a cropped-down real dataset.

The design rule, stated plainly

Real-time telephony and AI conversation happen in a separate, external AI Voice Service — never inside an Odoo worker. Odoo's job is campaign management, contact eligibility, the call queue, opt-out suppression, and turning a finished call's transcript into a reviewed change to a real Contact or Lead. A telephony or AI outage degrades to "no new calls dispatched," never to a stuck or crashed Odoo process.

Nothing an AI extracts is ever written to a Contact or Lead un-reviewed. Confidence below a configurable threshold, an opt-out, or a flagged follow-up all route the result to a human reviewer instead of applying it — and even an approved "changed" result only ever overwrites the specific fields it actually reported a new value for.

Two adapter modules, one shared contract

AI Voice Bot: Twilio places and tracks the calls. AI Voice Bot: Claude turns a finished call's transcript into the structured result this module reviews. Neither is required to install this module — a campaign can be built and validated without one, but starting it refuses without a real telephony provider configured.

Both adapters plug in through the same small runtime registry (not an _inherit chain, since a base module cannot depend on its own extensions) keyed by a payment.provider-style pluggable code field — so a third adapter for a different telephony or AI vendor is a self-contained module away, not a change to this one.

1. Campaigns, as a kanban

What you are seeing: three campaigns grouped by state — Completed, Draft, Running — each card showing eligible-contact and call counts. What it is for: the running campaign carries a red “3 to review” flag, so a reviewer never has to open a campaign to know it needs attention. Configurable: the standard activity progressbar (planned/today/overdue) comes from Odoo's own mail.activity.mixin — no extra field needed.

2. A running campaign

What you are seeing: the full state machine in the header (Draft → Validation → Manager Approval → Ready → Running → Completed), two stat buttons — Calls and, only when non-zero, Pending Review — and the campaign's telephony provider, AI provider, conversation script and confidence thresholds. What it is for: everything a manager needs to judge a campaign's health without leaving the form. Important: the review-pending count is a real stored, indexed aggregate — not a per-view estimate — so it stays accurate at scale.

3. The call queue, expanded

What you are seeing: every call this campaign has placed, with its own state (Queued, Completed, In Progress, No Answer, Opted Out) and review-state badge. What it is for: full operational visibility into exactly what has and hasn't gone out. Configurable: grouped by campaign by default; group or filter by any field, including the parsed AI business/contact status.

4. The Review Queue

What you are seeing: only calls actually awaiting a decision — pre-filtered, not just pre-sorted. What it is for: the one screen a Voice Bot Reviewer needs open all day. Important: an opted-out call still shows up here — the opt-out itself is applied to the suppression list immediately and unconditionally, but the review record is still worth a human's acknowledgement.

5. Reviewing a call

What you are seeing: the AI's extraction, parsed into real fields — confidence score, business and contact status, the proposed new name/job title/phone — never raw JSON. What it is for: a reviewer approves or rejects with full context, one click, no JSON-reading required. Configurable: Approve and Reject only appear while the call is actually pending — both disappear the instant a decision is recorded, and both are gated to the Reviewer group.

6. The Conversation Builder

What you are seeing: the question script the external AI Voice Service conducts a call from, edited inline — question type (Yes/No, Text, Email, Phone, Choice, Date, or a free-form AI-judged intent), retry limits, and whether a question should route to opt-out handling or human escalation. What it is for: the entire conversation is configuration, not code — a new script for a different campaign is a new record, not a deploy.

7. Settings

What you are seeing: three independently-contributed blocks sharing one settings page — Campaign Safety (this base module), Twilio, and Claude (both from their own adapter modules, appearing here only because they happen to be installed). What it is for: one settings screen regardless of which adapters a deployment chooses to install. Configurable: the Conversation Webhook Token (not shown here, further down the page) is the shared secret the external AI Voice Service authenticates its result postbacks with.

8. Campaign volume, as a pivot

What you are seeing: total/eligible/call/completed/failed/review-pending counts, sliceable by campaign state. What it is for: a manager asking "how many contacts did we actually reach this quarter" gets a real answer, not a guess. Important: these six measures are store=True specifically so a pivot's read_group can aggregate them — a non-stored computed field cannot be a pivot measure.

9. Opt-outs

What you are seeing: a suppressed phone number, the campaign and call it was detected on, and why. What it is for: a phone number here is never called by this suite again, checked both when a campaign's contact list is validated and again at queue-generation time. Important: an opt-out detected mid-conversation is applied the moment the webhook lands — it never waits on human review.