Automation projects usually fail for one of two reasons: the wrong process was chosen, or a broken process was automated without being fixed first. Both are avoidable with a short, honest assessment before anyone builds anything.
The Four Screens
1. Frequency × time
A task that takes ten minutes and happens forty times a week is a far better candidate than one that takes a day and happens twice a year. Count both numbers rather than relying on how annoying the task feels — irritation and cost are only loosely related.
2. Error cost
Some manual steps are tedious but harmless. Others carry real downstream cost when they go wrong: mis-keyed pricing, a missed compliance deadline, an order shipped to the wrong address. High error cost raises priority even when the time saved is modest, because you are buying consistency as much as speed.
3. Stability of the rules
Automation encodes rules. If the rules change every quarter, you are signing up to change the automation every quarter. Stable, well-understood rules automate well. Processes still being argued about should be settled first — on paper, cheaply.
4. Clarity of the decision points
Where a person exercises judgement, ask what they are actually weighing. Sometimes it is a rule nobody has written down, which can be encoded. Sometimes it is genuine expertise about context and exceptions, which should stay with the person — and the automation should hand off to them cleanly rather than pretending to replace them.
Strong Candidates
- Re-keying the same data between two systems — the most common and most reliably worthwhile automation there is.
- Reports assembled by hand on a schedule.
- Routing and approvals currently run over email, where status is invisible and nothing is auditable.
- Document generation from data that already exists in a system.
- Notifications that depend on somebody remembering to send them.
Poor Candidates, For Now
- Processes nobody can describe consistently. Document first; automating disagreement produces an automated argument.
- Processes about to be replaced by a new system. Wait.
- Work that is genuinely different every time — automating the exception path is rarely worth it.
- Anything where the manual step is the only quality control. Replace the control before removing the person.
Fix Before You Automate
Automating a bad process makes bad outcomes arrive faster and with more confidence. If a step exists only as a workaround for a limitation, remove the limitation. If approvals go to four people because nobody trusts the data, fix the data. The cheapest automation is often the step you delete.
Start Small and Visible
The first automation should be something the team feels within a fortnight. Early credibility determines how much cooperation the second and third projects receive — and cooperation, not technology, is usually the binding constraint.
Related service: Business process automation services
Getting Real Numbers for the First Screen
Pull instance counts from something that already records them: a ticket queue export, message counts in a shared mailbox, rows added to a tracking sheet in a month, invoice numbers issued between two dates. Counts recalled in a meeting drift in one direction, since the instances people remember are the ones that went wrong, so a system export beats an estimate even when the export is rough.
Time per instance is worth measuring on a handful of real cases rather than asking. What gets left out of an estimate is everything around the typing: finding the record, waiting for a slow screen, switching systems and logging in again, chasing the field that was blank, redoing the one that came back wrong. Elapsed time is a separate number from handling time and usually much larger, because instances sit in a queue between the trigger and the work. A process with four minutes of handling and two days of elapsed time is felt by the business as two days, and shortening the four minutes does nothing to it unless the trigger and the handoff change too.
The number nobody counts is the share of instances that will not fit the automated path. Sample fifty actual records and see how many carry a missing field, a customer who is set up differently, a manual price override, or a legacy account that predates the current rules. If a third of instances need a person anyway, the savings apply to the other two thirds, and the manual path stays in service for the rest.
- Instances per month, taken from a system export rather than an estimate
- Minutes per instance, timed on real cases including the lookup, the login and the correction
- Elapsed time from trigger to done, which is the number the rest of the business notices
- Share of sampled instances that would need a person anyway, and what makes each one different
The Two-Description Test
The poor-candidate list opens with processes nobody can describe consistently, and there is a cheap way to find out which ones those are. Ask two people who do the work to write the steps down separately, without conferring, then compare. Wording differences do not matter. Differences in the order of steps, in who approves what, in which system gets updated first, or in what happens to an exception all matter, because those are exactly the points an automation has to commit to a single answer on.
Disagreement is not always confusion. Often both descriptions are correct and describe variants that were never reconciled: one region does it differently, a product line has its own approval, accounts opened before a migration behave another way. That turns the question into a decision the business has to make, which is whether to standardize the variants or to encode each one deliberately as its own branch. Encoding three branches is buildable work; discovering the third branch after go-live is not, because it arrives as wrong data already written into a live system.
- The trigger: what event starts the work, and how the person finds out it has started
- The system of record for each field, where the same field exists in more than one place
- What happens when a required value is missing or a match against the other system fails
- Who can approve an exception, and whether that authority exists anywhere in writing
- The end state: what has to be true before an instance counts as finished
Designing for the Cost of Being Wrong
Screen 2 ranks candidates by what an error costs downstream. The same answer decides what has to be in the first build, because expensive errors tend to be the quiet ones. A loud error stops the run, writes nothing, and gets noticed the same day. A quiet error completes successfully and writes the wrong value, and it keeps doing that at machine speed until something downstream trips over it. A person mis-keys one price; a wrong field mapping mis-keys every price for a month. That is the real change automation makes to error cost: it converts a random, self-limiting error into a systematic one.
Where the error is quiet, the build needs a check that does not depend on anyone spotting the problem: count the records on both sides, compare a total that should agree, and report the difference to somebody who will actually open it. That belongs in the first build rather than being added after the first incident, and it needs a definition of success beyond the absence of an error email. Retries deserve the same attention. If the job can run twice, which happens whenever a service restarts, a file gets resent, or someone reruns a failed batch, the second run must not create a second record. Matching on a stable key that both systems already carry, such as an invoice number or an external ID, before deciding whether to create or update is what prevents that, and duplicate creation is the most common quiet failure in an integration that otherwise looks healthy.
- Whether a wrong result shows up in the output or only surfaces weeks later, somewhere else
- What a second run of the same input does: create, update, or nothing
- The reconciliation: what is counted on each side, how often, and what a mismatch sets off
- What state the two systems are left in when a run stops halfway through
Which Part of the Rule Moves
Screen 3 asks whether the rules are stable. The follow-up question is which part of the rule moves, because the three kinds of change cost very different amounts. A value moving is the cheapest: a rate, a threshold, a list of approved codes, a fiscal calendar. A case being added is more work: a new region, product line or customer type joins a decision that already exists, and the logic gains a branch that has to be tested against the others. A structural change is the expensive one: a new required field, an extra approval level, a step that did not exist before. Knowing which kind you are facing is how you price the commitment Screen 3 describes, not a way around it.
You can find this out before building by asking what changed in the last two years and what each change actually required of the systems involved. Where the moving part is a value, it should live somewhere a person can maintain it, a table in the system of record or a controlled list, rather than being written into the logic where every edit is a development task. Even then the list needs an owner and a record of who changed what and when, because a list with no owner is a list nobody updates, and the automation quietly freezes on the last version anyone touched.
- Values on a schedule: rates, thresholds, price lists, approved code sets, fiscal calendars
- Cases being added: a new region, product line, or customer type joining an existing decision
- Structural change: a new required field, an extra approval, a step inserted in the middle
- Where the changing part lives today, and who is allowed to change it
After It Works: Who Owns It
Automations do not announce when they stop working. A form gains a field, a report changes its column order, an API version is retired, or a password expires under a policy nobody connected to this job. What follows is usually not an outage anyone reports but a quiet return to doing the work by hand. Running integrations under a service account rather than a person's login removes one whole category of this, because a personal account gets disabled when that person leaves, and interactive sign-in prompts break jobs that run with nobody watching.
Once the routine cases stop reaching people, the only cases they see are the hard ones. That changes what a new person learns, because the ordinary instances that used to teach the pattern no longer pass through anyone's hands. It also changes the staffing arithmetic: an exception queue made entirely of genuinely difficult cases needs more time per item, not less, so treating the drop in volume as a proportional drop in workload is how that queue starts aging.
- Which account the automation runs as, and what happens to it when that person leaves
- Where failure notices go, and who is expected to read them
- The manual fallback while it is down, and who is allowed to run it
- Who may change the logic, and where that change is recorded
- What gets rechecked after either connected system is updated or upgraded
Frequently Asked Questions
How is this different from process mapping?
The screens are triage across many processes; mapping is detailed work on the one process you selected. The screens rank candidates using numbers you can get without documenting anything in depth, mostly counts, times and a sample of exceptions. Mapping produces the step-by-step description an automation is actually built from, including every field, the system of record for each, and what happens to each exception. Mapping ten candidates before choosing one is a common way to spend a great deal of effort ahead of any decision.
What has to already exist before a process can be automated?
A system that holds the data, a way into it, and an account with the rights to do what the automation does. The way in can be an API, a database connection, a file drop, or a scheduled export, and which one is available usually matters more than which one is preferable. Where a step depends on a person reading a document, something has to turn that document into structured data first, which is its own project. If the information only exists in email bodies or in somebody's head, capture has to be solved before automation has anything to work with.
What actually makes an automation run between two systems?
A trigger, and there are three common kinds. The source system can push an event as it happens, which is fast and quiet but requires the source to support it and an endpoint it can reach. A schedule can poll for records changed since a marker, which works with almost anything but depends on a reliable last-modified field; without one, each run has to compare everything. A file can arrive in a watched location, which is the usual answer for systems that offer no live interface. The choice sets how quickly changes appear on the other side and how the job catches up after a period when it was down.
How does this kind of work usually proceed once a process is chosen?
Work of this kind generally begins by confirming the process description and the field-level mapping between systems, including which side wins when both hold a value for the same field. Building against a copy of real data, or against a sandbox loaded with it, is what surfaces the records that break the mapping, since test data invented for the purpose tends to be well behaved. Running the new path alongside the existing one and comparing the two outputs is the standard way to find the gap between what the rules say and what the data does. Cutover is a judgment call about when that comparison stops producing surprises.
What does the business side need to decide?
The decisions that stall automation projects are business decisions rather than technical ones: which system is authoritative for each field, what happens to records that do not match, who is allowed to approve an exception, and whether existing variants get standardized or encoded as separate branches. Someone with the authority to settle those questions has to settle them, because otherwise a developer's assumption becomes the rule the moment it is written into code. Sample records are the other thing that consistently earns its keep, covering the ordinary cases and the awkward ones, because they show what the data contains rather than what people believe it contains.
What if two candidates score about the same?
Break the tie on access and ownership rather than on value. Prefer the process whose systems can already be reached without a procurement conversation, whose rules have someone who can decide them, and whose output somebody looks at regularly, so an error is caught in days rather than at quarter end. Also prefer the one that does not require another team to change how they work, since that coordination cost is invisible in the scoring and often larger than the build.
Can a process be automated only partly?
Yes, and where Screen 4 finds real expertise at the decision point, partial is usually the right shape. The automation does the gathering: it assembles the record, pulls the related history, checks the values that can be checked mechanically, and presents the result for a decision. The person decides, and the automation writes the decision back so the audit trail stays in one place. Splitting on the decision point generally beats waiting for a version that handles every case, because that version tends to arrive late and still not handle every case.