A clear next step, from the first request to the final invoice.

The useful test of work-order software is whether another person can understand the job and take the next appropriate action. A dispatcher should see what needs assigning. A technician should find the correct site and scope. The person preparing the customer handover should know what was completed, what remains open and which commercial details need review.

This walkthrough follows those handovers in WorkOrderPro. Use it with one representative job during your evaluation. The example is a workflow exercise, not a customer case study or a promise of a particular completion time. Your actual work type, permissions, plan and settings determine which actions are available. Include an exception in the exercise so you see how the process behaves when the visit does not go exactly as planned.

Start with one clear customer request

The office records who is asking for help, where the work is needed and what problem has been reported. Keep the customer's description distinguishable from a technician's later assessment. Someone reporting an intermittent problem may not know its cause, so the initial job should not imply that a technical diagnosis has already happened.

Connect the request to the right customer and job site. A company can have several locations, and one location can have multiple contacts or access arrangements. Confirm the specific unit, building or agreed asset reference where that detail matters. This helps prevent a well-written job card from sending the technician to the wrong place.

Choose the relevant work type and next action. A scheduled visit, reactive callout and quotation request do not necessarily follow an identical sequence. Use the workflow that matches the actual service rather than forcing every request through extra steps for appearance's sake. Record an understandable problem description and priority so the dispatcher can make the next decision.

Review the information needed for attendance

Before assigning the visit, check whether the team has enough information to attend usefully. The office may need a contact number, access window, description of the affected equipment or confirmation of what the customer expects from the visit. Collect the information that supports the task without making the initial form a questionnaire full of details nobody uses.

Put the most useful briefing information first. A technician reading on a phone needs to identify the site and immediate task quickly. Prior-job history can help, but a long collection of old notes may obscure the new request. Refer to specific relevant history and explain the connection rather than pasting every previous conversation into the current description.

Keep uncertainty visible. If access has not been confirmed or a customer decision is still needed, record the outstanding action. A job scheduled on a calendar can still be unready for attendance. The important question is whether the assigned person and the office understand what must happen before the visit can proceed.

Plan the visit against actual workload

The dispatcher reviews the work to be assigned and the team's existing commitments. Use the dispatch view to consider timing, workload and the people involved. A blank space on a screen is not the only factor in choosing a technician: the required skills, site access, equipment and travel assumptions still need human judgement.

Assign the appropriate person and confirm the timing through the supported workflow. Check the result from the technician's account during a trial. The task should appear with the correct site and job details, not merely look assigned from the administrator's screen. If the work needs more than one person, verify the lead and supporting crew behaviour for the particular job.

Communicate changes deliberately. A reassignment affects someone who may already be travelling or preparing for the work. Confirm that the updated assignment is visible and understood. Notifications can help, but they are not a guarantee that the recipient has seen or acted on a message. Review delivery and app state when a notification is important to the handover.

Let the technician work from the assigned record

The technician opens the assigned job and reviews the site, scope and relevant preparation information. The record should help them start the visit with the same understanding as the office. If the information is incomplete or the situation differs from the request, the next useful action is to document that difference and communicate it through the agreed process.

Use the job's available actions to record progress. Travel, arrival, assessment and work updates provide different information; they should not be treated as interchangeable labels. Your chosen workflow determines the available transitions. A scheduled service may need a different sequence from a callout that requires assessment and a quotation before work is authorised.

During the trial, have the technician perform these actions on the intended device. Check the real screen and result rather than relying on a desktop demonstration of the field experience. Include a slow connection or interrupted session if that reflects normal work. The office should be able to see the resulting record after supported changes have successfully synchronised.

Keep assessment and commercial approval distinct

A visit can reveal additional work or a different problem from the one originally reported. Record the assessment clearly, then determine whether the existing authorisation covers the proposed work. A technician's observation and the customer's commercial approval are different parts of the record, even when they happen during the same conversation.

Where a quotation is needed, describe the proposed services, parts and terms using the available quotation workflow. Make the scope understandable to the customer. A price with no clear description can create a new disagreement about what was included, especially if the assessment has changed the expected work since the original booking.

Use the supported approval process and confirm its recorded outcome before proceeding with additional work that requires approval. If a decision arrives through another communication channel, preserve it through the business's authorised record process. Do not assume that a technician's recollection of a phone call will be enough for the next person preparing an invoice or answering a customer question.

Record time, parts and observations in context

Time records are most useful when they are connected to the right activity and job. Review what the relevant timer or entry represents in your workflow. A clocked-in shift, travel activity and time spent on a particular job can answer different questions. Avoid treating every recorded minute as automatically billable without checking the agreed commercial arrangement.

Record the relevant services and parts using the supported job and stock workflow. Check names, quantities and the relationship to the approved scope. A catalogue entry provides a reusable reference, but it does not remove the need to review what was actually used. If a required item is unavailable or the quantity differs, preserve the exception for the office instead of leaving an unexplained mismatch.

Write notes for the next reader. Explain what was found, what action was taken and what still needs attention. A brief, specific description is more useful than a generic “done” message. Use the appropriate technical language for the work, while keeping the customer-facing explanation understandable to the person receiving the handover.

Add useful photos without overstating what they prove

Photos can support the written account by showing a relevant condition or stage of the work. Capture images that help another authorised person understand the job. Check the subject, clarity and job association before relying on the record. A successfully uploaded image can still be unhelpful if it is blurred or attached to the wrong site.

Use the available photo stages and descriptions accurately. An image of visible completed work does not establish every hidden condition, a professional certification or a guaranteed legal outcome. Keep technical conclusions with the person responsible for making them. Where a customer should see a selection of photos, review the actual customer-facing result rather than assuming every internal file should be shared.

Confirm that uploads have reached the job record. If a device shows a pending action, distinguish that state from a completed upload. Test retries and retrieval from the office during evaluation. The job-photo guide explains the workflow questions to explore, including association, visibility and useful context.

Handle an exception before it disappears into a note

An exception needs a next action and an owner. If the technician cannot gain access, the office may need to contact the customer and arrange a new attendance. If approval is outstanding, the job may need a decision rather than another field visit. A vague note without an assigned follow-up can leave the job looking active while nobody knows how to move it forward.

Use the appropriate supported state and explain the reason. The state helps the team group work; the note explains the circumstances. Avoid marking incomplete work as completed simply to clear the technician's screen. Equally, do not leave a finished job in progress because one unrelated administrative question has not been routed to the right person.

Include one exception in your trial. Choose the situation your team sees most often, such as missing access, changed scope, a part that is not available or a return visit. Ask both the office and technician to explain what the next person will see. This reveals whether the workflow supports the actual handover, not just a tidy demonstration.

Review completion as a handover to the office

Completion should provide enough information for the next person to understand the outcome. Review the notes, relevant photos, time and line items for the particular job. The purpose is not to make every job equally elaborate. It is to avoid a record that says the work is finished while omitting information needed to answer the customer's next question.

Keep specialist documentation separate where appropriate. A work-order record does not replace an electrical certificate, professional inspection report or every document required by a contract. Identify the relevant document and retrieval process rather than describing an ordinary completion action as certification. Demonstrate specialist requirements separately before adopting the product for a process that depends on them.

Check the office view after the technician completes the supported workflow. Confirm that the status and details agree with what happened at the site. If a correction is required, use the available authorised process and preserve the reason for the change. The office should not have to reconstruct the visit from separate personal messages.

Review the invoice and track payment separately

A finished job, an issued invoice and a paid invoice are different business events. Use the job information to support the next commercial step, then review the resulting invoice for the customer, description, line items and tax treatment applicable to the business. Where invoice generation is configured, verify the actual trigger and output rather than assuming every time entry or stock movement becomes a charge automatically.

Confirm how the customer receives the document and how payment is recorded. If online payment or an accounting connection is essential, demonstrate the configured path with an appropriate test before relying on it. An available feature name is not evidence that your own payment or accounting setup is connected, authorised and reconciled correctly.

When reviewing performance, distinguish completed-work value from money received. An unpaid invoice is not cash in the bank, and the total value of all job records can include work that is unfinished or quoted. Use the report that answers the decision you are making and check its definition rather than treating every currency figure as revenue.

Give each role an observable finish condition

The workflow becomes easier to introduce when each person knows what a successful handover looks like. Describe the condition in terms of the next person's task. For example, the dispatcher has finished preparation when the assigned technician can identify the right site, scope and attendance details. That is more useful than saying a form has been completed.

Use the table below as an evaluation aid. Adjust it to the actual service and permission model. It is not a promise that every optional integration or specialist process is included in every plan. Demonstrate the important action and record any requirement that needs separate configuration or confirmation.

Start with a small rollout and a complete job

Introduce one representative workflow with the people who actually perform it. Use a controlled sample before entering a large backlog or inviting the whole team. Confirm the customer and site setup, required permissions and basic catalogue information. A smaller complete exercise often reveals more useful setup questions than importing thousands of incomplete records first.

Choose what counts as first value for your team. It might be the office receiving a usable completion record, or the dispatcher assigning a visit that the technician can action without a separate explanation. Observe that outcome rather than measuring onboarding only by how many settings screens were visited. Keep the remaining configuration tasks visible and give them owners.

Review the subscription with the whole active team. WorkOrderPro bills active team users, including administrators and dispatchers as well as technicians; disabled accounts are excluded. Use the pricing calculator for the chosen plan, billing cycle and displayed tax treatment. Include any separately agreed implementation or integration requirement in your decision rather than assuming it is part of the standard subscription.

Frequently asked questions

Does every job follow exactly the same status sequence?

No. Different work types can require different actions, particularly when a callout needs assessment and approval before work. Use the supported workflow appropriate to the service. Test the actual transitions and exceptions with your staff rather than assuming one illustrated sequence describes every possible job.

Is a job automatically paid when it is marked complete?

No. Completion records the operational outcome. Invoice creation and payment are separate events. Review the invoice and the configured payment process, and use the appropriate payment status when checking money received. A completed-work total should not be interpreted as proof that the customer has paid.

Can the technician approve additional work on the customer's behalf?

The technician can record an assessment and prepare proposed work, but the necessary customer decision must be obtained through the appropriate process. Keep the scope and approval outcome clear. Do not treat a changed job description or an internal note as a substitute for the commercial authorisation your business requires.

What happens when the device loses connectivity?

Behaviour depends on the action and supported app workflow. Distinguish saved, pending, failed and synchronised changes where the interface provides those states. Test your intended devices and confirm that the office receives the final record. Avoid assuming that every screen, photo or integration works offline.

Do photos replace technical certificates or professional reports?

No. Photos provide context for the work record. Specialist certification, inspection and reporting remain separate responsibilities where applicable. Identify the documents your service requires and demonstrate how authorised staff will retrieve them. Do not describe a gallery or customer acknowledgement as an independent technical certification.

Can the office change the assignment after the job is created?

Use the supported dispatch and reassignment workflow for the job's current state. Check the resulting technician view and communicate material changes. If work is already underway, include that situation in your trial so the team understands the effect on the original attendance and any remaining action.

Which users should we include when calculating the subscription?

Count active team users across the office and field team, including administrators, dispatchers and technicians. Disabled accounts are excluded. Select the required plan and billing cycle in the pricing calculator and review its displayed total. Confirm any separately agreed services before committing to a rollout.

What should we bring to a product demonstration?

Bring one typical job, the roles involved and one realistic exception. Explain the customer request, site, scope decision and expected completion handover. Ask the people who will use the software to try their own steps. The result should be a demonstrated workflow and a clear list of requirements still needing confirmation.