We engineer the repetitive work out of your operations.
Re-keying orders from emails. Checking invoices against purchase orders. Copying the same figures between spreadsheets, portals and CRMs. We study how that work actually happens, then build software that does it reliably — and brings in a person wherever a decision needs one.
A few sentences is enough. You don't need to know what the software should be.
Example process
Supplier invoices received by email
Invoice INV-20417/Complete
TouchesStepTime
AP inbox
S1Receive — Software, AP inbox: AP inbox09:14:02
Invoice arrives as a PDF attachment.
M1Read — Model: 09:14:04
Supplier, invoice number, 6 line items and total read.
ERP
S2Match — Software, ERP: ERP09:14:05
Matched to purchase order PO-7781.
R1Check — Rules: 09:14:05
3 of 4 checks pass. Total is 6.2% above the PO; tolerance is 2%.
P1Review — Person, AP team: AP team09:41:37
Reviewer approves: freight surcharge agreed with the supplier.
Accounting
S3Post — Software, Accounting: Accounting09:41:38
Posted for the next payment run.
Documents
S4File — Software, Documents: Documents09:41:38
Invoice, PO, reviewer note and trace filed together.
EDone — End: 09:41:38
Complete. 1 human decision, fully traced.
The problem
Your systems don't talk to each other, so your people do.
An order arrives by email. Someone copies it into a spreadsheet. Someone else re-keys it into a supplier portal, checks it against the CRM, and pulls it into a report at the end of the week. Each step is small. Together they take hours, rely on rules nobody wrote down, and stall when the one person who knows them is away.
That isn't a people problem. It's a design problem: the work between your systems was never designed, so people have been filling the gap.
One order, five systems
Inbox
ExtractCopies the orderClarifies unclear orders
Spreadsheet
SubmitRe-keys itApproves exceptions
Supplier portal
CompareChecks itResolves mismatches
CRM
CompileBuilds the reportActs on the report
Weekly report
Today: four hand-offs, each carried by a person. It works as long as everyone is available, careful, and remembers the rules.
What we automate
Repetitive work has a recognizable shape.
If one of these sounds like a morning in your team, it's likely a good candidate. The marks under each one show what a system for it is usually built from.
Software
Rules
Model
People
Inbox-driven work
Requests, orders and documents arrive by email, and someone reads, sorts and re-keys each one.
Customer purchase orders typed into the ERP from PDF attachments
A shared inbox where every message is triaged and forwarded by hand
Usually built from software, a model, rules, people.
Document processing
Invoices, contracts, statements and forms, read by a person to pull out the same fields every time.
Totals and line items taken from supplier invoices
Signed contracts checked for missing pages, dates or signatures
Usually built from a model, rules, people.
Cross-system workflows
One piece of work entered, in slightly different forms, into several tools that never talk to each other.
A new order recorded in the CRM, the ERP and a carrier portal
Status changes copied from one system to another at the end of each day
Usually built from software, rules.
Reconciliation
Two sources that should agree, compared line by line, with the differences chased down.
Payment provider payouts matched against bank statements
Carrier invoices checked against shipment records
Usually built from software, rules, people.
Recurring verification
The same checks, run every day, week or month, and recorded the same way.
Supplier registration numbers checked against a public register
Certificates and licenses tracked before they expire
Usually built from software, rules, people.
Research and data gathering
Information collected from websites, registries and portals, then written up in a standard format.
Company details assembled for each new lead or supplier
Prices and availability checked across several supplier portals
Usually built from software, a model, rules.
Onboarding
A new customer, supplier or employee, set up in every system they touch.
Documents collected and verified, then accounts created in four tools
Missing information chased until each file is complete
Usually built from software, a model, rules, people.
Reporting
The same report, rebuilt every period from several exports.
Morning reports downloaded, combined and summarized for the team
Month-end figures pulled from three systems into one pack
Usually built from software, rules.
Compliance operations
Checks that have to be performed, evidenced and recorded identically every time.
Names screened against sanctions lists, with each result recorded
Evidence gathered into folders ahead of an audit
Usually built from software, rules, a model, people.
Internal administration
Requests and approvals that follow the same path, every time, through the same people.
Access requests routed, approved and provisioned
Contract renewals flagged, approved and filed
Usually built from software, rules, people.
Worked example
Customer orders by email, before and after.
A common process in distribution and manufacturing. The details differ from company to company; the shape rarely does.
Illustrative example, not a client engagement
As it runs today
8 steps · 5 systems · 1 coordinator connecting them
Done by hand: A customer emails a purchase order: a PDF, a spreadsheet, or lines typed into the message.
Inbox
Done by hand: A coordinator finds the customer in the ERP and opens a new sales order.
ERP
Done by hand: Each line is typed in by hand: item codes, quantities, requested dates.
ERP
Done by hand: Prices are checked against the customer's price list, kept in a spreadsheet.
Spreadsheet
Done by hand: Stock is checked in the warehouse system.
Warehouse
Done by hand: If anything doesn’t match, the coordinator emails the customer and makes a note to follow up.
Inbox
Done by hand: A confirmation is written and sent.
Inbox
Done by hand: The original PO is saved to a shared drive, when someone remembers.
Drive
Engineered
7 steps · same 5 systems · 1 human checkpoint, for exceptions
S1Every message to the orders inbox becomes a case with its own ID.
Inbox
M1The purchase order is read in whatever format it arrives, and each line extracted.
S2Stock and credit status are looked up for every line.
ERP · Warehouse
R1Each line is checked: known item, this customer’s price, sensible quantity, deliverable date.
Price list
P1A person: Only orders that fail a check reach the coordinator — with the original PO, the extracted lines and the reason. They correct, approve, or call the customer.
S3The sales order is created and confirmed to the customer from an approved template.
ERP · Inbox
S4PO, order and every decision are filed together.
Drive
What changes
Hand-offs
The coordinator stops re-typing orders and spends that time on the ones that need attention, and on customers.
Exceptions
Every mismatch lands in one queue with its reason. None of them live in someone’s inbox.
Human review
Required wherever a price, a date or a promise to a customer would change.
Traceability
Any order can be traced back to the email it came from, and every check it passed.
Reliability
When a document can’t be read confidently or a system is down, the order waits for a person. It never guesses.
How we work
We start with the work, not the technology.
Processes rarely break at the obvious steps. They break at the edges: the exception nobody mentioned, the rule that lives in one person’s head. So before we design anything, we watch the work being done.
Understand
OutputA map of the process — systems, rules, decisions, exceptions — and a straight answer on what is worth automating.
01
Observe
Sit with the people who do the work and follow real cases from start to finish, including the awkward ones.
02
Map
Write down every system, rule, decision and exception. There are almost always more exceptions than anyone remembers.
03
Separate
Sort each step: fully deterministic, safe to automate with checks, or genuinely needing a person. Some steps shouldn’t be automated at all, and we’ll say so.
Build
OutputA working system, integrated with your tools and tested against your own past cases.
04
Design
Decide what the software does, where people decide, and exactly what happens when something fails.
05
Build
Integrate with the systems you already use: APIs where they exist, careful browser automation where they don’t.
06
Prove
Run it on real past cases, then alongside your team, and compare the results before it handles live work on its own.
Run
OutputMonitoring, alerts, and a named owner for keeping it working.
07
Operate
Watch every run, alert on failures, and adapt the system as your process, suppliers and tools change. Systems need owners after launch.
Engineering
Each step gets the simplest technology that does it reliably.
We’re software engineers first. A process is a chain of different kinds of work, so we choose the tool step by step — not once for the whole system, and never for the pitch.
Software
When the steps are known
Plain code, APIs and integrations. Fast, cheap to run and easy to test. Most of a well-built system is this.
Rules
When a policy decides
Tolerances, thresholds, eligibility. Written as explicit rules your team can read, test and change — not buried in code or in someone’s memory.
Models
When the input is unstructured
Free-text emails, scans, inconsistent PDFs. Language models and OCR handle what rules can’t, and their output is checked before anything acts on it.
People
When judgment or accountability matters
The system prepares the case; a person decides. We design these checkpoints on purpose, not as a fallback for when the software is unsure.
Models are a component, not the premise.
We expect language models to be part of many systems we build; they are remarkably good at reading messy input. They’re used where they are the best tool for a step, and their output is checked like any other input. Where a rule or a query does the job, we use the rule or the query.
How our systems behave
Every run leaves a trace
What arrived, what was read, which rules ran, who decided what, and when.
Failures are loud
When input is unclear or a system is unavailable, work stops and the right person is told. Nothing guesses silently.
Built on what you have
Your inbox, spreadsheets, ERP and portals. You don’t replace systems to start.
Rules in one place
Business rules live somewhere your team can read and review them.
Documented for handover
Written down, so the process stops depending on one person — including us.
Start here
Tell us about the work someone does by hand.
You don’t need a specification, a budget or a list of systems. Describe the work the way you’d explain it to a new colleague. Something like this is enough to start:
“Every morning someone downloads three reports, compares them, and enters the differences into a supplier portal.”
What happens next
We read it and reply by email with a few questions about how the work runs today.
You walk us through the process on a short call, ideally with the person who does it.
We tell you plainly whether it’s worth automating, what we’d build, and what we’d leave to people.