Demo Request Qualification Form Brief
Define the minimum information needed to arrange a relevant software demo, with a clear purpose, routing rule and honest response expectation for each field.
Read this resource as Markdown
When to use this template
Use this when a real demo is available but the team needs limited task or platform context to prepare it. Explain the request outcome before asking for information and separate demo arrangements from marketing preferences.
Choose another approach when: The product cannot support the requested demonstration, you want to enrich a contact profile without a clear purpose, or you plan to treat requesting a demo as consent to every marketing campaign.
Gather these inputs
- The actual demo scope, audience constraints and person responsible for arrangements.
- The concrete routing or preparation decision each proposed field informs.
- Current response coverage, data-handling practice and any separate communication preferences.
Copy and adapt the template
Edit the text below and copy it into your own document. Edits stay in this browser field and are not submitted or saved by this page.
Worked example
Illustrative example, not a Crany customer result. Replace every example detail with facts you can verify.
Fictional example: a founder can demonstrate a checklist workflow, and needs to know the intended handoff task to prepare a relevant example. The brief includes a task question and a contact route for arranging the conversation. A mandatory annual-revenue field is removed because nobody can explain how it changes preparation or routing. A phone number remains optional when arrangements can be made through the supplied email. “Not sure yet” is a valid task-context answer if the founder can discuss it during the demo. The acknowledgement says that arrangements require a response; it does not display “Demo booked” before a time is actually agreed. No real contact is submitted by this brief.
How to use it
- List the decisions needed to prepare or route the available demo.
- Keep only fields that serve those decisions and explain required, optional and uncertain answers.
- Test the acknowledgement and routing cases before handing the brief to an implementer.
Check before using it
- A request, an accepted appointment and completed product access are different states.
- The form does not silently bundle a demo request with broad marketing permission.
- Sensitive records and credentials are not used as qualification inputs.
What to measure
Track routing accuracy, avoidable clarification and mismatches between the expected and actual next step. Fewer fields are not automatically better if necessary preparation becomes impossible; assess the real task rather than claiming a universal form-length optimum.
Research and sources
GOV.UK recommends knowing why each question is needed; W3C WAI explains form instructions. This original demo-routing brief adapts those principles without imposing government layouts or determining legal permission.
- GOV.UK Design System: Question pages — checked 2026-10-24. Know the purpose of each question, request only necessary information and make optional inputs clear. Government-specific layouts are not imposed on private software.
- W3C WAI: Form Instructions — checked 2026-10-24. Clear required/optional input, formats and contextual help associated with form controls.
About Crany
Crany is an AI marketing co-founder in development for software founders and vibe coders, designed to strategize, execute approved marketing and improve based on results. This free resource is usable independently of the product. Join the public waitlist.