AI for business operations, and the jobs it takes over

What an AI operations team actually is

An AI operations team is a set of AI workers that carry the internal jobs sitting between your departments. Approvals that wait three days on somebody's phone. A proposal that has to be typed out again from a template. A weekly report somebody builds by copying numbers between two screens. The knowledge about how a job is done, which currently exists in one experienced person's memory.

This is the least visible department and usually the most expensive one. Nobody bills for internal admin, so it never appears as a cost, and it grows quietly until a business that sells the same things it sold three years ago somehow needs twice the staff to do it.

The core of it is a shared store of what your business knows: your prices, your process, your documents, your rules. Every other worker reads from it, which is what stops eight different systems holding eight different versions of the truth.

The team, and what each one does

Ten jobs. They look unexciting written down, which is precisely why nobody has done them.

• The knowledge keeper. Holds the central store of what your business knows and answers questions from it, so a new starter can find out how something works without interrupting the person who knows.
• The workflow runner. Carries a job from one step to the next without anyone pushing it. When this happens, do that, tell this person, wait for that answer, then continue.
• The document drafter. Produces proposals, contracts from your templates, invoices, meeting notes and internal write-ups, filled in from real records rather than from a blank copy of last time.
• The approvals clerk. Routes anything needing a yes to the right person, reminds them, and tells you which approvals are the reason work is stuck.
• The procedure writer. Turns how something is actually done into a written checklist. It watches the real steps rather than the theoretical ones, which is why the result is usable.
• The trainer. Turns those checklists into training for new staff, so onboarding stops being a fortnight of shadowing whoever is least busy.
• The connector. Joins the tools you already pay for so information stops being retyped between them. Retyping is where most internal errors are born.
• The founder's assistant. Handles scheduling, summarises long threads and meetings, and drafts the replies that are clogging one person's day.
• The custom worker. Built for one recurring job specific to your business, the one that has no name and that everybody grumbles about.
• The watchman. Checks the other workers are still working. Automations fail quietly, and a quiet failure discovered three weeks later is worse than never having automated at all.

A Tuesday inside an AI operations team

7:00am. The founder's assistant has already built the morning brief. What was agreed yesterday, what is waiting on you, which three approvals are blocking other people's work.

9:20am. A won deal arrives from sales. The workflow runner opens the job, creates the folder, drafts the client welcome note, adds the tasks to the delivery board and tells the person who will actually do the work. Nobody typed the customer's details twice.

10:45am. A supplier invoice comes in as a photograph. The document drafter reads it, matches it to the purchase order and puts it in the approvals lane with the discrepancy highlighted: the quantity is right and the price is not.

11:30am. The approvals clerk sends its second reminder about a request from Friday. Its report at the end of the week will show who is a bottleneck, which is uncomfortable and useful.

1:15pm. A new member of staff asks how a particular refund is handled. The knowledge keeper answers from the written procedure and links the checklist. Nobody senior lost twenty minutes.

2:40pm. The procedure writer finishes a draft of a process that had never been documented. It is wrong in two places. The person who does the job corrects it in five minutes, which is a much smaller task than writing it from nothing.

4:30pm. The watchman reports that one automation has not run since Sunday because a password expired at the other end. It is fixed the same afternoon rather than discovered at month end.

The pattern is the same all day. Nothing dramatic, and about three hours of somebody's attention returned.

What stays human in operations

Exceptions stay human. A workflow handles the ninety cases it was designed for. The other ten are why you employ people, and a system that tries to force them into the same path produces the worst outcome available: a confidently wrong decision, applied consistently.

Anything about a person stays human. Pay, performance, discipline, hours. These pass through the operations department as paperwork and they are not paperwork to the person on the other end.

Deciding that a process should change stays human. A system will run a bad process reliably forever. Noticing that the process itself is the problem is a judgement, and it usually comes from somebody doing the work rather than from a report.

Anything legal or contractual stays human at the point of signature. Drafting from your own templates is fine. Committing your business to terms is not, and the line should be written into the system rather than assumed.

How operations connects to other departments

Operations is the department that makes the others into a system rather than a set of separate tools. Every handoff between two other departments passes through something operations owns: a workflow, a document, an approval or a shared store of facts.

Wobble works to written procedures, and that shows up here more than anywhere. Every workflow has a documented procedure, a named owner and a check before it goes live. That makes some businesses a poor fit, and it is better to know that early than in month four.

• The sales team hands over won deals, and operations turns each one into a job with an owner, a folder and a first task.
• The finance team receives clean, matched documents rather than a photograph of an invoice in a group chat.
• The hiring team uses the same written procedures as training material, so a new starter learns the real process rather than a version of it.

What an operations system costs and what changes the number

An audit, then a build, then a monthly fee while it runs. The audit here is the whole argument. It finds where time is actually going, which is rarely where the owner expects, and it ranks the jobs by what they cost you rather than by how interesting they are to build.

One technical choice affects both cost and control. n8n can be run on your own server, while Make and Zapier cannot. Self-hosting means more setup and more ownership. The hosted platforms mean less setup and a subscription that grows with usage. Neither is correct in general, and you should be told which one you are getting and why.

• How many processes are in scope, and how many steps and people each involves.
• Whether your tools can be connected at all, or whether records are on paper.
• How stable the processes are, since a process that changes monthly is expensive to automate.
• Whether procedures exist in writing or have to be captured from scratch.
• Whether the platform is self-hosted or hosted, which changes both the running cost and who controls it.
• Whether Wobble operates it monthly or hands it to your own team once the handover is done.

Signs your operation is not ready for this yet

If the process changes every few weeks, automating it locks in a version that will be wrong by next month. Let it settle first. A process nobody can describe the same way twice is not a process, it is a habit, and habits should be agreed before they are wired up.

If everything lives in group chats and in people's heads, the first phase of this is not automation, it is writing things down. That phase is unglamorous, it takes real hours from your own people, and no supplier can do it without them. Businesses that will not give those hours should not start.

If your records are on paper or in a system with no way to connect to anything, the honest answer may be that the cheapest fix is a different system rather than AI on top of this one.

If the true bottleneck is one person who will not let go, this will not help. The approvals clerk will simply produce a very well organised record of the same person being the reason nothing moves. That is a management problem and it deserves a management answer.

The approvals an operations system must never absorb

Operations is the easiest place to over-automate, because almost everything in it looks mechanical. The line worth holding is that the system moves the work and a person still decides. A purchase above a threshold, an exception to a documented procedure, a supplier substitution, anything changing what a customer was promised: each one waits for a person, and the request arrives with the context attached so the decision takes a minute rather than a morning.

Where this goes wrong is approval fatigue. If everything needs human approval then nothing is really being approved, and the person clicking through at nine in the morning has become a rubber stamp with a job title. So the threshold is set deliberately at the start and reviewed once a quarter against what actually got rejected. If nothing has been rejected in three months, the threshold is wrong.

Quillon is the published example of the far end of operations automation: an Australian training resources business whose delivery pipeline, previously built by hand for every unit, was rebuilt as a single audited automation. The margin that unlocked is on the work page with the numbers.

Wobble is answerable for the operations it installed and stays month to month rather than on a lock-in, because an operations system that has stopped earning should be cancellable in the month somebody notices.

Common questions

What is AI for business operations?

AI for business operations is a team of AI workers handling internal work: a shared store of what the business knows, a workflow runner that carries jobs between steps, a document drafter, an approvals clerk, a procedure writer, a connector between tools and a watchman that checks the rest are still running.

How is this different from ordinary automation?

Ordinary automation follows fixed rules and stops when the input is not what it expected. These workers can read a document, a photograph or a message written loosely by a person, and decide what it is. The rules still matter. What changes is how messy the input is allowed to be.

Which process should be automated first?

The one that is repetitive, follows a pattern and costs you money when it is slow. Count how many times a week it happens and how long each one takes. That number usually points somewhere less exciting than the process people expected, which is a good sign.

What happens when a workflow hits something unexpected?

It should stop and ask, and this is the part worth checking before you buy. A workflow with no exception route quietly does the wrong thing and nobody finds out for weeks. Every workflow needs a named owner, a written procedure and a defined place where it hands over.

Do we own the workflows and the knowledge base?

On every model except renting the output, yes. The accounts, the workflows, the documentation and the data are yours, and if the engagement ends Wobble removes its access and leaves them with you. On the rent model Wobble owns and runs it, and the output stops when payment stops.

Will our team actually use it?

Only if somebody is responsible for making sure they do. This is the most common reason internal systems fail. The install includes training and a named owner for each workflow, and a business that cannot name those owners is not ready to start.