Stop running your trade business from a WhatsApp group.

Run the job from the first request to the final invoice

A work order is the instruction to carry out a defined piece of work. A job card is the practical record the field team uses to understand that instruction and record the result. In many service businesses, the names overlap. What matters is that the office, technician and customer can identify the same job, understand its current position and find the evidence needed for the next decision.

WorkOrderPro organises the process around customers, job sites and work orders. That structure matters when one customer has several properties, when a technician returns to a site, or when the person approving the work is different from the person receiving the invoice. Start with those relationships and your team has a clearer basis for scheduling, communication and billing.

You do not need to move every historical record on your first day. Choose a representative job and follow it through the system. A useful evaluation includes the ordinary handovers and one exception: a changed scope, a missing part, an unavailable customer or a return visit. Those situations tell you more about operational fit than a dashboard filled with sample figures.

Capture a request the technician can act on

A useful service request explains the problem, its location, the contact person and any access restrictions. “Air conditioner broken” leaves several questions unanswered. “Reception unit is leaking onto the floor; building manager available after 10:00; security requires visitor registration” gives dispatch something concrete to work with. Include urgency without assuming that every urgent request has an agreed appointment.

Keep the customer and job site separate. The customer is the party you deal with commercially; the site is where the work happens. For a property manager, those may involve different addresses and different contacts. Confirm who can authorise additional work, who can provide access and who needs to receive the final paperwork. This avoids passing the same question between the office and field team.

Agree scope and price before the work expands

A quote should make the proposed work understandable. Separate the inspection or callout from additional labour and parts where that distinction matters. Describe exclusions and assumptions in plain language. If the cause of a fault is not yet known, make the initial diagnostic scope clear rather than presenting an uncertain repair as a fixed, fully specified job.

When the proposed work changes, ask for approval of the changed scope before proceeding. A customer's acceptance of an earlier quote is not blanket permission for any later total. During your WorkOrderPro evaluation, test a quote with labour, a part and a discount, then inspect the approved version and the resulting job. The office should be able to explain the amount without relying on a private conversation.

Dispatch with enough context for a successful visit

The dispatcher needs the appointment, address, assigned person and job requirements together. Check travel time, access windows and the skills or equipment required before committing to a visit. The nearest technician is not always the right technician: a specialist repair may require qualifications, tools or parts that another person carries.

Use the dispatch board to evaluate how your team assigns work and reacts to changes. Try moving a job, opening its details and checking what the assigned person receives. Confirm who is allowed to change the schedule. A clear ownership rule prevents two people from independently promising different arrival times to the same customer.

Record the work without losing the reason for it

At the site, the technician needs more than a button that says complete. Record the diagnosis, work performed, relevant time, parts used and anything still unresolved. Photos are useful when they show the condition before work and the result afterwards. A photo of a room without an explanation may be less useful than a short note identifying the actual fault.

Decide which records are needed for each kind of job. A cleaning visit might need the areas serviced and exceptions. An electrical maintenance visit might need the asset, fault and work performed, together with any separate professional documentation required for that work. A digital job card helps organise evidence; it does not by itself issue a specialist certificate or prove that every trade requirement was met.

Review completion before treating the job as billable

Completion should answer whether the agreed work was done, whether follow-up is needed and whether the record supports an invoice. If a part is unavailable, distinguish the work completed today from the work still outstanding. If a customer is absent, record that fact rather than implying that they signed off the result.

Office review should focus on exceptions. Check missing descriptions, unexpected quantities, unapproved extras and payments already received. Keep customer sign-off separate from payment confirmation. The customer may accept the work today and pay later under agreed terms; alternatively, they may have paid a deposit before the technician arrived. The job and invoice need to preserve that distinction.

Send an invoice the customer can reconcile

An invoice is easier to review when its customer details, job reference and descriptions correspond to the agreed work. Check the recipient and the billing address, then review labour, parts, discounts, tax details and prior payments. Use the work-order record to explain the charges rather than reconstructing the job from messages after everyone has moved on.

Sending, delivery and payment are different events. An email action does not establish that the customer received the document, and an invoice marked unpaid does not explain why it remains unpaid. Agree an office process for checking delivery failures, recording payment references and following up disputed items. Our guide to invoicing completed work describes the handover in more detail.

What each person needs from the same job record

A shared system is useful when it reduces repeated questions while preserving responsibility. Give each person their own account and establish which role owns each change. The table below is an operating checklist for your trial, not a promise that every possible permission or approval rule is preconfigured for your business.

Person	Information to check	Decision or handover
Owner or administrator	Team access, plan, customer records and billing settings	Who can use the system and which process the team follows
Dispatcher	Open requests, appointments, assigned technicians and access notes	Who attends, when they attend and what they need
Technician	Job scope, site contact, previous context and required evidence	What was done, what was used and what remains unresolved
Office billing user	Approved scope, completion details, prices and recorded payments	Whether the invoice is ready and where it should be sent
Customer contact	The information and actions made available through customer access	Whether to approve the proposed work or query the job details

The same person may perform several of these roles in a small business. Your subscription counts active team accounts, including administrators and dispatchers, rather than charging only for people who travel to sites. Avoid shared logins to reduce the apparent headcount: they make it harder to establish who changed a job and make offboarding less controlled.

Choose software using your actual work, not a feature count

A checklist of features is a starting point. The stronger test is whether your team can complete a realistic job with the details your customer expects. Record where someone needs help, where information is entered twice and where the next step is unclear. Those observations give you specific questions to raise during a demonstration and practical training topics for rollout.

Trial scenario	What to test	Evidence of a useful result
One-off repair	Request, quote, assignment, field notes and invoice	The office can trace the final charges to the agreed job
Repeat customer	A new job at an existing site	The team can find relevant history without mixing up properties
Changed scope	Additional work discovered during a visit	The approved scope and amount remain understandable
Return visit	Work paused for a part or customer availability	The next person can see what remains and why
Poor connectivity	Your required mobile actions with a weak connection	Saved work and successful synchronisation can be distinguished
Staff change	Disable an account and review permissions	The departing person no longer has the intended access

Keep an evaluation note for each scenario. Include the result, any limitation and the person responsible for resolving it. Do not treat a workaround as a supported integration until it has been demonstrated. If accounting export, an industry form or a particular device is essential, put it near the beginning of the trial rather than discovering the dependency after the whole team has moved.

For cleaning and property service teams

Start with the property, service areas, access arrangements and agreed scope. A recurring clean and a once-off deep clean need different instructions. Record areas that could not be accessed, damage noticed before work and additional tasks requiring approval. Where a supervisor checks the outcome, decide when that review happens and what the office needs before invoicing.

For customers with multiple buildings, use consistent site names so the dispatcher and invoice recipient can recognise the location. Test a routine visit and a changed booking during your evaluation. Confirm whether the way you schedule individual people matches how you operate crews; a team-based requirement should be demonstrated rather than assumed from an individual technician workflow.

For repair, installation and maintenance teams

Identify the asset or area being worked on, the reported symptom and any relevant previous intervention. An installation may need several visits, while a breakdown may need a diagnostic visit followed by approval for a repair. Keep those stages explicit so an initial attendance is not mistaken for completion of the whole assignment.

For repeat maintenance, define the interval, scope and customer expectation before setting up recurring work. Check what happens when a visit is postponed, skipped or needs corrective work. A schedule can remind the team that work is due, but someone still needs to review the result and arrange exceptions. Explore maintenance workflows with a real example from your contracts.

Start with a small rollout and a clear success measure

Choose one office owner and a small field group for the first operational trial. Agree the minimum information every job must contain. Create a small service and parts list using descriptions the team already understands. Avoid loading a large, untidy catalogue just because it is available: duplicated or unclear items make pricing and selection harder from the start.

Practise the handover together. The dispatcher creates a job, the technician finds the instructions and records the result, and the office reviews the invoice. Ask each person to complete their step without someone else clicking for them. Where they hesitate, adjust the instructions or raise a product question before rolling the same problem out to everyone.

Measure a few observable outcomes: jobs with an assigned owner, completed jobs with usable notes, invoices ready for review and work awaiting a specific next action. Compare those observations with your previous process. Treat any claimed time saving as something to measure in your business, not a guaranteed result from installing software.

Before subscribing, review the active team count, plan limits and billing cycle on the pricing page. Include office users in the calculation. Agree who will maintain customer details, review incomplete jobs and handle billing questions after rollout. If a specific workflow remains uncertain, request a demonstration using that example so you can make the decision with concrete evidence.