AI business automation for the routine work between your systems

Start with a process that runs often, follows mostly clear rules and costs real time or errors when done by hand. Order intake, supplier invoice handling, lead routing and weekly reporting are common first choices. We score each candidate on monthly volume, the cost of a mistake and the number of systems it touches, then pick one with a clear before-and-after measure. The connectors and approval queue it needs are then reused by the processes that follow.

RPA imitates a person clicking through screens, while our approach connects systems through APIs and events and uses AI only where an input needs interpreting. Screen-based bots tend to break when a layout changes and struggle with free-text emails or varied documents. API-based workflows are easier to monitor, test and version. Where a legacy application offers no API or database access, we can still automate that one step on screen, but we treat it as a last resort.

Yes, chasing suits agents well, because the steps vary from case to case but the goal is clear. When an order, claim or onboarding file is incomplete, the agent works out what is missing, sends a request by email or an approved WhatsApp template, reads the reply, checks that the new detail or document meets the rule and updates the record. It follows up on a schedule you set, stops after an agreed number of reminders and passes the case to a named person with a summary of every contact.

Any step that moves money, commits the business to a customer or supplier, or is hard to reverse should wait for a person. Typical examples are payments above a threshold, changes to a supplier's bank details, credit notes, messages about prices or delays, and record deletions. Steps where an AI output fails a validation check also pause for review. The approver sees the item with its context in email, Slack, WhatsApp or a review dashboard, and every decision is stored with a timestamp.

Measure volume, hands-on time per item, waiting time between steps and the rate of errors or rework, both before the build and after go-live. During process mapping we take these from system logs where they exist and from short timing samples where they do not. After launch, run logs add the share of items completed without a person, the share sent for review and the reason for each exception. The comparison then rests on your own figures rather than industry averages.

The manager who owns the process today should own its automated version. That person sets the business rules, approves changes, reviews exceptions and receives the weekly run summary. Your IT team or ours looks after hosting, credentials and upgrades. We document both roles in a short runbook at go-live, because automations without a business owner tend to drift out of step with how the team actually works.

The affected items wait in a queue rather than being dropped or half-written. Each step that calls another system retries with increasing delays, and because steps are designed to be safe to repeat, a retry cannot create a second invoice or message. If the system stays unavailable beyond an agreed time, the process owner is alerted and the waiting items appear on the monitoring dashboard. When the system returns, the queue clears in order, and anything that still fails is listed for a person to resolve.

Every run is recorded with its trigger, the data it read, each step's output, the result of every AI validation check and who approved what. Logs are stored in a database you control and kept for a retention period you set. Finance and compliance reviewers can trace any record back to the run that created or changed it, and workflow definitions are version-controlled, so you can also see which rules applied on a given date.

We design every workflow so that running it twice has the same effect as running it once. Each incoming item gets a unique key, records are matched on agreed identifiers such as email address, order number or VAT number before anything is created, and updates check that the target has not changed since it was read. When two systems disagree, a defined system of record wins, and genuine conflicts go to a person instead of being overwritten.

We replay real past cases through it in a staging environment and compare the results with what your team actually did. A sample of recent emails, orders or invoices, including the awkward ones, runs through every step against test copies of your systems. Differences are reviewed with the process owner, rules are adjusted and the replay is repeated until the remaining gaps are understood. The same cases become a regression set that runs again whenever a workflow, prompt or model changes.

Costs depend on scope: the first release gets a fixed quote after discovery, and each later process is quoted separately once the first is live. The main drivers are how many systems each process touches, how much unstructured input needs AI handling and your hosting and security requirements. Alongside each quote we estimate monthly hosting and model usage at your volumes. Self-hosted n8n carries no per-task fees, so running costs follow infrastructure and model use, and the dashboard reports them for every process.

A single, well-defined process with two or three integrations is often in production within a few weeks of the proposal being agreed, and later processes usually take less time. The first one carries the setup work: intake, connectors, the approval queue and monitoring. Each process after that reuses them, so effort goes mainly into its own rules and exceptions. Timelines still depend on the quality of each system's API and data, and you review working automation every one to two weeks.