A pre demo questionnaire: twelve questions before a demo goes on the calendar

What a pre demo questionnaire is

A pre demo questionnaire is a short, specific set of questions to ask before a demo goes on someone’s calendar: who is asking, what they need, and whether an hour with them is worth it for both sides.

The six groups below cover what a team needs to decide before handing over the time: who this is, what problem they have, what they’ve tried, timing, who else is involved, and what would make the hour pointless. Ask all twelve, or pick four.

This list is narrower than a full inbound lead qualification framework. Treat it as a pre qualification questionnaire example with one job: deciding whether one demo is worth an hour.

Who this is

Before anything else, the team needs to know who is actually on the other end of the request.

• What’s your role, and who else would join the call? A useful answer names a title and one other person who’d sit in. A useless answer is a name with no role, or a promise to loop people in later.
• What does the company do, in one plain sentence? A useful answer names a product and a customer. A useless answer is a slogan with neither.

What problem they have

This is the question a lot of forms skip in favor of a dropdown, and it tells the team whether to prioritize the request.

• What’s happening right now that made you look for something like this? A useful answer names a recent event: a deadline, an incident, a new hire, a board request. A useless answer is a general wish, like wanting to be more efficient.
• What happens if this stays unsolved for another quarter? A useful answer names a real cost tied to a date. A useless answer is a shrug, or “not a big deal, just exploring.”

What they have already tried

Someone who has already tried and rejected two alternatives is a different conversation than someone who typed a search query an hour ago.

• What have you already tried or looked at for this? A useful answer names specific tools, vendors, or a manual process built by hand. A useless answer is “nothing yet.”
• What didn’t work about it? A useful answer names a specific failure: too slow, too expensive, missing one feature. A useless answer is general dissatisfaction, no detail attached.

Timing

Timing questions do double duty: they surface urgency, and they surface whether the urgency is real.

• When do you need this live? A useful answer ties a date to something external: a launch, a renewal, a deadline someone else set. A useless answer is “as soon as possible,” with nothing behind it.
• Is there budget approved, or is that still being worked out? A useful answer names a number, a range, or a named approval step. A useless answer is silence, or a change of subject.

Who else is involved

A demo pitched to the wrong room wastes the hour even when every other answer was good.

• Who else needs to agree before you can buy this? A useful answer names a role: an engineering lead, a finance approver, a co-founder. A useless answer is “just me,” from someone who plainly is not the only person who decides.
• Has anyone on your team used something like this before? A useful answer names a comparable tool and what they thought of it. A useless answer is silence, which usually means the demo starts from zero.

What would make this a waste of both sides’ time

The point of this last group is to surface a hard blocker before anyone spends an hour on the call.

• Is there anything about how this works that would rule it out for you? A useful answer names a specific constraint: a platform, a region, a security requirement. A useless answer is “not that I know of,” with no thought behind it.
• What would you need to see on the call to call it worth your time? A useful answer names one concrete thing to show. A useless answer is “just show me what you’ve got.”

Three ways to ask these questions

The trade-offs differ more than the questions do.

• A form field wall. Fast to build and hard to skip, but every added field gives someone a reason to leave before finishing. A determined time-waster can fill in twelve boxes with twelve useless answers just as fast.
• An email reply. Cheaper than a form and reads less like one. It is slower: some people never answer, and the ones who do can take a day over a question a call would settle in ten seconds.
• A short phone call, what some teams already call a discovery call. It is the only one where a vague answer gets a natural follow-up instead of sitting unexamined in a spreadsheet, though it needs someone answering the line the same way every time.

Turning the list into a brief

Once the questions are settled, write them into a brief and put a phone line behind it. A Callable, an agentic telephony line, can ask these questions on every call, answer the basics itself, and take down anything else as a message for a person to read.

A brief like this one covers the same ground as the twelve questions above, written in plain language rather than a form schema.

This line answers calls to your demo and sales number. Greet the caller and ask, in normal conversation rather than a rigid list: their role and who else would join a demo; what their company does in one sentence; what’s happening right now that brought them to call; what they have already tried and what didn’t work about it; when they need this live and whether a budget exists yet; who else has to agree before they can buy; and whether anything about how the product works would rule it out for them. Ask one question at a time. If the caller asks what the product costs or how it works at a high level, answer from what is written in this brief. Anything else, a technical question, a price negotiation, or a request for someone by name, gets a plain answer and a note of what was asked. Do not promise a specific callback time. End every call by telling the caller someone will read the transcript and reach out.

Setting it up

Getting this running follows the same approach as any other Callable, whatever question set ends up in the brief.

• Write the brief. Paste the questions in using plain language, along with answers to whatever a caller might ask about the product.
• Test it. Call the line with a few different personas, including a deliberately weak one, and check it takes messages instead of guessing.
• Publish it. Put the number wherever the demo request currently lives: the contact page, the confirmation page, or today’s away message.
• Read the transcripts. The team still decides who gets the hour, now from a transcript that answers the same questions every time.