TL;DR

  • For web development Vancouver projects, agree on acceptance criteria before approving development, not after reviewing the finished website.
  • Website acceptance testing should cover customer journeys, SEO, analytics, editing access and ownership.
  • Setsail Marketing suits businesses seeking a documented strategy before website delivery.
  • Separate defects from new requests so launch approval does not become an argument about scope.

Why this matters

You need a website that helps customers decide and act. A Vancouver contractor needs useful project enquiries; an online retailer needs customers to complete purchases without confusion. Neither outcome is established by approving a homepage design.

Acceptance criteria turn those business needs into observable checks. Start with a brief for your web development team in Vancouver, then attach the tests to the agreed scope.

For a 2026 website project, keep the approved criteria alongside your proposal and change log. That gives you a shared reference when someone says the site is ready but your team disagrees.

How do you set acceptance criteria for a Vancouver website build?

Write each criterion as a specific action, expected result and proof of completion. Name the person who can approve it. Replace subjective requirements such as easy to use with tasks your customers and staff can actually complete.

Use this sequence before development begins:

  1. Define the outcome. Identify what the customer needs to accomplish and what your business needs to receive.
  2. Describe the test. Record the starting page, actions, inputs and expected result.
  3. Assign approval. Name the business approver and the person responsible for resolving failures.
  4. Capture evidence. Record the result with screenshots, a recording or the relevant system record.
  5. Resolve failures. Fix and retest failed requirements, or document the client's explicit acceptance of a remaining issue.

A test passes because its expected result occurs, not because someone has marked a task complete. Keep the evidence with the criterion so approval survives changes in staff or project contacts.

Acceptance testing sequence from defining the outcome to resolving failures

Agree on the expected result before anyone starts collecting approval evidence.

Use a repeatable acceptance record

Every acceptance record should contain these fields:

  • Requirement: What the agreed scope says the website must do.
  • Customer context: Who uses it and what they are trying to accomplish.
  • Test conditions: Device, browser, account state and any required test data.
  • Expected result: The visible behaviour and any required downstream record.
  • Approval evidence: Where the result is recorded and who accepts it.

Avoid adding requirements during final testing without identifying them as changes. Acceptance testing checks the agreed build; it does not quietly rewrite it.

What should your acceptance criteria cover?

Your checklist needs both customer-facing behaviour and the work happening behind it. A confirmation message alone does not establish that your sales team received an enquiry.

The table below compares test areas, not agency packages. Include the areas your agreed website scope actually requires.

Enquiry journey

  • Best for: Service businesses seeking booked work
  • Example passing result: A valid submission reaches the agreed destination with the required details
  • What it does not prove: That the enquiry will become a qualified sale

Purchase journey

  • Best for: Ecommerce businesses taking orders
  • Example passing result: A test order records the correct items and agreed checkout details
  • What it does not prove: That customers will buy at a profitable acquisition cost

Content editing

  • Best for: Teams updating their own website
  • Example passing result: An authorised editor changes agreed content without developer assistance
  • What it does not prove: That every layout can be redesigned through the editor

Search continuity

  • Best for: Businesses replacing an existing website
  • Example passing result: Agreed replacement URLs and redirects behave as documented
  • What it does not prove: That rankings will remain unchanged

Measurement

  • Best for: Businesses assessing marketing results
  • Example passing result: Agreed events appear in the intended reporting system during testing
  • What it does not prove: That every visitor can be measured

Handover

  • Best for: Businesses taking operational control
  • Example passing result: Named owners receive agreed accounts, documentation and access
  • What it does not prove: That ongoing maintenance is included

Test the complete journey, not just the visible page. Each area has a different failure mode, so avoid treating a design approval as permission to skip functional testing.

Enquiry journeys: prove the lead reaches the right person

For a service business, start with the information needed to assess the work. A Vancouver renovation enquiry might need a project description and location; another business will need different fields. Make those decisions with the person who qualifies enquiries.

A useful acceptance statement is: when a visitor submits valid information, the website displays confirmation and delivers the agreed fields to the named destination. Specify that destination rather than writing send to the team.

Test invalid entries, missing required information and the confirmation experience as well. Agree on how you will identify test submissions so staff do not mistake them for genuine opportunities.

For your 2026 launch checklist, record who confirms receipt. A successful browser message is insufficient evidence when nothing arrives in the inbox or customer relationship management system.

Purchase journeys: test the order, not just the button

For an ecommerce build, define the intended checkout path and the store settings included in scope. Test the relationship between product selection, basket contents, checkout and the resulting order record.

Use the payment provider's documented testing process where available. If a live transaction is necessary, agree on its handling before running it; do not improvise with a customer's order.

Your acceptance record should identify the expected behaviour for failed payments, unavailable delivery destinations and interrupted checkout where those scenarios are relevant. Include customer notifications and the order information your fulfilment team needs.

Passing checkout tests confirms that the agreed purchasing process works under the tested conditions. It does not establish demand, product-market fit or future sales performance.

Search and measurement: preserve the information you need

For a replacement website, approve a map of existing URLs and their intended destinations. Test those redirects and confirm that pages intended for search are not accidentally blocked from indexing.

Also review page titles, headings, canonical instructions and the agreed sitemap. A canonical instruction identifies the preferred version of a page for search engines; it is not a promise that search engines will select it.

Define measurement around business actions. For a 2026 service website, that might mean an accepted enquiry submission rather than every button click. For a store, distinguish a checkout start from a completed purchase.

Agree on event names, destinations and how duplicate events will be checked. Record the relevant consent conditions during testing rather than assuming all visits generate the same reporting data.

Technical acceptance is not a ranking or revenue guarantee. Keep implementation checks separate from the commercial results you will evaluate after launch.

Editing and handover: prove your team can operate the site

Ask an intended staff user to complete an agreed editing task using their assigned permissions. The test should show that they can update the relevant content and publish it without gaining unnecessary administrative access.

Handover should also identify the owners of the domain, hosting, website platform, analytics and connected business accounts. Record how access is granted and which third-party subscriptions remain your responsibility.

Request documentation for backups, restoration, updates and support responsibilities where those items are included. A backup existing is different from an agreed restoration process being understood.

Do not assume that everything shown during development transfers automatically. Put asset ownership, licences, account access and exclusions in the agreement before approving delivery.

Why acceptance criteria vary between website builds

The right tests follow the customer journey and the agreed scope. More pages do not automatically mean a more demanding acceptance process; a short website with a critical integration can require careful end-to-end testing.

  • Business action: An enquiry, order and appointment request require different proof of completion.
  • Existing website history: A replacement needs decisions about old URLs and content that a new site does not inherit.
  • Connected systems: Email, customer databases and fulfilment tools add destinations that need checking.
  • Editing responsibilities: Staff publishing regularly need different permissions and training from a team that outsources changes.
  • Customer context: Mobile browsing, location questions and purchasing concerns affect the journeys worth testing.
  • Delivery boundaries: Copywriting, photography, migration and maintenance need explicit inclusion or exclusion.

For a 2026 statement of work, write these differences into the acceptance schedule. A generic checklist is a starting point, not an agreed description of your project.

How do you decide which failures stop launch?

Stop launch when a failed requirement prevents an agreed essential customer action, exposes information or leaves the business without required control. Define that threshold before the final review, then assign each issue an owner and a retest requirement.

A broken enquiry destination is different from a minor spacing inconsistency. Both deserve a recorded decision, but they do not carry the same business consequence.

Separate a defect from a change request. A defect fails an agreed requirement; a change request adds or alters one. Keep both visible so disagreements do not disappear inside an informal message thread.

Do not approve an unresolved issue with a vague promise to revisit it. Record the impact, decision-maker, responsible person and agreed resolution arrangements.

Who should approve the finished website?

The business owner should appoint a final approver, with evidence from the people responsible for sales, operations and content. Your developer confirms implementation; your team confirms that the agreed business workflow works.

Keep a single acceptance register rather than collecting conflicting approvals across email and messaging tools. Each entry should show its status, evidence and outstanding decision.

Setsail Marketing's website work is best suited to businesses that want a documented strategy before delivery. Its in-house team plans and delivers the work, but your agreement still needs project-specific acceptance criteria and clear exclusions.

What happens after launch approval?

Repeat essential journey checks on the live website after launch. The live domain, connected accounts and production settings need their own confirmation; approval of a staging site does not prove the live environment behaves identically.

Keep website defects separate from commercial performance reviews. An accepted website can still need changes when real enquiries show that customers misunderstand an offer or abandon a decision.

For 2026 reporting, connect agreed business outcomes to the original plan. Setsail Marketing's strategy-first approach separates the documented plan from ongoing delivery; projected returns and payback remain estimates, not guarantees.

FAQ

What are acceptance criteria for a website build?

Website acceptance criteria are agreed pass-or-fail conditions used to approve delivery. Each criterion identifies an expected result, test conditions, evidence and an approver.

When should I agree on website acceptance criteria?

Agree on website acceptance criteria before development starts. Update them through documented scope changes rather than introducing new requirements during final approval.

Can I approve the design before testing the website?

Yes, design approval can happen before functional testing, but it does not replace it. Enquiries, purchases, integrations and account access need their own acceptance evidence.

Should a Vancouver website build include mobile testing?

A Vancouver website build should include agreed mobile test conditions for its essential customer journeys. Name the devices or browsers to be checked instead of accepting a vague promise that the site is mobile-friendly.

Does passing SEO acceptance tests guarantee rankings?

No, passing SEO acceptance tests does not guarantee rankings. These tests confirm agreed technical implementation, not how search engines will rank the website.

Is website maintenance included after acceptance?

Website maintenance is included only when the agreement says it is. Separate handover requirements, defect-resolution terms and ongoing maintenance responsibilities before signing off.

How do I start a website conversation with Setsail Marketing?

Book a Growth Strategy call with Setsail Marketing. The call is free, lasts 30 minutes and carries no commitment; a subsequent paid Growth Strategy is a separate engagement.

One last thing

Ask your team to demonstrate the website using the permissions they will actually have after handover. An administrator completing a task does not prove your content editor or sales coordinator can do it.

If your project needs a clearer plan, Book a Growth Strategy call with Setsail Marketing. The call is free, lasts 30 minutes and has no commitment. If there is a fit, the separate paid Growth Strategy includes research, channel priorities and a fixed 90-day plan; you keep the strategy whether or not you continue.

Explore the service, scope and client work