A contact form audit should follow the inquiry all the way to the person responsible for replying. Check the page, field labels, errors, confirmation, saved record and notification. Keep analytics separate from that delivery trail. A submit click can be recorded even when the inquiry never reaches your team.
Start with one important form, such as a consultation request or a product inquiry. Use a test environment where possible. For a production check, obtain authorization, use clearly labeled test details you control and agree who will remove or mark the record. Do not test another company's form by sending an unsolicited inquiry.
1. Define what a completed inquiry means
Write the expected outcome before opening the page. A visitor should understand what they are requesting, complete the required fields, receive an accurate confirmation and leave a record that the receiving team can find. If the workflow includes a notification, verify its receipt separately.
For a hypothetical consulting business, the intended result might be a saved consultation request and a notification in the shared sales inbox. That is different from a booked meeting. Unless the form actually reserves a time, the confirmation should explain the next step without calling the meeting booked.
Record the exact URL, form name, recipient or queue, required fields and follow-up owner. Include any stated response time. A response promise should reflect the team's actual process rather than a convenient line of copy. If no owner has been assigned, that is an operational gap to resolve alongside the technical audit.
2. Read the page as a first-time visitor
Look at the explanation immediately before the form. Does it say who should use it and what happens afterward? Make the request specific enough that someone can decide whether to continue. A button labeled “Request a consultation” should lead into a consultation request, with any qualification or scheduling step explained.
Review the information requested. Ask why each required field is necessary for the first response. A detailed budget or full address may be appropriate for one service and premature for another. Reducing fields is a hypothesis to evaluate against the quality of inquiries, not a universal instruction to remove every qualification question.
Check privacy and contact language in context. Optional marketing choices should be understandable alongside the inquiry itself. Keep links readable and usable on a phone. If the page makes a material promise, the confirmation and follow-up should carry the same meaning.
3. Check labels, instructions and keyboard use
Every input needs a clear purpose. The W3C guidance on labeling form controls explains how labels should be associated with their controls. A placeholder can disappear while someone types, so do not depend on it as the only explanation of a field.
Use the keyboard to move through the form. The sequence should be sensible, focus visible and controls operable. Check required markers, formatting instructions and grouped choices. Try the form at a small viewport and with enlarged text. Look for clipped instructions, covered controls or a keyboard that makes entry unnecessarily difficult.
This walkthrough is a useful check, not a complete accessibility certification. Automated tools can locate some defects, but human review is needed to understand whether a person can complete the task. Record the observed issue and a reproducible example instead of reducing the audit to a single score.
4. Test errors before the successful path
Use safe test inputs to check missing required information and an invalid email format. Read the response. Does it identify the affected field, explain the correction and preserve the other information already entered? A vague error at the top of a long form can leave a visitor guessing.
The W3C tutorial on form notifications covers useful feedback for errors and successful completion. Review whether the feedback is available beyond a color change. Check how focus and error messages behave with the keyboard and, where practical, assistive technology.
A network failure is a separate test. In an approved test environment, confirm that a failed request does not show a success message. Give the visitor a recovery path and avoid encouraging repeated submissions without explaining whether the first request was accepted. Keep a copy of the exact failure and the expected behavior for the developer.
5. Verify the saved record
For the authorized successful test, use a unique label such as “QA contact form review, October 14.” Capture the time, submitted fields and confirmation. Then find the record in the actual receiving system. Match its identifier or unique label and check that the relevant details arrived intact.
Do not treat an email as the only record if the workflow promises to save the inquiry in a CRM. Conversely, a CRM record does not establish that the inbox notification arrived. Verify each required outcome on its own. Note any processing delay and check again within the workflow's expected window.
Avoid copying private customer details into a general audit document. Use your own test record and retain only the evidence needed to demonstrate the result. If the form passes information to another service, confirm that the receiving record matches the submission rather than assuming the integration worked because it is configured.
6. Check the notification and follow-up handoff
Open the destination inbox or queue and read the notification. Confirm the sender, inquiry label, useful context and link to the saved record. A provider response saying “accepted” is evidence of submission to that provider, not proof that the intended teammate can see it.
Check who is responsible for replying and what happens if that person is unavailable. A shared queue, assignment rule or documented backup may be enough for a small team. The objective is a clear handoff, not a complicated automation project.
Review any acknowledgement shown to the visitor or sent by the workflow. It should describe the step actually completed. If it says a person will reply, verify that the business has a workable process behind the statement. Do not introduce new live email tests without permission simply to fill a blank in the audit.
7. Reconcile analytics with accepted inquiries
Google Analytics enhanced measurement includes form interaction events when enabled. Those events describe tracked interactions. They do not independently establish that your receiving system saved an inquiry or that your team received it.
Document what your implementation counts: a click, a browser submission, a confirmed server response or another defined event. Inspect the authorized test under the consent choices your site supports. Keep names, email addresses, phone numbers and message contents out of analytics payloads.
Compare the test trail using timestamps and non-personal identifiers where supported. Investigate refreshes, retries and duplicate events. For ongoing reporting, compare qualifying accepted inquiries over a completed window and explain exclusions such as spam, tests and duplicates. Do not turn differences between systems into a claimed conversion improvement without understanding their definitions.
8. Keep a compact acceptance worksheet
The following rows are examples of checks, not findings about your website. Assign an owner and retain the evidence for each result.
| Stage | Evidence to keep | Acceptance question |
|---|---|---|
| Page promise | URL and current wording | Is the next step clear and accurate? |
| Fields | Labels, instructions and keyboard notes | Can the intended visitor complete the form? |
| Error path | Safe invalid input and response | Is recovery clear without losing other entries? |
| Confirmation | Test timestamp and visible result | Does it describe the action actually completed? |
| Saved inquiry | Unique test label and record identifier | Did the receiving system retain the right details? |
| Notification | Read-back from the intended destination | Can the responsible person find the inquiry? |
| Measurement | Event definition and sanitized test trail | Does the count represent the stated outcome? |
Treat a missing saved inquiry or misleading success message as a blocker for that journey. Prioritize issues that stop completion or hide a failure before polishing decorative elements. Retest the repaired stage and the successful path after changing the form plugin, integration or confirmation behavior.
Your next step
Choose one form and agree on one authorized test record, the receiving destination and the person who will verify it. Complete the worksheet, repair the first blocker and repeat the same check. For the broader page review, use the website audit checklist before buying traffic. For experiments after the journey works, see the conversion optimization guide.
Smart Site Audit can help organize website findings. A public website analysis cannot independently verify your private CRM records, inbox receipt or team follow-up. Keep those checks attached to the audit so a working interface is supported by a working handoff.