The acceptance rate is your product spec, so write it down
How often users take the AI's output instead of ignoring or redoing it is the number that tells you whether the feature works. Most teams never set a target for it before they build.
The acceptance rate is your product spec, so write it down
There is one number that tells you whether an AI feature is working, and it is not accuracy. It is the acceptance rate: how often a user takes the output the feature gave them instead of ignoring it, editing it, or doing the work themselves. A feature can be accurate and rejected. It can be technically right and still leave users reaching past it. If you did not set a target for acceptance before you built, you built without a spec.
Accuracy is what you measure, acceptance is what you sell
A messaging-startup engineering director drew the line cleanly. His team had a drafting feature that scored well on correctness, and users kept rewriting its output anyway. The drafts were right in fact and wrong for the moment. Wrong in tone, wrong in length, wrong for who they were going to. Accuracy said the feature worked. The acceptance rate said it did not, and the acceptance rate was the one that predicted whether anyone would keep using it.
Acceptance folds in everything a correctness score leaves out. Speed. Fit. Trust. Whether the output arrives in a form the user can act on without redoing it. It is the closest number you have to the actual job the feature is supposed to do.
A target you commit to before you build
A fintech CTO treated the acceptance rate as a spec, written down before engineering started. The team agreed on what share of outputs users should accept for the feature to be worth shipping, and that number became the bar. It changed the build. Knowing users needed to accept most drafts unedited pushed decisions about tone and format that a pure accuracy goal would have ignored.
The discipline is the same one that separates a feature with a definition of done from one that ships when someone gets tired. A committed acceptance target is falsifiable. You either hit it or you do not, and either answer is useful. A feature with no target can always be declared a success, which is the same as having no way to tell.
How to make acceptance a real spec
- Define acceptance precisely, the specific user action that counts as taking the output, decided before launch.
- Set the target before the build, so tone and format decisions serve a number instead of a hunch.
- Segment the rate by case type, because a healthy average can hide a slice where users reject almost everything.
- Watch edits, not just accepts, since an output accepted after heavy rewriting is a soft failure wearing a success.
How we approach it at Density Labs
In the AI Opportunity Assessment, our two-week fixed-scope engagement, defining the acceptance target is part of scoping the feature, not an afterthought once it is live. We help a team write down what user action counts as acceptance and what rate makes the feature worth building, so the number exists before the budget does. It turns a vague hope that people will use the thing into a spec you can hold the build to.
An accuracy score describes the model. The acceptance rate describes the product. Write the second one down before you build, and you will know what you are aiming at instead of learning it after launch.