Digital adoption
Questions to ask before the software demo
Arrive with your workflow, your data and your deal-breakers written down—so the demo answers your questions, not the vendor's.
The demo was impressive, the purchase was fast, and six months later the team is back on spreadsheets because the tool does not match how work actually flows.
A demo is a test you design. Bring your real scenarios, your exception cases and your exit questions—and score every tool against the same list.
Write your scenarios before seeing anything
Vendors demo strengths. Your job is to test your workflow: three to five real scenarios from request to completion, including the exceptions that eat your week—the partial delivery, the changed scope, the missing approval.
Write each scenario as a story with real (anonymized) data: ‘A client calls to change a job after the crew is dispatched. Show me what happens.’ If the tool cannot show it, that is an answer.
Agree internally what is a deal-breaker versus a preference before the demo. Otherwise the slickest feature wins the argument your operation never had.
The questions vendors do not volunteer
Data: Can we export everything, in a usable format, at any time, at no extra cost? What happens to our data if we leave or if you are acquired?
Fit: Which of our scenarios requires a workaround, and who has made that workaround work at a company our size? Can we speak to them?
Cost: What is the three-year total cost at our size—licences, implementation, training, the integrations we actually need, and the price tier we will hit as we grow?
Support: Who helps us after go-live, in which languages, at what response time? For Quebec teams, ask explicitly about French-language support and interfaces.
Score every tool against the same list
Build a simple scorecard from your scenarios and deal-breakers before the first demo. Score each tool immediately after its demo, while memory is fresh, with the same people in every session.
Include the people who will use the tool daily, not only the people buying it. A tool the coordinator refuses is expensive shelfware.
Run a paid pilot or a bounded trial on real work before a full commitment when the vendor allows it. A week of real exceptions teaches more than another demo.
A demo scorecard to copy
| Area | Score 1–5 and note evidence |
|---|---|
| Core scenarios | Each of your 3–5 real workflows shown end to end |
| Exceptions | Your two most common exception cases handled visibly |
| Data ownership | Full export, usable format, no ransom clause |
| Total cost | Three-year cost at your size, in writing |
| Support & language | Post-launch help in your team's working languages |
| References | A comparable company you can actually call |
A buyer's checklist, not an endorsement or rejection of any product category.
Try it in your operation
- Write your three to five scenarios and deal-breakers before booking any demo.
- Score the next two demos with the same scorecard and the same observers.
- Call one reference customer of similar size before any decision.
- Where possible, run a bounded trial on real work before signing.
How to tell whether it helped
After any purchase, check at three and six months: are the core scenarios actually running in the tool, or did the team route around it? Adoption by the people doing the work is the only score that matters.
Sources & review notes
- [1]Digital adoption guidance for small and medium businesses
Canada Digital Adoption Program (archived program resources)
Software contracts can include auto-renewal, data and price-escalation clauses. Have significant agreements reviewed before signing.