Skip to content
Brain Matrix

Problem 01 — Manual work

Too much of your business runs on people doing repetitive work

Work that moves between inboxes, spreadsheets and browser tabs cannot scale, and hiring against it only raises the ceiling slightly. We automate the parts of a process that are genuinely structured, and put AI where it reduces effort rather than where it demonstrates well.

Symptoms we hear

  • Staff re-key the same data into three systems
  • Approvals wait in inboxes for days
  • Reporting is a monthly manual assembly job
  • Headcount grows in lockstep with volume

The problem

The problem, stated plainly

Somewhere in your business, capable people spend a significant share of their week moving information rather than making decisions with it. They re-key data that already exists in another system, chase approvals that sit in inboxes, and assemble reports by hand from sources that could be joined automatically.

This is rarely anyone's fault. It is what happens when systems are bought one at a time and the gaps between them quietly become somebody's job. The cost is invisible on any single day, and substantial across a year — and the first real symptom is usually that volume growth requires headcount growth to match.

  • The same data is entered into two or three systems
  • Approvals wait in inboxes for days
  • Monthly reporting is a manual assembly job
  • Exceptions are handled by whoever remembers the rule
  • Headcount grows in lockstep with volume
  • A critical process depends on one person being available

Root cause

Why this happens

Understanding why a problem exists is what separates a solution from a workaround.

  1. 01

    Systems were bought one at a time

    Each tool solved one department's problem well. Nobody was responsible for the seams between them, so the seams became work — and that work is invisible in every individual system's business case.

  2. 02

    The spreadsheet was genuinely faster, once

    A spreadsheet is the cheapest way to solve a problem this week and the most expensive way to still be solving it in three years. It never announces the moment it stopped being the right tool.

  3. 03

    Every step has an owner; the process does not

    When responsibility is distributed by step, nobody sees the end-to-end cycle time. Local efficiency improves while the whole gets slower, and the queue sits between the departments that each believe they are performing well.

  4. 04

    Automation was tried and it broke

    Brittle scripts and screen-level automation fail the first time an interface changes, and the organisation learns the wrong lesson — that automation is unreliable, rather than that this automation had no error handling.

Possible solutions

The options actually available

AI is one tool among several, and often not the first one. What follows is the honest range, including the cases where the right answer is not to automate.

Deterministic workflow automation

When it fits

Steps that are genuinely rule-based, with a clear right answer and reasonable volume.

What to watch

Hidden exceptions. The process people describe is almost always tidier than the one they run, and the exceptions are where the value and the risk both sit.

System integration and data plumbing

When it fits

Re-keying between systems, reconciliation, and reporting assembled from several sources.

What to watch

Systems without usable APIs. Where a core system is closed, the honest options are a controlled replica, a vendor conversation, or a narrower scope.

Language models for unstructured input

When it fits

Extracting, classifying or drafting from documents, email and free text — the work that resisted automation for decades.

What to watch

Evaluation. Without a test set and a measured accuracy target, you have a demo rather than a system, and you will not know when it degrades.

Agentic workflows

When it fits

Multi-step tasks where the sequence varies and the system needs to use tools to reach an outcome.

What to watch

Permissions, reversibility and cost. An agent that can act needs the same controls as a member of staff who can act, plus a way to undo what it did.

Human-in-the-loop review

When it fits

High-consequence work, where speed matters but an unreviewed error is expensive.

What to watch

Review fatigue. If a person approves everything without reading it, you have added a step and removed a control.

Not automating it

When it fits

Low volume, high judgement, or a process about to change anyway. Sometimes the answer is a policy change, a form redesign, or deleting a step nobody needs.

What to watch

Nothing — this is frequently the correct recommendation, and we will make it.

Our approach

How we approach it

The order matters more than the technology. Most failed automation projects were technically fine and were built on an unmeasured process.

  1. 01

    Measure the baseline first

    Cycle time, volume, error rate, and where work actually waits. Without this you cannot tell whether the project worked, and you will not be able to defend it internally when someone asks.

  2. 02

    Separate structured work from judgement

    Almost no process is entirely one or the other. The valuable move is usually automating the structured spine and leaving the judgement to people, rather than attempting the whole thing and failing at the exceptions.

  3. 03

    Design the failure path before the happy path

    What happens when the third-party API is down, the document is malformed, or the model is unsure. Systems that handle this gracefully get trusted and get used; systems that do not get quietly worked around.

  4. 04

    Automate the spine, then the edges

    Ship the high-volume path early so the benefit starts accruing, then extend coverage into the exceptions as you learn which ones are actually frequent rather than merely memorable.

  5. 05

    Instrument everything

    Throughput, error rates, model confidence, cost per transaction, and what humans overrode. Automation without measurement degrades silently, and nobody notices until it has been wrong for a quarter.

Technical capability

What we actually build with

Listed so a technical evaluator can judge us on specifics rather than adjectives.

Automation & orchestration

  • Event-driven pipelines
  • Queues, retries and idempotency
  • Scheduling and long-running jobs
  • Workflow engines and state machines
  • Approval and exception routing

AI engineering

  • LLM integration and structured output
  • Evaluation harnesses and regression testing
  • Retrieval over your own data
  • Guardrails and confidence thresholds
  • Cost, latency and token control
  • Tool-using agents with scoped permissions

Integration

  • REST, GraphQL and webhooks
  • ETL and change data capture
  • Adapters for closed and legacy systems
  • File, SFTP and scheduled exchange
  • Identity and single sign-on

Operations

  • Observability and alerting
  • Audit trails and attribution
  • Replay and reprocessing
  • Cost monitoring
  • Runbooks and handover

Qualification

Whether this is for you

We would rather lose a project than take one that should not exist.

This works well when

  • A process you can name, with volume behind it
  • Someone internally who owns the outcome
  • Willingness to measure a baseline before building
  • Data that exists somewhere reachable

We are the wrong choice when

  • An instruction to add AI without a target process
  • A process that is about to be replaced anyway
  • No internal owner after go-live
  • A requirement for guaranteed savings before any measurement

Questions

What clients ask us

How long before we see anything working?

For a single well-defined process, a working first slice in production is typically a matter of weeks rather than months, because we deliberately start with the high-volume path rather than full coverage. Programmes across several processes take longer, but each one should still be delivering before the next begins.

Will this replace jobs?

In most engagements it changes what a role contains rather than removing it: the structured part is automated and people move to exceptions, relationships and decisions. We will not tell you it never results in fewer roles, because for some businesses it does. It is worth deciding your position on that before you start, not after.

How do you handle the exceptions that break automation?

By designing for them first. Exceptions get an explicit route — a queue, a person, a fallback — rather than being treated as edge cases to handle later. In practice, the exception path is where most of the design effort goes, and it is what separates automation people trust from automation people route around.

What if the AI gets it wrong?

That is a design input, not a surprise. We set a measured accuracy target against a real test set, add confidence thresholds so low-confidence cases go to a person, log every decision for audit, and make actions reversible where the stakes justify it. If a process cannot tolerate any error without review, we design a review step rather than pretending the risk away.

Our data is messy. Is that a blocker?

Usually not a blocker, often a first phase. Messy data limits what is possible on day one but rarely rules out a narrow, valuable start. What genuinely blocks projects is data that is unreachable — locked in a closed system with no export — rather than data that is untidy.

Do we need to commit to the whole programme up front?

No. We phase work so that each phase ends with something usable and you can stop. That is a deliberate commercial position: if a phase does not earn the next one, you should not be contractually obliged to continue.

Next step

Let's talk about what's holding your business back.

A 45-minute conversation with a senior engineer. We will look at your situation, say what we would do, and tell you if the answer is not software. No pitch deck, no pressure.