“The site should bring leads” is a business goal, not a useful build acceptance test. A developer can control what the site shows and how the inquiry path works; they cannot control every visitor, market condition, ad, or sales follow-up. Write criteria for behaviors the provider can demonstrate, then measure commercial performance after launch.
State the visitor’s job
For each important page, identify whom it serves and what the visitor needs to decide. A service page might need to explain the service, intended customer, core deliverables, exclusions, proof, and next step. The exact copy remains subject to your factual approval. “Clear and persuasive” is too subjective alone; “page contains approved service scope, eligibility, and a visible inquiry action on desktop and mobile” is testable.
Choose one primary path. It might be a contact form, booking link, phone call, or quote request. Record where the action appears, where it sends the visitor, and who receives the resulting inquiry. If the service requires qualification, specify the fields and what the business will do with those answers.
Make the technical checks observable
A compact acceptance table could include: all agreed pages render at their final URLs; navigation reaches each important page; the main action is visible and usable on a narrow mobile screen; the form validates required fields and shows an accurate confirmation; a test inquiry arrives at the correct inbox or CRM; the recipient can reply; and consent and privacy links appear where required by the agreed scope.
If analytics are part of the project, identify the event and test that it fires only on a successful submission or completed booking. A button click is not automatically a lead. Record the analytics account owner and whether the provider is responsible for setup, verification, or ongoing reporting. A dashboard number alone does not prove that inquiries are valid or answered.
Keep commercial goals separate
Write the business hypothesis beside the build criteria: “We expect a clearer service page to improve qualified inquiries.” Then record baseline traffic and inquiries, define “qualified,” and choose a review period that fits your sales cycle. This allows you to learn after launch without turning an uncontrollable lead target into a defect claim.
Make sure the site does not promise services, prices, credentials, or response times the business has not approved. A working form connected to the wrong inbox, or a compelling page with a false claim, fails the business even if the design is attractive.
ARCHV’s website process calls for defined pages, functionality, responsibilities, and checks of agreed links, forms, and mobile layouts. Conversion performance depends on traffic, offer, market, and follow-up; ARCHV does not guarantee a lead count. Use the website estimate to describe the pages and behavior you need so the final scope can be priced. One public client review alleging a site missed a lead-generation purpose is an individual report, not a verified performance audit; the useful lesson is to specify what the inquiry path must do.