+1 515-644-1400Call any time. 24/7 outage response is an add-on.hello@allodi.us
Allodi
How it works

How our Odoo support works: a human expert, AI agents, and a fence between them and your money.

This page explains exactly who does what when you open a ticket, what the agent is allowed to touch, and what you can see afterwards. If any of it is unclear, that is a bug in this page. Tell us.

The model

Odoo support work splits into two parts. There is the legwork: reading the ticket, finding the relevant model and view, checking the database, reading the module that overrides the standard behavior, writing the patch, running the test. And there is the judgment: is this the right fix, will it affect something else, is this something the customer should be asked about first, is it safe to run against a live company's books.

The legwork is what makes support slow and expensive at most partners. It is also what AI coding agents are now very good at, when they have access to the actual system and a person who knows Odoo checking their work. So that is the split. An agent does the legwork. A human Odoo implementer with years of production experience does the judgment, and holds the only keys that can change anything that matters.

The expert stays. The waiting goes.

Who does what

  • The agentReads tickets, inspects your database and code read-only, and writes up what it found. Drafts changes on a branch and tries them on a copy. Changes nothing on your system outside a short list of pre-approved routine actions.
  • The humanReviews every proposal, rejects or amends it, approves the change, runs the deployment, and answers for the result. Talks to you when a ticket needs a decision only you can make.
  • The logRecords every step of every ticket: what the agent looked at, what it proposed, what the human decided, what was changed, and the commit it lives in. You can read all of it.

The approval flow

Every change, from a typo in a report to a stuck cron job, goes through the same five steps. Only the short list of pre-approved routine actions described under the fences skips step three.

Ticket to AI triage to human approval to change to log Five boxes in a row connected by arrows: 1 Ticket, 2 AI triage with dry run, 3 Human approval, 4 Change applied, 5 Logged in the portal. A dashed return arrow from human approval back to AI triage is labelled rejected, with notes. 1 TICKET You open it in the portal or by email 2 AI TRIAGE Reads code and data, drafts a fix, dry-runs it 3 HUMAN APPROVAL Expert reviews the diff and the dry-run output, approves or sends back 4 CHANGE Applied by the human, from a branch you can read 5 LOG Ticket shows what was looked at and changed rejected, with notes Ticket to AI triage to human approval to change to log Five boxes stacked vertically connected by arrows: 1 Ticket, 2 AI triage with dry run, 3 Human approval, 4 Change applied, 5 Logged in the portal. A dashed return arrow from human approval back to AI triage is labelled rejected, with notes. 1 TICKET You open it in the portal or by email 2 AI TRIAGE Reads code and data, drafts a fix, dry-runs it 3 HUMAN APPROVAL Expert reviews the diff and the dry-run output, approves or sends back rejected, with notes 4 CHANGE Applied by the human, from a branch you can read 5 LOG Ticket shows what was looked at and changed
A person approves in step 3 and applies the change in step 4. Outside the pre-approved routine actions, the agent can read and propose, but not change your system.

  1. You open a ticket

    In the support portal or by email to support@allodi.us. Say what is wrong in your own words. Screenshots help; Odoo jargon is not required.

  2. The agent triages it

    It reads the ticket, then inspects your Odoo read-only: the models involved, the views, any custom module that overrides them, recent changes, and the relevant records. It drafts a proposed change on a git branch and runs it against a copy of your database in dry-run mode, recording what would change. If the ticket is a question rather than a change, it drafts an answer with references. If the ticket touches anything on the fence list below, it stops and writes up what it found for the human.

  3. A human reviews and approves

    The expert reads the diff and the dry-run output, checks it against what they know of your business and of Odoo, and either approves, amends, or sends it back to the agent with notes. If the change needs a decision from you (which of two behaviors you want, whether to touch historical records), they ask you in the ticket before anything moves.

  4. The change is applied

    By the human, from the reviewed branch, using a deployment script that is itself in your repository. Production credentials never leave that step. For data changes, the same dry-run is repeated against production before it is committed, and the before-and-after is written to the ticket.

  5. It is logged and you are told

    The ticket closes with a plain-language summary, a link to the commit, the dry-run output and the list of records or files touched. Changes are also noted in the record's own chatter inside Odoo, so someone looking at that invoice or product a year later sees what was done and why.

The fences

These rules come from our contract (master services agreement, section 5.3). Without approval from a named person at Allodi, the agent does not deploy code or upgrade modules, migrate or restore production, change anything that affects money, prices or tax, send messages from your Odoo or on your behalf, or change user access or security settings. Outside those, it acts on its own only for a short list of pre-approved routine actions, which customers see in the support portal; we can narrow that list at any time, and widen it only after ten business days' notice in the portal.

  • MoneyNo posting, cancelling or editing of invoices, bills, payments, journal entries, prices or bank reconciliations. The agent may read them to diagnose a problem and propose what a person should do.
  • TaxNo changes to tax rates, tax groups, fiscal positions, tax reports or anything connected to a tax filing service. These are changed by a person on your written instruction.
  • DeploymentsNo pushing to your main branch and no restarting or upgrading modules on production, and no migration or restore on production. The agent works on branches and on copies. A person deploys.
  • User access and securityNo adding, removing or changing users, groups, access rights or security settings. The agent may read them to diagnose a problem; a person makes the change.
  • Outbound email and messagesNothing is sent from your Odoo to a customer, vendor or employee by the agent. Test runs are done with mail disabled, and we check the outbox afterwards to confirm nothing leaked. This rule exists because we have seen what happens without it.
  • External servicesNo calls to payment processors, shipping carriers, bank feeds or tax services during testing. Anything with a real-world side effect is switched to a logging mode that records what would have been sent.
  • Your data leaving your serverThe agent inspects your system in place. Database dumps are not uploaded to any AI service. What the agent sees to do its work is described in the privacy and data processing note.

Separately from the agent, on Managed Odoo our monitoring software may take a few listed first-response steps by itself when your server is down, such as restarting the Odoo service or the web server, each one recorded in the ticket (Managed Odoo service description, section 5.2a; master services agreement, section 5.10).

The support portal

The portal is where you open tickets and where you see what happened to them. It is deliberately boring. For each ticket you see the request, what was looked at, the decision, and the final summary with a link to the commit.

Your backup and restore-test results, versions and hours used are reported to you each month.

Nothing on the portal is a marketing dashboard. If a number is on it, it is because you would want to check it.

The audit log

Every change to your system, whether code or data, is attributable: who asked for it, who proposed it, who approved it, when it ran, and what it touched. For code, that is a git commit with a human author and a ticket reference. For data, it is a note in the affected record's chatter inside Odoo plus the dry-run and result in the ticket.

This is not just for comfort. When something looks wrong in six months, the first question is always "what changed?" and the answer should take one search, not a week of archaeology.

Ask and we send you the whole log as a file at any time. It is your record, not ours.

Plain facts about the agent

The agent makes mistakes. It has invented field names that do not exist and proposed fixes that would have worked on standard Odoo but not on a customized one. That is exactly why step three exists and why it is a person who has run Odoo in production, not a checklist.

Some tickets are not small. When a request turns out to be a real project, we say so and quote it rather than quietly burning your fix hours on it.

We use Claude models from Anthropic for the agent work, with the agent running on infrastructure we control. We tell you which model on request.

Every change to your system has a named person behind it. That is the whole point of the model, and it is why you can trust the speed.

If we are unavailable

Your Odoo does not depend on us. The server is in your company's own hosting account, the code is in a repository you control, the nightly backups go to a Backblaze bucket in your own account and keep running for as long as you keep that account and the backup job in place, the credentials we create are recorded where you can reach them, and the runbook explains how it all fits together. If we were unavailable, what stops is our work: monitoring, patching, restore tests and support, and Allodi Print, which goes back to Odoo's standard PDF download. Another Odoo partner or your own IT team can take over from the runbook with the access you give them.

Managed Odoo is month to month with thirty days' notice either way. When a subscription ends, we hand over a final backup, the credentials we created, the source of your custom modules and the runbook, and remove our own access, within ten business days and at no charge (Master Services Agreement, sections 8.2 and 8.5, in the published contracts).

See the approval step for yourself

In the live demo, the agent answers questions about a sample company, shows every query it ran, and prepares changes that happen only when you approve them.

  • Plans, add-ons and hourly rates are published; larger projects are quoted up front, and the project fees in the free scan's quote are binding for what the scan counts.
  • On a move, the start milestone is refunded if your database cannot run on the new server, unless the cause is on your side or a third party refuses to release your data (conditions).
  • Managed Odoo is month to month: thirty days' notice, no minimum term.
  • Your server, code, backups and credentials are in your company's name.
Try the live demo Talk to us

Or call us: +1 515-644-1400, any time. How to start.