# Website Handoff Review

Use this worksheet with Method Media’s **A small-business website is a handoff, not a brochure**.

Review one important visitor path from the first page through the first responsible response. Use safe internal test information. Do not enter passwords, payment-card details, private customer records, health information, access tokens, or other secrets.

This is a general operating worksheet. It is not an accessibility certification, performance audit, legal or privacy advice, or a guarantee of inquiries, rankings, sales, or revenue.

## 1. Name the path

- Page being reviewed:
- Intended visitor:
- Useful result promised:
- One primary action:
- What the visitor reasonably expects that action to do:
- Person responsible for the first response:
- Date reviewed:

## 2. Check the promise

- [ ] The page states what is available now.
- [ ] The intended audience can recognize whether the offer or resource fits.
- [ ] Important scope, price or pricing status, and availability are visible.
- [ ] The primary action names what happens next.
- [ ] The page does not imply a purchase, submission, subscription, or response time that the real system cannot support.

Evidence or correction:


## 3. Check the action

- Action type: read / download / request / buy / enroll / email / other
- Destination:
- Does it work on desktop?
- Does it work on mobile?
- Does it work with a keyboard?
- Is visible focus present?
- Can the visitor understand the result without internal knowledge?

Evidence or correction:


## 4. Check the information requested

For each field, name the decision it supports and the person who uses it.

| Field | Why it is needed | Responsible user | Keep / remove / rewrite |
| --- | --- | --- | --- |
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |

- [ ] Only information required for the stated action is requested.
- [ ] Required fields are visibly marked.
- [ ] Labels and instructions are understandable before an error occurs.
- [ ] The form states what not to submit.
- [ ] Consent or acknowledgement language matches the real handling process.

## 5. Check what happens after the action

- What the visitor sees:
- What record is created:
- Reference or evidence of receipt:
- Where the record appears:
- Who is alerted:
- Who owns the first response:
- What the visitor is told will happen next:
- Is that expectation currently supportable?

If the action opens an email draft, verify that the page states nothing is sent until the visitor reviews and sends it.

## 6. Check ownership and next action

- Owner:
- Current status:
- First useful response:
- One specific next action:
- Review date:
- Condition that closes the record:
- Condition that requires a human exception decision:

Do not write “follow up” as the next action. Name the observable action and when the owner will review it.

## 7. Run three safe tests

| Test | Expected result | Actual result | Owner | Correction needed |
| --- | --- | --- | --- | --- |
| Ordinary request |  |  |  |  |
| Missing or invalid information |  |  |  |  |
| Out-of-scope or unusual request |  |  |  |  |

For each test, confirm:

- [ ] The visible message matches what actually happened.
- [ ] The request reaches the intended destination.
- [ ] One person owns the next decision.
- [ ] An acknowledgement contains no unsupported promise.
- [ ] A failed step becomes visible.
- [ ] A manual path remains available for consequential work.

## 8. Rank the corrections

### Now

Fix before asking more visitors to use the path.

1.
2.
3.

### Next

Important after the handoff is dependable.

1.
2.
3.

### Later

Useful only after evidence supports the extra work.

1.
2.
3.

## 9. Close the review

- Most important broken handoff:
- Smallest responsible repair:
- Named owner:
- Evidence that will show the repair works:
- Date to review again:

The review is complete when the promise, action, transfer, owner, and first response are truthful and visible. It does not replace professional review required by the real accessibility, privacy, security, contractual, or regulatory context.