A good inquiry can disappear without a broken homepage or a traffic problem.

The visitor may understand the service and be ready to ask for help, then meet a vague button, an unexpected form, an error with no useful explanation, a confirmation that overpromises, or a message that reaches an inbox nobody owns. Analytics may show a click or form event while the business never receives enough context to respond.

That is why the useful unit of review is not the contact form alone. It is the complete handoff from a visitor’s question to a responsible person with enough information to take the next step.

This checklist helps you inspect that handoff. It can establish what the website and operating process do during a controlled test. It cannot tell you why real visitors leave, whether demand is strong, or whether a change will increase inquiries without additional evidence.

Draw the inquiry path before changing it

Start with one real service and one realistic visitor need. Write the route as a sequence:

Entry page → service explanation → primary action → contact method → input and validation → submission or email draft → delivery → triage → response

Use the route that actually exists. A form that sends data to a customer system is different from a page that opens an email application. A phone link is different from a booking tool. Do not describe every path as a “submission” if no data is sent by the website.

For each step, name the handoff:

  • What does the visitor know before taking the action?
  • What does the interface ask the visitor to do?
  • What visible result tells the visitor what happened?
  • Which system receives the inquiry?
  • Which person or role owns the next action?
  • What is the recovery path when the expected step fails?

This map exposes gaps that a visual review can miss. A polished form can still route to an abandoned inbox. A reliable delivery service can still receive a message that lacks the location, service type, or timing needed to route it.

Use this copyable inquiry audit table

Copy the table into a document or spreadsheet. Run one row at a time with a fresh browser session, a real phone, and a test address you control. Replace the example pass conditions with the behavior your business has approved. On a narrow screen, swipe the table horizontally to read every column.

Step Evidence to capture Example pass condition Owner
Entry page Page URL, service named, service area or boundary, visible proof A first-time visitor can identify the relevant service and whether the stated scope may fit Content owner
Primary action Exact button or link text, placement, destination The action says what happens next and opens the intended destination Website owner
Contact method Form, email, phone, booking, or another route The page accurately explains whether the action sends, opens, calls, or schedules Website owner
Requested context Every required and optional field Each request has a defined routing or response purpose; unnecessary fields are removed Service owner
Labels and instructions Visible labels, required markers, formats, examples A visitor can tell what to enter without relying on placeholder text alone Website owner
Input support Input type, autocomplete purpose, keyboard behavior Common personal fields expose the supported purpose and are practical to complete on mobile Website owner
Error recovery Triggered errors, preserved values, focus and announcement behavior The error identifies the affected field in text, explains a correction when possible, and retains usable entries Website owner
Action result Confirmation, new page, status message, email draft, or other outcome The result accurately states what happened and what the visitor must still do Website owner
Delivery Timestamp and test identifier at the receiving system The complete inquiry arrives once at the approved destination System owner
Triage Inbox, queue, notification, assignment, or escalation record A named role can see the inquiry and knows who takes it next Operations owner
Response Approved response expectation and test record The assigned owner can reply through the intended channel with the submitted context Service owner
Failure path Disabled script, invalid input, delivery failure, unavailable recipient, or no email handler The visitor receives a truthful recovery route that the business monitors Operations owner

A pass in one row does not prove the next row. A button reaching the contact page does not prove delivery. A success message does not prove that the message reached the correct inbox. An email arriving does not prove that anyone is responsible for it.

Check the promise before the form

The inquiry can be lost before a field appears. Compare the call to action with the destination.

If the button says Request an estimate, the next page should not present a general “Tell us anything” form without explaining what information starts an estimate. If it says Check availability, the destination should not imply that availability has been confirmed merely because a message was sent.

Record the exact words rather than summarizing them. Check the desktop header, mobile menu, service page, footer, and any repeated call to action. Different labels may be appropriate for different services, but each label should describe its own next step.

If the problem begins earlier—visitors cannot tell what the business does, who it serves, or where it works—use the homepage clarity checklist before rewriting the form. Contact-path changes cannot repair an unclear offer by themselves.

Ask for enough context to route the inquiry

A short form is not automatically a good form. Neither is a detailed one. The right question is whether each field earns its place at this stage.

For every field, write down:

  1. who uses the answer;
  2. which routing or response decision it supports;
  3. whether the visitor can reasonably know the answer now;
  4. what happens if the answer is missing;
  5. whether the information could be requested later.

Service type, desired outcome, location, and meaningful timing can help a business route work, but the correct set depends on the service. Do not collect information merely because a template includes a field. Questions about sensitive or regulated information need review outside this general website checklist.

W3C’s guidance on Labels or Instructions says inputs that accept user information need labels or instructions so people know what is expected. It also cautions that too much instruction can be as unhelpful as too little. Use a visible label for each field, identify required information, and provide a format or example when the expected answer is not obvious.

For common details about the person, code can support the label. W3C’s Identify Input Purpose guidance explains that supported input purposes can be programmatically identified—for example, with appropriate HTML autocomplete values. That can let browsers and assistive technology present or fill familiar information more consistently. It does not replace a clear visible label.

Make errors specific and recoverable

Trigger every required-field and format error yourself. Try the form with a keyboard, at a narrow viewport, and after entering a long answer. Check what remains visible and where focus goes.

W3C’s Error Identification guidance requires an automatically detected input error to identify the affected item and describe the error in text. A red border alone is not enough. A message such as “Something went wrong” also leaves the visitor to discover which answer needs attention.

The GOV.UK Design System error-message pattern is a useful implementation reference: explain what went wrong and how to fix it, associate the message with the relevant question, and keep the answers already entered. It is a pattern to adapt and test, not proof that a form meets every accessibility need.

Review the difference between a visitor error and a service failure. “Enter an email address in the format name@example.com” gives the visitor a correction. “Our email service is unavailable” is not something the visitor can fix by editing the field. The latter needs an honest alternative contact route or a clear request to try later—not a validation warning that blames the input.

Say exactly what happened after the action

The last button label, confirmation text, and underlying behavior must agree.

Common outcomes include:

  • the website accepted the form data and queued it for delivery;
  • a third-party service accepted a booking request;
  • the browser opened an email draft that the visitor must review and send;
  • a phone link opened the device’s calling interface;
  • the action failed before anything left the page.

Do not show “Message sent” when the website only opened a draft. Do not promise a response time that the assigned team cannot consistently meet. If new confirmation text appears without moving focus, W3C’s Status Messages guidance explains that important results, progress, and error messages should be programmatically available to assistive technology without unnecessarily interrupting the user’s work.

Email links deserve a separate test. A mailto: action depends on the visitor having a usable email handler. Verify the behavior on supported desktop and mobile environments, state that the message is not sent until the visitor sends it, and keep a visible address available as a recovery route.

Follow the inquiry inside the business

Once the website hands off the message, continue the test.

Use a unique, harmless test identifier in the message. Confirm the receiving timestamp, destination, subject, body, attachments if supported, duplicate behavior, and any automated reply. Then trace the inquiry through assignment and response.

Ask operational questions that website analytics cannot answer:

  • Is the receiving address tied to the business rather than one person’s private account?
  • Who checks it when the usual owner is absent?
  • How is a website, software, support, sales, or partnership inquiry assigned?
  • What evidence shows that the handoff occurred?
  • What happens when a notification fails?
  • Can the assigned person see the original context without asking the visitor to repeat it?

This ownership belongs in the broader website handoff checklist. The contact path is an operating system, not a decorative block at the bottom of a page.

Separate facts from hypotheses

An inquiry audit becomes unreliable when observation and explanation are written as the same thing. Use three labels:

  • Fact: directly observed or reproduced, such as “the mobile service button opens /contact/” or “the test message reached the shared inbox at 10:14.”
  • Hypothesis: a plausible effect that has not been demonstrated, such as “the label may create uncertainty because it does not name the next step.”
  • Unknown: a question requiring other evidence, such as whether real visitors abandon here, whether inquiries are qualified, or whether a different field set would perform better.

Do not turn an audit into a conversion claim. A repaired error message may make the form easier to complete; the test does not prove that it will create more demand or revenue. A shorter form may remove work; it may also remove context the service team needs. Verify the interface first, then use permitted analytics, inquiry quality, and customer feedback to evaluate a change over time.

Run the original scenario from end to end

After each fix, repeat the exact route that exposed the problem. Then check an adjacent route in proportion to the risk: another service, another device width, keyboard use, a direct email option, or the absence of a configured email application.

Record the tested environment, date, result, receiving destination, and owner. Exclude staff tests from customer reporting where possible. If the delivery or response step cannot be exercised safely, mark it unverified rather than calling the inquiry path complete.

The small-business website launch checklist places this test in the larger release process: verify the published version, the primary visitor task, mobile behavior, measurement, and rollback after deployment.

Fix the handoff, not just the form

A useful inquiry path gives the visitor an accurate next step, preserves their work when something fails, reports the real outcome, delivers complete context, and assigns the response to someone who knows what to do.

Fireproof Studio’s project page follows a specific email-based handoff: the form collects an email address, type of help, desired outcome, and timing; its button opens the visitor’s email application with a message addressed to hello@fireproof.studio. The page states that nothing is sent until the visitor reviews and sends that email, and it also provides the address as a direct email link. If you want help inspecting or rebuilding your own service inquiry path, start there and describe where the current handoff breaks.