A website is not automatically ready because every page is filled and the design is approved. Acceptance asks whether visitors and administrators can do what was agreed. Make that test concrete before the final project week. This prevents discussions mixing taste, missing content and actual blockers.
From wish to verifiable scenario
“The contact form must work well” is too broad an agreement. Describe who performs the action, with which data and what result must be visible. For example: a new visitor selects a service, submits a question and sees an acknowledgement; the assigned employee receives enough context to handle it.
Include an imperfect attempt too. Leave a mandatory field empty, use a long name or visit a deep URL directly. These are normal situations. The website must clarify how to continue and must not lose previously entered information without reason.
For a fictional consultancy website, the core route consists of service selection, explanation and enquiry. An error in that route may block launch. A secondary photograph still awaiting replacement has a different impact. Discuss that distinction with the client beforehand.
Include management in the handover
Have an editor independently change existing text, build a new page and check publication. Use content that differs from the easiest example. If every longer heading needs technical help, management may not be sufficiently developed. This too can form part of the agreed delivery.
Also check that ownership and working agreements are available. Who receives notifications, who can fix an error and which components need maintenance? For delivering a website the visible frontend is not the whole task. The organisation must also be able to use the result.
Record discrepancies with their impact
A useful acceptance list records the page, action performed, observed behaviour and desired outcome for each finding. Add a responsible person and decision. Avoid isolated comments such as “this does not feel right” without explaining which expectation is unmet.
- Blocker: an agreed main task cannot be completed.
- Significant discrepancy: the task succeeds, but with confusion or a cumbersome detour.
- Improvement: the agreed behaviour is present but may be refined later.
This classification is a working agreement, not a universal standard. Decide together which impact is decisive in this project. A missing download may be supplementary in one project and the main deliverable in another.
Make the launch decision explicit
Review open points with the decision-maker. Record what is resolved, what is deliberately postponed and who follows up. Approval must reference the reviewed version and known exceptions. Prevent different content or a different technical combination from being published unnoticed afterwards.
Plan a brief check after the actual transition too. Forms, addresses and external references may behave differently in the public environment from preparation. For complex features, allow enough time to discuss the required acceptance scenarios. A good handover does not promise that no error will ever occur again. It provides demonstrable insight into what was checked, which tasks work and which follow-up agreements apply.