A readiness checklist before you automate anything
Before automating anything, confirm eight things: the process is written down and agreed, you have measured the current state, the data is clean enough to build on, you have API access to every system involved, one named person owns the outcome, the failure behaviour is defined, you know what the system may not decide alone, and you have agreed who maintains it afterwards. Projects that skip these do not fail during the build — they fail three months later.
Key points
- Write the process down and get two people to agree on it.
- Capture the before number, or you cannot prove the after.
- Confirm API access early; it causes more delay than build work.
- Name one owner for the outcome, not a department.
- Define failure behaviour before success behaviour.
The checklist
Each item takes well under an hour and prevents a category of failure that is expensive to fix later.
- The process is written down, and two people who do it agree the description is accurate.
- The current state is measured: response time, volume, drop-off, whatever the project is meant to improve.
- The data the automation will touch has been looked at — duplicates, inconsistent fields and gaps identified.
- API or integration access to every system involved has been confirmed, not assumed.
- One named person owns the outcome. Not a team, a person.
- Failure behaviour is defined: what alerts, to whom, how fast, and what retries safely.
- The decisions the system may not make alone are written down explicitly.
- Who maintains it after handover is agreed, along with what they can change without a developer.
The two that get skipped most
Measurement and system access. Measurement gets skipped because it feels like delay, and then there is no way to demonstrate the result or justify the next project.
Access gets assumed rather than confirmed, and then a two-week build becomes a six-week one while somebody finds out whether the booking system has an API and who holds the credentials.
If you cannot complete the list
An incomplete checklist is not a reason to abandon the project; it is a map of what to do first. A process nobody can describe needs describing. Dirty data needs a cleanup pass. No owner needs an owner.
That preparatory work is usually cheaper than the automation itself, and it is work you would have had to do eventually anyway.
Frequently asked questions
- What do we need before starting an automation project?
- A written and agreed process description, a baseline measurement, a look at the data quality, confirmed API access to every system, one named owner, defined failure behaviour, explicit limits on what the system may decide, and agreement on who maintains it afterwards.
- What causes the most delay in automation projects?
- Waiting on system access. Teams assume an API exists and that someone has the credentials, and discovering otherwise mid-project turns a two-week build into a much longer one.
- Why measure before automating?
- Without a baseline you cannot demonstrate that the project worked, which turns funding the next one into an argument instead of a decision. Capturing the before number takes about an hour.
Related capabilities
Keep reading
Want this built for your operation?
DAMASAVERO builds AI automation and business systems from Dubai, for clients across the UAE and worldwide.