Skip to main content
Automation · Operaria (pilot)

Automating administrative tasks with Operaria: what it does today, what it does not, and why we call it a pilot

Operaria is our administrative automation engine inside Odoo: it reads, classifies, records and notifies, and writes every step in the chatter. It is in pilot and we say so plainly. Here is what it does, what it does not, and how to trial it without risk.

Odoo delivery order with the automatic steps recorded in the chatter

There is a difference between integrating and automating that is worth being clear about before going on. Integrating is connecting two systems so they pass data to each other: the marketplace puts the order into Odoo, the carrier returns the tracking. Automating is taking work away from a person: once the order is in, it follows its path without anyone pushing it. Operaria is the second. It is our administrative automation engine, it runs inside Odoo and, today, it is in pilot: it works, but it does not yet have paying customers. We say so on the home page and we repeat it here, because anything else would be selling smoke.

Key idea: an automation is only acceptable if it writes down what it did. Operaria writes every step in the chatter of the Odoo document, with time and result. Without a trace there is no automation: there is a black box that one day gets it wrong and nobody knows when.

What Operaria does: it reads, classifies, records and notifies

Four verbs, all four inside Odoo. It reads what comes in: an imported order, an email with a delivery note, a supplier invoice as a PDF. It classifies: what it is, which document it belongs to, what needs doing. It records: it creates or completes the corresponding Odoo document, without anyone typing. And it notifies: the customer by SMS or email, or the team member when something does not add up and judgement is needed. On the flexigotech.com home page there is a real execution log from the chatter of a delivery order: order imported, delivery created and reserved, carrier label generated, SMS sent, shipment confirmed to the marketplace with the tracking, and the request and response XML saved for audit. Ten seconds, and nobody touched anything.

Which tasks fit and which do not

Not everything administrative automates well. The rule we use to decide what goes into the pilot is simple: the task has to be repetitive, have a rule that can be written in one sentence, and a result that can be checked. If it meets all three, it fits. If it needs judgement, negotiation or an exception every other day, it does not.

TaskFits?Why
From order to shipment: delivery, label, tracking, customer noticeYesClear rule, checkable result, repeats hundreds of times.
Recording supplier invoices that arrive by emailYes, with reviewThe draft is created with the data read; a person validates before posting.
Payment reminders by due dateYesThe date rules; the text and the intervals are set once.
Answering a complaintNoNeeds judgement and context. Operaria alerts the person with everything in front of them, and stops there.
Negotiating a price or approving a discountNoBusiness decision. Not delegated to a rule.

What it needs from your Odoo to work

Little, and nothing unusual. Its own Odoo user with just the permissions for the documents it will touch, so the chatter shows Operaria did it and not a person. The connectors already installed for the channels involved in the task: the marketplace's, the carrier's, the email's. A staging environment to test with copied real data, which comes standard on Odoo.sh. And a written rule, even a one-liner, for what happens with the exception. It runs on Odoo 19, 18 and 17, on Odoo.sh and on your own server; not on Odoo Online, because custom modules cannot be installed there.

Why inside Odoo and not in a separate tool

There are general-purpose automation tools that connect applications with visual flows, and for many things they are the right answer. Operaria does not compete there. Its place is the Odoo document: the order, the delivery, the invoice. It works with the same permissions as a user, writes in the same chatter and respects the same workflow rules. That has two practical consequences. First: there is no second system with its own copy of the data drifting out of sync. Second: when something fails, the error sits on the document where someone will see it, not in an external dashboard nobody opens.

What “in pilot” means, exactly

It means three things. That the engine runs on our own flows and on real demonstrations on Odoo 19, 18 and 17. That it does not yet have paying customers, so there are no customer cases to show, and we will not make them up. And that whoever joins now joins under pilot conditions: scope limited to one or two tasks, weekly review of the trace, and the option to switch it off at any time with nothing left half-done, because every step is a normal Odoo action that can be undone by hand.

How to trial it without risk

  1. One task is chosen, the most repetitive and the most boring. It is almost always the order → delivery → label → notice chain.
  2. The rule is written in one sentence and it is agreed what happens with exceptions: who gets alerted and what is left untouched.
  3. It starts on staging, on a copy of the database, with real orders from the previous week. The trace is read document by document.
  4. It moves to production with a limit: only one channel, or only one carrier, for two weeks. Then it is widened or switched off.

What we do not do is promise hours saved. We do not have that figure from real customers and we will not extrapolate it from our internal use. The only commitment of the pilot is that every action is written down, nothing happens outside Odoo and it can be stopped. If that is enough to interest you, let's talk.

Frequently asked questions

Is Operaria the same as a marketplace or carrier connector?

No. Connectors integrate: they bring in the order or return the tracking. Operaria automates what happens in between inside Odoo, chaining those steps and notifying. It uses the connectors; it does not replace them.

What happens if it gets it wrong?

Every step is a normal Odoo action and is written in the chatter with time and result, so you can see where and undo it by hand. In the pilot, moreover, the scope is limited to one task and one channel, precisely so that a mistake does not multiply.

Does the pilot have a cost?

Terms are agreed case by case depending on the task and the configuration work it requires. We do not publish service prices. What is fixed: the limited scope, the trace and the right to stop.

Useful links inside FlexigoTech

Operaria on the home pageThe real execution log from a delivery order's chatterIntegrations and automationEverything we have built, project by projectLogistics integration in OdooThe carrier connectors Operaria chains togetherWhat Atendyo is and what it solves for a shopThe other own product: the conversation with the customer

Got a task that repeats a hundred times a week?

Tell us which. We will tell you whether it fits the Operaria pilot, with which rule and which limit, or whether something else is the sensible choice. Email comercial@flexigobe.com or call +34 616 809 504.

Talk about the pilot