Comparing a live product demo with a prepared sales presentation

Use a prepared presentation to understand a supplier's proposed approach. A live product demo shows actions in the account and configuration displayed. Treat them as different evidence types; neither alone proves the product will work with your data, permissions and connected systems.

Give both formats a useful job

A presentation can set out the problem the supplier believes it is solving, the proposed workflow, implementation responsibilities and dependencies. Slides suit a process spanning several systems. Ask the presenter to separate what exists in the proposed edition from what would need configuration, another service or future work.

A live demo should expose actions and states that slides cannot. Ask to see a user start a task, make a change, encounter an exception and find the final result.

Identify the edition, user role and environment on screen, and note any difference from what is being offered. A smooth scripted route may be informative, but it does not establish what an ordinary user can do in your organisation.

Send one scenario before the session

Choose a representative task with a normal route and a meaningful exception. For a hypothetical campaign workflow, ask a supplier to create an enquiry record with a source label, correct that label, show the receiving user's view and explain how the correction reaches another system. Give each supplier safe sample information and the same expected result.

Let suppliers prepare so the request is fair and feasible. During the session, ask them to show the steps in the proposed product.

If a step cannot be shown, ask why: missing setup, an unavailable edition, an absent connection and an action outside the product are different limitations. Record the answer without treating a verbal assurance as an observed result.

Agree who will ask questions and take notes. Include someone who performs the task and, where needed, someone who owns the receiving system. Keep the session focused on the scenario.

Record the evidence at the level shown

Where possible, ask an ordinary-role user to perform or view a relevant step. Note when a demonstrator switches to administrator access. If an approval, export or corrected record is visible only to an administrator, that distinction matters for the workflow.

Record what was preloaded and what had to be changed during the session. An unscripted question can reveal how the supplier handles an exception, but a single awkward moment is not a production test. Ask for a follow-up demonstration if setup hid a critical result.

Decide what needs stronger evidence

After each session, write down observed actions, supplier explanations, dependencies and unanswered questions separately. Compare suppliers against the same expected outcome, while allowing different ways to achieve it.

If the decision turns on data transfer, permissions or usability for your staff, define a later validation step with the relevant owners. A limited trial or proof of concept has a different burden of evidence from a sales session.

The comparison is useful when a colleague can tell which parts were shown, which were promised and what still needs checking before a purchase decision.

Evidence Requirements for Key Evaluation Areas