WEBSITE PLANNING

Separate Accepted Forms From Delivered Notifications

Design separate states for the saved inquiry and the notification that alerts staff to it.

Draw the handoff

A useful form workflow distinguishes validation, durable acceptance, notification attempt and staff review. The browser’s success message should correspond to the actual promise being made. If the system has saved an inquiry but email delivery is pending, do not describe that as a confirmed appointment or a guaranteed read message.

Use a hypothetical state table

Imagine request R104 is accepted at 10:00, its notification is queued at 10:00 and the mail provider accepts that notification at 10:01. Staff opens the inquiry later. These are separate states with separate evidence. Store a stable request identifier so the records can be reconciled without copying private form content into every log.

Understand the mail boundary

SMTP acceptance concerns responsibility for email handling; it does not mean a person read the message. An application should therefore define what each delivery signal actually proves. Avoid labeling every provider response delivered-to-owner unless that is genuinely what the evidence establishes. Keep unresolved notification status visible to authorized operators.

Measure the right success

A lead event should correspond to your documented acceptance rule, not merely a button click. Failed validation should not count as an accepted lead. Notification failure should trigger operational recovery without asking the customer to repeatedly submit a successfully saved request. During review, inspect the state transitions with approved test fixtures; do not create unsolicited live customer messages as a routine diagnostic.

Apply this to your website

Bring the relevant URL and a description of the decision to request a scoped website review. Do not send passwords or private customer records. The primary reference is the linked technical guidance.