Start with a job your team recognises
A polished dashboard can show totals without answering the questions that delay a real job. To evaluate software, choose one representative order and follow it through every role. Use demonstration data with realistic complexity: several panels, different processing, a trade customer, delivery and a deposit.
Prepare the expected result before the demonstration. Write down the panel identities, price basis, document needs and approval responsibilities. This gives both sides something concrete to check and avoids turning the session into a tour of unrelated features.
Change something after the first price
Ask what happens when one panel changes size after the quote is prepared. Does the commercial price change? Is the drawing regenerated? Can the workshop identify the current revision? What happens if the customer has already approved or paid a deposit?
The important test is consistency across the saved record and documents. A responsive preview is useful, but it cannot establish that the purchase order, cutting ticket and invoice still describe the same approved job.
Follow the money independently
Compare the item prices, discounts, delivery, tax and final total. Then apply a partial payment and inspect the amount still due. Ask how a declined or interrupted payment is represented and how staff avoid collecting it twice.
Use a separate expected calculation and provider references. A correct-looking invoice can still have the wrong customer, wrong payment allocation or wrong tax treatment. Ask to see the correction and audit trail, not only the successful path.
Walk through a partial fulfilment
Receive only part of a supplier order. Put the goods into a specific location. Release only the ready items to production or delivery, then inspect what remains outstanding.
This reveals whether the system distinguishes ordered, received, reserved, ready and delivered. Those states matter to the counter team explaining a delay and to the person deciding whether another purchase is needed.
Give each role its own task
Ask a counter operator to find the quote, a workshop user to find the drawing, a driver to find the stop and a manager to find the outstanding balance. Check the same workflow on the devices they will use.
Permissions should match responsibilities. A driver should not need a manager account just to complete a delivery, and a price override should not become invisible because everyone shares a login.
Ask about failure and recovery
Disconnect the demonstration device only in an agreed test environment. Ask what is stored, which payment methods remain supported, what the user sees while waiting and how duplicate synchronisation is prevented. Test uncertainty as well as outright failure.
For hosting, request a recovery explanation tied to the proposed environment: backup coverage, a demonstrated restore, responsibility for alerts and export options. A backup feature name is not a recovery commitment.
Finish with an acceptance list
Record each outcome as demonstrated, requiring configuration, requiring further work or unavailable. Give unresolved questions an owner. Agree migration checks, training and a staged launch plan before replacing the system staff already rely on.
For Panelane, we use the same approach: a specific workflow, representative records and an agreed implementation scope. Bring your difficult order to the first call. It is a better starting point than a feature count.