By Artem Korsakov ·
Website acceptance should not be limited to viewing the homepage on a large monitor. For businesses, it is more important whether a person can find the needed service, how to contact you, and whether staff receive submissions. Verification should focus on the agreed result. Remembering all requests on payment day is too late.
Prepare the acceptance basis in advance
Take the approved scope of work, texts, and scenario rules. If agreements only state 'corporate website turnkey', clarify before project completion exactly what constitutes readiness. This reduces the likelihood of disputes over whether a remark is an error or a new order. How to align the scope of work during contractor selection is discussed in the article on comparing estimates.
Request a test environment or agree on a safe verification mode. Fake orders should not accidentally go into execution, and real personal data is unnecessary for standard form testing. The testing method depends on which external systems are connected.
Navigate the buyer's journey on a mobile device
Start from the page where visitors are planned to be directed.
- Open a service.
- Find terms and conditions.
- View photographs.
- Press the primary button.
Check whether a popup obscures important information and if it is possible to fill out the form without inconvenient screen zooming.
Do not only test correct input. Leave required fields empty, provide obviously incomplete contact details, and navigate back. The visitor should understand what needs correction and whether previously entered data is preserved.
Ensure submissions arrive
Send an agreed test submission and track its path to staff. Verify contact details, selected service, comments, timestamps, and source if data transmission is part of the project. A success message on the website does not confirm delivery to the sales system.
In a hypothetical supplier project, a visitor requests three items. The manager should receive not only the phone number but also names, article numbers, and quantities if such a scope is agreed. If an empty email arrives instead of the selection, the scenario remains incomplete despite a neat form.
Discuss re-sending and connection failures. A clear response is essential: what the client sees, where the submission remains, and who learns about the problem. Not every system offers identical recovery capabilities, so promised mechanisms must be tested.
Review editor functionality
Allow company staff to independently change prices, text, or photographs according to the contractor's instructions. This demonstrates whether a truly manageable site is handed over. Also verify that modified information appears on the public page.
Request demonstration of content saving and restoration within the agreed volume. There is no need to experiment with deleting working directories. For verification, a safe example and a clear procedure for handling staff errors are sufficient.
Document which actions the company performs independently and which require a specialist. The ability to change text does not mean the ability to safely restructure the entire site via an editor. Management limits must be clear upon handover. Costs remaining after launch are discussed in the article Website monthly costs.
Close remarks and project handover
Collect all remarks in a single document. For each, specify:
- page;
- action taken;
- expected result;
- actual behavior.
A screenshot helps but does not replace a description. Separate non-compliance with the agreed result from new requests arising during review.
Before closing the stage, obtain:
- agreed access rights;
- instructions;
- information about payments for external services;
- support contacts.
Ensure the company controls important accounts. Payment and acceptance procedures are determined by your agreements, so disputed points should be clarified before the payment deadline.
In the trike_dev project, readiness criteria are agreed upon together with the solution scope. Then final verification comes down to navigating working scenarios, and there will be no need to argue whether the site looks complete.