Use confirmation pages as part of the process, not as an endpoint
A confirmation page explains the result, the next step, and the expected response time. It provides reassurance and offers only appropriate follow-up actions.
For UX teams and web developers, "Confirmation Pages as a Process Step" shows the difference between "Concrete Confirmation of Receipt" and "Expected Further Process." An "Empty Thank You Phrase" is a typical warning sign.
Published: 3 min read · Author: Sebastian Geier
How does a confirmation page become a helpful part of the overall process?
A confirmation page must state the actual system state achieved and explain how the process will be handled further. A reference, expected channel, and correction path provide reassurance. A pending technical commitment must not be presented as already completed.
Practical example: "Empty thank-you message"
After a project request, only "Thank you" appears initially. The new confirmation page states the type of request received, displays a reference, announces the technical review via email, and provides a way to add information; it does not yet claim a confirmed date because this is still being reviewed internally.
Empty thank-you message
Empty thank-you message – The page only confirms "Thank you" and leaves open whether the request has been received or what happens next.
Premature success status – A successful transfer is displayed as a completed booking or commitment, even though technical review is still pending.
Marketing Distraction Additional CTAs overshadow references, next steps, and necessary information immediately following a significant transaction.
Concrete Confirmation of Receipt
Test criterion
Concrete Confirmation of Receipt
The page identifies the process, submitted content, and, if applicable, a reference, without claiming more success than is technically verifiable.
Test criterion
Expected Further Process
Processing step, realistic communication channel, and responsible party are clearly announced.
Useful Correction Path People can review, add to, or report errors without having to blindly restart the entire process.
Expected Further Process
For each process, clearly identify the actually confirmed system state and the immediately following processing step.
Design the confirmation page with a reference, summary, response path, and an appropriate correction or contact option.
Test the page after success, delayed handover, and repeated access, and compare the results with email and backend status.
Useful Correction Path
Percentage of completed processes with a clear reference, a comprehensible next step, and an easily accessible correction option.
Number of support contacts where it remains unclear whether a submission was successful or when the next response will occur.
Related questions and next steps
Use required fields only where they are truly necessary Expands on the "Specific Confirmation of Receipt" checkpoint. The guiding question is: Which form fields must be completed?
A complementary perspective is offered Differentiate Calls to Action According to Decision Readiness. It answers the question: "Which calls to action are appropriate for different stages of a B2B decision?"
If you want to practically implement "Confirmation Pages as a Process Step," you can refer to Robust Website Systems This document focuses on "Confirmation, System States, and Filter Feedback" and "Specific Receipt Confirmation."
Conclusion: Confirmation Pages as a Process Step
A confirmation page translates the technical completion into an understandable process status. It provides orientation without preempting any commitment that has not yet been made.
Sources and Further Information
The classification of "confirmation pages as a process step" is based on the following official documentation and standards.
Understanding Status Messages – W3C WAIOfficial explanation of how to make dynamic status messages available to assistive technologies without changing focus.
Panel – GOV.UK Design SystemOfficial component guidance for highlighted confirmations with a clear conclusion and reference information.
User Notification – W3C Web Accessibility InitiativeOfficial guidance for providing understandable overall and inline feedback after successful or unsuccessful form submissions.
Key Thesis
After submission, the page specifically confirms what has been received and what happens next. Relevant references and change paths replace an empty thank-you message.
What This Is Not About
An audit that only considers the most obvious defect is not effective. "Empty thank-you message," "Premature success status," and "Marketing distraction" remain relevant.
What it's about
"Concrete Confirmation of Receipt," "Expected Further Process," and "Useful Correction Path" form the common framework. Their separate review prevents purely cosmetic approval.
UX, navigation & forms
Reducing the risk of project cancellations due to unclear data protection and response promises
"Confirmation Pages as a Process Step" includes, as a separate review step, the question: How do clear data protection and response promises reduce the form abandonment risk?
UX, navigation & forms
Consciously design empty states, loading states, and error states.
"Confirmation Pages as a Process Step" is supplemented by a separate decision: How can empty states, loading states, and error states be designed effectively?
Insights Overview
All VELUNO Insights at a Glance
Further analyses on Website Systems, digital visibility, and robust working models.
Concrete Confirmation of Receipt: Next Step
An end-to-end test should compare the confirmation page, the sent message, and the actual backend status. Discrepancies are then treated as process errors and not simply as text corrections.