AI solutions
Business Process Automation
In most companies the process does not run inside the ERP; it runs in the gaps between systems. Approvals live in email threads, tracking lives in a spreadsheet, and the reminder lives in someone's head. We build the automation layer that closes those gaps: it follows the process end to end, moves data between systems, spots what is late, and asks the right person when a decision is genuinely needed.
Where the process actually breaks
A purchase request is raised in the ERP, goes to a manager for approval, the manager approves by email, and a buyer sees it and creates the order by hand. None of the steps is difficult. But when the approval email gets buried, the request sits for three days and nobody notices, because there is no place that shows what is waiting.
The real cost is not the repeated keystrokes but the absence of visibility: which step a job is waiting at, who sent it back, and how long it has been sitting there. The process becomes dependent on one person, and when that person takes leave it stops, because how the work gets done is recorded in habit rather than in a procedure.
- Approvals live in email; there is no shared list of what is pending
- The same data is entered separately into CRM, ERP, WMS and spreadsheets
- The only way to find where a job is waiting is to ask
- Delays surface when the customer complains
- Who approved this has no recorded answer
Which processes we automate
The best candidates are processes with clear rules, high repetition and a visible cost of failure. We look for two kinds of gain: cutting the waiting time between steps, and systematically catching the situations that slip past when nobody happens to look.
Bringing a process into scope does not mean automating all of it. Most of the return usually comes from removing two or three manual bridges: the step that carries data between systems, the step that chases an approval, and the step that notices something is late. Steps that involve genuine judgement stay with people.
- Purchase requests, tiered approval and order creation
- Invoice approval and payment preparation
- Order-to-production-to-dispatch tracking with automatic detection of late jobs
- Receiving discrepancies, count variances and damage cases
- Returns and exchange flows
- Statement reconciliation and periodic statement distribution
- Classifying customer requests and routing them to the right team
- Non-conformance and corrective action tracking
- Contract, price list and renewal reminders
- Employee onboarding and offboarding: accounts, equipment, access revocation
How we design the automation
We start with a process map, but of the real flow rather than the written procedure. Put system logs, email traffic and conversations with the team together, and the picture almost always differs from the version told internally: an extra approval nobody documented, a step that is quietly skipped, or a bottleneck that is not where everyone assumed.
The backbone is a deterministic workflow: states, transition rules, an authority matrix, SLA clocks and escalation steps. AI goes on top of that backbone, only where genuine ambiguity exists — classifying a free-text request, extracting fields from an email, suggesting a priority, flagging unusual behaviour. Amount calculations, authority checks and regulated steps stay in the rules engine, because those need to be computed, not predicted.
- Real flow reconstructed from system logs and conversations on the floor
- State machine, authority matrix, SLA clocks and escalation rules
- Triggers: webhooks, scheduled checks, database changes, inbound email
- AI used for classification, extraction, prioritisation and summarisation
- Calculation, authority and compliance steps kept in the rules engine
- No new portal for users: approve from email, mobile, or the ERP screen they already use
How it sits on top of your existing systems
The automation layer does not replace your ERP, CRM or WMS; it coordinates them. That starts by naming the source of truth for every piece of data: is the correct stock figure in the WMS or the ERP, is the correct customer address in the CRM or on the order. Any automation built without settling this eventually becomes a problem where two systems overwrite each other.
Early on we usually favour a read-heavy design: the system observes and reports on the process first, and write permissions are granted step by step as confidence builds. Every write is protected against duplicates and has a compensating action where one is needed.
- A named source of truth for every data field
- Explicit read/write directions and conflict rules
- API, database, import interface, file exchange or UI automation
- Observe-and-report first, then staged write permissions
- Duplicate protection, safe retries and compensating actions
Marketplace, shipping and e-invoice connections are a separate service; see our integration page.
Where people stay in control
The point of automation is not to take the decision away, but to put the right information in front of whoever makes it. Amount thresholds, a new customer or supplier, a term outside the contract, an unusual discount, a dispatch that would push stock below its critical level — these route to a human. The automation assembles the relevant data, comparable past cases and any warnings, and presents them to the approver.
Trust is earned over time, and thresholds move over time. Once a process has run steadily we can start letting low-risk transactions through automatically, but that is always based on measured behaviour and taken with your approval. The ability to switch the automation off and take the process back manually is designed in from the start.
- Approval points and authority matrix defined at the start
- Context, comparable past cases and warnings presented together to the approver
- Auto-pass thresholds adjusted on measured behaviour, with your sign-off
- The ability to stop the automation and take the process back manually
- An audit trail answering who, when and under which rule, for every step
What changes in manufacturing, logistics and retail
In manufacturing, automation pays off less in production itself than in the coordination around it. In logistics and distribution the work is exception management by nature: detecting the moment a shipment misses a planned milestone, telling the customer about a delay before they ask.
In retail and e-commerce, volume multiplies with the number of stores and warehouses. What the three share is that coordination load grows disproportionately with the business, and it usually lands on the most experienced people you have.
- Manufacturing: tiered purchase approvals, subcontractor claim checks, non-conformance tracking, stoppage notifications
- Logistics and distribution: shipment exception detection, proactive delay notification, proof-of-delivery matching
- Retail and e-commerce: returns and exchanges, store request management, replenishment triggers, promotion approvals
Where we start and how we measure
We choose the first process together, against clear criteria: high repetition, definable rules, a visible cost of failure, and accessible data. A process with all four shows quickly whether the automation is working. Starting with the company's most complex process is the worst option available.
Measurement begins before the pilot does. Without the current numbers on record, anything said afterwards is just a claim. We do not open with a promised improvement rate; we fix the measurement method and keep using it in production.
- First process chosen for repetition, clear rules, visible failure cost and accessible data
- End-to-end process map with system access verified
- A written split between automated steps and human steps
- Baseline indicators recorded before the pilot
- Indicators tracked: elapsed time, waiting time between steps, work in progress, SLA breaches, rework rate
- Handover package: process documentation, rule sets and admin screens
Frequently asked questions
Do we have to replace our ERP or CRM?
No. The automation layer is built on top of your existing systems and coordinates them; it does not replace them. Replacing an ERP that works in practice is a far bigger project than the problem you set out to solve. During implementation we define which system holds the authoritative version of each data element.
Our legacy system has no API and the original developer is long gone. Is that a blocker?
Usually not. An API is not the only route in: controlled reads and writes at the database layer, the system's own import/export interface, file-based exchange, and UI automation where necessary. Even without access to the source code, access to the data layer is often available.
What happens if the automation makes a wrong decision?
We only give automation the steps whose rules can be defined; steps requiring judgement stay with people. Even so, we design for the errors the system can make. Every step is in the audit trail, a faulty transaction can be traced back, and a compensating action runs where one is needed. Auto-pass thresholds start narrow.
Where does our data go? Is it exposed to an AI provider?
We decide this together at the start. The system can run entirely within your own infrastructure. If an external model service is used, we work under enterprise terms where data is not used for training and retention is limited. Most of the flow runs in the rules engine and never touches a model at all; minimising what reaches a model is a deliberate design choice.
Our team has worked in spreadsheets and email for years. What if they don't adopt it?
This is the most common reason automation projects fail, and we address it through design decisions. We avoid moving people into a new portal: approvals can be given from within an email, from a phone, or from the ERP screen they already use. The team's work usually shrinks rather than changes. The critical point remains building on the real flow.
Will we be dependent on you after go-live?
No, and we make that explicit in the contract. Process documentation, workflow and rule definitions, the integration map and admin screens are all part of delivery, and your team can change rule thresholds, approval tiers and notification settings. Terms around code and intellectual property are set out in writing at the proposal stage.
Let's start with one process
Pick the one that costs you the most time — purchase approvals, shipment tracking, statement reconciliation, returns, whichever it is. We will map how it actually runs, identify which steps suit automation and which should stay with people, and establish concretely which route into your existing systems is available.