Automation projects often begin with a tool demonstration or a task that annoys the loudest person in the room. A better starting point is a workflow whose frequency, rules, ownership, inputs, exceptions, and business value are understood well enough to improve safely.
The best first automation is rarely the most sophisticated. It is the one that proves the organization can define work, manage exceptions, measure a result, and support people through a change.
Score the workflow before selecting the technology
I use six practical dimensions to compare automation candidates. A strong first project scores well across most of them—not merely one.
How often does the same trigger and sequence occur?
How many transactions, records, customers, or staff actions are involved?
Can the normal decision path be explained consistently?
What revenue, service, labor, risk, or decision impact occurs when work waits?
Are required inputs structured, accessible, complete, and lawful to use?
How often does a person need to interpret, override, approve, or escalate?
A high-volume process with unstable rules is not automatically a strong candidate. Neither is a simple task whose failure would create serious customer, financial, privacy, or compliance consequences.
Strong first automation candidates
- Repeated data movement between approved systems with consistent fields.
- Scheduled reporting that follows governed definitions and sources.
- Reminders and internal task creation based on clear dates or statuses.
- Lead or customer routing with documented assignment rules and an exception queue.
- Document generation from validated source records and approved templates.
- Quality checks that flag missing, duplicate, stale, or inconsistent information for review.
What not to automate first
Automation amplifies the operating model it is given. When the process is unclear, the result is faster inconsistency and harder-to-see failure.
- A disputed process: departments do not agree on the desired workflow or outcome.
- Unstable policy: rules change constantly and have no accountable owner.
- Judgment-heavy decisions: context, empathy, negotiation, or material risk requires human review.
- Bad source data: required inputs are incomplete, duplicated, inaccessible, or inconsistently defined.
- Rare work: the build and maintenance burden exceeds the recurring benefit.
- Sensitive communication: an unreviewed automated message could damage trust or create a binding promise.
The sequence that makes automation durable
Map
Document the trigger, inputs, decisions, outputs, exceptions, owner, and definition of done.
Standardize
Resolve duplicate steps, unclear fields, conflicting rules, and ownership gaps before coding them.
Instrument
Establish baseline volume, time, error, delay, and completion measures.
Automate the normal path
Begin with the repeatable work and the smallest scope that can produce a measurable result.
Surface exceptions
Create alerts, queues, ownership, deadlines, and a manual override for situations the rules cannot safely resolve.
Operate
Monitor failures, review performance, document changes, train users, and improve the workflow over time.
Define success before the build
Select a small group of measures that describe the desired operating result: hours removed, cycle time reduced, completion rate improved, response time, error rate, exception aging, adoption, or customer experience.
Then set a validation period and compare the result with the baseline. “The automation ran” is a technical event. “The business reliably saved time or improved an outcome” is the reason to continue investing.