Most businesses do not have an automation problem. They have a prioritisation problem.
There are dozens of tasks that could be automated: moving data between systems, chasing approvals, sending updates, creating documents, routing requests and answering routine questions. The hard part is knowing which one should be first.
A poor first automation project usually targets the most visible manual task. A strong one targets the workflow where repeated delay, error or unclear ownership is already costing the business time, trust or revenue.
This guide gives leaders a practical way to choose that first workflow. It is designed for businesses considering business process automation, workflow automation, AI-assisted operations or a focused internal tool.
Start with the point where work gets stuck
Look for a workflow where people repeatedly ask one of these questions:
- Who owns this now?
- Has this been approved?
- Which version of the data is correct?
- Why has this customer not received an update?
- What happened after I submitted the request?
Those questions point to a broken handoff. The work may move through email, spreadsheets, chat messages and separate tools, but no single system records the real state of the process. Automation can help, but only after the workflow itself is understood.
For example, a sales team may copy deal information into a proposal document, send it for approval, wait for pricing confirmation, update a CRM and notify delivery. Automating document creation alone removes a few minutes. Designing one controlled workflow can remove missing context, unclear approval ownership and duplicate data entry at the same time.
Do not automate a process you cannot describe
Before selecting a platform, map the current process from trigger to outcome. Keep the map concrete. It should show:
- The event that starts the workflow
- Each person, team and system involved
- Inputs required at each step
- Decisions, approvals and exception paths
- The point where the business considers the work complete
If the team cannot agree on these basics, building automation will only make an unclear process move faster. First resolve the state definitions, ownership and rules. Then decide where software should act.
A useful distinction is between a workflow that is merely inconvenient and one that is operationally fragile. Inconvenience may be solved by clearer instructions. Fragility shows up as repeated rework, lost requests, stale records, late customer communication, compliance risk or a small number of people carrying critical knowledge in their heads.
A five-part test for choosing the first workflow to automate
Score each candidate workflow against the following questions. The goal is not a perfect numerical model. It is a shared, defensible decision about where to begin.
1. Is the work frequent enough to matter?
Frequency creates leverage. A workflow completed once a quarter may be important, but it is rarely the right first automation project. Prioritise work that happens daily, weekly or at high volume during predictable peaks.
Count more than clicks. Include time spent finding information, clarifying status, correcting errors and following up with the next owner.
2. Does the workflow create expensive errors or delays?
Errors are not limited to bad data. A missed approval, duplicated order, late customer update or incomplete handoff can all create real cost. Identify the consequence of failure, how often it happens and whether a person can recover quickly.
A good first project often removes a recurring operational risk, not just a repetitive task.
3. Are the rules stable enough to express?
Automation needs a reliable rule, even if the rule is simple. “Send a reminder when an invoice is overdue by seven days” is clear. “Decide whether this unusual customer request deserves an exception” requires judgement and context.
Use deterministic workflow automation for known rules, routing and validation. Use AI where classification, extraction or summarisation can prepare work. Keep a person responsible for consequential or uncertain decisions.
4. Is the data accessible and trustworthy?
Every automation depends on source data. Check where the authoritative record lives, whether fields are consistently populated, how systems identify the same customer or transaction, and what happens when data conflicts.
A workflow cannot become reliable if it reads from stale spreadsheets, ambiguous email threads or systems without a safe integration path. Sometimes the right first investment is cleaning the data model or adding a small internal tool that creates one source of truth.
5. Can the business safely handle exceptions?
Real operations are full of exceptions. A customer changes a requirement, a payment fails, an approver is unavailable or a source system returns incomplete data. A useful automated workflow must make these cases visible rather than silently failing.
For each step, decide what the system should do when it cannot continue: retry, pause, assign an owner, request more information or escalate. The exception path is where reliability is designed.
Use a simple priority matrix
Create a shortlist of three to five workflows. Give each one a score from one to five for frequency, business impact, rule clarity, data readiness and recoverability. A workflow with high impact but unclear rules may be valuable, but it needs discovery first. A workflow with modest impact and excellent readiness is often the best pilot.
The best first automation is usually not the biggest transformation. It is a bounded workflow with a visible outcome, clear owners and enough repetition to prove value.
What should remain human?
Automation should remove administrative coordination, not hide accountability. Keep human review when a decision changes a contract, payment, access level, customer commitment, employment outcome or another difficult-to-reverse result.
In those cases, the system can still do valuable work. It can collect evidence, validate inputs, create a recommendation, route the request to the right approver and record the final decision. This approach speeds the process while preserving control.
For AI-assisted workflows, show the reviewer the source information, the proposed action, the reason for the recommendation and the next consequence. A bare AI output is not enough for meaningful review.
Build the smallest useful pilot
The first release should complete one workflow end to end. Avoid a broad request such as “automate operations.” Define a narrow outcome instead: every new enquiry is qualified, assigned and acknowledged within the agreed process; every purchase request has the required information and approval trail; every service request reaches the correct owner with its context intact.
A strong pilot includes:
- One clear trigger and one defined completion state
- Only the integrations necessary for the first workflow
- Explicit roles, permissions and approvals
- Validation before records are changed
- Visible status and an audit history
- Alerts or a queue for failures and exceptions
This scope gives the business a real operating improvement without creating a fragile, oversized system.
Measure the workflow, not the feature list
Do not judge a project by how many steps it automates. Measure whether the business process became clearer and more dependable.
Useful measures include cycle time, backlog age, rework, incomplete requests, manual touchpoints, exception volume, customer response delay and the percentage of work completed without a follow-up. Choose a baseline before changing the process, then review the same measures after the pilot has been operating long enough to reveal real patterns.
Numbers alone do not tell the full story. Ask the people doing the work whether they can now see ownership, status and the next action without chasing someone. If they cannot, the process still needs design work.
Common mistakes when starting business process automation
- Starting with a tool instead of a workflow. Software should serve a clear process, not define it accidentally.
- Automating bad inputs. Validation and data ownership are part of the solution.
- Ignoring exceptions. A workflow that works only on its happiest path creates operational risk.
- Removing human review too early. Keep accountability where uncertainty or consequence is high.
- Building too much at once. Prove one valuable process, then extend the pattern.
- Leaving the workflow unowned. Someone must own the rules, performance and future changes.
When to use existing tools, low-code or custom software
Existing products are often the fastest option when the workflow is standard and the required data already lives in supported systems. Low-code tools can work well for bounded internal workflows with simple rules and manageable integration needs.
Consider custom software when the process is central to how the business operates, several systems need coordinated actions, roles need fine-grained permissions, the experience needs to reflect a specific operating model, or the workflow needs product-level reliability and long-term ownership.
The decision is not about preferring custom development. It is about selecting the smallest dependable system that can represent the real work.
From a manual process to a dependable operating system
Business process automation works best when it creates clarity: one visible workflow, defined states, accountable owners, safe integrations and a path for exceptions. The first project should create that clarity in one high-value area, then give the business a pattern it can reuse.
Comlabs helps businesses map fragile operational workflows, decide what to automate, and build dependable internal systems and integrations around the way their teams actually work. Explore business process automation with Comlabs.