Optified - "That's not what I asked for" -- and how to make sure you never say it again

The gap between "I asked for a reporting dashboard" and what you got

You asked for a dashboard showing overdue jobs. You got a dashboard showing overdue jobs — sorted by date created, when what you actually needed was sorted by how overdue they are, with the highest-value jobs first. Technically, the request was met. Practically, it's useless, and now there's a rebuild, a delay, and a slightly awkward conversation about why "reporting dashboard" wasn't specific enough.

This isn't a communication failure between you and your developer or implementer. It's a missing step that has a name in business analysis: acceptance criteria — the specific, checkable conditions that define when a piece of work is actually, provably done.

The difference between a request and a criterion

A request describes what you want in general terms. A request is not testable — two reasonable people can read it and picture different outcomes. An acceptance criterion removes that gap:

• Request: "A dashboard showing overdue jobs."
  Criterion: "The dashboard shows all jobs more than 3 days overdue, sorted by job value (highest first), refreshed at least every hour, visible to office staff without needing admin access."
• Request: "Make quoting faster."
  Criterion: "A standard quote for an existing customer can be created and sent in under 5 minutes, without needing to re-enter customer details that already exist in the system."

Notice what changed: the second version can be tested. Either it took under 5 minutes or it didn't. Either the dashboard sorts by value or it doesn't. There's no room for "well, technically."

Why this is worth doing even for small changes

Owners often reserve this level of specificity for big projects and skip it for smaller requests — "just add a field," "just change the report." But small requests are exactly where vague acceptance criteria cost the most relative to the size of the job: a half-day task becomes two days of back-and-forth because "just add a field" meant something different to the person who asked than the person who built it.

Five minutes writing three or four specific, checkable sentences before work starts routinely saves far more than five minutes of rework after.

How to actually do this without turning into a process person

You don't need a template or a meeting. Before you hand off any system change, answer one question in writing: "how will I know, specifically, that this is finished correctly?" If your answer is vague enough that a reasonable person could disagree with you about whether it's done, it's not a criterion yet — it's still a wish.

This discipline is baked into how Optified's Value Discovery defines every deliverable — not "improved reporting," but specific, checkable outcomes you can hold us to, before the work starts.

Want this measured for your business?

Book a free 20-minute Value Scan and we'll tell you whether there is a commercially meaningful opportunity in the process that hurts most. If there isn't, we'll say so.

Not ready to talk? Estimate what one process costs you a year with our free calculator.