The scorecard you used was a guess
Before you built your first automation, you probably scored it — maybe informally, maybe with something like our readiness checklist: value on one side, feasibility on the other, a gut call on how clean the data was and how stable the process would be.
That scorecard was the best information you had at the time. It was also a guess.
You can't know how clear the rules are until someone tries to write them down for a machine. You can't know how clean the inputs are until a tool actually tries to read them. You can't know how stable a process is until you watch it for three months while automation runs underneath it.
Now you've built one. You have real answers to questions you used to estimate. The mistake most teams make at this point is filing the project as "done" and moving straight to the next item on the list — using the same guesses to rank it.
What building something actually teaches you
Five things get clearer the moment a process goes live, and they map directly onto the feasibility side of any readiness score:
Rules clarity. You find out how many exceptions actually exist — not the ones people remembered when you asked, but the ones that showed up in week three.
Input quality. You find out whether the "clean" data someone promised you was clean, or whether it needed a cleanup pass before anything could run on it.
System access. You find out whether the integration was as solid as the sales page claimed, or whether it needed a workaround, a middleware tool, or a manual bridge.
Stability. You find out whether the process actually held still, or whether someone changed a form field in month two and broke the automation quietly.
Ownership. You find out whether the person who was supposed to own this actually engaged with it, or whether you're the de facto owner now because nobody else stepped up.
None of this was visible from a spreadsheet. All of it is visible now.
Recalibrate the five feasibility questions
Before you touch your next candidate, go back to the one you just built and re-score it honestly, using what actually happened — not what you predicted.
Write both numbers down — your original guess and your corrected score — side by side. The gap between them is the useful part. It tells you what kind of thing you tend to underestimate or overestimate, which is exactly what you need to fix before you score candidate two, three, and four.
Don't stop at the number — update the ranking
Once you've corrected the score on your first win, run the same correction logic across your whole backlog, not just the one project. If input quality was consistently worse than you guessed, discount every remaining candidate that depends on similar data sources. If system access turned out easier than expected because an integration platform handled more than you thought, bump up feasibility on anything that touches the same systems.
This is also the moment to check whether your actual payoff matched your predicted value. The four-number scorecard is built for exactly this — it tells you whether the hours, errors, and delays you expected to remove actually went away, which is the other half of the correction. A project that scored high on paper but delivered a thin payoff should pull your value estimates down for similar work, the same way a feasibility miss pulls your feasibility estimates down.
Lock in what you learned, not just what you built
The automation itself needs to be locked in as a standard — that's a separate step, and we've covered it in detail: deciding whether the win should become an SOP, a template, or an automation depending on how repeatable and rule-based it is.
But the scoring correction deserves its own home too. Don't let it live in someone's head or a Slack thread. Write it down next to your original readiness sheet: what you guessed, what turned out to be true, and what that changes about how you'll score the next five candidates. This is a five-minute document, not a project. It just needs to exist somewhere your team will actually look before the next round of planning.
Feed the correction into your next planning cycle
This is the real point of an Improve stage: not just rolling out a fix wider, but making your next Plan stage sharper than your last one. If you're sequencing a backlog of tech fixes, this corrected scorecard is exactly the input that should shape your 90-day plan — so the next project you greenlight is ranked on evidence, not on the same optimism that got your first guess wrong.
The checklist got you to a reasonable first bet. The build told you the truth. The next round should be smarter because of it — and that's the whole point of running it as a cycle instead of a one-off project.