The demo request page is where interest becomes a name in a CRM, and it is often the least designed page on the site. A form with eleven fields, a vague line that says “Our team will be in touch” and nothing about what the demo will cover. The visitor wanted to see the product, and the page asks for a lot before it says anything.
This guide shows you demo request page design for B2B SaaS. You will get a four line promise check, a table of form fields with what each costs, what to show beside the form, how to design the confirmation and an accessibility checklist. The form advice is our own judgment from design work, not a measured result.
Key takeaways
Tell visitors what happens after they submit: who contacts them, when and what the demo covers.
Ask only what you need to route and prepare the call. Every extra field is a cost to the visitor.
Show proof and the product next to the form, not only a form on its own.
Design the confirmation page as the next step, not a dead end.
Make the form accessible: labels, error messages and input purposes.
What is a demo request page?
A demo request page is the page where a visitor asks to see the product with someone from your team. It is the conversion point for many B2B SaaS sites, so it deserves its own design.
The visitor arrives with a question: is it worth giving these people my details? The page has to answer it. That means a clear promise, a short form, enough evidence to feel safe and a believable next step.
Before the page, check that the site sends the right visitors to it. A SaaS Website Messaging Audit shows whether visitors understand what they are asking to see.
What is the Demo Page Promise Check?
The Demo Page Promise Check lists four things the page must say before a visitor will fill in a form. If any is missing, the form feels risky.
Line | The visitor’s question | Example form |
|---|---|---|
1. Who | Who will I talk to? | “A product specialist, not a sales script” |
2. When | How soon will I hear back? | “We reply within one working day” |
3. What | What will the demo cover? | “Your use case, on your data if you like” |
4. Cost | What does it cost me? | “Thirty minutes. No obligation.” |
Write the four lines, then put them next to the form. If you cannot promise one truthfully, fix the process before you fix the page. A promise you do not keep, such as a reply time that is not met, costs more trust than no promise.
Which form fields should you ask for?
Ask for what you need to route the request and prepare the call, and gather the rest in the call. Each field has a cost for the visitor, and a benefit for you. Weigh them.
Field | Why you want it | Cost to the visitor | Option |
|---|---|---|---|
Work email | To reply, and to find the company | Low | Keep |
Name | To address them | Low | Keep |
Company | To route and prepare | Low | Keep, or infer from email |
Role | To tailor the demo | Low to medium | Keep, as a short list |
Company size | To route | Medium | Ask only if routing needs it |
Phone number | To call | High for many | Make optional, say why |
“What do you want to see?” | To prepare | Medium | Optional, with a prompt |
Budget or timeline | To qualify | High | Ask on the call |
Start with the shortest form that lets your team respond well, and add a field only when someone can say what they will do with the answer. Avoid fields that exist because another company has them.
Pro tip: For each field, name the person who uses the answer and the moment they use it. A field with no user is a field to remove.
What should sit next to the form?
Place proof and a preview of the demo next to the form so the visitor does not have to leave the page to feel safe. Many demo pages show only a form, which gives the visitor little reason to go on.
The four promise lines from the check above.
One customer quote or named customer, close to the form.
A short preview of the product, such as a screen or a ten second loop.
A list of what the demo covers, in the visitor’s words.
A secondary route for people not ready to talk, such as a recorded tour or a documentation link.
Do not add a full navigation bar and ten links around the form. Keep the exits few and the focus on the action.
How should the form behave?
A good form is short, forgiving and clear about errors. Interaction details often decide whether the form is finished.
Label every field above the input, not only inside it as placeholder text.
Mark optional fields as optional, and avoid marking everything required.
Use the right keyboard on phones for email and phone fields.
Validate gently, as the visitor goes, and explain how to fix each error.
Keep the button label specific, such as “Request a demo”, and show a working state after the click.
Do not clear the form when something fails.
If the page uses a booking calendar, test it on a phone and check that times display in the visitor’s time zone.
How do you design the confirmation page?
Treat the confirmation as the next step in the conversation. It is the moment of highest interest, and it should not end with “Thanks.”
Element | What it does |
|---|---|
A clear confirmation | The visitor knows it worked |
What happens next | Repeats who, when and what, in order |
A calendar link or booking step | Lets them pick a time now, if that fits your process |
Something useful to do while waiting | A short tour, a use case page or a case study |
A confirmation email | Arrives within a minute with the same details |
Track the confirmation as a conversion in your analytics, and test that the tracking fires after the real form submit, not only on page load.
How do you make the form accessible?
Use real labels, clear text errors and input purposes that browsers can read. WCAG 2.2 covers each of these, and passing them also helps every visitor.
Error identification (3.3.1, level A). The criterion reads: “If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.” Color alone is not enough.
Input purpose (1.3.5, level AA). Use autocomplete values for fields about the user, such as name, email and phone, so tools can fill them. An email type alone does not meet the criterion.
Keep every control reachable and usable with a keyboard, and keep the focus visible.
Check color contrast on labels, placeholders and the button.
Test the form with a screen reader and by tabbing through it.
What stops visitors from booking a demo?
Most demo pages lose people to a long form, a vague next step or a dead end after they submit. Watch for these six:
Too many fields. The cost of the form outweighs the interest.
No promise about what happens next. The visitor guesses.
A form and nothing else. No proof, no preview.
Mandatory phone number with no reason. Many visitors leave.
A dead end confirmation. The best moment is wasted.
Not testing the tracking. You cannot tell what works.
How do you test the page this week?
Test with five people who match your buyer, and also test the process behind the page.
Show the page and ask: what happens if you fill this in?
Ask them to complete it on a phone and note where they hesitate.
Submit a real test request and time the reply against your promise.
Check that the CRM, the email and the analytics all received it.
Pass if four of five can state the promise, and your reply meets it.
Pro tip: Submit the form yourself from a personal email every month. You will find broken routing, slow replies and failed emails before a customer does.
Also read: SaaS Homepage Redesign Checklist.
To see how we design product pages, read our ORYN AI agent monitoring landing page case study, or browse all of our case studies.
Does your demo page keep its promise?
Send us your demo page and we will check it against the four lines. Book a page review · See our work
Demo request page design FAQs
A short form, four clear promises about who will contact the visitor, when, what the demo covers and what it costs, proof such as a customer quote, a preview of the product and a route for people not ready to talk. The confirmation page should repeat what happens next.
As few as let your team respond well. Many B2B forms work with name, work email, company and role, plus an optional field for what the visitor wants to see. Add a field only when you can say who will use the answer and what they will do with it.
Usually it should be optional, with a line explaining why you ask. A required phone number is a high cost for many visitors who prefer email. If your process depends on a call, say so, and let people choose a booking time instead.
Confirm that the request worked, repeat who will contact them, when and about what, and offer a calendar link if it fits your process. Add something useful to do while they wait, such as a product tour or case study, and send a confirmation email within a minute.
Yes. Kraftbase is a product messaging and UI/UX design studio for AI and B2B SaaS companies. We design the page, the form and the confirmation together with the message, so a visitor sees a clear promise and a believable next step.
Give every field a visible label, mark optional fields, describe errors in text next to the field, use autocomplete values so browsers can fill name and email and keep everything usable by keyboard. WCAG 2.2 criteria 3.3.1 and 1.3.5 cover the error and input purpose parts.
Track the share of visitors who submit and who schedule, and compare against a baseline for the same traffic source. Also check the quality of requests, how quickly you reply and whether the tracking fires. Test the page with five buyers and fix the point where they hesitate.
About the author
Jenish is a designer at Kraftbase, a product messaging and UI/UX design studio in Vadodara, India, that helps AI and B2B SaaS teams in the US, UAE and India explain and design what they’ve built.
Sources
Understanding Success Criterion 3.3.1: Error Identification, WCAG 2.2, W3C, read Nov 3, 2026
Understanding Success Criterion 1.3.5: Identify Input Purpose, WCAG 2.2, W3C, read Nov 3, 2026
Demo Page Promise Check: Kraftbase framework, not a published standard
Page review
Does your demo page keep its promise?
Send us your demo page and we will check it against the four lines.
The demo request page is where interest becomes a name in a CRM, and it is often the least designed page on the site. A form with eleven fields, a vague line that says “Our team will be in touch” and nothing about what the demo will cover. The visitor wanted to see the product, and the page asks for a lot before it says anything.
This guide shows you demo request page design for B2B SaaS. You will get a four line promise check, a table of form fields with what each costs, what to show beside the form, how to design the confirmation and an accessibility checklist. The form advice is our own judgment from design work, not a measured result.
Key takeaways
Tell visitors what happens after they submit: who contacts them, when and what the demo covers.
Ask only what you need to route and prepare the call. Every extra field is a cost to the visitor.
Show proof and the product next to the form, not only a form on its own.
Design the confirmation page as the next step, not a dead end.
Make the form accessible: labels, error messages and input purposes.
What is a demo request page?
A demo request page is the page where a visitor asks to see the product with someone from your team. It is the conversion point for many B2B SaaS sites, so it deserves its own design.
The visitor arrives with a question: is it worth giving these people my details? The page has to answer it. That means a clear promise, a short form, enough evidence to feel safe and a believable next step.
Before the page, check that the site sends the right visitors to it. A SaaS Website Messaging Audit shows whether visitors understand what they are asking to see.
What is the Demo Page Promise Check?
The Demo Page Promise Check lists four things the page must say before a visitor will fill in a form. If any is missing, the form feels risky.
Line | The visitor’s question | Example form |
|---|---|---|
1. Who | Who will I talk to? | “A product specialist, not a sales script” |
2. When | How soon will I hear back? | “We reply within one working day” |
3. What | What will the demo cover? | “Your use case, on your data if you like” |
4. Cost | What does it cost me? | “Thirty minutes. No obligation.” |
Write the four lines, then put them next to the form. If you cannot promise one truthfully, fix the process before you fix the page. A promise you do not keep, such as a reply time that is not met, costs more trust than no promise.
Which form fields should you ask for?
Ask for what you need to route the request and prepare the call, and gather the rest in the call. Each field has a cost for the visitor, and a benefit for you. Weigh them.
Field | Why you want it | Cost to the visitor | Option |
|---|---|---|---|
Work email | To reply, and to find the company | Low | Keep |
Name | To address them | Low | Keep |
Company | To route and prepare | Low | Keep, or infer from email |
Role | To tailor the demo | Low to medium | Keep, as a short list |
Company size | To route | Medium | Ask only if routing needs it |
Phone number | To call | High for many | Make optional, say why |
“What do you want to see?” | To prepare | Medium | Optional, with a prompt |
Budget or timeline | To qualify | High | Ask on the call |
Start with the shortest form that lets your team respond well, and add a field only when someone can say what they will do with the answer. Avoid fields that exist because another company has them.
Pro tip: For each field, name the person who uses the answer and the moment they use it. A field with no user is a field to remove.
What should sit next to the form?
Place proof and a preview of the demo next to the form so the visitor does not have to leave the page to feel safe. Many demo pages show only a form, which gives the visitor little reason to go on.
The four promise lines from the check above.
One customer quote or named customer, close to the form.
A short preview of the product, such as a screen or a ten second loop.
A list of what the demo covers, in the visitor’s words.
A secondary route for people not ready to talk, such as a recorded tour or a documentation link.
Do not add a full navigation bar and ten links around the form. Keep the exits few and the focus on the action.
How should the form behave?
A good form is short, forgiving and clear about errors. Interaction details often decide whether the form is finished.
Label every field above the input, not only inside it as placeholder text.
Mark optional fields as optional, and avoid marking everything required.
Use the right keyboard on phones for email and phone fields.
Validate gently, as the visitor goes, and explain how to fix each error.
Keep the button label specific, such as “Request a demo”, and show a working state after the click.
Do not clear the form when something fails.
If the page uses a booking calendar, test it on a phone and check that times display in the visitor’s time zone.
How do you design the confirmation page?
Treat the confirmation as the next step in the conversation. It is the moment of highest interest, and it should not end with “Thanks.”
Element | What it does |
|---|---|
A clear confirmation | The visitor knows it worked |
What happens next | Repeats who, when and what, in order |
A calendar link or booking step | Lets them pick a time now, if that fits your process |
Something useful to do while waiting | A short tour, a use case page or a case study |
A confirmation email | Arrives within a minute with the same details |
Track the confirmation as a conversion in your analytics, and test that the tracking fires after the real form submit, not only on page load.
How do you make the form accessible?
Use real labels, clear text errors and input purposes that browsers can read. WCAG 2.2 covers each of these, and passing them also helps every visitor.
Error identification (3.3.1, level A). The criterion reads: “If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.” Color alone is not enough.
Input purpose (1.3.5, level AA). Use autocomplete values for fields about the user, such as name, email and phone, so tools can fill them. An email type alone does not meet the criterion.
Keep every control reachable and usable with a keyboard, and keep the focus visible.
Check color contrast on labels, placeholders and the button.
Test the form with a screen reader and by tabbing through it.
What stops visitors from booking a demo?
Most demo pages lose people to a long form, a vague next step or a dead end after they submit. Watch for these six:
Too many fields. The cost of the form outweighs the interest.
No promise about what happens next. The visitor guesses.
A form and nothing else. No proof, no preview.
Mandatory phone number with no reason. Many visitors leave.
A dead end confirmation. The best moment is wasted.
Not testing the tracking. You cannot tell what works.
How do you test the page this week?
Test with five people who match your buyer, and also test the process behind the page.
Show the page and ask: what happens if you fill this in?
Ask them to complete it on a phone and note where they hesitate.
Submit a real test request and time the reply against your promise.
Check that the CRM, the email and the analytics all received it.
Pass if four of five can state the promise, and your reply meets it.
Pro tip: Submit the form yourself from a personal email every month. You will find broken routing, slow replies and failed emails before a customer does.
Also read: SaaS Homepage Redesign Checklist.
To see how we design product pages, read our ORYN AI agent monitoring landing page case study, or browse all of our case studies.
Does your demo page keep its promise?
Send us your demo page and we will check it against the four lines. Book a page review · See our work
Demo request page design FAQs
A short form, four clear promises about who will contact the visitor, when, what the demo covers and what it costs, proof such as a customer quote, a preview of the product and a route for people not ready to talk. The confirmation page should repeat what happens next.
As few as let your team respond well. Many B2B forms work with name, work email, company and role, plus an optional field for what the visitor wants to see. Add a field only when you can say who will use the answer and what they will do with it.
Usually it should be optional, with a line explaining why you ask. A required phone number is a high cost for many visitors who prefer email. If your process depends on a call, say so, and let people choose a booking time instead.
Confirm that the request worked, repeat who will contact them, when and about what, and offer a calendar link if it fits your process. Add something useful to do while they wait, such as a product tour or case study, and send a confirmation email within a minute.
Yes. Kraftbase is a product messaging and UI/UX design studio for AI and B2B SaaS companies. We design the page, the form and the confirmation together with the message, so a visitor sees a clear promise and a believable next step.
Give every field a visible label, mark optional fields, describe errors in text next to the field, use autocomplete values so browsers can fill name and email and keep everything usable by keyboard. WCAG 2.2 criteria 3.3.1 and 1.3.5 cover the error and input purpose parts.
Track the share of visitors who submit and who schedule, and compare against a baseline for the same traffic source. Also check the quality of requests, how quickly you reply and whether the tracking fires. Test the page with five buyers and fix the point where they hesitate.
About the author
Jenish is a designer at Kraftbase, a product messaging and UI/UX design studio in Vadodara, India, that helps AI and B2B SaaS teams in the US, UAE and India explain and design what they’ve built.
Sources
Understanding Success Criterion 3.3.1: Error Identification, WCAG 2.2, W3C, read Nov 3, 2026
Understanding Success Criterion 1.3.5: Identify Input Purpose, WCAG 2.2, W3C, read Nov 3, 2026
Demo Page Promise Check: Kraftbase framework, not a published standard
Page review
Does your demo page keep its promise?
Send us your demo page and we will check it against the four lines.