Services / AI / Workflow automation

The work between your apps does itself, and tells you when it can't

Copying a name from one system into another. Chasing an approval. Sending the same reminder every Tuesday. None of it is difficult, all of it is somebody's week, and software has been able to do it reliably for years.

Why it matters

The cost is the wait

The gaps between your systems are where the time goes. The CRM does not talk to the accounting package, so someone rekeys the customer. The website form emails a shared inbox, so someone reads it and creates the record by hand. An approval means finding the right person and asking them twice. Each gap is individually small enough to live with, which is precisely why none of them ever get fixed.

Automation has a poor reputation in organisations that have tried it before, usually for one of two reasons. Either somebody automated a process that was already broken, so it produced bad outcomes faster and with more confidence, or it worked silently for eight months and then failed just as silently for a fortnight. Both are design failures rather than technology failures. We map the process first and delete steps before automating them, and we treat the failure path (retry, alert a named person, park the item) with as much care as the happy path.

What we build ranges from a two-day connection between two mainstream tools to a queue-backed system running thousands of jobs a day with a complete audit trail. Which one you need is a cost question rather than a taste one, and we are direct about where the crossover sits: hosted platforms are live within hours and charge per task forever, while something we build and you host costs more up front and nothing per run.

What you actually get

Built to be trusted

Connecting two apps is easy and most people have already tried it. The list below is what keeps an automation running and trusted in month eighteen.

01

We delete steps before we automate them

The first session maps what actually happens, with the people who do it. It reliably turns up approvals nobody reads, reports nobody opens and checks that exist because of a system replaced in 2019. Automating those preserves them forever, and this conversation frequently saves more time than the software does.

02

Every failure reaches a person

Retry with backoff, then alert a named owner, then park the item in a queue for review. Silent failure is how automation loses the trust of the people depending on it, so nothing is permitted to fail quietly.

03

It cannot do the same thing twice

Duplicate webhooks, retried jobs and double-clicked buttons are normal in any integration. Every step is built to be safely repeatable, so a retry never creates a second invoice, a second customer or a second payment.

04

Triggered by whatever is realistic

A new email, an uploaded file, a form submission, a webhook, a row appearing in a spreadsheet, or simply a schedule. With a queue in front, so a busy hour absorbs into a backlog rather than dropping work on the floor.

05

Rules where rules will do

Most steps are deterministic and should stay that way, because rules are cheaper, faster and testable. AI is used only where the input is genuinely unstructured, reading the intent of an email, classifying a free-text request, drafting a reply for someone to approve.

06

A searchable record of every run

What triggered it, what it did, what each system replied and how long it took. When somebody asks in June why a customer received that email in March, the answer is retrieved in seconds rather than reconstructed from memory.

Where it earns its keep

Same pattern, different desks

Three different industries with the same underlying complaint: skilled people spending their day moving information between screens.

Recruitment & staffing

01 · Recruitment & staffing

The pipeline that updates itself

The problem
Applications arrive from four job boards, a careers page and direct email. Each one is downloaded, the CV read, the candidate created in the system, the client emailed, a spreadsheet updated, a rejection eventually sent. When volume spikes, the acknowledgements and rejections are the first things to slip, which is exactly what candidates complain about in public.
What we build
Applications from every source land in one flow: parsed into structured candidate records, deduplicated against people already on file, tagged against the role's requirements and routed to the right consultant. Status changes trigger the client update and the candidate acknowledgement automatically, with a person approving anything that goes out under their own name.
What changes
Consultants spend their day on conversations instead of data entry, every applicant gets a reply, and the pipeline in the system finally matches the pipeline in everyone's heads.
Property management & lettings

02 · Property management & lettings

Maintenance requests that route themselves

The problem
Tenants report faults by phone, email, WhatsApp and a portal. Someone reads each one, judges whether it is urgent, finds a contractor with the right trade and availability, raises the job, informs the landlord and chases for completion. Anything that slips through becomes a complaint with a statutory clock attached to it.
What we build
Reports from every channel are classified by trade and urgency, matched against an approved contractor list with the right certification and coverage, raised as a job with the tenant's photographs attached, and chased automatically until closed. Anything flagged as a safety issue skips the automation entirely and goes straight to a named person.
What changes
Faster response on the jobs that carry real risk, a complete audit trail per property, and evenings and weekends covered without anyone sitting beside an inbox.
Wholesale & distribution

03 · Wholesale & distribution

Orders that stop being retyped

The problem
Customers order by email, attached PDF, spreadsheet and occasionally a scanned fax, each in their own format. Every one is retyped into the order system, and every typo becomes a wrong delivery, a credit note and a phone call. Month-end reconciliation between orders, the warehouse and the accounts is a manual joining exercise.
What we build
Incoming orders are read whatever their format, matched to the right customer and product codes, checked against stock and the current price list, and either created automatically or held for a person when something does not reconcile. Confirmations, picking notes and invoices flow out without being asked for.
What changes
Orders enter the system within minutes rather than at the end of the day, mismatches are caught before the lorry is loaded, and the office stops being the bottleneck between a customer and a delivery.

The technology

The tools behind it, named

The platform choice here is genuinely a budget decision rather than an engineering preference. A hosted tool is live this week and charges per task forever; something we build costs more at the start and nothing per run. We will show you where the lines cross at your volumes.

6 layers · 30 technologies

01

Automation platforms

For connecting mainstream tools quickly. n8n runs on your own infrastructure, which matters when sensitive records are involved and when per-task pricing starts to punish you for growing.

  • n8n
  • Zapier
  • Make
  • Power Automate

02

When it needs to be more than a flowchart

Long-running processes with approvals, waits, retries and steps that must never run twice need a real workflow engine: durable, resumable and observable.

  • Temporal
  • Apache Airflow
  • Celery
  • RabbitMQ
  • Apache Kafka

03

The systems being connected

Most of any automation project is this: reliable, well-behaved connections into the tools your business already runs on and is not about to replace.

  • HubSpot
  • Salesforce
  • Xero
  • QuickBooks
  • Stripe
  • Google Sheets

04

The connections nobody sells

Where no off-the-shelf connector exists (legacy software, scheduled file drops, an API documented in a PDF from 2011), we build the link, with rate limiting, retries and schema validation so it survives contact with reality.

  • Python
  • TypeScript
  • FastAPI
  • PostgreSQL
  • Docker

05

The judgement steps

Used sparingly and deliberately: reading an unstructured email, classifying a free-text request, drafting a reply for approval. Everything else stays as rules.

  • Anthropic Claude
  • OpenAI
  • Google Gemini
  • Mistral
  • Ollama

06

Watching it run

Dashboards, alerting and a searchable log of every run, because an automation nobody is watching is an outage waiting to be discovered by a customer.

  • Grafana
  • Sentry
  • PagerDuty
  • Redis
  • Cloudflare

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

Two weeks for a first automation, a few months for a set of them, and we sequence the work by payback rather than by what is technically interesting.

01

We watch the work being done

Sitting with the people who run the process, screen by screen. What gets described in a meeting and what actually happens are rarely the same thing, and the difference is exactly where an automation designed from the description would have broken.

02

We cut before we build

Steps that exist because of a system replaced years ago, approvals nobody reads, a weekly report generated for someone who left. You get the list and you decide. Automating a broken process only makes it fail faster, and more expensively.

03

We rank by payback

Every candidate gets an estimate: hours saved a week, cost to build, cost to run, and what breaks if it fails at three in the morning. The order of work falls out of those numbers, and it is usually not the order anyone expected walking in.

04

We build the unhappy path first

What happens when the API is down, the file is malformed, the record already exists, the credit limit is exceeded, the contractor never responds. Deciding those before writing the happy path is the difference between an automation that runs for years and one that gets quietly switched off.

05

We run it alongside your people

For the first cycle the automation does the work and a person checks it, on real volume. Discrepancies get found while somebody is still watching for them, not a month after the process was trusted.

06

We hand over the controls

Documentation, a dashboard, and, where you want it, the ability for your own team to change rules, thresholds and message wording without calling us. You own the automations and the infrastructure they run on.

Before you commit

The questions worth asking

Is this about reducing headcount?

That is your decision rather than ours, and we would rather answer it straight than reassure you. In practice what usually changes is the content of a role: the retyping goes, the exceptions and the customer conversations stay, and those were the parts that needed a person anyway. What we can tell you from experience is that the projects that go well are the ones where the people who run the process helped design its replacement, and the ones that fail are the ones imposed on people who were never asked.

What happens when our process changes?

It will change, and we plan for that rather than treating it as an argument to have later. Rules, thresholds and message wording are configuration your team can edit; structural changes are small pieces of work. What we design out is the pattern where a process change quietly breaks an automation and nobody notices for a fortnight. Every flow is monitored and every failure alerts a named owner.

What if a system we depend on changes its API?

Something breaks, eventually. That is the honest answer for any integration, including ours. What we control is the blast radius: everything coming in is validated, unexpected shapes raise an alert instead of being processed regardless, and the connection logic lives in one place so the fix is small. Vendors deprecate things without much warning; the difference is whether you hear about it from a monitor or from a customer.

Should we use Zapier, or have something built?

It depends entirely on volume, sensitivity and how long you will run it. A hosted platform is live in hours, needs no maintenance and charges per task, excellent for a few hundred runs a month between mainstream tools. Past a few thousand runs a month, or where records are not allowed to pass through a third party, both the pricing and the data policy start arguing for something you host yourself. We will model both against your real numbers before recommending either.

Could AI just run the whole workflow?

It could, and it would be a worse system. A model deciding every step is slower, more expensive and far harder to test than a rule that reads "if the amount is over five thousand, route to the finance director". We use AI where the input is genuinely unstructured and rules everywhere else, which means most of a good automation is boring deterministic software, and that is the point rather than a shortcoming.

How do we know it is doing the right thing?

Every run is logged with its trigger, its inputs, what each system replied and its outcome, all searchable after the fact. On top of that we report volume, failure rate and hours saved, so the business case gets checked against reality rather than left as the thing that justified the project in the first place.

What does your team redo every single week?

Describe the process everyone groans about: the retyping, the chasing, the Tuesday morning report. We will tell you what should be deleted, what should be automated, and what it would pay back.

Start the conversation