AI automation for ERP and ecommerce operations
AI automation for ERP and ecommerce operations: purchase planning, order intake, reporting and support drafting, written into Odoo under approval.
An operations team running an ERP and a few storefronts spends its day moving facts between systems: stock levels into a reorder spreadsheet, a wholesale customer's email into a sales order, yesterday's numbers from four places into one message for the owner. Each move is small, each is done by a person, and each is a place where a model can draft and a program can write.
This service builds those automations. It is the work we know best, and it follows one pattern wherever it is applied: scheduled jobs, deterministic writes into the ERP, a person who approves, and a storefront that is never written directly.
The operations work that is automatable
The test is simple: does the task have inputs a program can fetch, a decision a model can draft well enough to be checked quickly, and an output that lands in one system of record? Five kinds of work pass that test in most ERP and ecommerce operations.
Purchase planning
Read stock on hand, open sales and purchase orders and supplier lead times from the ERP. Propose what to reorder, from whom and in what quantity, as draft purchase orders. A buyer reviews the batch and confirms; nothing goes to a supplier on its own.
End-of-day reporting
Pull the day's sales by channel, shipments, stock exceptions and support backlog, write the summary a person used to assemble by hand, and post it where the team already reads. Read-only, which makes it the safest first automation.
Wholesale shipping
Take confirmed wholesale orders, apply the customer's packing and labeling rules, and prepare the shipment in the shipping platform for the warehouse to release. Carrier and rate rules stay deterministic; the model handles messy inputs such as special instructions in an email.
Order intake
Turn orders that arrive as emails, spreadsheets or partner API calls into sales orders in the ERP. The model reads the unstructured input; the program matches products, checks the customer record and creates the order under an idempotency key, so a retry cannot duplicate it.
Support drafting
For each ticket, look up the customer's orders, shipments and history, and draft the reply. A support agent edits and sends. Where the ticket needs an action, such as a replacement order, the program executes it under the agent's approval. The model drafts; it never acts.
The pattern
The automations above differ in what they read and draft and are identical in how they write. Four rules, taken from Butler, the operations tool we built for PPC International. PPC International is a Brdy Holdings portfolio company: Butler is internal work on a business we own, not an external client reference, and it is the only deployment we describe.
Scheduled, not triggered by chat
Each automation runs on a schedule with a known window. The team knows when the draft POs appear and when the report posts.
Deterministic writes into Odoo
The model proposes. Plain code writes, with a fixed shape, an idempotency key and fail-closed error handling. The ERP is the only destination for a business fact.
A person approves
Every write that commits money or touches a customer waits in a queue for a named person. The audit log records what was proposed, what was changed and who released it.
The storefront is never written directly
Prices, listings and stock go into Odoo, and Odoo's existing connector exports them to Shopify. One truth, one export path, and nothing for the storefront and the ERP to disagree about.
The last rule has a cost: if the ERP's connector cannot carry a field to the storefront, the automation cannot set that field either. The answer is to extend the export or accept that the field stays manual, never to open a second write path. The reasoning is set out in Read widely, write narrowly.
Odoo AI automation and Shopify operations automation
Odoo suits this work because almost every business fact already lives in one of its models: products, stock, sale orders, purchase orders, partners. We write through Odoo's API into those standard models, with Odoo's own validation applied, so the records look like ones a person entered and your existing reports keep working.
Shopify, including multiple storefronts, is read freely: orders, fulfillment state, inventory levels, customer records. It is not written to. If Shopify is your system of record for some fact, with no ERP behind it, that changes the design and we will say so in scoping.
Integrations
The automations we have built integrate with Odoo ERP, Shopify, Slack, ShipStation, Postmark and Google Workspace, with model access through a provider API and a local model as fallback. Integration means we have written and run connectors against these systems' APIs. It does not mean partnership, certification or endorsement, and none of those vendors has reviewed this work.
Other systems with a usable API can be added. The scoping question is the same each time: what does the automation read from it, and does it ever write to it? Reading is cheap. A new write destination is a design decision.
What a first automation project looks like
Pick one workflow with a clear owner. Purchase planning or end-of-day reporting are the usual first choices: one has an obvious payoff and a natural approver, the other is read-only. If the choice is not obvious, the opportunity assessment ranks the candidates.
List the reads and the one write. Which Odoo models, which storefronts, which mailbox. Then the single destination, such as draft purchase orders in Odoo, and who approves.
Take a baseline. How long the task takes today, how often, and what goes wrong. Without this nobody can say later whether the automation helped.
Build in staging, review the writes, run with full approval. The automation runs against a staging copy first, with its own credentials. Before it touches production, its write paths, approvals and secrets are reviewed; the security review page describes what that covers. Then it runs live with every proposal approved by hand until the record shows they are right, and only then is approval narrowed to the exceptions. The first project is sized to run in weeks, not quarters; the custom AI software page sets out what you receive at the end.
Common questions
Does the automation ever write to Shopify directly?
No. Prices, listings and stock are written into Odoo and reach Shopify through Odoo's existing connector. Shopify is read from, for orders, fulfillment and inventory, but never written. Keeping one write path is what lets the ERP and the storefront agree, and what keeps the security review short.
What happens if the model is wrong?
A person sees it before it is committed. The model only drafts: a proposed reorder, a draft reply, a parsed order. The approver edits or rejects it in the queue, and the audit log keeps both the proposal and the correction. If the model is wrong often, the log shows it and the prompt or rules get fixed, with approval still in place.
We use an ERP other than Odoo. Does this still apply?
The pattern applies to any ERP with an API that can create and confirm the records in question. Our hands-on depth is in Odoo, so the examples use it. For another system, scoping starts by checking that its API can carry the writes and that its own connectors can export to your storefronts.
Can we start with something read-only?
Yes, and it is often the right call. End-of-day reporting reads from the ERP, the storefronts and the shipping platform and posts a summary; it changes no records. It proves the schedule and the connectors before any automation that writes is turned on.
How do we know whether it is working?
By comparing against the baseline taken before it shipped: how long the task took, how often, and how many errors it produced. The audit log gives the after figures. We do not report results without a baseline and a method.
Which task does your team re-key every day?
A scoping conversation about that one task is enough to tell whether it should be the first automation.
Book a call