When an automation project disappoints, the cause is seldom the software. More often the process was not quite what everyone thought it was, an exception nobody mentioned turned out to be common, or no one was clearly responsible for the result once it went live.

These are all things that can be settled before a line of code is written. Here are the seven questions we work through with every client before we build.

1. What exactly is the process today?

Ask the people who do the work to walk through it step by step, with real examples. Written procedures describe how a process should run; the people doing it know how it actually runs — including the workarounds, the spreadsheets on the side and the “we always check with Maria first”.

If two people describe the same process differently, that is not a detail to smooth over. It has to be resolved, because software can only follow one version.

2. Which part should be automated — and which should not?

Not every step benefits from automation. Repetitive, rule-based steps with clear inputs are good candidates. Steps that depend on judgment, relationships or context that is never written down are usually better supported than replaced: the system prepares, suggests or flags, and a person decides.

Draw the line explicitly. “The system drafts the reply; a person approves it” is a design decision, and it should be made on purpose.

3. What are the exceptions?

Every process has cases that don’t follow the normal path: the order with a missing address, the invoice in the wrong currency, the customer with a special arrangement. Ask how often each happens and what is done today.

An automation that handles 80% of cases and quietly mishandles the other 20% can create more work than it saves. Decide in advance what happens to an exception — usually, it goes to a person with the context they need.

4. Where does the data come from, and how good is it?

List every system the process reads from and writes to. For each, check:

  • Can it be reached reliably (an API, an export, a shared database)?
  • Is the data complete and consistent enough to act on?
  • Who is allowed to see it, and are there privacy or contractual limits on its use?

Data problems found during the build are expensive. Found now, they are just part of the plan.

5. Who owns it once it is running?

An automated process still needs an owner: someone who watches the results, handles what it escalates and decides when it should change. Without one, small problems accumulate until people stop trusting it and quietly go back to the old way.

Name the owner before the build starts, and involve them in the design.

6. How will you know it works?

Agree on a small number of measures, and record today’s baseline so there is something to compare against. Typical ones are time per case, error or rework rate, turnaround time and the share of cases handled without intervention.

Agree, too, on how the system’s decisions can be checked afterwards. A log of what it did and why makes problems easy to find and makes the system much easier to trust.

7. What happens if it stops?

Systems fail, connections break and providers change their services. Decide what the fallback is: who is alerted, how the work continues manually in the meantime and how cases caught in between are recovered.

A simple, documented fallback is often the difference between a minor inconvenience and a bad day.

The short version

Before building, you should be able to say: this is the process, this is the part we automate, this is what happens to the exceptions, this is the data it relies on, this is who owns it, this is how we measure it and this is what we do if it stops.

That is the groundwork we do at the start of every Solutions engagement, before we design, build and implement. If you have a process in mind, we would be glad to look at it with you.