Software acceptance criteria: how buyers write tests that end arguments

Contents

• Why should the buyer write the criteria?
• What does a good acceptance criterion look like?
• Which kinds of criteria does a milestone need?
• How do you write the criteria, step by step?
• Worked scenario: accepting a quotation-request milestone
• What do Netbase records show about milestones and acceptance?
• Which questions should you ask a supplier about acceptance?
• Which acceptance criteria cause rework?
• How this guide is sourced and where it stops
• Common questions
• Bring your first criteria

Why should the buyer write the criteria?

The person who accepts the work is the person who knows what "done" means for the business. When a supplier writes the criteria alone, they tend to describe what it plans to build; when the buyer writes them, they describe what the business needs to be true. The supplier should still review every criterion for testability and cost, but the first draft belongs to the buyer's product or process owner.

Buyer-written criteria also settle the most common acceptance argument before it starts. A defect is work that fails an agreed criterion; a new wish is a change. Without written criteria, every disappointment at review time becomes a negotiation about which of the two it is.

This page is the buyer's authoring method. The supplier's side of acceptance, with internal verification, review and the three recorded outcomes, is described on the project delivery page.

What does a good acceptance criterion look like?

OutsourcingVN is operated by Netbase JSC, which delivers software against criteria like these, so read the template as one used by a supplier as well as recommended to buyers. It suits any supplier. Each criterion is one row with seven fields.

The Given, When, Then shape comes from behaviour-driven development; Cucumber's Gherkin reference describes Given as the initial context, When as the event and Then as the expected outcome compared with the actual one. You do not need the tooling to use the shape. You need the discipline of one situation, one action and one checkable result.

Which kinds of criteria does a milestone need?

A feature-only list misses most of what makes a release acceptable. Draft criteria in five families and check that each milestone has at least one row where it matters:

• Behaviour. "Given an unverified phone number, when the user requests a code, then an OTP arrives and expires after the agreed period."
• Data. "Given the supplied export of 2,000 customer records, when the import runs, then every record appears with its email and tier, and rejected rows are listed in a report."
• Content and language. "Given the French interface, when any checkout page loads, then no English strings remain, using the supplied glossary."
• Non-functional. "Given the checkout pages, when checked against WCAG 2.2 level AA, then no failures remain on the agreed success criteria." Name the browsers, devices and load you care about in the same way.
• Operational. "Given a failed payment callback, when it occurs, then the admin sees the order flagged and an alert reaches the named mailbox."

For AI features such as classification or a chatbot, a single example is not a test. Criteria there describe a test set, a threshold agreed in advance and a human-review rule; the AI workflow evaluation guide covers how to build that set.

Worked scenario: accepting a quotation-request milestone

A packaging distributor commissions a quotation-request form feeding its sales inbox and CRM. The operations manager writes nine criteria: four behaviour rows, two data rows, one content row, one accessibility row and one operational row for failed CRM sync.

At review, seven rows pass on the staging recording. One behaviour row fails: a request with an attached file over the limit shows a generic error instead of the agreed message. That is a defect against AC-04 and goes back to the supplier. The operations manager also asks for a new "urgent" checkbox. There is no criterion for it, so it is logged as a change request with its own estimate, and the milestone is accepted once AC-04 passes. Nobody argues about whether the checkbox was "implied".

What do Netbase records show about milestones and acceptance?

Netbase's delivery lifecycle includes agile execution with outcome-based milestones, and delivery runs with weekly reviews and a named project manager, which gives buyers a regular point to check work against criteria rather than a single test at the end.

For a founder who is not named, Netbase delivered a bilingual English and Nepali classifieds platform in six milestones over four months with training and six months of support. The platform used AI-powered content filtering that detects and flags offensive content into an admin moderation dashboard. The classifieds platform record shows a scope large enough that acceptance only works milestone by milestone.

For a client who is not named, Netbase built a WhatsApp Business AI chatbot with intent and conversation-flow handling, an LLM API and CRM synchronisation, delivered in milestones from design and prototype to documentation, knowledge transfer and 30 days of support over 4-8 weeks. The chatbot and CRM record is a useful model for splitting acceptance between a prototype and the documented, supported release.

Which questions should you ask a supplier about acceptance?

• Will you review my criteria for testability before we sign? A supplier that accepts every criterion unread will dispute them later.
• Which environment will I accept on, and with what data? Staging with realistic data beats a demo on a developer's machine.
• What evidence will you hand over with each milestone? Recordings, test reports and release notes.
• How do you tell a defect from a change? Expect an answer that points to the written criteria.
• How long is the review window, and what happens if I miss it? Agree it in writing.
• What is re-tested when a defect is fixed? Fixes should not quietly break rows that already passed.

Which acceptance criteria cause rework?

• Adjectives instead of results. "Fast", "intuitive" and "modern" cannot pass or fail. Replace them with a measurable condition or remove them.
• Criteria written after the build. They describe what was built, not what was needed.
• One criterion covering a whole feature. Split it until each row has one action.
• Missing data. A test that depends on "typical orders" fails the day real orders arrive.
• No named reviewer. Five people commenting means nobody accepting.
• Release readiness confused with acceptance. A milestone can pass its criteria and still not be ready to launch; run the release readiness checklist before go-live.

How this guide is sourced and where it stops

This guide combines Cucumber's Gherkin reference and the W3C WCAG 2.2 recommendation with Netbase records approved in the OutsourcingVN claim register: the delivery lifecycle, weekly reviews, the classifieds platform and the WhatsApp chatbot. The methodology explains how records are sourced. Those records describe milestone delivery and scope; they include no measured rework rate or acceptance statistic, and this page claims none. The quotation-request scenario is illustrative, not a client project.

Bring your first criteria

A draft list of criteria, even rough, makes a proposal far more precise. Custom Product Engineering builds against milestones accepted this way.

OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project with your brief and a few sample criteria, and a person will reply with the questions that would make them testable.

Related services and solutions