Business Process Automation
We automate the processes a business actually runs on, and then prove the automation did what it was supposed to.
Most processes that are worth automating are not the ones anyone has written down. They live in a spreadsheet somebody maintains by hand, a mailbox somebody watches, and a monthly afternoon that everybody has stopped noticing.
What this is for
The work that runs the business and produces nothing while it runs:
Handoffs between systems that never learned to talk, currently bridged by a person copying fields
The recurring report that takes a day to assemble and is out of date when it lands
Approvals and routing that wait on one inbox, and stop entirely when that person is away
Reconciliation — two records that must agree, checked by eye, monthly
Anything with a runbook or a standard operating procedure, because both are an automation someone already wrote out longhand
We are engineers rather than a platform reseller. If the right answer is a tool you already pay for, we will say so and help you use it properly.
How the work goes
1. We watch the process as it is. Not the documented version. The one people actually run, including the parts they have stopped mentioning because they are normal now.
2. We measure what it costs. Time per cycle, how often it runs, what it blocks while it waits, and how often it goes wrong. This is the number the whole decision rests on, and it is usually the first time anyone has written it down.
3. We say what to automate, and what to leave alone. Some of it will not be worth it. We say so below, and we would rather have that conversation here than in a meeting.
4. We build it. In your stack, on your infrastructure, with the code and the runbook handed over. No platform licence that only we know how to operate.
5. We prove it did the right thing. See below. This is the part that is usually missing.
6. We keep it working. A process does not sit still. A supplier changes a form, a system gets upgraded, a rule changes, somebody leaves. We make it work and keep it working while the world changes around it — a standing arrangement rather than a handover.
What you get
The process written down as it actually runs, which has value on its own and is yours whether or not we build anything
A measured before-and-after, so the decision to keep going is arithmetic
Working automation in your own environment, with the source and the runbook
A reconciliation or audit trail that shows what the automation did, and flags what it could not do
A named human step wherever one belongs, and a clear account of why it is there
Someone who keeps it running as the systems around it change, for as long as you want us there
What we would tell you not to automate
Three things come up on almost every engagement, and none of them should be a project.
A process nobody has measured. If the time it takes has never been counted, count it first. Automating an unmeasured process buys you a faster version of something you cannot tell was worth doing.
A process that is about to change. If the team is mid-migration or the rules are under review, automation freezes the current shape at exactly the wrong moment.
The last ten per cent. Most processes have a long tail of exceptions, and the tail is where the cost lives. Automating the common path and leaving a person on the exceptions is usually the right answer, and it is cheaper than the alternative by a wide margin.
We would rather scope a smaller piece of work that finishes than a larger one that stalls.
Proving what the automation did
An automated process fails differently from a manual one. A person who is unsure stops and asks. Software that is unsure carries on, at full speed, and the first anyone hears of it is a number that does not reconcile a month later.
So the part we care most about is evidence: a record of what ran, what it changed, what it declined to touch, and a reconciliation that a person can check without reading the code. Verification is a line MLabs already sells on its own, and it is the reason we are worth hiring for this rather than for the building alone.
We have run this on ourselves. MLabs’ own sales and marketing operation is automated — scheduled jobs draft everything that goes out, a human approves, and every run is metered. That ledger is public, including the parts that are unflattering: the bill is mostly context rather than output, and the most expensive input in the whole operation is the human approval step we deliberately kept.
How we scope
Every process is different, so the first conversation is about yours rather than about us. We will want to understand what the process does, how often, who touches it, and what happens when it goes wrong.
Nothing is shared before a mutual NDA, and nobody needs to hand over access to a system to have the first conversation. From there we scope a defined piece of work and quote it.
Who does the work
Senior engineers, and the same people who scoped it. MLabs builds and verifies software for organisations where being wrong is expensive, and automation work is the same discipline pointed at a company’s own operations.
Start with one process
Pick the one that annoys people the most, the one that is not getting done, the one you have never been able to get humans to do consistently, or the one that would have the biggest impact on your bottom line.