How do I write a process explanation that tells readers what happens after they submit something?

Build it in stages, and label which details are confirmed. Start with the moment of submission: what the person sees or receives right away. Then explain any later steps only when an authoritative source confirms them. If a step, timeline, outcome, or status-check method is unknown, say so plainly rather than filling the gap with a likely-sounding promise.

A reusable outline:

1. Right after submission: [confirmed on-screen message or other confirmation].
2. What may happen next: [verified next step, or “The next steps are not specified here.”]
3. Timing: [published timeframe and its source, or “No timeframe is stated here.”]
4. Status: [verified place or method to check, or “No status-check method is confirmed here.”]
5. If something goes wrong: [verified instruction, or a neutral direction to use the service’s published help channel].

W3C recommends concise, clear feedback about whether a web-form submission succeeded or errors occurred. It also describes explaining errors and how to correct them. [S1] That is guidance on form feedback; it does not establish what happens later in any particular service.

Describe what the interface actually reports, using its wording where practical. For example, if the form displays a success message, you might write: “After submission, the form displays: ‘[verified confirmation text].’ This confirms [only what the message explicitly confirms].” Do not turn a receipt or success message into “Your request is approved,” “Your application is complete,” or “We will contact you within [number] days” unless an authoritative source supports that exact claim.

For errors, explain the observable feedback and any verified correction guidance. W3C recommends clear error explanations tied to the relevant field and guidance on correcting them. [S1] A writer can therefore check whether the published instructions describe what users see and what they should do next. If you have not verified the interface, use a placeholder during drafting—[confirm actual success message]—rather than presenting an imagined message as fact.

Do not present a guessed workflow as settled. Ask the service owner or consult its authoritative documentation, then record the precise claim and where it is supported. Until confirmed, mark each gap for follow-up or state the limit in reader-facing language. For example: “This page confirms what happens when you submit the form, but it does not specify later review steps or a timeframe. Check [verified official information channel] for current instructions.” Keep the bracketed phrase only if you have verified that channel; otherwise say that no status method is confirmed in this explanation.

W3C identifies validation, notifications, and multi-page forms as separate design topics, and recommends progress information when a long form is divided into logical stages. [S2] These design recommendations do not prove that a particular service has later review stages, a published processing time, or a status tracker. Keep interface progress during form completion distinct from progress after submission.

Assume, for illustration only, that a hypothetical form’s verified confirmation reads “[submission received].” A cautious draft could say:

“After you submit, the form displays ‘[submission received].’ This is the confirmation shown by the form. The information available to us does not specify later review steps, a timeframe, or a status-check method. See [verified official instructions] for any current information about what to do next.”

Those bracketed details are placeholders, not claims about a real service. Remove or replace them only after checking the actual interface and authoritative information. W3C’s guidance supports clear feedback about submission success or errors, but does not establish this hypothetical service’s workflow or outcomes. [S1]

Before publishing, compare every sentence with what you have verified. If the evidence only confirms receipt, say receipt—not review, acceptance, completion, or a promised result. If a timeframe or status channel cannot be confirmed, leave it out or state that the explanation does not specify it.