When not to automate: fix the process first

Automation is genuinely good at removing dull, repetitive work. It is also very good at taking a process nobody fully understands and running it faster, more often, and further out of sight. When that happens the errors do not disappear; they simply arrive in greater volume and are harder to trace.

So before recommending any integration or automation, we ask a deliberately unglamorous question: does everyone involved agree what this process is, and why?

“We have always done it this way” is not a requirement

Most charity processes were designed by circumstance. Someone left, a system changed, a funder asked for a particular report, and a step was added to cope. Years later the step is still there and nobody remembers why.

Automating that step encodes an accident into software—and makes it considerably more expensive to remove later. History explains a process. It does not justify it.

Map the process as it actually happens

Not as the procedure document describes it. Sit with the people doing the work and follow one real case from the first trigger to the final outcome. Note every system it touches, every handover, every place someone waits, and every point where information is retyped.

Start with one page; split genuinely complex journeys into manageable sections where needed. The exercise is almost always revealing. Two people who have worked on the same process for years will frequently disagree about the order of the middle three steps.

Ask why the information is being handled at all

For each piece of data collected, stored or entered, ask three things: who uses it, what decision it supports, and where the authoritative version lives. It is common to find fields captured because a report needed them in 2019, and information entered twice because two teams do not trust each other's copy.

Removing an unnecessary step is faster, cheaper and more reliable than automating it.

Find the exceptions before you build

The main path is rarely the difficult part. The cost sits in the exceptions: the donation without a matching supporter, the joint gift, the refund, the record with a missing postcode, the case that has to go to a manager.

Ask what happens when something fails, who notices, and how it gets fixed. Automation without a defined failure route does not remove work—it relocates it into a queue nobody is watching until a supporter complains.

Establish who owns it

Every automated process needs a named owner: someone who decides how it should behave, is told when it fails, and is accountable for reviewing it. Not the supplier, and not “IT” in general.

Where ownership is unclear before automation, it becomes genuinely unmanageable afterwards, because the work is no longer visible on anyone's desk.

Ownership needs support to be meaningful. Anything running in production needs monitoring, a documented retry and exception route, and a safe way for its owner to pause it without asking a developer.

Check the data underneath

Automation applies your existing data quality consistently. If supporter records are duplicated, an automated flow will helpfully duplicate the follow-up. If reference numbers are entered in three formats, matching will fail on a predictable share of cases.

Sample enough real records to cover the normal path and the exceptions that matter. Fifty can be a useful starting point rather than a universal rule; what counts is whether your sample includes the awkward cases you will have to handle.

Sometimes manual is the right answer

There are legitimate reasons to leave a process alone. Low volume, where the build cost will never be recovered. Genuine variability, where every case differs enough that rules become unmanageable. And processes about to change anyway, because a service is being redesigned or a system replaced.

High-judgement work—safeguarding decisions, sensitive supporter conversations—is a slightly different case. You can often support it well without automating the decision itself: gather and present the information, route the case to the right person, draft a response for review. The person stays responsible for the judgement and the approval.

Deciding not to automate is a valid outcome of a review, and stating it plainly is more useful than building something to demonstrate progress.

Redesign first, choose technology second

Once the process is mapped, redesign it on paper: remove duplicate steps, agree the authoritative source for each piece of information, define the exception routes, and simplify the sequence. Write down the target process in plain language and have the people who do the work confirm it is right.

Only then look at technology. A well-understood process usually needs less tooling than expected, and the tooling it does need becomes obvious. Choosing a platform first inverts this and quietly hands the design decisions to whichever product you happened to see demonstrated.

A five-question automation readiness test

1. 01Can we describe this process end to end, and do the people who run it agree with the description?
2. 02Do we know the exceptions, roughly how often they occur, and what should happen to each?
3. 03Is there a named owner who will be told when it fails and can decide how it should change?
4. 04Is the data it depends on accurate and consistent enough for the matching we are relying on?
5. 05Is the process worth automating—volume, risk or time saved—and is it stable enough to be worth building for?

Five yeses mean the process is ready for a costed design or a pilot; they do not prove a return on investment on their own. With only two or three, the useful work is process work rather than technology work. That is not a delay to the project; it is most of the value in it.