Field service guides for South African businesses

WorkOrderPro implementation navigation guide · Updated 12 September 2026.

Choose a task you can complete and review

A practical guide is most useful when you begin with a defined task and an observable result. Creating a job card, preparing a dispatch brief and reviewing an invoice handover are related activities, but each has a different outcome. Choose the task that is currently preventing the next person from doing their work. That gives the exercise a clear purpose and makes the result easier to assess.

The guide cards above take you directly to the available topics. Use the implementation sequence below if you are introducing a new process or evaluating WorkOrderPro for the first time. You can follow the sequence through one representative job, or start at the stage where your current handover breaks down. There is no requirement to complete every guide before improving one routine.

Define success before beginning. For a job brief, success might mean that a technician understands the site and agreed purpose without another call to the office. For a billing handover, it might mean that a reviewer can distinguish completed work from an outstanding customer decision. These are concrete outcomes you can observe, rather than assuming that filling every field proves the task has been completed well.

Prepare a small, realistic working example

Choose a job that represents ordinary work your business performs. Include the customer, physical site, requested task and the people who handle it. Avoid an example that is so simple it skips the handovers you need to evaluate. A visit with one missing material or a changed appointment can be more informative than a perfectly completed job with no decisions left open.

Use invented or appropriately minimised details when practising a process that does not require real customer information. The goal is to understand the workflow, so unnecessary personal data and sensitive access details add little value. If you use an existing job, preserve its actual history and avoid changing a live customer record simply to create a demonstration scenario.

Assign an office participant and a field participant where the task crosses those roles. They should work from the same example and review each other's output. If one person performs both roles in a small business, deliberately review the saved record later as if someone else had created it. This helps expose information that seemed obvious only because you remembered the original conversation.

Establish customer and site identity before the job brief

The customer record and job site answer different questions. The customer identifies the commercial relationship; the site identifies the place where work happens. A property owner, access contact and approving person may not be the same individual. The first setup exercise should make those responsibilities understandable rather than relying on a familiar name to carry every meaning.

Use consistent site names before importing a large customer list. Include two locations for one customer in the example if your business handles portfolios or repeat work. Ask the other participant to select the correct site without help. If the name is ambiguous, fix the convention while the sample is small instead of allowing the uncertainty to spread across the full dataset.

Record missing information as a next action rather than inventing a value to complete the form. A placeholder that looks like a verified reference can mislead a later reviewer. The preparation is complete when the people using the example can identify the intended customer and location and understand which contact is responsible for the next decision.

Create a job card that preserves the requested work

Open the job-card creation guide when you are ready to turn the enquiry into a shared record. Preserve the customer's description and distinguish it from a diagnosis or proposal that has not yet been made. The brief should explain the purpose of the visit and which information remains unknown.

Write the scope in language that another employee can understand. A note such as “repair as discussed” depends on a conversation that the attending user or billing reviewer may not have heard. Identify the relevant area or equipment and the intended outcome without overstating what the team has already confirmed. The customer request, assessment and performed work should remain distinguishable throughout the exercise.

Ask the field participant to read the saved brief and explain what they believe has been agreed. Do not supply extra context until they have identified their questions. Those questions are useful evidence about the record. Revise the brief where needed, then check whether the next person can proceed without relying on the original writer's memory.

Prepare a quotation around a clear customer decision

A quotation exercise should make the proposed work and amount understandable. Use representative service descriptions, labour and material lines, quantities and units. The responsible person still verifies suitability and scope; a calculated total does not establish that the proposal contains every item the real job requires. Keep the commercial agreement distinct from any technical assessment.

Use the remote quote-approval guide to explore the handover between preparing a proposal and obtaining the relevant decision. Identify who can approve the work and what they need to review. A person providing access may not have authority to agree additional expenditure. Sending a quotation is different from receiving approval.

Include one proposed change in the example. Ask the office reviewer to identify the current agreed scope and the outstanding decision. Demonstrate any essential digital approval or signature workflow in the selected plan, and inspect the resulting customer-facing record. The exercise is complete when both participants can explain what the customer has been asked to decide and what happens next.

Schedule the job only when the brief is usable

Open the technician dispatch guide after the example contains enough information for a realistic assignment. Review the purpose, relevant people, access and preparation. A calendar entry should reflect the actual appointment commitment, while an outstanding preparation item should remain visible. Creating a scheduled record does not by itself establish that the visit is ready.

Use the assignment arrangement your team needs, including supporting users if more than one person attends. Review travel and practical constraints through your operational process. A dispatch interface does not establish qualifications or automatically provide every specialist planning capability. If route optimisation, rostering or multi-day dependencies are essential, demonstrate those requirements separately.

Then move the appointment and have the field participant inspect the updated brief. Identify who informs the customer and whether another commitment needs attention. The result should make the current plan clear without forcing the user to choose between an older document and a newer message. This change scenario is a useful check that the process works beyond the first successful assignment.

Decide what evidence the field record needs

The visit outcome should tell the office what was done and what remains open. Agree the information the reviewer needs before collecting a large set of notes or photos. An observation, a proposed action and completed work are different facts. The exercise should preserve those distinctions rather than rely on one status to explain the entire visit.

Use the before-and-after photo guide to prepare a small, purposeful set of example images. Each should identify the relevant area or item and explain why it matters. Avoid unnecessary personal information or sensitive details. A large attachment count is not evidence that the handover will be understandable.

Ask the office participant to explain the outcome from the saved record alone. If a photo or note is ambiguous, improve its context. Verify any essential metadata, retention, editing or specialist-document requirement separately. Ordinary photos should not be assumed to provide immutable evidence, certification or guaranteed acceptance by an external reviewer.

Include an exception before judging the workflow

A process tested only with fully completed work can hide its most important weaknesses. Add one ordinary exception: a material is unavailable, access changes, the customer asks for extra work or another assessment is needed. Record the facts and assign the next action. The goal is to see whether the office can continue the work without guessing what the field user intended.

Keep the exception distinct from completed activities. A visit can end with some work performed and another item still waiting for a decision. The customer-facing record and internal handover should not imply that everything was finished merely because attendance ended. Confirm how your process explains the difference and who follows up.

Review the billing handover before producing the final document

Open the invoicing guide when the example contains an outcome the office can inspect. The reviewer needs the agreed scope, performed work and relevant materials or changes. A completed status may still conceal a missing reference or an additional item awaiting approval. Identify those exceptions before treating the job as ready for a final customer charge.

Inspect the customer-facing document rather than only the internal form. Check descriptions, site references, quantities, totals and the contact information available for a query. If the business needs a particular purchase order reference or specialised billing arrangement, demonstrate it explicitly. A quotation and final invoice should not be assumed to satisfy every deposit, staged-payment or construction-accounting process.

Ask the reviewer to explain the result without consulting the attending participant. They should recognise what was agreed, what happened and which item remains unresolved. If they need another conversation, identify the information that would make the record clearer. The exercise should reduce ambiguity in the handover, rather than simply produce a document more quickly.

Compare paper, messages and digital records using the same example

The paper versus digital job-card guide and WhatsApp versus job-management guide are most useful when you bring the same job to each comparison. Review the information needed at intake, attendance and office handover. This makes the comparison about your process rather than a general preference for one tool.

Identify which parts of the current approach work well and where information becomes hard to retrieve or interpret. A quick conversation may be effective for an immediate clarification, while the resulting decision still needs a shared record. The practical question is how the next person finds the current agreement and next action after the conversation ends.

Do not assume a new application fixes unclear ownership automatically. Decide who records the customer reference, updates the appointment and follows the outstanding decision. Then evaluate whether the selected tool supports those responsibilities with reasonable effort. A useful result can include retaining a communication channel while making the authoritative job record clearer.

Test connectivity with a named action and expected result

Field connectivity should be evaluated through specific actions on the devices your team uses. Reading an already loaded brief, saving a new outcome, uploading a photo and receiving an office change are different tests. Write down the starting state and the result the office should eventually see. A broad offline label does not establish that every action behaves identically.

The field-service continuity guide can help frame operational questions, but use current conditions and your own service arrangements when preparing the exercise. Demonstrate the essential actions during a weak or unavailable connection, then reconnect and verify the saved result. Avoid assuming that a visible page proves a change has reached the shared system.

Check the human signal as well as the stored information. The field user should recognise an incomplete handover and the office should know when another action is still needed. Record any limitation and decide whether a clear procedure can accommodate it. This creates a practical acceptance test instead of relying on a universal claim about the whole product.

Keep specialist requirements outside unverified assumptions

A general operations guide can help organise information, but it does not determine technical procedures, qualifications or regulatory compliance. If your workflow depends on a specialist form, certification, legal requirement or accounting treatment, identify the responsible authority or professional and verify the requirement through current reliable information. Keep that decision distinct from the administrative exercise.

The same principle applies to product capabilities. A feature name such as equipment, contracts or reporting does not establish every detailed action your business may need. Demonstrate the exact workflow in the intended plan. If the guide discusses a broader practice, distinguish that practice from a capability you have actually verified in the application.

Write down any requirement that remains unproven and assign someone to resolve it. This is especially useful before a customer commitment or full rollout. A small trial is successful when it makes the fit and gaps clearer; it does not need to pretend that every possible requirement has already been met.

Review the exercise with the people who use the handover

Bring the office and field participants together after the example is complete. Ask each to identify useful information, missing context and unnecessary effort. They may see different problems because they enter and consume the record at different times. Use the same saved job to ground the discussion, rather than relying on a general impression of the interface.

Agree a small revision to the process and repeat only the relevant part of the exercise. If the site naming is unclear, improve that convention. If billing cannot distinguish extra work, revise the outcome and decision record. Avoid changing everything simultaneously, because it becomes harder to tell which adjustment improved the handover.

Record the result in a short checklist that another employee can follow. Include who owns the next action and how exceptions are recognised. The checklist should reflect what the team demonstrated, not copy every step from an article without considering its purpose. This gives onboarding a practical foundation that can evolve from actual use.

Roll out gradually and review completed jobs

Begin with a limited set of customers and a small group of users who can finish the workflow together. Agree naming conventions and check important identifiers before importing more data. A large import can carry inconsistent references into the new process faster than the team can correct them. Expand when the first examples are understandable and repeatable.

Review a small group of completed jobs after rollout. Look for missing context, unresolved actions and records that still require private explanations. These observations can show whether the process is being adopted, but they should not be turned into guaranteed savings or broad performance claims without an appropriate basis. The useful question is what the team can now do more clearly and what still needs adjustment.

Choose the next guide or product conversation

Return to the guide cards when the first exercise reveals the next task. A clearer job brief may make dispatch the next priority; a complete field record may reveal a billing-reference problem. Follow the dependency that prevents the next person from proceeding. You can use the blog for broader context when a decision needs discussion before another implementation exercise.

If you are evaluating WorkOrderPro, confirm the selected plan and complete active-team total on the pricing page. Active administrators, dispatchers and field users count, while disabled accounts are excluded. Demonstrate essential requirements before expanding the team. A useful trial ends with evidence about the workflow and a clear owner for rollout, rather than a collection of enabled accounts.

Use the contact page to describe a requirement that remains uncertain. Include the task, the people involved and the result you need to inspect. This makes a product discussion more useful than a broad request for every feature. The aim is a practical decision supported by one complete, understandable job and a record of what still needs verification.