When to use it
Offer a short guided fix before asking someone to write a support report. This template suits a browser-based service with email-link sign-in. Adapt the instructions to the product you actually support before sharing it.
How it works
The first choice routes people to either the sign-in page or the page-loading steps. The sign-in path asks them to request one fresh email and use the newest link. The loading path asks them to copy unsent text, reload once and check their connection. Neither path asks for a password or sign-in link.
Each step asks whether the fix worked, failed or could not be tried. Solved responses reach a specific ending and never see contact fields. Both unresolved choices route forward to escalation. The other fix’s question is skipped and never required.
The Text Steps tried field uses First match to describe the actual unresolved path. It distinguishes “tried and still stuck” from “could not try”, so the report does not invent actions. The escalation page pipes that recap into its copy, then asks for email and a description of the issue. The final confirmation repeats the recap without promising a fix or reply time.
Two optional context fields read @device and @referrer using First match. When unavailable, they say “Device not provided” and “Referrer not provided”. These are browser-supplied context, not verified identity or access rules. Removing them does not change any support route.
Make it your own
Change the issue choices and fix instructions to match real, tested advice for your service. In the Logic panel, update each page’s Go to by answer routes when adding a step or ending. Keep every route forward and give “could not try” a way to contact support. Edit Steps tried whenever a troubleshooting instruction changes. See conditional logic and calculated fields.
Test both solved endings, both unresolved states on each path, and missing visit details. Go back and change an unresolved answer to solved: email and report details should then be skipped rather than submitted. These paths and visit-context fields work on Free.
Put the answers to work
Use Responses to distinguish solved attempts from unresolved reports. Read Steps tried and the problem description before asking someone to repeat a fix. The form stores responses; it does not create a ticket in another help desk.
For a direct report without guided steps, use the support request form or the bug report form.