An automation project should start with discovery rather than software when the proposed solution has arrived before a clear understanding of the problem. This is especially important where the process crosses teams, depends on existing systems or rules, has an unclear commercial case, or may be better solved without new software.

Discovery is an investment decision, not a delay

Discovery is useful when leaders need to decide whether further investment is justified, rather than assume that a platform purchase is the answer. Government service guidance describes discovery as the stage for understanding the problem, users, constraints, wider context and opportunities for improvement before committing to build. It also recognises that stopping after discovery can be the right outcome when the expected improvement does not justify the cost.

That principle transfers well to commercial automation decisions, although it is guidance for government services rather than a universal private-sector requirement. The objective is not to produce paperwork; it is to reduce the chance of buying software for the wrong problem.

Signals that discovery should come first

  • The request is framed as a product choice — such as an AI agent, workflow platform or bot — but the operational problem has not been defined clearly.
  • The work involves multiple departments, customer touchpoints, suppliers or offline activity, so a single team’s view is unlikely to show the whole process.
  • The expected value is unquantified. Leaders cannot yet explain the material effect on time, errors, service consistency, capacity or customer experience.
  • Important constraints are unresolved, including contractual obligations, legacy technology, existing systems or established operating processes.
  • The workflow is variable, exception-heavy or dependent on human judgement, rather than plainly routine and repeatable.
  • There may be lower-cost alternatives, such as clearer information, a service change, a campaign, a partnership or better use of existing data.
  • Success cannot yet be measured in a meaningful way.

Where software is more likely to be the right starting point

Automation is generally a stronger fit for routine, repetitive work where a consistent workflow can reduce manual effort and errors. Official Microsoft guidance also highlights the importance of integration with existing systems, scalability, security and compliance features, and performance measurement when assessing automation tools.

This does not mean every well-understood process needs a lengthy discovery phase. If the problem, users, constraints, ownership and value are already evidenced, a focused software evaluation may be proportionate. The key judgement is whether uncertainty is material enough to make a premature commitment expensive or difficult to reverse.

What decision-makers should want from discovery

The useful outcome is a better investment decision, not a predetermined build. A sound discovery should give decision-makers enough confidence to choose between proceeding, narrowing the scope, changing the proposed solution, improving the process without automation, or stopping work altogether.

  • What business problem are we solving, and for whom?
  • Which part of the work is genuinely routine and repeatable?
  • What constraints could affect viability or cost?
  • What improvement would make the investment worthwhile?
  • How will we know whether the outcome has improved?
  • What credible non-software or lower-complexity alternatives have been considered?

The business case for starting with discovery

The cost of discovery should be judged against the cost of selecting an unsuitable tool, automating a weak process or scaling a workflow that does not meet user needs. In practice, the most valuable finding may be that the opportunity is smaller than expected, belongs elsewhere in the organisation, or calls for a service or process change rather than automation.

For business owners and operations leaders, the practical question is not whether discovery is always necessary. It is whether the evidence is strong enough to make a software commitment with confidence. When it is not, discovery is the more disciplined place to start.

OUROPT can help organisations assess automation opportunities and shape AI-assisted workflows around a clear business problem before committing to a build.

Explore our services →

Sources and references

  1. How the discovery phase workswww.gov.uk
  2. What is business process automation?www.microsoft.com