SIGNUP CONFIRMATION COPY WORKSHEET
Companion to: Plan a signup confirmation page that matches what happened

Purpose: Specify what a visitor may be told after one signup action, the evidence
that permits each message, and the next action the visitor can actually take.
This is a planning resource. It does not save requests, deliver files or messages,
reserve appointments, create a page, or grant ClickFunnels AI access.

All Lantern Studio details below are fictional. No checks have been run.
Do not put real customer information or private access links in a shared copy.

A. DEFINE THE JOURNEY
Offer / resource:
Exact signup action (guide request, list subscription, event registration, etc.):
What the visitor was promised before submission:
Destination that must confirm the result:
Evidence the page can use for this specific attempt:
What the page cannot establish:
Business owner who will settle missing commitments:
Implementation owner who will verify the result conditions:
Page version / permitted environment for a later check:

B. WORKED EXAMPLE — LANTERN STUDIO
Fictional offer: A room-measuring guide containing a blank sheet and worked example.
Intended process: Accept a guide signup, then provide the file on the result page.
Email: Optional separate route, not a condition for saying the signup completed.
Booking: Not offered in this example.
Actual implementation / observed outcomes: NOT BUILT OR TESTED by this worksheet.

L01 — Still processing
Condition: The attempt remains in progress; final outcome not established.
Headline: Checking your signup
Visitor action: Wait for the result while progress information remains available.
Forbidden inference: Signup accepted or guide delivered.
Open dependency: Define the supported timeout and recovery behavior.

L02 — Accepted and file available
Condition: Intended destination accepted the signup; correct file access is available.
Headline: Your guide signup is complete
Body: Open the room-measuring guide below. It includes a blank room sheet and a
worked example.
Planned link label: Open the room-measuring guide
Help: Provide a verified support link for trouble opening the file.
Forbidden inference: Email delivered, guide read, or appointment reserved.
Open dependencies: Actual visitor-accessible file and real support destination.

L03 — Accepted but file unavailable
Condition: Signup accepted; file access failed.
Headline: Your signup is complete, but the guide is unavailable
Visitor action: Follow the supported recovery or support route.
Forbidden inference: Lost signup, successful download, or known delivery time.
Open dependencies: Resolve that route and any supported recovery commitment.

L04 — Rejected before saving
Condition: Authoritative rejection before save; this is not merely a timeout.
Headline: Your signup was not completed
Visitor action: Explain the relevant correction and how to submit again.
Forbidden inference: A missing response means definite rejection.
Open dependency: Exact input/error/retry behavior for the actual implementation.

L05 — Outcome unknown
Condition: The system cannot establish whether the attempt completed.
Headline: We could not confirm your signup
Visitor action: Explain the supported status-check or contact route before retrying.
Forbidden inference: Definite failure, definite success, or a safe automatic retry.
Open dependency: A working status lookup or alternative recovery process.

C. BLANK MESSAGE RECORD — COPY FOR EACH STATE
State ID:
What is known about this attempt:
Required evidence before this message is allowed:
What remains unknown:
Headline:
Body:
Primary action label:
Actual destination or behavior (UNRESOLVED until supplied):
Timing statement and basis, if any:
Help route:
Statements this state must not imply:
Dynamic inline update or new page/context:
Owner / unresolved dependency / next action:

D. RETURN AND ACCESSIBILITY PLAN
Direct visit with no identifiable result should show:
Refresh after a confirmed result should show:
Old bookmark with unavailable result should show:
Old confirmed signup with newly unavailable file should show:
Necessary information to display (omit unnecessary personal detail):
Page title and main heading:
Text equivalent of the visual status:
How an inline status is surfaced to assistive technology without taking focus:
Keyboard path to next action and help:
How narrow-screen presentation will keep result and next step understandable:
Actual verification evidence: NOT RUN / BLOCKED / OBSERVED, with date and scope:

E. COPY REVIEW
[ ] Each claim has a specific result condition.
[ ] Unknown result differs from definite rejection.
[ ] Receipt, file access, sending, arrival and booking are separate.
[ ] No decorative reference, invented help address or unsupported deadline.
[ ] Link labels have real destinations before publication.
[ ] Direct arrival cannot manufacture a successful signup.
[ ] Inline status and a new page load are treated as different accessibility cases.
[ ] Intended checks remain separate from observed results.

SOURCE NOTES
GOV.UK confirmation-page pattern (design principles and return visits):
https://design-system.service.gov.uk/patterns/confirmation-pages/
W3C status-message explanation (inline updates without context change):
https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html

For a CFAI project, use the agent guide's actual workflow/access requirements:
https://www.clickfunnels.ai/agents
A completed worksheet is a brief, not a built or publicly verified journey.