A practical decision guide
Software demo checklist
Leave the meeting with answers you can use. Ask each vendor to demonstrate the same work, explain the conditions and name the questions that still need a test.
1. Send the workflow before the meeting
Choose a task your team performs regularly and describe its starting point and desired outcome. Include the people, records and handovers involved. Use fictional or sanitised sample data so you can repeat the task without sharing customer information.
Separate essential requirements from preferences. A useful prompt is: show how a sales representative passes a qualified lead to delivery while keeping its history visible to the new owner. “Show us the CRM features” leaves the vendor to choose what matters.
Send the task and proposed plan to the vendor in advance. Ask them to identify anything that needs a different edition, an integration, paid setup or a later release. Keep future promises separate from what is available to demonstrate.
Write requirements with a clear acceptance test2. Give the meeting a practical agenda
The following 45-minute agenda is a suggested starting point, not a benchmark. Adjust it to the complexity of the task. Keep the same structure across vendors so that a longer presentation does not become an unfair advantage.
| Time | Activity | Leave with |
|---|---|---|
| 5 minutes | Confirm the workflow, roles and proposed plan. | A shared understanding of scope. |
| 20 minutes | Demonstrate the everyday task from start to finish. | Observed steps, workarounds and required configuration. |
| 10 minutes | Try an exception, access change or export. | Evidence about a less convenient path. |
| 5 minutes | Confirm limits, add-ons and implementation work. | Conditions to match against the written quote. |
| 5 minutes | Review unresolved questions and the trial plan. | An owner and next step for each open item. |
3. Ask questions that expose the conditions
Ask the vendor to show the proposed edition and explain any preparation they performed. A polished demonstration may use an administrator account, a specially prepared dataset or features outside the quoted plan. Record those conditions before comparing the result.
When a step fails, write down what happened and what would be needed to fix it. One failure in a demonstration is evidence about that attempt, not proof that the product can never perform the task. Likewise, a successful demonstration is not proof that your team can run the workflow unaided.
| Ask | Why it helps |
|---|---|
| Can a normal user repeat this task? | Separates administrator access from the intended role. |
| Which plan and add-ons are in use? | Connects the demonstration to the offer you would buy. |
| What happens when the record is incomplete? | Shows validation, error handling and recovery. |
| Can we export the result and its attachments? | Makes the exit path concrete. |
| Which steps need implementation work? | Identifies effort outside the subscription. |
| Can we repeat this in a trial? | Turns a demonstration into something your team can verify. |
4. Keep a compact evidence log
For each task, save the expected outcome, what was demonstrated, the plan and configuration, and a link or note that lets someone revisit the evidence. Ask permission before recording the meeting. Give any unanswered question a follow-up owner and date.
Use plain states such as demonstrated, needs a trial and unresolved. Do not translate an unanswered question into a failed requirement. The downloadable demo plan starts every result unresolved so that the worksheet does not imply a test has already happened.
5. Use a pilot to verify essential tasks
After the meeting, ask the actual users to repeat the essential workflow. Keep the sample and acceptance criteria consistent across options. Include an access change, an integration failure or an export when those are part of the requirement.
Record those observations in a scorecard only after the team agrees how to judge them. Compare costs separately on the same seat count and time period. Keep unresolved must-haves visible even when the overall impression is positive.
Plan the software pilotYour decision checklist
Checkmarks stay on this page only. Use your browser’s print command to keep a copy.
Common questions
Should the vendor follow our script?
Share your essential tasks in advance and leave room for useful context. If the vendor proposes another path, record how it changes the outcome, effort or assumptions.
Is a successful demo enough to choose?
Use it to decide what to test next. Essential requirements deserve a hands-on check by the people who will do the work.
Can I download a checklist?
The free demo planner creates a category-specific worksheet and an editable CSV. Add your own acceptance criteria before assessing a vendor.