Workflow Automation

What we mean by "workflow automation"

We mean: replace the repetitive, predictable parts of how your business runs with code that does the work in the background. New invoice arrives → it goes to AP. New lead arrives → enriched, scored, routed. Order ships → tracking emailed, inventory decremented, finance notified.

We do not mean:

• A million Zapier Zaps glued together by someone who left the company two years ago.
• A 200-step low-code flow nobody can debug.
• An "AI" agent doing a job a CRON job would do for free.

The goal is reliable, observable, maintainable automation that survives the next person joining your team. Most of what we ship looks boring. That's deliberate.

When you should automate (and when you shouldn't)

You should automate when all of these are true:

1. The workflow runs regularly — at least weekly, ideally daily.
2. The rules are clear — or can be made clear with one discovery sprint.
3. The volume is non-trivial — humans are visibly spending hours on it.
4. Errors are visible — you can tell when the workflow goes wrong, either via downstream signal or via monitoring.

You should not automate when:

• The workflow runs three times a year. Just do it manually.
• The "rules" are actually a person's judgement. Either build an AI agent (see AI Agents) or leave it alone.
• You don't yet understand the workflow. Map it first, automate second.
• The tool you're trying to integrate has a terrible API. Sometimes the answer is to switch tools.

For the deep cut, our AI agents vs automation post walks through the decision tree.

How we choose the right tool

This is the most common question we get, and the most expensive thing to get wrong. Here's how we pick.

We will tell you if you're picking wrong. We've talked clients out of automation projects more often than we've talked them in.

Our process for a workflow build

1. The audit — week 1

We sit with the people doing the work. We watch them do the workflow live. We screen-record it (with consent). We measure how long each step takes, what the failure modes look like, and where the workflow waits on other systems.

The audit deliverable is a ranked list of automation candidates with honest ROI estimates — hours saved per week × loaded cost per hour, minus build cost amortised over 12 months. We rank candidates by payback period. Usually three to five workflows hit the threshold; the rest don't and we tell you so.

2. Spec — week 1 or 2

For each candidate that passes the ROI test, we write a one-page spec: trigger, steps, integrations, error paths, success metric, owner. The spec gets signed off by the operational owner of the workflow — not by IT, not by us. If the owner can't sign off on the spec, we're solving the wrong problem.

3. Build — weeks 2 to 6

We ship in slices, not big-bang. A typical workflow build goes:

1. Happy path (60% of cases) → live in week 2
2. Edge cases and retries (90%) → live in week 3 or 4
3. Polish, observability, runbook → week 4 or 5

We keep the manual workflow running in parallel during weeks 2 and 3. We turn off the manual workflow only when the automation has run clean for at least a week on real volume.

4. Handover — week 6 onwards

Every workflow we ship comes with:

• A runbook: what it does, what to do when it breaks, who to call.
• A dashboard: how many runs, success rate, latency, errors.
• An alerting channel: a Slack channel or email list that gets pinged when something needs attention.
• Code or flow XML in your git repository, not ours.

You can keep us on retainer for the operational side, or take it fully in-house. Roughly half our clients keep the retainer; the other half take it in-house once they're comfortable.

What good observability looks like

This is where most workflow automation projects die in production. Things break — APIs change, data arrives malformed, a human deletes the row the workflow was waiting on — and nobody knows for three weeks.

Every workflow we ship has:

• Structured logs per run: trigger, inputs, each step's outcome, final result, duration.
• Replay capability: re-run a failed workflow from the exact point of failure with the original inputs.
• Idempotency keys: re-running a workflow produces the same outcome, never duplicates.
• Alerting: failure rate above threshold, latency above threshold, queue depth above threshold.
• Dashboard: a one-page view that an ops person can scan in 30 seconds to know if everything is fine.

Pricing — the honest version

We will quote firm. The audit is always the first paid engagement so the build quote is grounded in real workflows, not guesses.

Stack we tend to reach for

• Microsoft Power Automate + Dataverse + SharePoint — for Microsoft-first organisations
• n8n self-hosted on Fly.io / your cloud — for code-friendly teams that want flexibility
• TypeScript on Firebase Cloud Functions or Cloud Run — for high-volume, latency-sensitive, or unusual integrations
• Resend + Twilio + Stripe — the holy trinity of "your operations probably touch these"
• Langfuse + Sentry + Slack — observability triangle

Why we are good at this

Two reasons.

One: we have built dispatch and operations tooling for cold-chain logistics (MeatLogix case study), freight RFQ marketplaces, and accounts payable. The patterns repeat — idempotency, retry, observability, human-in-the-loop. We bring the patterns to your problem instead of inventing them on your time.

Two: we are not religious about tools. If your team already runs Power Automate and your IT will only sign off on Microsoft, we will not try to sell you a custom Node.js server. We meet the operational reality you have.

If you want a short opinion on whether a specific workflow is worth automating, send us a note. One paragraph is enough. We respond within one business day.