Automation is useful when it removes repeated operational work without hiding a new risk. The right first question is not “what can software do?” It is “which defined workflow is stable enough, frequent enough, and important enough to examine?”

Start with a stable, repeated process

Choose one workflow with a clear owner and a visible beginning and end. Examples include preparing a recurring report, moving approved data between systems, handling a document, or routing an approval. Avoid starting with “digitalise everything”; a narrow workflow makes assumptions and outcomes reviewable.

Before proposing a solution, write down the current steps, the people and systems involved, the exceptions, and the point where the work is considered complete. If the steps change every week, stabilize the process first.

Score the work you can observe

Use actual observations rather than an invented return-on-investment percentage. For the chosen workflow, record:

  • frequency and number of occurrences;
  • manual time per occurrence;
  • errors, rework, and corrections;
  • operational or customer risk;
  • handoffs between people and systems; and
  • availability and quality of the required data.

A high score in one category is not enough on its own. A rare process may not justify automation even when it is frustrating. A frequent process may still need better ownership, data, or rules before software is appropriate.

Evaluate in this order: buy, configure, integrate, build

  1. Buy: check whether an existing SaaS product solves the problem sufficiently.
  2. Configure: use the capabilities and workflow settings already available.
  3. Integrate: connect the systems that already contain the necessary data.
  4. Build: create a focused internal tool or automation only for the remaining gap.

This order keeps maintenance and ownership visible. A small custom component can be the right answer, but it should be the result of understanding the gap rather than the default starting point.

Establish a baseline with real occurrences

Count actual occurrences over a representative period. Record the time spent, the people involved, the rework, and the operational consequence of a missed or incorrect step. Keep the baseline with its assumptions so that a later decision can be checked against reality.

Do not promise savings or calculate a payback from generic benchmarks. The relevant comparison is the expected build and maintenance effort against the value of improving this specific workflow.

Five reasons not to automate yet

Do not automate when:

  1. a standard product already solves the problem well enough;
  2. the process is rare and the manual effort is acceptable;
  3. the process is changing so often that the rules are not stable;
  4. the build and maintenance cost is greater than the likely value; or
  5. configuration or a clearer operating rule solves the gap.

A workflow can still be worth reviewing when the answer is “not yet.” Stabilizing ownership, documenting steps, or configuring an existing product may be the most useful next action.

A practical next step

Describe one workflow, its current steps, the systems involved, and the pain it creates. A fixed-scope audit can then establish the baseline, compare buy/configure/integrate/build options, and recommend whether custom software belongs in the next step.