Software

Business Automation

Removing the work that nobody should be doing by hand

How this is usually engaged

Usually a short assessment first, producing a ranked list of candidate tasks with estimated effort and time saved for each. You then choose what to build, and small automations are typically delivered in days rather than weeks. We are content for the assessment to conclude that only one item is worth doing.

Start a project brief

Practice: Software Engineering
Sectors: 4 served
Process: 5 stages
Standard: Built and tested to WCAG 2.2 AA

Automating the repetitive, rule-based work between systems — document handling, data transfer, scheduled processing and approval routing — with the exceptions handled rather than ignored.

01What this solves

The problem this addresses

Most organisations have a handful of tasks that consume real hours and require no judgement: downloading a report to upload it somewhere else, copying figures between systems, chasing approvals by email, producing the same document from the same fields every week. They persist because each one is individually too small to justify a project, and collectively nobody has added them up. They also fail quietly, because a person doing them notices when something looks wrong and a half-built script does not.

02Capabilities

What is included

Process assessment

A ranked list of candidate tasks with frequency, current effort, failure cost and build estimate for each, so the decision is arithmetic rather than enthusiasm.

Document generation and handling

Contracts, quotes, statements and reports produced from source data on a schedule or a trigger, with extraction from inbound documents where the format is stable enough to rely on.

Scheduled data processing

Imports, exports, reconciliations and batch jobs that run on a schedule, with monitoring that alerts a person when a run fails or produces an implausible result.

Approval routing

Requests routed by rule to the right approver with escalation and deadlines, replacing email chains where the current status is whatever the last reply says.

Exception handling

A queue of items the automation could not process, with the reason, the original data and the ability for a person to correct and resubmit.

Notification and alerting

The right people told about the right events, with thresholds set so the alerts stay meaningful rather than becoming a channel everyone mutes.

03Use cases

Where this work usually starts

Reports moved between systems by hand

Someone exports a file every morning and uploads it elsewhere, and the day it is missed nobody notices until a customer asks.

Finance

Documents assembled from a template each week

Statements, invoices or compliance packs built by copying fields from one screen into another, with the typing errors that come with it.

Professional Services

Approvals chased over email

A purchase or leave request routed by asking around, with no record of who approved what or when it stalled.

04Approach

How we approach it

We measure before we automate: how often the task runs, how long it takes, how often it goes wrong and what it costs when it does. Tasks that are frequent, rule-based and stable are worth automating; tasks that are rare or that hinge on judgement usually are not, and we will say which is which. What we build handles the exception path explicitly — retries, alerts, and a queue a person can inspect and resolve — because an automation that silently stops is worse than the manual process it replaced.

05Process

How the work runs

The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.

01
Measure
Frequency, duration, error rate and cost of failure for each candidate task, gathered from the people who do them.
02
Select
A ranked shortlist, with an explicit recommendation about which tasks should stay manual.
03
Design the exception path
What happens when a source system is down, a file arrives malformed or a value is outside the expected range.
04
Build and run in parallel
The automation runs alongside the manual process until its output has matched for an agreed period.
05
Cut over and monitor
Manual work stops, alerting is verified, and someone is named as the owner of each automation.

06Deliverables

What you receive

Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.

Assessment reportCandidate tasks ranked by time saved against build effort, including the ones we recommend leaving alone.
Automations in production with scheduling and monitoring
Exception queue and resolution interface
Run history and audit log
Operating documentationWhat each automation does, what it touches, who is alerted and how to stop it.

07Technologies

What we use on this work

These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.

Languages & Runtimes

TypeScript
Node.js
Python

Data & Storage

PostgreSQL
Redis

DevOps & Operations

Docker
GitHub Actions

The full technology directory

Highlighted entries are used routinely on delivery work

08Security

How this is kept secure

Automations run under their own identities with the narrowest permissions the task needs, never under a member of staff's account. Credentials for third-party systems live in a managed secret store with rotation, and every run is logged with its inputs, outputs and outcome. Where an automation acts on personal data we document what it touches and how long it retains it, so the process fits your existing records.

Our full security and quality approach

09Questions

Asked before we start

Which tasks are not worth automating?

Anything that runs a few times a year, anything where a person is genuinely exercising judgement, and anything whose inputs change format unpredictably. We also advise against automating a process that is about to be replaced, and against automating a broken process — that just produces wrong answers faster. Fix the process first, then automate what is left.

Will this reduce headcount?

That is your decision, not ours, and we will not pretend to model it for you. In practice most of what we automate is work people are relieved to stop doing, and the time returns to tasks that were being squeezed. If a role genuinely disappears, you will want that conversation with your HR advisers well before the automation goes live.

What happens when a system we automate against changes?

It will, so automations are built to fail loudly rather than quietly — a failed run raises an alert and stops rather than continuing with bad data. Where we depend on a third-party interface we note that dependency in the documentation. Vendor-side changes to APIs or file formats are a maintenance cost you should expect to carry.

Can we use a tool like a workflow builder instead of custom work?

For simple connections between popular products, yes, and that is often the cheaper answer — we will point you at it rather than quoting. Custom work becomes worthwhile when the logic has real branching, when systems have no ready connector, when volumes make per-task pricing expensive, or when you need an audit trail those tools do not produce.

START HERE

Talk to us about Business Automation

The project brief takes about five minutes and gives us enough to have a useful first conversation about Business Automation rather than a generic one. If you would rather just ask a question, the short form is there for that.

Start a project Send a short message

We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.