The starting point
Field-service businesses can start with a job history connecting the reported issue, individual visits, actions and follow-up. A completed appointment is not necessarily a resolved problem. Describe how jobs and visits connect before deciding whether a potential licensing conversation is worth further preparation.
Build a useful inventory.
Describe categories and connections. Keep actual records in your own systems during the initial fit review.
| Illustrative category | Describe without exporting | First question |
|---|---|---|
| Job histories | Fault category; job period; action references | Can visits reach their original job? |
| Visit events | Attendance, no-access and callback categories | Is a visit count being called a job count? |
| Follow-up | Test or review coverage; unresolved states | Does completed mean work done or fault resolved? |
Scroll across to read all three columns.
Check the status dictionary before describing success.
Microsoft’s Field Service reference gives work orders and bookings separate lifecycles. Several bookings may belong to a single work order, and configuration affects completion and posting. Compare those distinctions with the meanings in your system. An invoiced job can establish a billing step while leaving the repair outcome uncertain; ask which follow-up record supports the intended label.
Choose linkage that does not start with a person.
A parent job reference or explicit callback link can explain the sequence without putting a customer’s name at its center. Keep access failures, declined work and failed checks distinguishable. Exact premises, technician routes, messages and photographs require separate scrutiny. Where a migration lost the parent link, record the gap rather than reconstructing every visit from shared addresses.
Use a specific introduction brief.
Describe service type, retained dates, job and visit counts, outcome coverage and unresolved rights. VOID can explore a potential route from that metadata with no upfront seller referral fee. Any receiving-program compensation depends on its conditions and is disclosed before the named introduction. The business approves the recipient and exact information; an inquiry does not authorize a job sample, customer contact or license.
Hypothetical screening example
Illustration: narrow a three-visit episode.
A fictional repair job has an inspection visit, a parts visit and a later check. The first two appointments are complete, but only the check records the defined result. The inventory describes three visits belonging to one job and preserves the failed intermediate check. An unrelated new job at the same premises stays separate.
Next decision. Narrow: discuss linked repair episodes; hold a blanket claim that every completed visit resolved a fault.
Questions before the next step.
Can dispatch counts show how many problems were resolved?
Only after jobs, visits and outcome evidence are distinguished. Several dispatches may address one problem, and some visits perform no repair.
What should we prepare for the first conversation?
A category description and coverage limits. Keep job sheets, customer addresses, images and system credentials inside your business.
Source notes
Software documentation describes possible record structures. It does not establish your retained history, rights or buyer acceptance.
Microsoft — work order lifecycle and system statusesMicrosoft · Checked 2026-10-11Work orders and bookings have separate lifecycles. Multiple bookings can relate to one work order; configuration affects completion, posting and invoice creation.