Manual processes do not fail suddenly. They degrade, absorbing more of the week until the cost is normal and invisible. These are the signals that the threshold has been crossed, and the questions worth asking before assuming software is the answer.
One: the same data is typed into more than one system
Rekeying between systems is the clearest candidate in most businesses. It is high volume, entirely rule-governed, and it introduces errors that surface much later in something expensive like an invoice or a delivery address.
Two: growth requires headcount in a straight line
If handling twice the volume means twice the administrators, the operation has no leverage in it. That is fine at a small scale and becomes the constraint on growth surprisingly quickly.
Three: your best people spend their week on admin
A senior person moving data between windows is the most expensive automation candidate you have, and the easiest to justify. The value is not the hours saved so much as what those hours get spent on instead.
Four: nobody can say where a job currently is
When answering where is my order requires asking three people, the process has no state anybody can query. That is usually a systems integration problem rather than a discipline problem.
When a business tells us its people are working late, the cause is rarely volume. It is that the work crosses four systems and a person is the integration layer between them.
Lena Fischer, Solutions Architect, Engineered With AI
Five: errors are found by customers
A process without a checking step relies on the person doing it being consistently careful, which is not a reasonable expectation at volume. If the first line of defence is a customer complaint, the cost of each error includes the relationship.
Six: month end takes over the month
Reconciliation and reporting work that consumes several days each cycle is the classic case: fixed inputs, a defined notion of a match, and a clear exception path. It is also work that must be done, which makes the payback straightforward to model.
Seven: knowledge lives in one person
If a process stops when someone is on holiday, the risk is already material and automation is the wrong first move. Documenting it is, and that documentation is what makes any later automation possible. This is the honest sequence rather than a delaying tactic.
Telling the problems apart
Not everything on this list is an automation problem. Signals three, four and six usually are. Signal seven is a documentation problem. Signal two can be a hiring problem if the work genuinely needs judgement. Getting this wrong produces a system that automates a bad process faster.
Where to go from here
Pick the signal that costs the most and check whether the underlying task passes the one-page test: could a competent new starter do it correctly from a page of written instructions? If yes, it is a candidate. The automation index covers what that looks like by sector.
What to do with the signal you picked
Having identified the costliest signal, resist the urge to scope a system immediately. Spend a week recording what the process actually involves, including the cases people handle without thinking about them. Almost every process contains a branch nobody mentions in the first conversation, and that branch is what turns a straightforward build into an overrun.
The output of that week is a written description with the exceptions listed. That document is the deliverable that determines whether anything else works, and it has value even if no software is ever built, because it makes the process teachable and survivable.
Automating a bad process makes it worse faster
If the current process has accumulated steps that exist only because of an old system or a departed colleague, encoding it preserves those steps permanently and gives them the authority of software. The point at which a process is written down is the natural moment to ask which steps still earn their place, and that question routinely removes more work than the automation itself would have saved.
This is the least technical part of an automation project and consistently the most valuable. It is also why the first deliverable is a document rather than a demo.
Recognise more than a couple of these?
Tell us where the work is piling up and we will say whether automation is the right answer or whether the process needs rewriting first.
