A Testing Checklist Before Your Next Customer Demo
The feature works in development. Your demo account has a different role, a half-finished setup flow, and a third-party connection that expired yesterday.
A customer demo is a specific operating situation. You need to know whether the account, data, and environment you will actually use can complete the story you intend to tell.
The review can be narrow. You are checking a defined presentation path and its likely interruptions. That evidence supports demo readiness; it does not establish that every part of the product is ready for a wider release.
Write the demo as one customer outcome
For a fictional support SaaS, the story might be: import a prepared conversation, assign it to a teammate, draft a reply, and find the updated conversation in the queue.
List the starting screen, account role, workspace, required data, and final result. Mark the steps where you intend to type, create data, call an external service, or change something that affects the next rehearsal.
Keep the story aligned with the customer’s problem. A list of unrelated menu clicks creates more setup requirements and makes it harder to recover when a dependency is unavailable.
If a feature is still a prototype, decide how you will describe that status before the call. Label any prerecorded material and prepared output clearly.
Inspect the exact demo account
Sign in using the browser and method you plan to use during the call. Verify the workspace, role, plan, and relevant permissions.
Open the first screen and check for incomplete setup, stale banners, trial notices, or missing data. If billing access is needed, use an appropriately configured demo entitlement; do not rely on an unrelated personal subscription accidentally supplying access.
Use fictional or explicitly approved sample content. Ensure that opening search, recent items, notifications, or workspace menus will not expose another customer’s information.
Prepare the account without weakening the permissions the demo is meant to show. If the story is about a regular support agent, rehearsing only as an owner leaves that story unverified.
Check the data before running the story
Verify that the example conversation exists, contains the intended messages, and belongs to the right workspace. Check that the teammate used for assignment is an active member.
If the story changes the item’s status, establish a repeatable reset procedure. Prefer a new disposable item for each rehearsal or an explicit fixture reset in a demo environment.
Avoid a test that locates “the first conversation” when the order changes after assignment. Use a recognizable marker and follow the same item to its final state.
For a generated response, define what needs to be true without requiring identical wording every time. It might need to address the sample question, remain editable, and appear only as a draft. Review the content itself if you intend to show it to a customer.
Walk the presentation route
Run the actual sequence rather than jumping straight to the destination through a bookmarked internal page.
| Checkpoint | Pass condition |
|---|---|
| Opening screen | Intended account and sample are ready without hidden setup |
| Primary interaction | Action is available for the demonstrated role |
| External dependency | Required connection works in this environment |
| Save or assignment | The same item has the intended result after reopening |
| Return to queue | Updated state appears where the story says it will |
| Screen layout | Controls and results remain readable at the presentation window size |
If you will present in a narrow window beside call controls, rehearse at that size. A full-screen desktop review may miss a menu or dialog that becomes awkward during the actual call.
Separate preparation from actions with side effects
Review whether the journey sends an email, posts a message, charges a payment method, or changes an external system. Use the supported sandbox or controlled test destination for those steps.
In the support example, a generated reply can remain a draft. If sending is part of the demo, prepare a recipient you control and verify the delivery path there. Make that boundary explicit in the rehearsal notes.
A successful simulation demonstrates the application’s behavior within that setup. State any external delivery or production behavior that remains unverified, especially if the customer asks about it.
Prepare a truthful recovery route
Decide what to do if the external generation service is slow or unavailable. You may be able to show a previously completed example, resume at a later step, or use a clearly identified recording.
Verify that fallback before the call. Keep it tied to the same product capability, and identify it as prepared material when used. A fallback should help explain the workflow without implying that a failed live operation succeeded.
Know which screen remains safe to show after an error. A recovery plan is much easier to use when the interface provides a retry or a way back to the prepared queue.
Leave the account in its starting state
Rehearsal changes data. Before the call, restore the intended sample or prepare a fresh one, then check the starting screen again.
Record the environment and deployed version. If a new deployment lands after rehearsal, retest the presentation path when the affected behavior or dependencies may have changed.
A compact handoff note can contain:
- Account role, workspace, and starting URL.
- Sample marker and intended final state.
- Integrations and test destinations involved.
- Last verified version and any known issue.
- Reset instructions and labeled fallback location.
HiTest can keep a repeatable browser test for the presentation route using a dedicated test account. Keep the demo’s data reset and external side-effect boundaries explicit.
For a broader public launch, use the pre-launch testing checklist. A successful rehearsal is useful evidence for the specific demo you prepared.