Skip to content
SIMPLYFLOW
← All articles
Automation Strategy 10 min

Which Business Process Should You Improve First?

A practical guide to choosing the first workflow to improve, building a contained case for change and proving that it created useful capacity.

Published · Updated

Several workflow candidates passing through a structured comparison to one contained priority
Table of contents

The first business process to improve is usually a recurring workflow with a visible business consequence, a clear owner and a contained path to a better result. It should matter enough to justify attention and be bounded enough to change without reorganising the whole company.

That is a different test from choosing the task that consumes the most hours or the AI use case that sounds most advanced. A good first move creates useful capacity, reduces a meaningful source of friction and gives the business evidence for what to improve next.

This prioritisation method develops one step in the broader framework for deciding where to start with AI and automation.

Compare opportunities by value, feasibility, effort and risk. Choose the smallest intervention that can produce a result worth measuring.

Start with the consequence you want to change

Most teams first notice symptoms. Leads wait too long for a response. Invoices go out late. A monthly report takes days to assemble. Customer onboarding depends on one person remembering every step.

Describe the consequence before discussing a solution. A useful problem statement names:

  • what happens now;
  • who is affected;
  • how often it happens;
  • the delay, error, cost or lost capacity it creates;
  • what a better outcome would look like.

“Automate our CRM” is a technology instruction. “Every new enquiry should have an owner and a next action within one working hour” is an operating outcome. The second gives you something you can inspect, improve and measure.

If the team cannot agree on the consequence, the opportunity is not ready for prioritisation. Use the diagnostic guide to establish whether the constraint is process clarity, ownership or a suitable automation opportunity.

Build a shortlist from recurring friction

Ask functional leaders where work repeatedly waits, gets copied, gets checked or gets chased. Look for workflows with one or more of these signals:

  • the same information is entered into several systems;
  • a person spends time routing predictable requests;
  • completion depends on reminders or personal memory;
  • errors create rework later in the process;
  • customers wait while the team finds information;
  • management cannot see whether work is moving;
  • volume is growing faster than the team’s ability to handle it.

Keep each candidate specific. “Finance administration” is too broad. “Prepare approved delivery records for invoicing every Friday” has a trigger, inputs, participants and an output.

A shortlist of three to five workflows is enough. A catalogue of every manual task adds effort before it improves the decision.

Classify each problem before scoring it

A repeated manual task can point to different constraints. The intervention should match the cause.

Process problem: The steps, decisions or required information are inconsistent. Clarify the workflow before adding technology.

Ownership problem: The next action has no accountable person or deadline. Assign responsibility and escalation first.

Information problem: People cannot access reliable inputs when they need them. Improve capture, structure or access.

Integration problem: The process is sound, but systems do not exchange information. Connect them using stable fields and clear rules.

Automation opportunity: The path is repeatable, rules can be stated and the volume makes manual handling wasteful.

Applied AI opportunity: An otherwise useful workflow contains language, documents or variable inputs that conventional rules cannot handle efficiently. AI may classify, extract or draft, with review proportional to the risk.

Classification prevents a common failure: automating a symptom and preserving the condition that created it.

Compare value, feasibility, effort and risk

Score each candidate on a simple one-to-five scale. The purpose is comparison, not mathematical precision.

Value

Consider the full business effect:

  • labour released from repetitive work;
  • fewer errors and less rework;
  • shorter customer or internal waiting time;
  • higher throughput with the current team;
  • better cash timing or lower commercial leakage;
  • more management attention available for decisions.

Give higher scores to consequences the business already cares about and can observe.

Feasibility

Check whether the workflow has a stable trigger, accessible inputs, explainable decisions and a dependable owner. A process can have high value and still be a poor first project if its data is inaccessible or every case follows a different path.

Effort

Include process design, technical build, testing, training, documentation and ongoing maintenance. Buying a tool does not remove implementation work. An apparent shortcut can carry more configuration and adoption effort than a small custom connection.

Risk

Assess what happens when the new workflow is wrong or unavailable. Consider customer impact, financial effect, sensitive data, reversibility and the ease of detecting a mistake. High-risk opportunities may still be worthwhile, but they usually need tighter scope and stronger review.

You can record the assumptions behind these scores in a workflow map rather than relying on impressions.

Choose the smallest worthwhile intervention

The highest-value problem does not automatically become the best first project. Look for a useful intersection: meaningful value, sufficient feasibility, manageable effort and acceptable risk.

Then reduce the scope. One customer segment, one document type, one team or one part of the path may be enough to test the case. Preserve a clear beginning and end. Define how exceptions leave the automated path and who receives them.

For example, a service business may want to improve its whole sales-to-delivery process. A suitable first release could cover only accepted proposals: create the project record, copy approved client details, assign an onboarding owner and flag missing information. The business learns from a real handoff without redesigning sales, delivery and billing at once.

Write the business case before selecting technology

A credible business case compares the cost of the current workflow with the full cost of changing it. Record current volume, manual time, errors, delays and capacity constraints. Estimate delivery, licences, maintenance and exception handling separately.

Use ranges when the inputs are uncertain. The point is to identify which assumptions determine the decision. The business case guide provides a worked method.

Do not turn all released time into a cash saving. Time becomes value when the business can use it for more work, better service, avoided overtime, delayed hiring or another defined outcome.

Define proof before work begins

Choose a small set of baseline and outcome measures. Useful measures include:

  • elapsed time from trigger to completion;
  • manual touches per case;
  • error or rework rate;
  • response time;
  • cases completed per week;
  • percentage of exceptions requiring intervention;
  • time available for a named higher-value activity.

Set a review period long enough to include normal variation. Compare the same definition before and after. Record any change in volume or staffing that affects the result.

The first improvement has done its job when it solves the bounded problem and produces reliable evidence. Expansion should follow that evidence, not the enthusiasm of launch week.

A practical first-process checklist

Your first process is a strong candidate when you can answer yes to most of these statements:

  • The business consequence is specific and worth changing.
  • The workflow occurs often enough to measure.
  • Its trigger, output and owner are clear.
  • The normal path can be described.
  • Important exceptions are known.
  • Required information is accessible.
  • A contained first release is possible.
  • Failure can be detected and handled.
  • Success measures exist before implementation.

If several answers are no, the next step may be diagnosis or process clarification. That still creates progress. Choosing where to start means selecting the right intervention, including a non-technical one when it is sufficient.