A useful software demonstration ends with a clearer buying decision. You should understand which parts of your work the product supports, which steps need configuration and which requirements still need confirmation. A polished tour of every menu is less useful than watching the people in your team complete the handover that currently causes difficulty.
Use the request form to tell us who you are and the kind of team you run. The preparation guide below helps you choose what to bring and what to test. Requesting a demonstration starts a conversation; it does not itself create a confirmed appointment, reserve implementation work or change your subscription. The aim is to evaluate a practical work-order workflow and the conditions under which it would be useful for your business.
Choose the decision you need the demo to support
Start with one question that matters to the business. Can a dispatcher assign work without repeatedly explaining it in a separate message? Can a technician return enough information for the office to prepare the customer handover? Can the team distinguish unfinished work from an unpaid invoice? These questions make it easier to judge the demonstration because the desired outcome is observable.
Describe the current process briefly. Identify the people involved, the record they use and the point where information becomes unclear or has to be entered again. You do not need to prepare a long business case before requesting a conversation. One specific example of a difficult handover provides more useful context than a list of broad aims such as efficiency or digital transformation.
Decide what would count as a satisfactory demonstration. For example, the dispatcher can find the job's next action, or the invoice reviewer can understand the work without contacting the technician again. Keep this condition realistic and under the product trial's control. A demonstration can establish workflow behaviour; it cannot prove future revenue growth or a guaranteed reduction in labour costs.
Bring a representative job rather than a perfect one
Choose a job that resembles the work your team regularly handles. It might be a reactive repair, a quoted installation or a planned maintenance visit. Include the customer type, site, reported problem, assignment and expected outcome. If the real job contains private information, use a fictional version with the same operational structure instead of distributing the original records unnecessarily.
Avoid choosing an unusually simple example solely because it is easy to demonstrate. A single line item with no access arrangements or follow-up may miss the reason you are considering software. Equally, do not begin with the most complex exception your business has ever seen. Start with a normal job, then add one realistic complication that tests the next handover.
Explain what makes the example representative. Perhaps the office often coordinates a landlord and tenant, technicians need to identify a specific asset, or additional work requires customer approval. Those details help focus the session. The objective is to understand the job your people need to perform, not to impress anyone with the size of the sample record.
Involve the people who handle the work
Invite the person who receives or schedules jobs and someone who will use the field workflow. If billing or customer handover is a major concern, include the colleague responsible for that step. Each role notices different problems. A screen that appears straightforward to the owner may still leave the technician unsure which action to take at a customer site.
Give each participant a task to evaluate. The dispatcher can check assignment and exceptions; the technician can check site information and updates; the office reviewer can inspect the returned record. This is more useful than asking everyone whether they like the interface at the end. A task gives each person evidence they can discuss with the rest of the team.
If everyone cannot attend together, preserve the same sample job and acceptance questions for follow-up. Avoid making the buying decision entirely from one person's summary of a screen they will not use. The person accountable for rollout should understand any unresolved role-specific concern before inviting the wider team or importing a large set of live records.
Prepare the minimum information needed for the exercise
A fictional customer, a clear site description and a short problem statement are enough to begin a useful walkthrough. Add the relevant service or part examples if quotation and invoicing are central to the decision. Use representative quantities and terms rather than sharing confidential customer pricing unnecessarily. The structure of the work usually matters more than the identity of the real customer.
Write down the roles that need access and the devices the field team expects to use. Mention any essential connection, export or specialist document requirement. These details should guide what is demonstrated and what needs a separate check. A requirement mentioned only after the buying decision can create avoidable implementation uncertainty.
Keep account passwords, payment credentials, private access codes and other secrets out of the demo request. If a later evaluation requires a connection to another service, agree the appropriate setup process for that connection. A contact form is a place to describe the requirement, not to transfer credentials or an unrestricted copy of the business's customer database.
| Preparation item | What to bring | What it helps evaluate |
|---|---|---|
| Main workflow question | One difficult handover and the intended improvement | Whether the demonstration answers a real operational need |
| Representative job | Fictional customer, site, request and expected outcome | The practical sequence from intake to office review |
| Team roles | Dispatcher, technician and any billing or review role | Whether each person can perform the necessary actions |
| One exception | Missing access, changed scope or return visit | How unfinished work remains understandable |
| Commercial requirements | Needed plan capabilities and active-user count | The subscription and any separate setup decisions |
| Technical requirements | Intended devices and essential connections or exports | What must be verified outside the basic walkthrough |
Watch the office-to-technician handover
Begin with the office record and the assignment. Ask the person managing intake to identify the customer, site and requested work. Then inspect what the technician receives. The useful question is whether the field user can understand the task without relying on the presenter to fill in missing context verbally.
Check the information that matters for attendance. A multi-site customer may need a particular unit or asset reference, while a planned visit may depend on an access window. Review how a change is recorded and communicated. If the demonstration includes a reassignment, confirm the result from both the dispatcher and technician perspectives.
Do not treat a notification animation as the entire handover. Verify the underlying assigned job and its current details. A notification can help draw attention, but the team still needs a reliable place to see what they are responsible for. Ask how they will recognise an update after opening the app later or returning from a period without connectivity.
Test the field actions you actually need
Have the technician open the assigned job on the intended type of device where practical. Follow the relevant actions for the work type, such as travel, arrival, assessment, scope approval or completion. Explain how your current team handles those stages. The demonstration should reveal whether the supported workflow fits that process or requires a change you are willing to make.
Inspect the input and the result. Enter a useful note, record a relevant photo or review a time entry, then look at what the office receives. A control that accepts input is only part of the task. The record needs to reach the correct job and be understandable to the next authorised person.
Be precise about specialist needs. If the team requires a particular inspection document, certification process or measurement workflow, ask for that exact requirement to be demonstrated or confirmed separately. A general-purpose job record does not automatically replace professional documentation. Keep the distinction visible when comparing products or agreeing the scope of a trial.
Include a realistic approval or exception
Choose an exception that affects your ordinary work. For a callout, an assessment may reveal a repair requiring customer approval. For maintenance, the technician may be unable to access the equipment. For an installation, a part may be unavailable and a return visit required. The exception should lead to a concrete question about the next action and its owner.
Observe how the proposed work and customer decision are recorded where approval is required. Check that an internal assessment, quotation and recorded approval are distinguishable. If the customer declines or has not replied, ask what the office sees. A useful workflow does not depend on every customer immediately accepting every proposal.
Follow the exception through to the next person. The technician should not need to mark incomplete work as finished simply to move on. The dispatcher should be able to identify the unresolved action without searching a personal chat history. Use the result to discuss any process change the team would need during rollout.
Examine the completion record from the office's view
After the field portion of the exercise, ask the office reviewer to explain what happened using the returned record. They should be able to identify the completed scope, relevant notes and any remaining action. If they need information that is missing, record that gap and determine whether it is a configuration question, a training issue or an unsupported requirement.
Review customer-facing material separately. A job can contain internal notes or images that should not automatically be included in the handover. Demonstrate the supported visibility and sharing process with the intended recipient role. Confirm the actual view instead of relying only on the administrator's description of what a customer ought to see.
Keep the outcome accurately described. Photos, time entries and customer acknowledgements support an operational record, but they do not guarantee that every technical or contractual obligation has been satisfied. Ask the responsible person how any separate professional documents will be produced, stored and retrieved alongside the job workflow.
Check invoicing and payment as separate steps
If invoicing matters to the decision, review the actual commercial record produced from the sample job. Check the customer, descriptions, quantities and relevant tax settings. Ask which values are entered, reused or generated under the configured workflow. Avoid assuming that every time entry or stock movement automatically becomes an invoice line without observing the result.
Then distinguish invoice status from payment status. A completed job is not proof that an invoice has been issued, and an issued invoice is not proof that the customer has paid. Review how the product represents those events and which view the office uses for follow-up. This helps prevent a currency total from being interpreted as cash received when it represents something else.
Where payment or accounting integration is essential, identify the provider, account type and exact operation required. Include connection, error and reconciliation questions in the follow-up plan. A basic product demonstration may identify the available route, but your own configured connection needs verification before the business relies on it for live transactions.
Test weak connectivity with an action checklist
Ask about the specific actions the technician needs when a connection is unavailable. Viewing a downloaded record, editing a note, capturing a photo and submitting an approval can behave differently. A broad statement that an app works offline does not answer every one of those questions. List the important actions and observe their current behaviour on the supported app.
Check how pending or failed changes are shown and how the user recovers. Restore the connection and confirm that the intended record reaches the office. If the process depends on a retry, test the retry. If the device changes account, ask how the application protects the previous user's local information and unfinished work.
Keep the result specific to the device, version and action tested. Do not generalise one successful demonstration into a guarantee of automatic recovery after every possible device failure. Use the offline-app evaluation guide to prepare a more detailed acceptance exercise where connectivity is central to your operation.
Review the whole active-team subscription
Count all active team users who need access, including administrators, dispatchers and technicians. For example, five field technicians and two active office users form a seven-user team for seat planning. Disabled accounts are excluded. This prevents a demonstration focused on the technician experience from leaving out office seats when you compare the full subscription.
Use the pricing page to select the appropriate plan and billing cycle and review the displayed total and tax treatment. Confirm which required capabilities belong to the chosen plan. Do not use a remembered price or a single seat figure as the complete budget for a different team configuration.
Separate standard product access from any additional work being discussed. Data preparation, bespoke integration, training or other implementation work should be confirmed on its own terms if needed. A demonstration request does not imply those services are included. Record the commercial assumptions you need resolved before making the buying decision.
Leave with a short evidence-based decision record
Record what was demonstrated, what you observed and what remains uncertain. Use straightforward outcomes such as supported in the trial, requires configuration or needs further confirmation. Avoid turning a presenter's intention into a confirmed feature. If something is not demonstrated, keep it as an open requirement until there is an appropriate answer.
Choose the next action based on the remaining uncertainty. You may be ready for a controlled trial, or you may need one integration check or a role-specific session first. Give that action an owner and a clear finish condition. This keeps the evaluation moving without treating every open question as a reason to restart the entire process.
| Evaluation question | Evidence worth recording | Follow-up when uncertain |
|---|---|---|
| Can the field user act on the assignment? | Technician identifies the correct site and scope | Review missing briefing details or device behaviour |
| Does an exception remain visible? | Office can name the next action and responsible person | Re-run the relevant exception with the intended roles |
| Is completion useful to the office? | Reviewer understands the outcome from the submitted record | Adjust required information or confirm a product gap |
| Is customer sharing appropriate? | Recipient sees the intended information | Check permissions and visibility with a sample account |
| Is the commercial path understood? | Invoice, payment and subscription definitions are clear | Verify the particular connection or plan requirement |
| Is rollout manageable? | First workflow and responsible staff are identified | Start with a smaller controlled trial |
Frequently asked questions
What happens after I request a demonstration?
The request provides contact and team information for a follow-up conversation. A suitable time and focus can then be discussed. Submitting the form is not itself a confirmed appointment or an agreement to deliver implementation work. Use the follow-up to explain the workflow you want evaluated.
Do I need to upload our real customer database first?
No. A fictional sample with the same operational structure is sufficient for a useful initial walkthrough. Bring the relevant site, job and role details without unnecessary personal information. Discuss data migration separately if it becomes part of the rollout plan, including mapping, review and ownership of the source records.
Who should attend from our company?
Include the people involved in the handover you want to improve. That often means someone from the office and a technician, with a billing or review colleague where relevant. Give each person a task to assess. Their observed experience is more useful than a general opinion about the interface.
Can we demonstrate a complicated exception?
Describe the exception when arranging the session and identify the decision it affects. Start from a representative job so everyone understands the normal workflow, then test the complication. If it requires a specialist integration or professional process, confirm that requirement separately instead of assuming a general demonstration covers it.
Will the demo prove how much money we will save?
A demonstration can show product behaviour and help estimate the work involved in adopting it. It cannot prove future savings or revenue. If you want to measure an improvement, establish your current process and observe the same outcome during a controlled trial. Treat estimates as assumptions until you have your own evidence.
Can we use the app offline during the trial?
Test the specific supported actions your team needs on the intended devices. Check pending states, recovery and office receipt after reconnection. Do not assume every screen, attachment or approval behaves the same way. Record the exact actions demonstrated and any limitation that affects your working conditions.
Does the team price include office users?
Active administrators and dispatchers count alongside active technicians. Disabled accounts are excluded. Use the pricing calculator with the complete active team, chosen plan and billing cycle. Confirm tax treatment and any separately agreed services so the comparison reflects the actual scope you intend to use.
What is a sensible next step after the walkthrough?
Choose one unresolved question or one complete trial workflow and assign an owner. If the core handover fits, run it with representative staff and synthetic data before a wider rollout. Keep required capabilities and commercial assumptions explicit. The next step should reduce a specific uncertainty rather than repeat a general product tour.