Use the demo to investigate how the supplier handles your workflow, decisions, and exceptions. A polished interface is only one part of delivery capability.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
Bring a real sequence
Describe a request that enters your business, changes hands, and ends in an agreed result. Ask the supplier to explain how they would represent its states and responsibilities. Make clear which details are illustrative so a discussion is not mistaken for a product commitment or an estimate.
Ask about an awkward case
Change one fact: the assigned person is absent, the customer submits twice, or a connected system is unavailable. Ask who notices, what is preserved, and how the work resumes. You are looking for a coherent operating explanation rather than a claim that errors never happen.
Investigate the working relationship
Ask how business decisions become implementation work, how demonstrations are reviewed, and where unresolved questions are tracked. Request an example of an acceptance criterion without asking for another client's confidential material. Find out who you will work with and which responsibilities remain with your team.
Run the same five checks in every demo
Here is a suggested demo agenda for a request-management project. Use sample records without customer details. After each check, record demonstrated, described or still untested; these are different levels of evidence.
| Ask the supplier to show | Look for this evidence | Follow-up question |
|---|---|---|
| One request from submission to completion | The record, responsible person and next action stay connected as the work changes hands. | Which steps would our team still complete outside this system? |
| The same request submitted twice | A deliberate duplicate policy and an understandable result for the user. | How does the user find the original request? |
| A failed connection to another tool | The unfinished work remains visible, with enough context for an owner to recover it. | Who notices the failure, and what happens if they are absent? |
| An account without the required permission | The restricted action is refused; hiding its button is not the whole check. | How will permissions be tested with our actual roles? |
| Handover to our operating team | An example of the documentation, access and support process included in the proposed scope. | What must be agreed separately before launch? |
Leave with evidence gaps
Write down what was demonstrated, what was described, and what still requires discovery. Do not treat a prototype as proof that an integration has been tested in your environment. The next conversation should resolve specific gaps and establish whether a scoped engagement is justified, rather than simply repeat the presentation.