Perspective
Redesign the Work First, Then Automate It: How We Approach a Process
Automating or outsourcing a process as it stands fixes its faults in place. We redesign the work first, so you pay to run a process that is worth running.
4-minute read4 November 2026
In Brief
- A process moved as it stands carries its faults along: automation runs them faster, and a contract writes them into a price. Changing them afterwards costs more than changing them first.
- We see four actions before any automation: map the work as it runs, test each step by asking what happens if it goes, give what remains one owner, and decide where a person stays on the decision.
- Thinqmesh follows that order. We map the process with its real costs, redesign it, and bring the first automated workflow to a working version within four weeks.
Proposals to automate or outsource a process usually share a starting assumption: the process is right, and only its cost or speed is wrong. The assumption is seldom tested, because the people commissioning the change rarely work in the process, and those who do have long since stopped noticing its oddities. Our view is that the redesign comes first, since it is the cheapest part of the whole change.
Whatever You Move, You Move With Its Faults
Automation reproduces every step, including the ones that exist only to compensate for another step, and runs them faster. Outsourcing writes the same steps into a service description and prices them. Either way, you have spent money to make your current arrangements harder to change.
The costs arrive quietly. Exceptions that took a morning now take a ticket queue. A sign-off added after one incident years ago stays in the flow because no one has the authority to remove it. A short redesign of a single process, measured in weeks, removes that work for good and leaves a process that is simple enough to improve again.
Four Actions That Come Before Automation
Each one removes work for good, which is cheaper than automating it, and each can be done on a single process within weeks.
Map the Work as It Really Runs
We follow real cases from start to finish and record the volumes, the time taken and the cost of each step.
A process drawn on a wall chart and a process run by a team are rarely the same. We walk actual cases with the people who handle them, and count how often each step happens, how long it waits and what it costs. The map shows where effort goes, including the exceptions that few teams have counted.
Get started
- Choose one process and pull ten recent real cases.
- Trace each case from first request to final record, noting every handover.
Test Every Step by Asking What Happens If It Goes
Steps that exist to compensate for an earlier step often disappear once the earlier one is put right.
Re-keying, reconciliation and checks of checks usually exist because something upstream is unreliable. For each step we ask what would happen if it stopped, and test the answer with the people downstream. What can go is removed, and only what remains is worth automating.
Get started
- List the steps in your process that only check another step.
- Ask the person downstream of each what would change if it were removed.
Give What Remains One Owner
One person answers for the process, one system holds it, and everyone shares one definition of done.
A process with several part-owners improves slowly, because each change needs several agreements. With a single owner, a single system and a clear definition of done, a change can be decided and tried within a week, and the owner can see where work has stalled.
Get started
- Name one person who answers for the process end to end.
- Write down, in one sentence, what done means for a single item.
Decide Where a Person Stays on the Decision
Payments, exceptions and anything a customer will feel keep a person in the loop.
Automation suits the repeatable path. We mark in the redesigned process every point where judgement is needed, such as a payment, an exception or a message a customer will read, and keep a person there. Every automated step leaves a record of what happened and why.
Get started
- Mark each step where a mistake would reach a customer or move money.
- Agree who reviews each of those and what they see.
How Thinqmesh Solves This
We work in a fixed order: the process is mapped as it runs today, redesigned, and only then automated. One redesigned workflow reaches a first working version within four weeks.
- Week 1
The Process as It Runs Today, With Its Real Costs
We map the work with the people who do it and record volumes, turnaround and cost, so the redesign starts from facts.
- Week 2
A Redesigned Process With Owners
Steps that have outlived their reason are removed, what remains gets one owner, one system and one definition of done, and automation and approvals are marked.
- Week 3
The First Workflow Built and Tested
The first automated workflow is built and tested on your real cases, with a person kept on payments, exceptions and anything a customer will feel.
- Week 4
A First Workflow Working
The first workflow is running and a dashboard shows volumes, turnaround and errors. The full engagement runs to six weeks, with handover notes and training for the team that runs it.
You finish with a redesigned process, a first automated workflow in production, a dashboard of volumes and errors, and a team trained to run it.
