Automation

What Automation means here

Automation is handing a repeatable piece of work to a system instead of a person. The site’s definition adds the condition that matters. An audit separates the processes worth automating from the ones that should be left alone, and the AI and automation systems themselves are developed after that audit.

So the word carries a sequence with it. Nothing is automated because it can be. It is automated because an audit found the work repeats, the data is usable and the risk is understood. The AI workflow page defines the single process an automation is built around.

Not every task, and not every Decision

The site’s article on automating a task against automating a decision makes the central distinction. A task automated well saves time. A decision automated without being scoped for it produces a result nobody signed off on, and the two get confused because they usually sit inside the same workflow.

A task can be checked against a right answer and handed over completely once the rules are set. Formatting a report, pulling figures into a template and routing a ticket are examples. A decision carries consequence and needs someone accountable. Choosing which candidate gets a callback is one. The article says approving “AI for the intake process” is rarely approving a single thing, because a real intake is a chain with one or two decisions buried in it.

The Ladder

The article sorts work onto four rungs: Assist, Recommend, Execute and Never delegate. Assist means AI drafts and gathers, and a person decides. Recommend means AI ranks or suggests, and a person stays accountable. Execute means AI acts inside clear rules, unsupervised. Never delegate covers hiring, dismissal and anything with legal, safety or rights implications, which stay human whatever the technology can do.

Five questions decide the rung and not what the technology can attempt: how often the work happens, what a wrong outcome costs, whether it can be undone, how clear the governing rules are, and whether the outcome needs a kind of legitimacy a model cannot hold. A password reset scores low on risk and high on volume, so it sits at Execute. A dismissal scores the opposite, so no capability moves it.

The Audit decides

The audit is where the sorting is done. Each candidate process is weighed on how often it repeats, what the manual version costs in effort, whether the data it needs exists in a usable state and what regulatory exposure attaches to it. That is the opportunity identification step.

Candidates that are technically possible but not worth doing are named and set aside with the reason recorded. The audit article adds a practical check before anything new is recommended: what the business already pays for and does not use, because the fastest gain is often switching something on. That is part of why the definition says the processes to leave alone are separated out.

Step five, not a Separate product

The AI automation page describes the work as the fifth step of the audit methodology, sold as a piece of work in its own right. It is not a product with a specification, and there is nothing to choose from before an audit. What gets built is whatever the first four steps established was worth building, on the processes that were mapped and documented and against the exceptions those processes carry.

The how we audit page describes the same step. What the prototype proved is built for production, and that is the automation. The workflow design page covers the stage before it, where one process is drawn end to end before anything is built.

The kinds of work

The automation page lists four kinds. Document handling covers reading and extracting the data held in invoices, contracts, forms and inbound email, where it was previously keyed in by hand. Reporting and data covers consolidating figures that sit in several systems into the reports somebody assembled by hand on a fixed cycle.

Customer communication covers triaging incoming enquiries, drafting replies for an operator to approve and not send unseen, and searching internal knowledge that had only ever been in people’s heads. Internal processes and workflow covers connecting systems that do not talk to each other, and moving work between tools the organisation already runs and already pays for.

One Workflow at a time

The site scales in a set way. It builds one proven workflow at a time, and each new process returns to step one of the audit and is not added to a single result rolled across an operation that was never mapped for it. Every phase has to justify the one after it.

The well-scoped workflow article gives the reason. A defined single-purpose workflow gives a result that can be measured, and a broad rollout usually does not. This page uses none of that article’s figures, only its argument. Its four principles are a clear objective, a defined scope, built-in guardrails and a business impact that can be shown.

Automation and Agents

An automation does not have to involve an agent. The agentic AI page describes the approach where AI carries out a sequence of steps on its own instead of answering one prompt at a time, and the AI agent page covers the system that does it. Both are ways of building an automation, and neither is the only way.

The agentic AI page says the first question an audit asks is whether a process needs a sequence of steps carried out unattended at all, or whether something simpler does the job. Many tasks belong lower down that list. An automation is the outcome, and the choice of how to build it follows from the process.

Built so the organisation can run it

The automation page states a principle for the build. Oversight, logging, escalation and the point at which a person takes over are designed into it and not added once something has gone wrong. That is the difference between an automation the organisation can run and one that only whoever wrote it can run.

The same page names two things that end an engagement. The organisation names an internal owner for each workflow that goes live, and the people who will run it are trained. That is what makes the result belong to the organisation, and it is why the page says automation and training are usually bought together and not in sequence.

Visual Builder or Custom Code

The site’s review of no-code automation against a custom API build describes two general shapes. One wires a workflow together from pre-built connectors in a visual builder. The other writes the integration directly against a vendor’s API. This page names no platform and compares no product.

The review’s advice is about order. Volume and how often the process changes decide between them, and the biggest mistake is picking a platform before mapping how often the process actually runs and changes. A visual builder starts fast and fits what its connectors support. A custom build takes longer to reach a first version and can do exactly what the process needs. The review sets out the trade-offs.

The Rules attach to what it does

Obligations under the EU AI Act and GDPR attach to what a system does and the risk it carries, not to whether it was built in a visual builder, written as custom code or bought off the shelf. A high-risk AI system carries the same documentation and oversight requirements whichever route produced it.

What the build route changes is how easily the organisation can show what happens to data at each step. The audit assesses the Act and GDPR inside the ranking, so what is automated is chosen knowing what it carries. It is a diagnostic and not a legal opinion, and no audit substitutes for advice from a qualified lawyer.

Taught from running it

The means-here line says the training is taught from years of building and running automation, optimisation and IT operations at scale and not from a textbook. The bespoke training page says the same and adds that nothing in a bespoke programme is demonstrated on invented material.

That is the link between the two halves of the business. The bespoke page’s comparison table says the training is delivered by practitioners who run AI operations daily, and it sets that against generic content with no context. The means-here line draws the same conclusion: the examples are real deployments and not tidy hypotheticals.

A worked example

This is an illustration, not a real client. A small firm’s audit ranks its month-end report first and sets a shared support inbox aside because its volume is low. The report is document and reporting work, which are two of the four kinds. It is drawn end to end in workflow design, and a narrow prototype runs on real exports.

The people who build the report today judge the prototype, and their verdict decides whether it is built for production. It goes live with its review point, its logging and its escalation drawn in, an owner named for it and the people who run it trained. The firm’s second process then returns to step one. Nothing was automated because it could be.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is treating automation as a product to choose from a list, when the site says it is the fifth step of an audit and there is nothing to choose before one. The second is treating task and decision as the same, and approving a whole chain as one thing.

The third is assuming automation means an agent or a particular tool. The site treats those as ways of building it. The fourth is treating a live automation as finished. The owner and the trained people are what keep it working.

Where it goes wrong

The commonest failure is automating without an audit, so the process is chosen because it looks easy and not because it is worth it. A second is approving a whole chain as one thing, so a decision gets made that nobody scoped. A third is building against the ideal path and not the exceptions.

A fourth is a tool nobody owns. The ownership article says an unowned tool fails quietly, when its outputs drift, its access widens and its written rules go stale. A fifth is scaling too early, by rolling one result across an operation that was never mapped for it.

Where it appears on the site

The AI automation page describes the work and the four kinds it covers. The how we audit page describes step five and what comes out of it: workflows in production with their oversight defined, documentation the organisation owns and staff trained to run and change what was built.

How long a build runs is settled by the audit and the discovery call, and it is not quoted beforehand. Every automation engagement starts from a completed audit, and every audit starts with a discovery call. The business outcomes page covers what the whole sequence is meant to leave behind.