Test one buyer task against a named launch candidate. Start from the visitor's entry page, check whether the offer and its limits make sense, follow the applicable evidence, and reach the existing contact route with a usable question. Record the expected and actual result at each step. Return failures to an owner, repeat the affected task after repair, and keep any untested receiving or follow-up step visible in the acceptance decision.
Our B2B inquiry-site guide already recommends testing the whole route, including receipt, ownership and mobile use. The script here turns that principle into a before-launch record: one task, observable criteria, linked issues and a retest history. The acceptance owner can use that record to see which task outcomes were checked.
Which buyer task will this run prove?
Choose a visitor with a specific question and enough starting context to attempt the task. Write what they need to decide and what should be possible at the end. “Check the website” is too broad to produce a useful pass or failure. A task such as finding the preparation requirements for an assessment can be observed and repeated.
The worked example uses Site F, a fictional B2B inquiry website, and P1, a fictional offer. An equipment evaluator has a drawing and wants to prepare an assessment question. Assume the applicable preparation note, N1, requires the P1 reference, intended use and drawing revision. An older note, N0, omits the drawing-revision requirement.
These requirements, pages, test results R1 and R2, and issue F01 are authored teaching records. They are not supplier policies, captured browser sessions, customer results or defects found on GRC. P1 has no established performance or compatibility. The test asks whether the evaluator can prepare the question; technical suitability still needs assessment.
What should the test record before it starts?
Record the candidate version, entry URL, source versions, date and tester. Add the market, language, device or viewport, browser and access state relevant to the task. Specify the outcome and any actions the tester is allowed to perform. A later reviewer should be able to reproduce the run without relying on the original tester's memory.
Shopify supports previewing an unpublished theme for feedback before launch. Record which candidate and visitor-access context the test covers. A preview result does not establish what a visitor currently gets at the main domain. After a separately authorized launch, recheck the intended public path in its actual access state.
The local, draft and public-result guide owns that evidence distinction. Apply it to this task without treating a local mockup, a theme preview and the public site as interchangeable. This buyer check also has a different purpose from the merchant editing handover, which tests whether the team can maintain the delivered controls.
Can the visitor understand the offer and find its evidence?
Give the tester the starting question and let them navigate without coaching. Ask them to identify the relevant offer, what it covers, what remains conditional and the next useful action. If they need the designer to reveal a hidden route or explain an absent requirement, record that dependency. Do not count the coached workaround as a successful visitor task.
Follow the link that promises supporting information and inspect its answer. In the example, the preparation link opens N0 successfully. That proves reachability, while the agreed criterion requires N1 and its drawing-revision item. The evaluator still cannot prepare the agreed request from those instructions. Log the task failure even if the destination looks polished.
Our page-to-inquiry link guide already separates link promises from answer coverage. Google's link guidance supports descriptive text relevant to the destination. Here, compare that destination with the actual task criterion as well. A clear label and an opening URL cannot supply a missing requirement.
Scroll sideways to compare the opening page with the required task evidence.
What does a complete buyer-task script look like?
Give each step an action and an observable expected result. Then add what actually happened, its evidence locator and a pass, fail or not-tested state. Keep the issue ID beside the failed step. A collection of screenshots can support the record, but it needs the task, candidate and interpretation to explain what each image proves.
The following table records two authored runs. R1 uses candidate C1 and stops when the preparation evidence is wrong. R2 uses repair candidate C2 and repeats the affected path. Neither run includes an actual message or receiving record. Every result in the table belongs to the fictional exercise.
Scroll inside the table to compare the expected result with the authored first run and retest. Step IDs repeat in every column.
| Buyer action | Expected result | R1 / authored initial run | R2 / authored retest |
|---|---|---|---|
| J1 / Enter from the agreed article or direct offer path. | J1 / Recognize P1 and the assessment question; record entry URL and candidate. | J1 / PASS in authored R1 / correct offer and task found. | J1 / PASS in authored R2 / same entry and candidate C2 recorded. |
| J2 / Read fit, conditions and the next decision. | J2 / Find what the offer covers and what requires assessment; no assumed compatibility. | J2 / PASS in authored R1 / uncertainty is visible. | J2 / PASS in authored R2 / conditions still visible after repair. |
| J3 / Open the preparation evidence. | J3 / Applicable N1 asks for reference, intended use and drawing revision. | J3 / FAIL / N0 opens but omits drawing revision. Issue F01 blocks this task. | J3 / PASS in authored R2 / N1 and its required items checked; F01 repair verified for this scope. |
| J4 / Reach the existing contact route and prepare the question. | J4 / Find channel instructions and enough context to ask; inspect actual message separately. | J4 / NOT TESTED / stopped at unresolved J3. | J4 / PASS for browser preparation only / route and instructions found. Composition and sending untested. |
| J5 / Verify usable receipt and a next owner in an agreed test. | J5 / An explicitly approved, labelled test reaches its intended recipient with usable context and an assigned next step. | J5 / NOT TESTED / no message sent. | J5 / NOT TESTED / no receiving record. End-to-end acceptance remains incomplete. |
J1 and J2 establish orientation and the visible assessment boundary. J3 checks the applicable preparation evidence. J4 covers the browser contact route and preparation only. J5 requires receiving and next-owner evidence. A pass at J4 therefore cannot fill J5's empty result, even after the note is corrected.
How do you test contact without overstating delivery?
Use the channel the business actually offers. Check whether the visitor can find its instructions and prepare the relevant question. Then distinguish message composition, sending, receipt and the next person's ability to act. Our contact-context guide covers what must survive that handoff; this launch script records the stage reached and its remaining evidence.
For a real receiving test, agree on the specific action, recipient and harmless labelled test details before sending. Check what arrived, whether the intended offer and question remain understandable, and who owns the next clarification. Record that outcome separately from opening the contact destination. If no receiving test was authorized or observed, leave that step not tested.
GRC's current Contact page offers WeChat as the primary route and email as an alternative. A website check can inspect those instructions without opening an external conversation or sending anything. Adapt the script to another merchant's actual channel and check its receiving behavior separately.
A synthetic test request is evidence of the tested path, not a real qualified inquiry. Even a received message may need missing information or business assessment before anyone can decide whether to proceed. Keep test records separate from reported lead or sales results.
How should a failure become a repair and a retest?
For F01, record the originating step J3, run R1, candidate C1 and exact reproduction path. State the expected result, N1 with drawing revision, and the authored actual result, N0 without it. The buyer impact is specific: the evaluator cannot prepare the agreed request. That makes F01 blocking for this task, rather than merely a different-looking document.
Identify the owner who confirms the applicable note and the owner who implements the accepted correction. In a real project, agree the change scope before implementation. The exercise proposes pointing to confirmed N1; it does not authorize any page, document or theme change.
Retest on a named candidate. The authored R2 checks the repaired note and repeats J1 through J4 so the corrected source still connects to the same offer, conditions and contact preparation. Save the actual recheck evidence in a real run. “Fixed” in an issue comment cannot stand in for that repeatable result.
Scroll sideways to follow the issue into its scoped retest and remaining check.
Keep the original failure alongside the retest. If a repair affects shared navigation, instructions or another supported entry, include those affected checks. This is targeted regression checking around the task; it does not establish that every page or possible buyer journey has been tested.
What can the launch decision actually conclude?
Compare the results with the agreed mandatory criteria. In the exercise, R2 supports browser preparation for J1–J4. J5 remains not tested, so the end-to-end criterion is incomplete. The acceptance report should state both conclusions. Resolving F01 cannot supply the missing receiving evidence.
Give the launch owner the candidate, task, tested environments, open issues and untested criteria. They can decide the next check or agree a narrower acceptance scope with the remaining gap recorded. Do not silently remove a criterion because the rest of the site is ready. A task report supplies evidence for that decision; it does not publish the theme or change storefront access.
Repeat the relevant task on the devices and entry routes included in the agreed scope. Recheck the public route after an authorized launch. Keep larger accessibility, security, technical search or measurement reviews in their own scope. This small acceptance script neither completes those audits nor predicts rankings, inquiry volume or sales.
What should you bring to an acceptance review?
Bring one intended buyer task, the candidate and source versions, the script with expected and actual results, and its issue and retest records. Include the untested receiving step if it remains open, the people responsible for clarification, and the decision the launch owner still needs to make.
The editable script and authored example accompanying this article can structure that record. GRC's website services include architecture, inquiry paths, quality checks and handover. Bring the candidate, task and unresolved evidence to Discuss your project to clarify the acceptance responsibilities and next work to agree.
