Hong Kong
The intake, approvals, handoffs and chasing that eat a day a week and that nobody owns — because the work lives between your tools rather than inside any one of them. We map it, shorten it, and build what is left.
The work nobody owns
Every system in your company is fine on its own. The cost is in the gaps between them, and no vendor is responsible for a gap.
A request arrives by email. Someone reads it, decides who it belongs to, and retypes it into a system. It waits for an approval that has to be chased twice. It is handed to a second team who need three facts that were in the original email and did not survive the retyping. Someone assembles a report about it at the end of the month.
None of those steps is anybody's job. They are the connective tissue of the company, and they are almost always invisible in an org chart, a budget or a software licence — which is precisely why they never get fixed.
Mapping this honestly is uncomfortable, because a good map always contains steps that exist only because of a decision nobody remembers making. Those steps are usually the cheapest thing to remove, and removing them is not automation at all.
Judgement
Automating a bad process makes a bad process happen faster and more reliably. It is the most common expensive mistake in this work.
The order that works: delete the steps that have no reason to exist, simplify the ones that do, and only then automate what is left. That sequence routinely turns a project people expected to be large into a small one, which is a good outcome even though it is a smaller invoice.
The rule of thumb for what survives to automation: it is frequent, it is rule-bound, and it is boring. Work that changes shape every time it runs is a bad candidate — it will need a person anyway, and the automation will need maintaining forever.
One front door for requests, captured in a structure, routed by rules — instead of four inboxes and a person deciding what each thing is.
Who must approve what, at which threshold, with a record of when and why — and automatic escalation when it sits too long.
Work moving between teams with its context intact, and a clock that someone can see before it has been breached rather than after.
The reminders a person currently sends. This is usually the single most disliked task in a company and among the easiest to remove.
The month-end assembly, the recurring export, the report that exists because one director asked for it in 2019 and nobody has checked since.
The cases the rules do not cover, routed to a named person with the context attached, because those are the ones that actually need a human.
Most automation is built to report what it did. The failure that costs real money is the thing that did not happen and told nobody: the approval never requested, the sync that stopped three weeks ago, the nightly job that has been exiting early since a password changed.
Errors announce themselves. Absence does not. So the monitoring has to be built around expectation — this should have run by now, this queue should not be this old, this number should not be zero on a Tuesday — rather than only around exceptions being thrown.
It is the least glamorous part of a workflow project and the part that determines whether the system is still trusted in year two. A workflow nobody trusts gets a shadow spreadsheet built alongside it within a month, and then you are paying for both.
The part most projects skip
Silent failure is the expensive failure mode, and it is invisible by definition.
Where AI fits
We are a systems consultancy, not an AI agency. That distinction changes what gets built.
Language models are genuinely good at the steps inside a workflow that need judgement over messy input: reading a document that arrives in twelve different layouts, triaging a free-text request, summarising a thread, drafting a first pass for a person to approve.
When we use one, it comes with guardrails, an evaluation set that proves it does the job on your real examples, a cost ceiling, and an audit trail of what it decided. Without those four things it is a demo, not a system.
Everywhere else — validation, routing, thresholds, permissions, totals — a rule, a form or a database constraint is cheaper, faster, explainable, and does not drift when a model is updated. Reaching for a model where a constraint would do is how a reliable process becomes an unpredictable one.
Questions
Automate the steps that are frequent, rule-bound and boring. Leave the judgement calls with people and give them better context instead. Work that changes every time it runs is a bad automation candidate and an expensive one to maintain.
In this kind of work it usually removes the part of a job nobody wanted — rekeying, chasing, reconciling — and gives the same people more of the work that needed a person. If a project's business case depends on headcount cuts, we will say so plainly rather than dress it up.
The exception goes to a named person with the context attached, and monitoring reports the things that did not happen — the approval nobody gave, the sync that quietly stopped. Silent failure is the failure mode that costs the most, and most automation skips it.
Inside the steps that genuinely need judgement: reading messy documents, triaging free-text requests, drafting something a person then approves — with guardrails, an evaluation set and a cost ceiling. Everywhere else a rule, a form or a database constraint is cheaper and does not drift.
Related
When the workflow needs somewhere to live that no product on the market provides.
When the reason work stalls is that the systems either side of it disagree.
The same work in the context of everything else we do.
A week inside the work before anything is built, and you keep the map either way.
Describe how a request travels through your company today. We will tell you which steps should be deleted, which should be simplified, and which are actually worth building.