Questions to ask before automating manual processes

Before automating, confirm five facts: a binary 'done' condition for each item with exact fields and approvals; input volume and variability; named exception owners and their authority; which systems and access methods you must connect and the data quality; and the monitoring, rollback and audit steps you will run post-launch.

Questions to ask before automating a manual process

Answer the five operational questions that decide success before you build: what exact condition counts as done for every item; how many items and how variable the inputs are; who resolves each exception and their authority; which systems you must connect and how data flows; and what monitoring and rollback you will run after launch.

Run this checklist early to avoid two common failures: an automation nobody trusts, or a brittle pipeline that breaks on the first uncommon case.

What does done look like for every item

For every case the automation touches, write a binary acceptance checklist that names the exact fields, the target systems, the record identifiers and the approval flag that prove completion, and get the process owner to sign it off in writing.

Treat the checklist like a QA script: exact column names if you use Google Sheets, API field names if you call HubSpot or Tally, and clear timing or SLA constraints. Developers and testers will use this to decide whether to proceed.

• List fields, target systems and the record identifier that prove completion
• Get explicit owner sign-off against the checklist

How many items and how variable are the inputs

Count how many cases a human processes each week and measure variability over a month; volume and variance determine whether rules, RPA, or an AI model is appropriate and whether a short pilot will show representative behaviour.

Export a representative sample (one month's records or 100 rows) and mark which fields are consistently present, which are often blank, and how many manual corrections occur per item. If inputs vary widely, normalise and validate before automating decisions.

• Export a real sample and note missing fields and manual corrections
• Use human-touch counts and variance to choose rules versus models

Which systems and data must be connected

List every system the automation must read or write, the access method (API, scheduled export, UI or manual copy) and the owner who can grant access, and record which fields each access method exposes.

If an API does not expose needed fields, plan an alternate path: a scheduled CSV export or middleware such as n8n. Put these decisions in a single table and get sign-off; missing connectors are the most common schedule risk.

• For each system, name the access method and the owner who can grant it
• Flag fields not exposed by APIs and plan a middleware or export

Who resolves exceptions and who has final authority

For each exception type, name the human who receives the alert, the channel (email, Slack, WhatsApp) and the precise authority they hold — correct data, approve payment, or escalate — plus an SLA for response.

Automation without named owners erodes trust: untriaged failures pile up, inboxes clog and people revert to manual work. Put exception routing in the process doc and test notifications during the pilot.

• List exception types, recipients and notification channels
• Define recipient authority and a concrete SLA for each

When to route to a human versus auto-approve

Auto-approve only when a numeric confidence threshold is met and the action is reversible; route everything else to a named human with a short SLA so exceptions clear quickly and trust stays high.

Use simple rules where possible: exact invoice numbers, presence of a PO, and amounts within tolerance can be auto-processed. Always keep an audit trail and an undo path so reversibility is cheap.

How to pilot and what a kill criterion looks like

Run a time-boxed pilot on a clear slice (by channel, product or geography), write the scope, the success metric and a kill criterion up front, and stop if the kill criterion triggers within the time box.

Document the pilot scope, the single success metric you will measure and the kill rule (for example, persistent error rate above threshold for consecutive days). Hold a short formal review at the pilot's end where the owner accepts, adjusts, or cancels the project.

• Pilot a narrow slice with a written success metric
• Define a kill criterion and schedule an end-of-pilot decision

What to monitor, log and how to rollback

Monitor three pillars: throughput (items processed), exception rate, and a golden outcome check that compares processed items to the source of truth; prepare a rollback that can be executed in minutes and a reprocess path for affected records.

Make monitoring visible to non-developers: a simple dashboard and weekly sample audits. Log the original input, the automation decision and the reviewer for every item so you can identify, reverse and reprocess errors quickly.

• Track throughput, exception rate and a golden outcome check
• Log inputs, decisions and reviewers and have a tested rollback

How this fails in practice and the exact sequence

The failure sequence repeats: incomplete acceptance checklist, untested connector, pilot proceeds, an unexpected format appears, exceptions spike, inboxes fill and the owner disables the automation. Each step is avoidable by following the checklist above.

When a connector accepts a changed CSV format without validation, parsers can populate the wrong field and downstream systems act on bad data. The fix sequence is: disable the pipeline, identify affected records from logs, reverse downstream actions, patch the parser and re-run a controlled reprocess.

• Missing acceptance checklist leads to silent failures
• Connector or format changes cause data corruption unless validated

What to do differently at scale

At scale, separate pipelines by channel, add schema validation and introduce staged approvals and change control so a single undetected issue doesn't multiply across thousands of items.

Use versioned schemas, automated connector tests and a staging mirror of live data for rule changes. Treat automation like software: deploy changes to staging, run tests, then promote rules to production with a change log.

• Segment pipelines, add schema validation and staging
• Introduce simple change control, versioning and automated tests

Concrete next step you can take this week

Run a fifteen-minute audit: export 30–90 days or 100+ cases into a Google Sheet, write the done checklist for one common case, and list the systems that must be connected; that note will tell you whether to pilot or fix data first.

Work with the process owner and add three columns to the sheet: done_check_passed, exception_type and time_taken. Fill these for 30 rows — if you cannot because data is missing, your first task is to improve input quality before automating. If you want help, see our internal links below.