Product and UX Content

Confirmation Message Checklist

Confirm what happened, what did not happen, what changes next, whether the action can be reversed, what evidence exists, and what the user must do.

Free editable Markdown · Content designers, product teams, and QA teams · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Outcome truth

Action and object: [Enter]
Trigger event: [Enter]
State: [Received / Processing / Scheduled / Sent / Complete / Partial]
What is proven: [Enter]
What is not yet proven: [Enter]
Relevant reference: [Safe identifier]
Timing or next event: [Enter]
Product owner: [Name/team]

Message

Heading: [Precise outcome]
Supporting detail: [Object, date, recipient, amount where appropriate]
Next action: [User / Organization / None]
Expected timing: [Range/time zone]
Status location: [Enter]
Reversal or change path: [Enter or unavailable]
Support and reference: [Enter]
Privacy-limited display: [Describe]

State coverage

Irreversible consequence: [Enter]
Expiration or cancellation: [Enter]

Received and completed states are not conflated.
Partial success identifies completed and failed parts.
Delayed processing gives a status and recovery path.
Duplicate submission does not create an inaccurate second success.
Email or notification failure does not change the underlying outcome.
Refresh and return visits show the current state.

QA and release

Build and test account: [Enter]
Cross-channel comparison: [Product/email/history]
Keyboard and announcement result: [Enter]
Narrow and localized display: [Enter]
Links and account context: [Enter]
Approved wording and version: [Enter]
Support feedback signal: [Enter]
Update trigger: [Behavior, policy, channel]

How to use this template

Define the exact backend or product event that permits each completion claim.
Record the user-facing outcome, object, timing, evidence, next action, and reversal rules.
Draft distinct received, processing, partial, complete, and failed communication states.
Test accessibility, privacy, duplicate, refresh, delayed, and cross-channel behavior.
Verify the released message against system truth and monitor support confusion.

Name the verified outcome precisely

Work with product and engineering to identify the event that triggers the message. A form may be received but not reviewed; a payment may be authorized but not settled; a file may be queued but not processed. Use the strongest wording the system can prove and no stronger. Confirm the user's relevant object, amount, date, recipient, plan, or reference while respecting privacy on shared screens. If an earlier action partly failed, do not let a generic green check imply that everything succeeded.

Explain what follows and what remains

Tell users when processing, delivery, review, access, or a response is expected and what evidence they will receive. State whether another action is required, who takes it, and where status can be checked. If the action can be changed, cancelled, refunded, revoked, or undone, provide the applicable path and deadline. If it cannot, that consequence should have appeared before action and may be restated now. Avoid using the completion state as an unrelated promotional opportunity before the user understands the result.

Verify channels, access, and exceptions

Check that in-product, email, notification, receipt, and account-history messages agree. Test duplicate actions, refresh, back navigation, delayed processing, partial success, expired links, and communication delivery failure. Confirmation must be announced accessibly, remain available long enough to understand, and not rely only on color or animation. Do not display unnecessary personal or financial details. Use a stable reference that support can safely recognize and ensure links return to the correct account and locale.

See the fields in context

Fictional example: scheduled report

ReportWillow and its scheduling behavior are invented and are not GPTHuman features.

Trigger: The imaginary schedule record is saved, but the report has not been generated.
Heading: “Your report is scheduled,” not “Your report is ready.”
Detail: Show the fictional date, time zone, and destination without exposing a full private address.
Next step: The user may edit or cancel before the stated deadline.
Cross-channel: The account history and fictional email use the same schedule state.

Frequently asked questions

Is “Success!” a sufficient confirmation?

Usually not. State what completed, what happens next, and any reference or required action.

Should confirmations include promotional content?

Only after the outcome is clear and when the promotion is relevant, optional, and does not distract from recovery or records.

How long should a confirmation remain visible?

Long enough to understand and access; consequential records should also be available in a durable appropriate channel.

What if the email receipt fails?

Do not claim the transaction failed if it completed. Explain the communication issue and provide another way to access the record.