Choose field workforce software by connecting the job, the scheduled resource and the evidence needed to close the work. Define availability and reassignment rules before comparing dispatch screens. A booking that ends and a job that is complete can mean different things, so the demonstration should follow both records through a representative handover.
Begin with the operational question: which person or resource should attend which job, and what does the back office need afterwards? Record the expected task, relevant skills, location and completion information. Ask the team handling the work to explain exceptions such as absence, follow-up visits and unfinished work before selecting the software workflow.
How should a job differ from its bookings?
Microsoft’s work-order and booking-status guidance provides a useful example. Field Service distinguishes work-order system statuses, substatuses and booking statuses. Give those records separate entries in the requirements so the team can explain what each one represents in the intended operation.
A status change can automatically update other statuses. Ask the demonstrator to show that relationship in the proposed configuration. Retain the starting and resulting states instead of assuming that a familiar label such as “completed” has the same meaning on every screen.
Every booking-status change creates a timestamp. Include the relevant history in the evidence discussion and ask which event each timestamp describes. An update by a technician, a back-office correction and the end of a visit deserve clear interpretation in the handover record.
A work order with multiple bookings depends on all related booking statuses. Use a sample requiring a follow-up visit so the team can inspect that relationship. Ask what should remain open after the first visit and which record owns the next action. This makes unfinished work visible rather than hiding it behind a completed booking.
Which availability information should dispatchers rely on?
Microsoft’s resource-setup documentation describes the scheduling inputs. Bookable resources can represent people, equipment and facilities. Decide which kinds the actual workflow needs; an individual technician, a required vehicle and a shared room may have different owners and availability rules.
Resource records include work hours, location, skills, territories and availability. Have the dispatcher and resource owner review the proposed values together. A scheduling screen is only useful when the underlying information represents the work accurately and someone is responsible for keeping it current.
The schedule assistant returns resources with capacity in their designated work hours. Define the intended working arrangement before assessing a suggestion. Record the calendar and capacity configuration used in the demonstration, and ask the dispatcher to explain why the returned resource fits the sample job.
A resource can belong to multiple territories while a requirement maps to one. Keep the territory decision explicit for the sample task. A broad label on a person’s record should not become an unsupported claim that the business operates or can fulfil every request in the named area.
| Operating question | Record to inspect | Proposed acceptance observation |
|---|---|---|
| What work remains? | Work order and agreed task | Back office identifies the outstanding action |
| Who is scheduled? | Resource and booking | Dispatcher explains the assignment |
| Is the resource available? | Calendar and capacity configuration | Sample suggestion matches the intended working arrangement |
| What happened on the visit? | Booking state and relevant history | Reviewer distinguishes visit progress from job completion |
| Who owns follow-up? | Remaining booking or work-order action | Named owner can locate and continue the work |
This original worksheet turns the demonstration into a review of the operating model. Add the evidence the business needs, such as approved completion notes or other documented artefacts, then verify the selected product’s support before describing any of them as available features.
What happens when the assigned resource becomes unavailable?
Time-off entries can represent temporary resource unavailability. Include a planned absence in the scheduling demonstration and inspect how the intended route handles it. Record the actual configuration and the effect on the sample schedule rather than assuming the absence automatically resolves all existing commitments.
Deactivating a resource does not cancel its existing bookings. Ask the dispatcher to review and explain the upcoming work during a departure or role change. Give the reassignment decision a named owner and retain the evidence that the intended jobs have been considered.
Distinguish a resource record’s lifecycle from the work already assigned to it. The person maintaining staff details may be different from the person responsible for dispatch. Put that handover in the operating requirements so a change to one record cannot leave the team uncertain about a visit.
Agree the customer-facing explanation of a rescheduled job with the actual business process. Keep any promised attendance time or follow-up commitment grounded in the operation’s confirmed plan. A software status alone is not a reason to invent a service guarantee.
Original absence-and-follow-up exercise
Use a fictional service job requiring an initial visit and possible follow-up in a separate test environment. Prepare approved sample resources and a temporary absence. The exercise follows the dispatch decision, the booking states and the remaining work through a reassignment.
First, record the expected job outcome and the resource requirements. Ask the dispatcher to locate a suitable resource and explain the relevant calendar, skills and territory information. Retain the proposed assignment and configuration with the test record.
Next, introduce the sample absence using the supported test route. Inspect the existing booking and the options for assigning the remaining work. Record the dispatcher’s decision and the observed result. Have another participant identify who now owns the next action without relying on an informal verbal explanation.
Then complete the initial sample visit while leaving a clearly defined follow-up requirement. Inspect the booking and work-order states together. Ask the back office to explain what remains open and how the next person finds it. Retain any mismatch between the intended process and the displayed result.
Finally, review the evidence with dispatch, the resource owner and the implementer. Assign unresolved configuration and handover questions, then repeat the affected part when a correction is made. Use the resulting record to assess operational fit before planning wider use.
Include the frontline participant in the review. Ask them to find the revised job, explain which part they are expected to complete and identify where to record an unresolved issue. Compare that understanding with the dispatcher’s view. Any difference becomes a concrete handover problem to resolve before the workflow is accepted for wider use.
For broader requirements, see business systems and software development. Get started with your job lifecycle, availability rules and completion evidence requirements.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.