The first automation project often starts with the task people complain about most. That irritation is useful evidence, although it says little about frequency, exceptions, business value, or the cost of failure. A better first candidate is a stable process that repeats often, has a clear owner, and can be measured before and after the change.
The question “what business process should I automate first?” is best answered by comparing processes before choosing a tool. Map how each one works today, score its value and feasibility, and select a narrow version with a safe fallback. This approach produces evidence about automation in your organisation before a large platform or integration programme exists.
Map the process before choosing an automation tool
A process has a trigger, a sequence of actions and decisions, an output, and an owner. “Automate sales” is too broad to evaluate because sales contains lead capture, qualification, routing, follow-up, proposals, approval, and reporting. “Route website enquiries to the correct account owner within five minutes” is specific enough to observe and measure.
Write down the current path before changing it. Use the process as people perform it today, including manual workarounds and exceptional cases. The resulting map should have enough detail to identify where time, errors, and judgement enter:
1Trigger
2 |
3Required information
4 |
5Rules or judgement
6 |
7Action in one or more systems
8 |
9Exceptions and failures
10 |
11Visible result
12 |
13Process owner
This map often reveals that part of the problem comes from unclear policy or missing information. Software can execute a rule consistently once the organisation has agreed on the rule. Automating a disputed process tends to move the dispute into code and make ordinary exceptions harder to resolve.
The map also helps distinguish automation from an internal tool. An automation moves information or performs actions after a trigger, while an internal tool gives people an interface for decisions, corrections, and exceptional cases. Many useful workflows need both, so the build-versus-buy internal tools framework can help once the process is clear.
Score each automation candidate
A simple scorecard keeps the loudest request from winning automatically. Score each candidate from one to five on the criteria below, and write one sentence explaining every score. The explanation matters because it exposes assumptions that a neat total would otherwise hide.
| Criterion | Low score | High score |
|---|---|---|
| Frequency | Happens rarely | Happens many times each day or week |
| Manual effort | Takes little attention | Consumes substantial repeated time |
| Business consequence | Delay or error has limited impact | Delay or error affects revenue, customers, cash, or compliance |
| Stability | Steps and policy change frequently | Rules and inputs are well understood |
| Exception load | Most cases require judgement | Most cases follow predictable rules |
| System access | Data is trapped or informal | Required systems expose reliable APIs or exports |
| Failure recovery | Errors are difficult to detect or reverse | Failures are visible and recoverable |
| Ownership | Nobody owns the process | One person owns rules and outcomes |
Frequency and effort describe the amount of repeated work available to remove. Business consequence captures processes where a smaller volume still matters, such as a missed customer escalation or incorrect payment. Stability, exceptions, and system access indicate how expensive the automation may be to build and maintain.
Failure recovery deserves its own score because a successful demonstration only covers the expected path. A process that can return to a manual queue is safer for a first automation than one that silently changes financial or customer data. Ownership matters for the same reason, since somebody needs to resolve exceptions and approve changes to the rules.
The highest total is a starting point for discussion. A candidate with severe failure consequences may need to wait even when its value score is high. Record any disqualifying constraint beside the total so it remains visible.
Calculate a useful baseline
The baseline should describe the current process in observable units. Count how often it runs, how much active time each occurrence requires, how often errors happen, how long exceptions wait, and which business outcome the process supports. Measure a representative period when existing systems can provide the data.
Consider a hypothetical operations team that copies approved customer records from a form into a CRM. The process runs 120 times per week, takes three active minutes per record, and occasionally stops because a required account identifier is missing. That is six hours of copying before the team handles corrections or waits for missing information.
The initial calculation can be simple. Its purpose is to make assumptions visible before implementation. Replace the sample terms with measures that match the process being evaluated:
1weekly manual effort = occurrences x active minutes
2expected recovered time = weekly effort x automation coverage
3net value = recovered time value + avoided error cost - build and operating cost
Automation coverage should account for exceptions. If 20 percent of records need human judgement, the first version may automate the predictable 80 percent and place the remainder in a review queue. The calculation should include the time required to monitor, support, and update the automation.
This baseline gives the pilot a real success condition. The team can compare handling time, exception volume, error rate, and user experience after launch. It can also discover that missing information at the form created most of the delay.
Processes that should wait
An unstable process is a poor foundation for automation. When policy, inputs, or ownership change every week, the implementation will require the same changes and may obscure why decisions are being made. Documenting and running the process manually for a short period can expose a stable core.
Rare tasks also deserve scrutiny. A painful quarterly report may take a day, while automating it may require several days of integration work and ongoing maintenance whenever the source systems change. A documented checklist, saved query, or better export may remove enough friction.
Processes with serious irreversible consequences need stronger controls. Payments, deletions, account permissions, legal decisions, and customer communications should have confirmation, limits, audit history, and a recovery plan appropriate to their impact. The first automation can prepare a draft or recommendation while a person authorises the consequential action.
The process should also wait when the company cannot access the required systems safely. Browser automation may provide a temporary path through a system with no API, although interface changes make it more fragile than a structured integration. The maintenance cost belongs in the candidate score.
Choose rules, AI, or human approval
Deterministic rules fit processes where the same inputs should produce the same action. Dates, statuses, thresholds, identifiers, and explicit mappings can usually be validated and tested directly. A conventional integration is often the smallest reliable implementation for this work.
A language model can help when inputs are unstructured or the process requires classification, extraction, summarisation, or a draft. The surrounding application still needs to validate structured outputs, enforce permissions, and decide which actions are allowed. The API-first AI agent approach provides a useful boundary when a model needs controlled access to application data or operations.
Human approval belongs at points where context, policy, or consequence requires judgement. The automation can gather information, apply routine checks, and prepare the proposed action so the reviewer spends attention on the uncertain part. Logging the proposal, decision, and outcome also creates evidence for deciding whether more of the process can become automatic later.
A workflow can combine all three mechanisms. The useful design gives each one a clear responsibility and provides a visible path for exceptions. Operators should be able to explain which mechanism handled a particular case.
Run one measurable pilot
The first pilot should cover one trigger, one outcome, and a known group of users. It needs a named owner, a manual fallback, basic monitoring, and a date when the team will review the evidence. Starting narrowly reduces the number of exceptions discovered at once.
Before launch, record the current baseline and the pilot boundary. The team should agree on these details before implementation starts. They provide the comparison needed during the review:
- Current volume and handling time
- Current error and exception behaviour
- Which cases the pilot will automate
- Which cases remain manual
- How failures become visible
- How the process returns to manual operation
- Who can change the rules
- Which result justifies expansion
Run the pilot long enough to encounter normal variation. Review time saved alongside support work, missed cases, user trust, and changes to the surrounding process. An automation that creates an opaque exception queue has preserved the underlying workload in a less visible form.
The first automation should teach the organisation how to select, operate, and improve automated workflows. MBV Labs helps lean teams build focused automations, integrations, APIs, and internal tools. If you have several candidate workflows and need to identify the smallest useful implementation, you can share the current process with MBV Labs.