Evaluate moving software with your own demo scenario

Prepare a job that feels familiar

Create a fictional job based on your work, without real customer details. Include addresses, a preferred date, an inventory, access restrictions and additional services. Add a change your staff regularly encounter, such as a revised date or another large item. Give each supplier identical information. A demonstration of a simple job cannot fairly be compared with another supplier tackling a complicated exception.

Follow the information between teams

Ask the demonstrator to enter the enquiry, prepare a quote and record acceptance. Then check where the planner and crew find those agreements. Change one important detail and see where the update appears. Note every point that requires retyping or a separate message. These are the handovers your team will need to manage once the software is in everyday use.

• Which quote version is retained?
• Who can see a changed instruction?
• How is missing information flagged?

Include a failure and a correction

Ask what happens when someone lacks permission, an address is incomplete or the connection drops. Have the demonstrator correct an entry and show whether the person making the change remains identifiable. A product does not need to automate every exception. You do need to understand the manual procedure and whether staff can use it. Record capabilities that were not demonstrated as unresolved questions, not confirmed features.

Let daily users assess their own steps

Invite a planner, an administrator and a crew representative to assess their part. Simple ratings such as usable, needs adjustment and not demonstrated are enough. Discuss configuration, training, integrations and migration separately afterwards. A good demonstration does not establish that these services are included. Ask the supplier to confirm the main findings and outstanding questions in writing before you make a decision.