Runs itself · retries · tells you when it can't

The work is fine. It's the waiting that costs you.

Most business processes are not slow because the tasks take long. They are slow because a form sits in an inbox overnight, then waits for someone to copy it into a second system, then waits again for an approval from a person who is in a meeting.

Workflow automation connects the systems you already run so a process moves the moment it can, rather than the next time somebody looks. The measurable win is almost never the minutes of typing saved — it is the hours and days of queueing between the steps.

Move over the graph
in flight 0completed 0drag to steer
TriggersOn the event
FailuresRetried, then parked
RerunsNever duplicate
Every runVisible

The real cost

Where a two-day process actually spends two days

A quote request, from arrival to sent. The solid blocks are somebody doing work. The hatched blocks are the request sitting still, waiting for a human to get to it.

Switch to automated and watch what changes. The work blocks barely move — that effort is real and mostly still happens. What collapses is the queueing, and that is where the elapsed time lived all along.

elapsed, request to quote sent
Work being done — Waiting for a person —

The stack

Whatever you already run, joined up

Sometimes the right answer is a low-code platform you can maintain yourselves. Sometimes it is code, because the logic is genuinely complex or the volume makes per-task pricing absurd. We will tell you which, and it is often a mix.

Automation platforms

Zapier
n8n
Make
IFTTT
Retool
Metabase

Orchestration & scheduling

Apache Airflow
Temporal
Prefect
Celery
GitHub Actions
Jenkins

Work & project management

Asana
Trello
ClickUp
Jira
Notion
Airtable

Sales, finance & commerce

Salesforce
HubSpot
Stripe
QuickBooks
Xero
Shopify

Communication & documents

Slack
Gmail
Google Sheets
Google Drive
Mailchimp
Twilio

Forms & intake

Typeform
Google Forms
Calendly
Google Calendar
WordPress forms
WooCommerce

Applications

Six processes worth joining up

Each one spans at least two systems and currently depends on somebody remembering to move it along.

Process 1 of 6
01 — Intake

Enquiry to CRM to first reply

A form, an email and a phone message all landing in the same place, enriched, assigned by rules, and acknowledged within minutes rather than the next working day.

  • One record regardless of channel
  • Round-robin or rules-based assignment
  • Nothing sits unacknowledged

The fastest measurable win

02 — Order

Order to fulfilment to invoice

An order arriving, stock reserved, warehouse notified, invoice raised in the accounting system, customer updated — without anyone retyping the same reference four times.

  • Idempotent, so retries never duplicate
  • Exceptions parked, not dropped
  • Every step traceable to the order

Retail, wholesale, manufacturing

03 — People

Onboarding and offboarding

A new starter triggering accounts, equipment, access, payroll and the induction schedule — and, more importantly, the reverse when somebody leaves.

  • Access revoked the same day
  • Checklist that cannot be half-done
  • Audit trail for compliance

Offboarding is the risky half

04 — Approvals

Requests and sign-off

Purchase requests, time off, discounts and expenses routed by value and role, chased automatically, and escalated when an approver goes quiet.

  • Rules by amount and department
  • Reminders without nagging in person
  • Delegation when someone is away

Removes the "who signs this?" email

05 — Reporting

Recurring reports and reconciliation

The Monday morning spreadsheet somebody assembles from four systems, produced automatically, with differences flagged instead of buried.

  • Same figures every time
  • Highlights variance, not just totals
  • Arrives before the meeting

Usually a half-day, every week

06 — Follow-up

Renewals, chasing and reminders

Quotes going quiet, invoices going overdue, contracts approaching renewal — surfaced and chased on a schedule with the right context attached.

  • Stops the moment someone replies
  • Escalates to a person when it stalls
  • Tone and timing you control

Revenue that otherwise leaks away

Interactive

Break the workflow on purpose

Anyone can demonstrate the happy path. What separates an automation that survives a year from one quietly abandoned after a month is what it does when a step fails — and steps do fail, constantly and unremarkably.

Below is a six-step order workflow. Choose a failure and compare two implementations of the same process: a script that simply runs the steps in order, and one built expecting trouble. The difference is not cleverness. It is a handful of unglamorous engineering decisions.

A script that runs the stepsno failure handling

An engineered workflowbuilt expecting trouble

Honesty

When we would tell you not to

Automation has a reputation problem largely earned by projects that should never have started. These are the ones we turn down or redirect.

01

The process is not settled

If it changes every few weeks, automating it means rebuilding it every few weeks. Let it stabilise, then automate.

02

Nobody can explain the rules

When the logic lives in one person's judgement and every case is "it depends", there is nothing to encode yet. That conversation is the first project.

03

The process is the problem

Three approvals that exist because of an incident in 2019. Automating them makes a bad process faster, not better. Remove the steps first.

04

It runs twice a month

Some tasks are genuinely cheaper to keep doing by hand. Build cost, maintenance and the attention it demands all have to clear a real bar.

05

The source data is a mess

Duplicate customers, inconsistent codes, three spellings of the same supplier. Automation propagates that at speed. Clean first.

06

No one will own it

Automations need an owner who notices when something is parked. Without that, the first failure becomes a silent, permanent one.

07

The system genuinely will not open up

No API, no export, no database access, and screen-scraping a vendor's interface is a maintenance liability we will usually advise against.

08

You are automating around a bad tool

If the software is the bottleneck, integration is a splint. Sometimes replacing it is cheaper over two years than working around it.

09

A platform already does it

If a subscription tool covers the whole workflow, use it. We would rather help you configure that than bill you to rebuild it.

Scope

What a workflow build includes

The mapping session is the part that pays for itself even if nothing gets built.

01

Process mapping

Sitting with the people who run it and writing down what actually happens — including the workarounds nobody documented and the exceptions that come up weekly.

02

Waiting analysis

Measuring where elapsed time really goes. Almost always it is queueing, not work, and that determines what is worth automating first.

03

Platform decision

Low-code, code, or both — decided on volume, complexity and who will maintain it, not on preference.

04

Connections

Authenticating to each system properly, with credentials scoped narrowly and rotated, rather than one shared login with full access.

05

Idempotency

Making every step safe to run twice, so a retry after a timeout never creates a second order, charge or email.

06

Error handling

Retries with backoff, a queue for what cannot be resolved automatically, and an alert to a person who can actually act on it.

07

Human steps

Where a person approves, edits or overrides — designed as part of the workflow rather than bolted on as an email.

08

Observability

A screen showing what ran, what is stuck and how long things are taking. Without it, you cannot tell whether it is working.

09

Handover

Documentation and a walkthrough, so the parts you should be able to change yourselves are ones you can change yourselves.

Questions

Workflow automation, answered

Why not just use Zapier or Make ourselves?

For a lot of workflows you should, and we will say so. Two systems, a simple trigger, modest volume — a low-code platform is faster and cheaper than anything we would build.

Where it stops fitting is branching logic, high volume with per-task pricing, anything needing genuine error recovery, or a process spanning five systems where a visual builder becomes harder to follow than code.

What happens when something breaks at 2am?

Transient failures — timeouts, rate limits, a service briefly down — retry automatically with increasing delays and usually resolve themselves before anyone notices.

What cannot be resolved is parked in a queue with the full context and an alert. Nothing is silently dropped, and nothing is half-applied.

Will this replace anyone's job?

In our experience it removes parts of jobs — the copying, the chasing, the checking whether something arrived. Roles shift toward the exceptions and the judgement calls.

If the objective is specifically headcount reduction, be direct about that up front, because it changes what gets designed and how people are told about it.

How long does one workflow take to build?

A well-understood process across two or three systems with good APIs is usually a matter of weeks, including testing against real cases.

The variable is rarely the automation. It is how much of the process turns out to be undocumented, and how cooperative the systems are.

Can we change it ourselves afterwards?

Where sensible, yes — that is part of the platform decision. Values, thresholds, message wording and schedules are the sorts of things that should not require us.

Structural changes to the logic are a different matter, and we would rather you call than have someone edit a live workflow on a Friday.

What if a vendor changes their API?

It happens, and monitoring is how you find out on the day rather than three weeks later from a customer complaint.

Connections are built so a change affects one place rather than being scattered across the workflow, which keeps the fix small.

Do you work with our existing automations?

Frequently. A common engagement is inheriting a sprawl of scripts and Zaps that somebody built, nobody documented, and everyone is now afraid to touch.

That usually starts with an audit: what exists, what still runs, what silently stopped working months ago.

Is AI involved in this?

Only where it earns its place. Most workflow automation is deterministic rules, and rules are cheaper, faster and more predictable than a model.

AI belongs at the steps where judgement is genuinely required — classifying a message, reading a document, drafting a reply. Using it for the rest is expensive and less reliable.