Business Process Automation Checklist: Before, During and After

A good automation checklist has three phases. Before: choose the process, name an owner, confirm data and access. During: build, test with real cases and set a manual fallback. After: monitor results, handle failures and review on a regular schedule. Skipping any phase is the usual reason automations quietly stop working.

How should you use this checklist?

Treat it as a set of questions to answer in writing, not boxes to tick quickly. If you cannot answer an item, that is useful information: it tells you what to resolve before you build. The checklist works for any business process, whether you build it yourself, use a no-code tool or work with a specialist.

Before: what should you settle first?

Process chosen. One process with a clear start and end, picked using a scoring method rather than instinct.

Process mapped. Steps, owners, inputs, outputs and exceptions written down, with one real run timed.

Goal and baseline. A plain statement of what should improve and today's figures, such as time per task or how often errors occur.

Named owner. One person accountable for the process and for signing off the result.

Rules written down. Each decision expressed as a clear rule, and a list of decisions that stay with a person.

Data ready. You know where each input lives, who maintains it and whether it is accurate and complete enough.

Access and permissions. The accounts, logins and permissions the automation needs, granted at the lowest level that works, with someone responsible for them.

Privacy and rules check. If personal data or a regulated activity is involved, confirm your obligations with a qualified adviser before building.

Manual fallback defined. You know what people will do if the automation is off or fails.

During: what should you do while building and testing?

Start small. Automate the standard path first and add exceptions one at a time.

Test with real cases. Use genuine past examples, including awkward ones, not only tidy samples.

Test the exceptions. Missing details, duplicates, late replies and unexpected formats should each be tried on purpose.

Add a human check at first. Have a person review outputs or approve actions for an initial period before it runs unattended.

Make failures visible. Decide how errors are logged and who is alerted when something goes wrong.

Test the fallback. Switch the automation off and confirm that people can still do the work by hand.

Record how it works. A short document on the trigger, steps, rules, accounts used and who to ask, so it does not depend on one person's memory.

Brief the people affected. Tell colleagues, and where relevant customers, what is changing and how to raise problems.

After: how do you keep it working?

Monitor from day one. Watch the first runs closely and check outputs against what you expected.

Compare with the baseline. Measure the same things you measured before: time, errors and handling effort.

Review failures. Every error or manual override is a clue to a missing rule or an unexpected input.

Watch for changes. New fields in a tool, a changed price list, an updated policy or a retired login can quietly break an automation.

Check access. Review who and what has permission, and remove accounts that are no longer needed.

Keep the fallback alive. Make sure people still remember how to do the task manually.

Set a review cadence. Agree a regular date to review performance and rules. How often depends on how critical the process is and how often it changes.

Know when to retire or rebuild it. If the process has changed substantially, update the map and the automation together.

What is the most commonly missed item?

Usually the manual fallback and the review cadence. Teams build the automation, see it work and move on. Months later a connection expires or a form changes, and nobody notices until a customer complains. A named owner, visible failures and a diary date for review prevent most of those surprises.

Erudience services related to this guide

Use cases related to this guide

Frequently asked questions

What should be on a business process automation checklist?

Before building: a chosen and mapped process, a named owner, written rules, ready data, access and a fallback. During: real-case testing and visible failures. After: monitoring, comparison with your baseline and scheduled reviews.

Who should own an automated process?

A named person who is accountable for the process itself, not only the tool. They should be able to confirm the results are correct and decide when to change or switch it off.

Why do I need a manual fallback?

Automations can fail because of expired connections, changed tools or unexpected data. A tested manual path means work continues while the problem is fixed.

How often should I review an automation?

It depends on how critical the process is and how often your tools and rules change. Set a regular review date when you launch it, and bring it forward whenever the process changes.

Does this checklist apply if I use a no-code tool?

Yes. The tool changes how you build it, not the need for an owner, tested exceptions, a fallback and monitoring.