A demo request page that gets the request to sales fast

Fields: what sales needs, nothing more

Every field on a demo form should change what the salesperson does. If nobody reads an answer before the call, drop the question. A common working set:

Asking for a work email rather than any email is reasonable for B2B. Requiring a phone number is not, unless you call every lead; it's the field people most often abandon a form over.

A slot, or a promise

There are two ways to finish the form, and the choice depends on how you sell.

Book a slot

The visitor picks a time on the page. Fast and satisfying, and it suits products with one standard demo. It works less well when you need to qualify first or route to different people.

Reply promise

The visitor sends the form and the page says "we'll email you within one working day to arrange a time". Slower, but sales can research the company and send the right person. Keep the promise: a reply three days later reads as indifference.

Whichever you choose, the thank-you page should restate it: what happens next, by when, and from whom.

The rest of the page

• What the demo covers and how long it takes. "30 minutes, tailored to your team, with time for questions."
• Who it's for: if you don't serve teams under ten, say so here.
• Pricing, or a link to it. Hiding prices behind a demo puts off buyers who just want a ballpark.
• A self-serve route for those who'd rather not talk to sales: a free trial, a recorded walkthrough, documentation.
• Logos or examples only if you have permission to use them.

Routing requests to HubSpot and Slack

Speed of reply is where demo pages are won. Two Anticode connectors help. HubSpot receives submissions that include an email address, so each request lands as a contact your sales team already works from. Slack posts each request into a channel, so someone sees it within minutes rather than at the next inbox check. Use both: Slack for the alert, HubSpot for the record. Each submission is sent once without retries and is always kept in your dashboard, sealed at rest. The demo request workflow and the guide to sending website leads to a CRM go further.

How Anticode builds it

Describe the product and the demo, for example "a request a demo page for our scheduling software for clinics, with what the demo covers, pricing link and a form asking for work email, company and team size". The built-in contact form asks for a name, email and message, and the booking form for the service, day, time, name, phone and email. For a reply-promise form with company and team size, use a custom form tied to a site function (up to 30 plain-text fields). A site function can also call your own HTTPS endpoint, signed, if you want your own system to score or route the request; its reply is shown on the thank-you page.

Limits

• No round-robin assignment between reps. Do that in HubSpot.
• A simple calendar. The built-in booking calendar offers six fixed times over the coming days (Mondays skipped), with no calendar sync and no video link created; you confirm each booking and send the invite yourself.
• No company enrichment or lead scoring built in.
• No embedded scheduling widgets: published pages can't embed outside tools. Link to your scheduling tool instead if you prefer it to the built-in calendar.

Questions people ask

How quickly should we reply to a demo request?

As soon as you can within working hours. A same-day reply is a sensible standard; state yours on the page and keep to it.

Can the form reject personal email addresses?

A site function on your own endpoint can refuse a submission with a message, so you could check the domain there. It runs when the form is sent, not as the visitor types.

Can we see which page the request came from?

Site analytics show page views by source. For per-request attribution, use a separate page or form per campaign.