Seven questions on whether your data and your process can actually carry an automation. Pick the option that describes today, not the one you are working towards. Nothing is sent anywhere: the scorecard runs in your browser and resets when you reload the page.
Does the information you would automate on live in a system, or in people's heads?
Knowledge that only exists in someone's head has to be written down before software can use it. That work is usually the longest part of the project and it is rarely in the plan.
If you pulled the same customer, case or invoice out of two systems, would the two records match?
Almost every useful automation joins two sources. Where identifiers and formats disagree, the join drops or mismatches rows quietly, and the result looks like a model that is getting things wrong.
Is there a named person who decides what a field means and approves changes to it?
Without an owner, questions about what a field means have no answer, and corrections never land. A committee that meets occasionally is not an owner.
Do you know who can read this data today, and could you show it?
An automation reads data on behalf of someone. Where permissions are vague before the project, the automation inherits that vagueness and spreads it further than a person ever would.
Can you see what a record looked like six months ago?
Records that are overwritten in place leave you only with the present. Anything that learns from past cases, or that has to explain a decision after the fact, needs the old state as well as the new one.
Has the process you want to automate held still long enough to write down?
A process that is still being redesigned encodes badly. Automating it fixes today's version into software, and every later change to the work becomes a change request.
If the output were wrong next Tuesday, how would you find out?
Every automation is wrong sometimes. What separates a useful one from a liability is whether the error surfaces before it reaches a customer, a filing or a payment.
Overall Readiness
0 of 7 questions answered
Nothing answered yet.
Work through the seven questions and pick the option that describes today. Your score and what it means appear here once all seven are answered.
Data readiness is not a measure of how much data you hold. It is a measure of whether that data can be reached by something other than the person who created it, and whether what comes back can be trusted without asking that person.
Automation projects rarely stall on the model. They stall on the joins: two systems that describe the same customer differently, a field whose meaning nobody can settle, a spreadsheet that turns out to be the real system of record. Those are ordinary problems, and they are far cheaper to find before a project than during one.
The seven questions above are the ones worth asking first because each has a concrete answer. Where the data lives, whether it joins, who owns it, who can read it, whether the past is still there, whether the process holds still, and how a wrong answer would come to light. A team that can answer all seven has enough to plan with, whether or not they ever hire anyone to help.
Four that come up repeatedly, and what each looks like from the inside before anyone has named it.
The official system holds the record, and the work is really tracked in a spreadsheet on someone's machine. An automation built on the official system produces answers the team knows are wrong and cannot explain why.
Both systems know the same customer, under different identifiers, entered by different people. Matching them on names works in the demo and fails on duplicates, abbreviations and the second branch of the same company.
Finance and operations both use a status field and mean different things by it. Neither is wrong. Without someone empowered to settle the definition, an automation reading that field encodes one department's meaning and reports it to the other.
The output looks plausible, arrives on time and is never checked. The first sign of a problem is a customer, an auditor or a regulator, which is the most expensive place for it to appear.
In this order, because each step makes the next one cheaper.
None of this needs an AI project, a vendor or a budget line. It is the work that makes one possible, and it improves ordinary reporting long before anything is automated.
For the one process you care about most, decide which system holds the truth. Then find out where the work is really being tracked. The gap between those two answers is your first piece of work.
One named person who can settle what a field means and approve a change to it. Not a committee, and not the team that administers the server. Until this exists, disputes about definitions have nowhere to go.
Pick the entity you join on most, usually the customer or the case, and get a single identifier for it into every source that mentions it. This is dull, manual work and it removes a whole class of failure.
Before anything is automated, write down what a wrong output looks like, what threshold stops the run, and who responds. A check designed after launch is designed around the errors you have already found.
The scorecard is self-serve and stays that way. These are the parts of the site that pick up where it stops.