Practical guide

How to Evaluate Business Software Before the Demo

A polished demo shows what a product does well. Before you watch it, decide what your team needs to get done and what you need the vendor to demonstrate.

Being possible is different from being a normal, supported way to use the product. Ask what it takes to make the workflow work, and who will maintain it.

Use the worksheet ↓

Bring a workflow, not just a feature list

Choose one piece of work that matters: receiving a request, assigning it, doing the work and confirming it is finished. Name who takes each step and what information they need.

Separate what must work on day one from what would be useful later. Ask the people doing the work where they repeat entry, wait for an answer or use a spreadsheet to bridge a gap.

Start: what triggers the work, and where does the information come from?
Handoff: who takes over, and how do they know it is their turn?
Finish: what counts as complete, and who needs to see it?

What does “it can do that” mean?

Ask the vendor to identify the route for each essential workflow. These are evaluation distinctions, not ratings of a product.

Built in: Show it working in the proposed plan. What setup, permissions and limits apply, and is this use covered by normal support?
Add-on or another subscription: Name the extra product, cost and support contact. Show how the combined arrangement works.
Integration or custom work: Identify who builds it, who maintains it and what happens after either product changes or the connection fails.
Workaround: Show the manual steps and exceptions. Who does them, how often, and what happens if that person is unavailable?

Ask to see the awkward part

The normal path is only part of the evaluation. Choose an exception your team recognizes and ask the vendor to walk through it.

A request arrives without a required detail.
Someone corrects information after work has started.
The usual approver is away, or a request needs to be reassigned.

An illustrative demo request

An office receives a service request, assigns a person and sends a confirmation. Ask the vendor to demonstrate a missing address, a reassignment and a canceled request. Use invented sample data, not a real customer record. This is an example to adapt, not an IT Mushroom client story.

Follow the information between tools

Decide which system holds the authoritative record for each important item. If a customer address changes, which system should be updated first, and how do the others catch up?

Ask to see an import and a usable export with sample data. A list of names is not a complete exit plan if attachments, relationships or activity history are needed to continue the work.

Which fields move automatically, in which direction, and how quickly?
How are duplicates, missing fields and conflicting edits handled?
If a connection fails, who can see it and recover the missed work?

Technical detail: what an integration claim needs

Ask which connector or API is used, which records and actions it supports, and whether the required subscription includes it. Ask about usage limits, credentials, change notices and responsibility for fixes. An available API does not by itself prove that your workflow is implemented or supported.

Check who can operate it, and what it will cost

Have the vendor demonstrate access for the people who will use, approve, administer and report on the work. Confirm that an authorized backup can take over without sharing a personal login.

Ask for a written account of the required product plan, add-ons, other subscriptions, setup, migration, training and ongoing support. Include the cost and responsibility of maintaining custom work.

What changes when staff, transaction volume, locations or services increase?
Who owns the company account, data and custom work, under the proposed terms?
How do you obtain records and attachments, remove a departing provider and leave the product?

Before agreeing to a purchase

Ask for the applicable terms and written answers about support, data access and exit. A demo is not a contractual commitment. Where the consequences warrant it, have an appropriate adviser review those terms. This worksheet does not establish legal rights or vendor obligations.

Leave with evidence and open questions

For each must-have, record what was demonstrated, what depends on extra work and what still needs confirmation. Keep an unanswered question open rather than turning a sales assurance into a confirmed capability.

A sensible next step may be a smaller pilot, a revised requirement, a costed integration or a different product. IT Mushroom recommends testing the most consequential uncertainty before committing the whole business to the change.

Take this into the demo

Copy or print this worksheet. Complete it in your own approved document. Use sample data in the demo and keep private records, quotes and contracts out of public tools.

This is a blank working template. No answers are collected or attached to Contact. You can select the text or use your browser’s print command without JavaScript.

1. Work and people

What task must work from start to finish? Who uses it, approves it and takes over next?
What must work on day one? What can wait?
Workflow / people / day-one needs: ____________________

2. Normal path and exception

Show our normal workflow using invented sample data.
Show one missing detail, correction or reassignment. Where does unfinished work appear?
Demo scenario / exception / evidence: ____________________

3. Information and reporting

Which system is authoritative for each important record? What reports do we need, and can the right people produce them?
Show an import and export. Are IDs, relationships, attachments and history included where we need them?
Records / reports / sample export to review: ____________________

4. Supported route and connections

Is each must-have built in, an add-on, an integration or a workaround? Is this a normal supported use?
Who sees a failed connection, recovers missed work and maintains it after updates?
Dependencies / maintainer / written confirmation needed: ____________________

5. Access, cost and growth

Show permissions for staff, approvers, administrators and a backup person.
What plans, subscriptions, setup and support are required? What changes with more people, volume or locations?
Required costs / limits / authorized owner: ____________________

6. Exit and decision

Who controls the account and data? What can we take with us, in what format, at what cost?
What remains unproven? What pilot or written answer would resolve it before we commit?
Open question / evidence / follow-up owner / date: ____________________

Mark each answer as demonstrated, confirmed in writing or still unknown. Record the evidence, the person who will follow up and the decision date. There is no software score.

Continue where it helps

For a conversation, use Contact in the company navigation or workspace controls. Sharing the public topic is optional; the worksheet is not attached.

Sources and review

The workflow recommendations and worksheets are IT Mushroom’s guidance. Product examples are supported by the sources below and should be checked against your current service and plan.

GOV.UK: Define user needs
Background for starting with people and their work. This is government guidance, not a procurement requirement for your business.
GOV.UK: Make use of open standards
Background for interoperability and avoiding unnecessary supplier dependence. Open formats alone do not establish a usable export or an exit right.