The automation readiness checklist

Twenty-four questions to answer before you brief anyone. Work through them and one of two things happens: you arrive at a scoping call with a far better project and get a far better quote, or you discover you are not ready and save yourself a five-figure mistake.

No email required and nothing to download. Copy the questions into a document and answer them honestly — the ones you cannot answer are more informative than the ones you can.

The process itself — 6 questions

1. Can you describe it step by step, including who does each step? Not the version in the handbook. If nobody can produce this, that is your first task, and it is worth doing regardless of whether you automate.
2. How often does it run? Per day, per week, per month. Frequency is the single biggest driver of whether a build pays back. Weekly or more is the threshold where the arithmetic usually works.
3. How long does one run take, measured rather than estimated? Time it three times. People underestimate familiar tasks by a wide margin, and this number is the denominator of your entire business case.
4. Who does it, and what does an hour of their time cost fully loaded? Salary plus employment costs divided by working hours. For a US administrator, $35 to $55 is a reasonable range.
5. Has it changed in the last six months? If it has changed twice, it will change again during the build. Consider waiting.
6. What happens today when it is not done — and how quickly does anyone notice? This tells you the real cost of failure, which sets how much error handling the build needs.

Exceptions — 4 questions

The highest-value section. Exception logic is routinely the majority of a build and almost none of the initial estimate. See the exception problem for why.

7. Of the last fifty times this ran, how many went through the standard path exactly? Count real cases, do not estimate. Under 80% means exceptions are a major part of the project.
8. What goes wrong when the usual person is on holiday? The highest-yield question on this list. Whatever their cover gets wrong is precisely what is undocumented.
9. Which customers, suppliers or job types are handled differently, and why? Ask why for each one. A meaningful share of exceptions cannot survive the question and can simply be removed.
10. Is there a shadow spreadsheet? A personal tracker maintained alongside the official system. Its columns are a precise map of what your systems do not capture.

Systems and access — 6 questions

This section is where projects actually stall. Sorting it before the build starts routinely saves a week.

11. Which systems does the process touch, by name and edition? Edition matters: API access is often gated behind a higher tier than you are on.
12. Does each one have an API, and is it included in your plan? Check before quoting. Discovering mid-build that API access costs another $200 a month is an avoidable surprise.
13. Who administers each system? Name a person for each. "IT" is not an answer, and finding out later costs days.
14. Can you create a dedicated service account with the permissions needed? Not a personal login. A revocable, auditable account belonging to the business.
15. Is there a vendor security review or procurement process? If so, start it now. It is frequently the long pole and nobody remembers it exists until week two.
16. Is any of these systems being replaced in the next twelve months? If yes, automate around it or wait. Building against a system you are retiring is money set on fire.

Data quality — 4 questions

17. Are there duplicate records in the systems involved? Search for your three biggest customers by name and see how many results come back. This is a thirty-second test that predicts a lot.
18. Are the fields the automation depends on filled in consistently? A required field that is blank on 30% of records is not a required field, and any logic depending on it will misbehave.
19. Is there one source of truth for each piece of information? If the customer's address exists in three systems with three values, decide which one wins before anything is built.
20. How is data entered today — typed, imported, or synced? Manually typed data is inconsistent data. That is not a criticism, it is a design input.

People and ownership — 4 questions

21. Who can approve scope and sign off the cutover? One named person who can decide within a day, without convening a meeting. Projects move at the speed of this person's calendar.
22. Who will own the automation after handover? Not "the ops team." A person, who knows this is coming, and who will receive the alerts.
23. Have you told the people who currently do this work? They hold the knowledge the project depends on. If they first hear about it when someone asks to shadow them, you will get a guarded and incomplete picture — and reasonably so.
24. What happens to the recovered hours? Have an answer before you start. "We will work that out later" is how automation projects generate quiet resistance from the people best placed to make them fail.

Reading your answers

There is no score. But three patterns are worth naming.

You are ready if the process runs at least weekly, you measured the time, fewer than a handful of meaningful exceptions exist or you have listed them, every system has an API and a named administrator, data is broadly clean, and one person can make decisions. Get quotes.

You are nearly ready if most of that holds but the exceptions are undocumented or the data is questionable. This is the most common position, and it is exactly what an audit is for — the discovery is the deliverable.

You are not ready if the process is still changing, nobody can describe it, or the systems involved are being replaced. Wait. Everything you build now gets rebuilt, and you will have paid twice for the same understanding.

The one calculation to do

With questions 2, 3 and 4 answered you can build the case yourself.

Monthly hours = runs per month × minutes per run ÷ 60.
Monthly saving = monthly hours × loaded hourly cost.
Payback in months = build cost ÷ monthly saving.

Worked: 300 runs a month at 9 minutes each is 45 hours. At $45 an hour that is $2,025 a month. Against a $10,000 build, payback is about five months. That is a straightforward yes.

Change it to 40 runs a month at 9 minutes: 6 hours, $270 a month, payback just over three years. That is a no on labour alone — and now the honest question is whether the second-order benefits justify it anyway. Faster response times, errors that stop happening, work that continues when someone is away. Sometimes they do. Make that argument explicitly rather than hiding it in an optimistic hours estimate.

Our build ranges are on the pricing page, and what twelve common automations cost gives per-automation figures you can put straight into the calculation above.