How to Give a Sales Demo: The 14-Item Checklist

A good sales demo is a buyer decision session, not a complete product tour. It carries confirmed discovery into a small number of relevant product moments, gives buyers room to test their interpretation, labels every proof claim, survives technical failure, and ends with an evidenced next step.

This guide is based on primary operational and regulatory sources accessed August 8, 2026, plus editorial practice. We did not analyze a proprietary call corpus or rely on unsupported conversion, talk-ratio, attention-span, or “best demo” benchmarks. Timing examples are planning ranges, not performance guarantees.

This page is the canonical how-to and checklist for giving a sales demo, including the prior 24 hours and immediate pre-screen check. The demo script template provides adaptable language, while sales demo best practices covers broader principles. Do not create a separate demo-checklist page for the same job.

Bridge discovery into the demo contract

Direct answer. Start by restating the buyer’s situation, desired change, constraints, and decision in their language. Ask what changed since discovery. Agree on which two or three questions today’s demo must answer. Only then share the screen.

Discovery produces hypotheses, not permanent truth. Before the demo, turn notes into a bridge document with five fields: buyer statement, consequence, desired state, evidence to show, and decision supported. Keep the original wording and source. If the buyer said reporting requires manual reconciliation, do not inflate that into “the team loses millions to bad data.”

If discovery is incomplete, say so and spend the opening filling the gaps. The sales discovery call guide and discovery checklist can help. A shorter, accurate demo is better than a polished response to the wrong problem.

Prepare the demo in the prior 24 hours

The prior-day check protects relevance. It should leave a one-page run sheet that a backup presenter could understand. Complete items one through eight of the printable checklist at the end.

1. Confirm the buyer contract. Re-read notes and recordings you are authorized to use. Write the current problem, desired outcome, constraints, decision, and exact questions the demonstration should answer.
2. Map attendees and authority. Confirm names, roles, technical depth, accessibility needs, and their part in the decision. Ask the champion whether a missing stakeholder requires different evidence or a later session.
3. Choose the critical path. Select two or three product moments. For each, specify starting state, action, visible result, buyer relevance, limitation, and check question. Remove every screen that does not support the agreed decision.
4. Prepare branches. Write a shorter path, technical-deep-dive path, executive path, and “not supported” answer. Identify which branch requires a specialist instead of improvisation.
5. Build the proof register. Classify each artifact as live product behavior, configured example, synthetic scenario, customer-reported result, internal measurement, third-party evidence, roadmap, or unsupported. Attach source, scope, date, and owner.
6. Sanitize the environment. Use synthetic or explicitly authorized data. Remove customer names, production credentials, private messages, internal channels, personal bookmarks, notifications, browser history, and unrelated CRM records.
7. Test the route and backup. Rehearse from a clean login with buyer-like permissions. Create a short recording or screenshots for the critical path and verify that they contain no sensitive data.
8. Send the decision agenda. State the buyer questions, participation expected, and proposed next-step decision. Invite corrections before the call rather than surprising the room.

For complicated meetings, use the sales call-prep workflow to assign evidence owners and close gaps before the presenter enters the room.

Run the immediate pre-screen check

The immediate check protects execution. Join early enough to test without making the buyer wait. Complete checklist items nine through fourteen:

• Load the correct tenant, persona, permissions, dataset, and product state; perform the first critical action.
• Check meeting link, camera, microphone, speaker, screen-share permission, resolution, zoom, and media audio.
• Close unrelated apps and disable notifications. Share a tab or dedicated window rather than the full desktop when feasible.
• Open the run sheet, proof register, objection parking lot, next-step calendar, and named backup artifacts.
• Confirm the backup presenter or specialist, handoff phrase, and retry limit.
• Check recording status and the organization’s notice, consent, retention, and access requirements before recording.

Google Meet’s official presentation guidance documents tab, window, and full-screen sharing plus audio and permission differences. Its Workspace sharing tips specifically recommend a single tab to hide sensitive information and turning off notifications where necessary. Check the equivalent controls for the platform you actually use.

Use the show, tell, ask loop

Use a repeatable show, tell, ask loop for each product moment. It keeps the buyer active and prevents narration from outrunning evidence.

1. Frame. Reconnect the moment to a confirmed buyer statement: “You said approvals become unclear after the handoff. Let’s test that path.”
2. Show. Perform one coherent action from starting state to visible result. Do not open unrelated menus or narrate every click.
3. Tell. Explain what happened, the product/configuration responsible, and the relevant boundary. Distinguish default behavior from custom setup.
4. Ask. Invite interpretation: “How does that compare with your current approval?” or “What would prevent this from fitting?”
5. Record. Capture confirmed fit, gap, question, owner, and whether the demo contract changed.

“Any questions?” is too broad. Ask the participant closest to the workflow to interpret what they saw. Then ask a stakeholder with a different concern. Silence is not proof of agreement; explicit buyer language is evidence.

Label proof and protect data boundaries

The visual credibility of a demo can make an unsupported claim feel true. Label the evidence at the moment it appears. Say “this is live in our demo tenant,” “this is synthetic data,” “this is a configured workflow,” or “this is planned, not available today.” Do not let a mockup look like shipped functionality.

The FTC’s advertising guidance says claims must be truthful, non-deceptive, and evidence-based. That is a useful baseline for product demos: objective performance, savings, accuracy, security, customer-result, and comparative claims need evidence appropriate to the claim. A testimonial is not universal proof.

For security-sensitive buyers, agree on a separate evidence lane. The demo presenter should not guess about encryption, data residency, subprocessors, retention, model training, access, audit logs, incident response, or certifications. Use approved security material and route unknowns to the named owner. The fintech demo security guide offers a deeper checklist even outside financial services.

Design participation and branch handling

Participation is not a trick to maintain attention. It lets the buyer test whether the product model matches their work. Ask before handing over control, avoid exposing administrative privileges, and provide an observer path for people who cannot or do not want to interact.

Use branch cards rather than improvising:

• Relevance branch: if the buyer changes the priority, restate the new question and choose the closest rehearsed path.
• Depth branch: if a technical participant asks how it works, answer the documented boundary, then decide whether to continue or schedule specialist validation.
• Constraint branch: if a required integration, permission, region, or workflow is unsupported, say so clearly and record the consequence.
• Objection branch: pause the demo, clarify the concern, answer with evidence, confirm whether it is resolved, then choose whether to resume.
• Time branch: when time contracts, prioritize the decision-critical moment and move optional material to a follow-up artifact.

Never force a branch merely because it was rehearsed. If a request would expose sensitive data, create an unsafe configuration, or imply unavailable capability, stop and explain the boundary. Use the sales objection-handling framework for the listening and clarification step.

Recover when the live demo fails

A backup is part of the demonstration, not an admission of poor preparation. NIST describes contingency planning as coordinated plans, procedures, and technical measures that support recovery after disruption. NIST’s contingency-planning overview includes alternate equipment and alternate processing as recovery approaches. A sales demo is smaller in scope, but the discipline transfers.

Set a retry limit before the meeting—usually one controlled retry for the failed step. If it still fails, state what failed and what remains unproven. Move to the approved recording, annotated screenshots, architecture diagram, or backup tenant. Label the artifact and its capture date. Do not play a recording as though it were live.

If the failed behavior is decision-critical, the backup explains intent but does not complete validation. Assign an owner, repair the environment, and schedule a focused verification. If it is not decision-critical, park it and protect the meeting’s core decision.

Common recovery errors include repeated refreshing, silently changing accounts, blaming the buyer’s network, exposing production data, opening source code or admin consoles without authorization, and promising that the failure “never happens.” Calm transparency preserves more trust than an improvised cover story.

Close on evidence, owners, and next steps

Stop screen sharing before the close so attention returns to the people. Read back four evidence buckets: confirmed fit, confirmed limitation, unverified question, and changed requirement. Ask each relevant stakeholder whether the summary matches their interpretation.

A next step should contain a decision, participants, owner, date, input, output, and acceptance criterion. “Send security docs” is a task, not a buying step. “Security lead and vendor owner review the data-flow diagram by Thursday to decide whether a controlled proof of concept can begin” is inspectable.

The discovery follow-up guide provides a concise evidence-led recap pattern. Apply the same principle after a demo: no invented consensus, no hidden limitation, and no vague “circle back.”

Rehearse and score the demo

Rehearse the exact critical path from a cold start, not a privileged session already placed on the perfect screen. Include one skeptical participant and one operator unfamiliar with the account. Inject a failed login, slow response, branch question, missing feature, and security question.

Score each dimension from zero to four: discovery fidelity, decision clarity, critical-path relevance, show/tell/ask execution, proof labeling, buyer participation, branch handling, time control, security/data safety, failure recovery, and next-step evidence. Define anchors: zero means absent or unsafe; two means usable but inconsistent; four means clear, evidenced, and repeatable. Any security/data boundary failure is a hard stop regardless of total.

After rehearsal, fix the two lowest dimensions and rerun. Do not optimize charisma while the environment contains customer data or the proof register is empty. Save the run sheet, evidence, failure notes, and revision owner so the next demo benefits.

Print the 14-item sales demo checklist

Gangly disclosure. Gangly’s repository says Call Prep can assemble CRM history, contact context, prior conversation summaries, likely objections, a recommended talk track, and discovery questions. Quality depends on CRM and connected-source data. Live Call Coach supports Zoom and Google Meet and surfaces guidance while the rep drives. Post-call notes are drafts the rep reviews before CRM sync. These are first-party statements, not independently tested outcomes.