What Are You Still Doing by Hand? A Field Guide to Finding the Process Worth Rebuilding

When we run a discovery week, the process that turns out to be worth rebuilding is almost never the one we were called in about. The stated problem is usually the loudest one. The valuable one is quieter: something a small number of people have been absorbing for years, that nobody thinks of as a system because it never had software, and that everyone has long since stopped seeing.

This is a field guide to finding it yourself. It costs nothing to run and it is more useful than most vendor workshops.

Six tests for work that should not be manual

Walk your operation with these in mind. Any one of them is a signal; two or more together is usually a project.

• The re-keying test. Does information get typed into a system when it already exists in another system, a PDF, or an email? Every instance is both a cost and an error rate.
• The chasing test. Is somebody's actual job following up with other people? Chasing is what a process does instead of having states.
• The single-point-of-failure test. Would a process seriously degrade if one specific person were away for two weeks? That person is holding a system in their head.
• The reconciliation test. Do you produce a report whose purpose is to explain why two other reports disagree? That report is a symptom, not a deliverable.
• The "that is just how it works here" test. Ask why a step exists. If nobody can explain it, it is either removable or it is an undocumented rule worth capturing properly.
• The month-end test. Does workload spike because of the calendar rather than because of the business? Batch work is nearly always continuous work that someone deferred.

Where to look, not just what to look for

The tests are easier to apply if you know where the evidence lives. Three places are consistently productive.

Look at what people build for themselves. Personal spreadsheets, private cheat sheets, saved email templates and Access databases are not workarounds — they are unfunded product specifications. Somebody needed a system badly enough to build a bad one. That is the strongest demand signal you will find anywhere, and it has already been validated by use.

Look at your recurring meetings. A standing meeting whose main function is telling people what happened is a reporting system that does not exist. A meeting that mostly assigns and chases work is a workflow that does not exist. You are already paying for both, in the most expensive currency available: senior people's calendars.

Look at your complaints, in both directions. What customers raise repeatedly usually maps to one specific internal hand-off. What staff complain about is almost always the manual work they can see and you cannot.

Three tests for whether it is ready

Finding a painful process is the easy half. Not every painful process makes a good first project, and picking a bad one is how organisations conclude that "AI did not work for us".

• Does the data already exist somewhere? Rebuilding a process that also requires you to start collecting data you have never had is two projects, and the second one is the hard one. Start where the data exists, even if it exists messily.
• Is there a clear before-and-after? You should be able to state it in a sentence a sceptic would accept: quotes go out same-day instead of in three days. If the benefit needs a paragraph and three assumptions, it will be impossible to prove afterwards.
• Does the team want it? A process owned by someone who feels threatened by the change will not survive contact with reality, however good the software is. Start where somebody is actively asking.

What to leave alone

An honest guide has to include this part, because the fastest way to discredit a programme is to automate the wrong thing well.

• Genuinely low-volume work. If it happens six times a year, a checklist is the correct technology. Automation carries a maintenance cost that low volume cannot repay.
• Processes about to change for external reasons. If a regulation or a major contract will reshape it within six months, wait and build it once.
• Work where being wrong is expensive and hard to undo — unless you are prepared to design the human checkpoints properly. That is not a reason never to build it. It is a reason not to make it your first project.
• The relationship parts. The conversation with an unhappy customer, the negotiation, the judgment call with real consequences. Automate the preparation, not the conversation.

The question that finds it fastest

If you do only one thing, ask the people doing the work this: what part of your week would you happily never do again, and what would you do with the time?

The first half surfaces the manual work. The second half is the one that matters, because it separates work that is merely annoying from work that is displacing something valuable. Somebody who answers "I would finally get to the customer follow-ups" has just told you what the automation is worth, in terms your finance director will accept.

Then build one thing

Resist the urge to turn the list into a programme. The list is useful precisely because it lets you choose one. Build that one properly, get it live, measure whether the before-and-after actually happened, and let the result decide whether there is a second.

Our Rebuild Library is the version of this exercise we have already done for the processes we see most often — workflows, internal apps, trackers, document capture, dashboards, forecasting, customer service, finance operations and more. Each entry sets out how it runs today, the tells, what it becomes, and the realistic first release. It is a reasonable place to start if you would rather recognise your problem than go hunting for it.