When automation is the wrong answer
Three situations where we tell clients to fix the process first and quote for less work.
In review
← All pieces
Map the process before you quote it.
An estimate produced before anyone has watched the work happen is a guess with a budget attached. Here is what we do in the first two weeks instead, and why it makes the second month cheaper.
Written by the KaizenSpark Tech engineering team. Last reviewed 26 August 2026.
Most software quotes are produced from a conversation. Someone describes a problem, a supplier recognises a shape they have built before, and a number comes back within the week. It feels efficient. It is the single most expensive habit in this industry.
The description is not the process
When we sit with the people doing a job, the work almost never matches the description we were given. A finance lead will describe invoice approval as three steps. Watching it, there are eleven — and four of them exist only because a system two departments away exports a file in the wrong format on Thursdays.
That gap is not anyone being careless. Descriptions are summaries, and summaries drop exactly the detail that determines cost: the exceptions, the re-keying, the handoffs where work waits.
A supplier who quotes from a description is pricing the summary. You will pay for the eleven steps either way — the only question is whether that happens in the estimate or in the change requests.
What the two weeks actually contain
- Interviews with operators, not managers. The person who does the task daily knows where it breaks. We ask them to do it while we watch rather than to explain it.
- A written map of the current state. Every step, who performs it, what system it touches, and where the work waits. This is the deliverable, and it belongs to you whether or not you build anything.
- The cost of each bottleneck. Hours per week, error rate, or revenue held up. Quantified where the evidence supports it and marked unquantified where it does not.
- Options with trade-offs. Usually three: the narrow fix, the fuller build, and the process change that needs no software at all. Each with what it costs and what it does not solve.
Why it makes the build cheaper
Two reasons, both boring. First, the integration surface stops being a surprise — we already know which systems have real APIs and which will need a scraper or a manual bridge, and that is the largest single variable in any estimate.
Second, scope arguments happen before anyone has written code. A change request in week two of discovery costs a conversation. The same change in week nine of a build costs a fortnight.
When discovery says do not build
It happens, and it should. Sometimes the honest output is that a process change, a different licence tier, or simply agreeing who owns a decision removes the problem for nothing. We would rather write that down and lose the build than deliver something that automates a bad process faster.
That is not generosity. Fixing a broken process before automating it is how the automation ends up worth keeping.
Spotted something wrong, or want the worked example behind a claim here? Email officials@kaizensparktech.com and we will correct it or send the detail.
Keep reading
Related notes
What we put in a handover pack
The test is whether an engineer who was not on the project can operate it without a meeting.
In reviewStart with the map.
Discovery is the cheapest stage of the engagement and the one that decides whether the rest is worth doing.