Technician Utilisation and First-Time Fix Reporting That Field Managers Trust
A technical guide for Dynamics 365 Field Service: define the denominator and the repeat-visit rules first, use the tables that carry the truth, build both measures and start the capture that makes them possible.
Field managers stop trusting utilisation and first-time fix reports when nobody wrote the definitions down, so define both before building. Utilisation needs a stated denominator: scheduled hours, available hours from the resource calendar, or paid hours, each giving a different figure. First-time fix needs a repeat-visit window, such as a return to the same asset for the same fault within an agreed number of days, and a rule excluding jobs paused for parts on order. In Dynamics 365 Field Service the truth sits in bookings, booking journals or time entries, and booking and work order status history. Where that data is missing, start capturing status changes, a parts-on-order substatus and a parent work order link this week.
Why do field managers stop trusting utilisation and first-time fix reports?
Almost never because the arithmetic is wrong. The report loses credibility the first time a manager says "that is not what utilisation means", or points at a job that was counted as a failed first visit when the technician was waiting for a part that the warehouse did not have. From that moment every figure is argued about, and the spreadsheet the manager keeps on the side becomes the real report again.
The causes are consistent. The denominator was never stated, so one dashboard divides by scheduled hours and another by contracted hours. First-time fix was defined by whoever wrote the query, with no repeat window and no exclusions. Percentages were stored per technician per day and then averaged, which weights a two-hour day the same as a ten-hour day. And the capture underneath was incomplete: technicians who move a booking straight from Scheduled to Completed leave no working time to measure. Fix the definitions first, the data second and the visuals last.
Which denominator should technician utilisation use?
There is no single correct utilisation. There are three defensible ones, each answering a different question, and a report that does not say which it uses will be contradicted by someone using another. Choose the one that matches the decision the report supports, label it on the visual, and if more than one audience needs a figure, show them side by side with their names rather than blending them. Decide separately whether travel time is productive: for a contract where travel is billed it may be, for a capacity question it usually is not.
| Utilisation | Numerator over denominator | Denominator comes from | The question it answers | The trap |
|---|---|---|---|---|
| Schedule utilisation | Working hours over scheduled (booked) hours | Bookable resource bookings | Did technicians spend the booked time working, or was it lost to overruns, no access and waiting? | It says nothing about spare capacity: a half-empty schedule can show a high figure. |
| Capacity utilisation | Working hours, or working plus travel, over available hours | Resource calendars (work hours) minus approved time off | Do we have more field capacity than work, or less? | Calendars that are never maintained, holidays not recorded, or a default calendar shared by everyone. |
| Paid-time utilisation | Billable or productive hours over paid hours | Payroll or HR hours, usually outside Dataverse | What share of the labour cost produces revenue or contracted work? | Needs a reliable feed from payroll and a clear rule for training, sickness and overtime. |
How should first-time fix be defined so it survives an argument?
First-time fix sounds simple: the fault was fixed on the first visit. The argument starts at the edges, so write the edges down. The rules below are the ones we put in front of a field service manager to decide, one by one, before building. The answers are a business decision, not a technical one, and different contract types can legitimately have different rules.
| Decision | Options | What we usually recommend |
|---|---|---|
| What is one job? | A work order, or a customer asset and fault combination across work orders | Both: a work order completed on its first booking, and no new work order for the same asset and fault inside the window. |
| What is a repeat visit? | A second booking on the same work order, or a new work order on the same asset | Count both, otherwise closing a work order and raising a new one hides the repeat. |
| How long is the repeat window? | An agreed number of days after completion | A window agreed with the service manager for the work type, written on the report. Too short hides repeats, too long counts unrelated faults. |
| What is the same fault? | Same incident type, same incident type category, or any fault on the asset | Same asset and same incident type or category, so a new unrelated fault is not a failed fix. |
| Parts on order | Count as failure, exclude, or report separately | Exclude from the rate and report the count separately, because it is a stock or planning problem, not a technician one. Only exclude when the parts wait was recorded at the time. |
| No access, customer cancelled, unsafe site | Count or exclude | Exclude with a recorded reason, and report the count. |
| Planned multi-visit work | Installations and projects designed to take several days | Exclude by incident type or work order type; they were never meant to finish in one visit. |
Which Dynamics 365 Field Service tables carry the truth for these measures?
Everything these two measures need is already in standard Field Service tables, provided technicians actually change statuses on the device. The logical names below are the ones we usually meet; they vary between Field Service versions and some capabilities have moved between releases, so confirm them in your own environment and in current Microsoft documentation before writing queries. How these records are designed during a build is covered on our Field Service implementation partner page; the same booking timestamps used here as audit evidence are described in our proof of work guide.
| Table (logical name usually seen) | What it holds | Used for |
|---|---|---|
| Bookable resource booking (bookableresourcebooking) | The resource, start and end time, duration, booking status, the related work order, and in Field Service versions actual arrival and total duration columns | Scheduled hours, visit count per work order, who attended |
| Booking status (bookingstatus) with its Field Service status column | Your custom statuses mapped to Field Service statuses such as Scheduled, Traveling, In Progress, On Break and Completed | Deciding which booking time is working, travel or break. An unmapped custom status silently drops time. |
| Booking journal (msdyn_bookingjournal) | Journal lines generated from status changes, with a journal type such as working hours, travel, break or overtime, start, end and duration | The utilisation numerator |
| Time entry (msdyn_timeentry) | Time entries that recent Field Service versions can create from booking status changes, depending on configuration | The utilisation numerator where your version and settings use time entries instead of, or alongside, journals |
| Booking timestamp (msdyn_bookingtimestamp), where present, and audit history | A row per booking status change with its time | Status history: whether a booking went through In Progress at all, and when |
| Work order (msdyn_workorder): system status (msdyn_systemstatus) and substatus (msdyn_substatus) | Unscheduled, Scheduled, In Progress, Completed, Posted or Cancelled, plus your own substatuses such as awaiting parts | Job outcome and the parts-on-order exclusion |
| Incident type (msdyn_incidenttype) and customer asset (msdyn_customerasset) | The fault classification and the equipment serviced | What counts as the same fault on the same asset inside the repeat window |
| Bookable resource calendars and time off requests | Working hours and approved absence per resource | Available hours for capacity utilisation |
How do you build the utilisation and first-time fix measures step by step?
Build from base quantities at the lowest sensible grain and let the report divide at the end. The modelling rules that make this hold, a star schema, conformed date and resource dimensions and ratios written as measures rather than stored columns, are the same ones set out for OEE in our Power BI for manufacturing guide, so this page does not repeat them. For utilisation, the resource by day fact sums journal or time entry durations by type and joins capacity from the calendar. For first-time fix, the outcome fact takes each completed work order, counts its bookings that reached In Progress, looks forward through the repeat window for a new work order on the same customer asset and incident type, and records the exclusion reason from the substatus. That forward lookup is easiest in a dataflow, Power Query or SQL over an analytical copy; once the history is large, Dataverse aggregate limits apply, and the options are in our guide to Dynamics 365 reporting limits.
- 1. Write both definitions down and get them signed. Agree the utilisation numerator and denominator, whether travel counts as productive, the first-time fix repeat-visit window, what counts as the same fault and every exclusion. The field service manager and finance sign the page before any report is built.
- 2. Map each definition to the table that holds it. Working, travel and break time from booking journals or time entries, capacity from resource calendars and time off, visit status from bookings and their Field Service status, job outcome from work order system status, substatus, incident type and customer asset.
- 3. Profile the data before trusting it. Count bookings completed without ever being set to In Progress, work orders with no incident type or customer asset, custom booking statuses with no Field Service status mapped and resources with empty calendars. These counts tell you which months are reportable.
- 4. Build a resource by day fact and a work order outcome fact. One row per resource per day with working, travel, break, scheduled and available hours, and one row per completed work order with its visit count, a repeat flag and an exclusion reason. Keep hours as base quantities, never as stored percentages.
- 5. Write the ratios as measures that divide at the end. Sum the hours or counts at whatever grain the user filters to and divide last, so a team or region figure is weighted correctly instead of being an average of individual percentages.
- 6. Show the exclusions and the definition on the report. Put the excluded job count by reason and the written definition beside each figure, with a drill-through to the work orders behind it, so a manager who disputes a number can open the jobs.
- 7. Reconcile one month with one manager before rollout. Walk a field manager through one month of their own team, job by job where they disagree, fix the capture or the rule that caused each difference, then publish to the wider organisation.
What should you start capturing this week if the data is not there yet?
If profiling shows bookings jumping from Scheduled to Completed, work orders with no asset, and no record of why a job needed a second visit, neither measure can be reported honestly for past months. Do not reconstruct them. Start the minimum capture now, and the measure becomes reportable from the first full month after the change. Each item below is configuration rather than custom code.
- Make the booking status journey part of the mobile flow: Traveling, In Progress and Completed set on the device, with Completed blocked or flagged when In Progress was skipped.
- Check every custom booking status has a Field Service status mapped, so its time lands in the right journal or time entry type.
- Add work order substatuses for awaiting parts, no access and customer cancelled, and require one when a booking ends without completing the work order.
- Require the incident type and the customer asset on work orders for the work types you will measure.
- Use the parent work order lookup, or a follow-up reason choice column, when a return visit is raised as a new work order, so repeats are linked rather than inferred.
- Record time off in the system and give each resource a real working hours calendar, otherwise capacity utilisation has no denominator. Broken calendars and resource data are covered in our Field Service scheduling rescue guide.
How do you get field managers and technicians to accept the numbers?
Trust is earned by making every figure checkable. Put the written definition on the report page, show how many jobs were excluded and why, and give every total a drill-through to the bookings and work orders behind it. Reconcile one month with one manager before anyone else sees the report, and treat each disagreement as either a capture problem or a rule problem to fix, not as a manager who does not understand data.
Be careful about using either measure for individual performance before the capture has been stable for a few months. A technician whose utilisation looks low because they never set In Progress on the device has a data problem, and a report that treats it as a performance problem will teach the whole team to game the statuses. Start with team and region figures, and the trends in them.
Should field service KPIs be reported from Dynamics 365 or from a system you own?
We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. If work orders, bookings and technicians already live in Dynamics 365 Field Service, report from there: the data model above exists, and the work is definitions, capture and a Power BI model. Where field operations run on a patchwork of tools, or per-user licensing does not fit a large subcontracted workforce, a custom-built CRM and field application on React, Node.js, PostgreSQL or .NET can record the same status journey and produce the same measures under your full control.
Should field service reporting run on Dynamics 365, Power Platform or a custom-built system?
Can afford licensing and want the Microsoft ecosystem
Dynamics 365
Microsoft 365, Teams and Outlook integration, a mature partner ecosystem, Copilot, and apps for sales, service and field operations that are configured rather than built.
Need full control and zero licensing
Custom CRM
A CRM built on React, Node.js, PostgreSQL or .NET that you own outright: your data model, your hosting, no per-user subscription, and features shaped exactly to your process.
Not sure which fits
We help you decide
A short discovery weighs licensing budget, process complexity, integrations and long-term ownership, then recommends one path. We deliver both, so the recommendation has no reason to lean.
What does a Field Service reporting engagement with Solzet involve?
Solzet has 8+ years of Dynamics 365 Customer Engagement and Power Platform delivery, and senior consultants and full-stack developers work remotely from Yerevan, Armenia, directly or white-label for Microsoft partners. A reporting engagement starts with the definitions workshop and a profile of your booking and work order data, so you know which months are reportable before anyone builds a visual. We then adjust the mobile capture and statuses where the data is thin, build the Power BI model and reports on Dataverse, and reconcile the first month with a field manager. If the gaps sit in the wider Field Service build rather than in reporting, see our Field Service implementation partner page.
What do people ask us?
How do you calculate technician utilisation in Dynamics 365 Field Service?
Divide working hours by a stated denominator. Working hours come from booking journals or time entries generated when technicians change booking status on the device. The denominator is scheduled hours from bookings, available hours from resource calendars minus time off, or paid hours from payroll, and each answers a different question. Sum hours at the filtered grain and divide at the end rather than averaging daily percentages, and label which denominator the report uses.
How is first-time fix rate calculated for field service?
Count completed work orders that needed only one working visit and had no new work order for the same customer asset and incident type within an agreed repeat window, then divide by all completed work orders in scope. Exclude, and report separately, jobs paused for parts on order, no access or customer cancellation where the reason was recorded at the time, and planned multi-visit work such as installations.
Should parts on order count against first-time fix?
We usually recommend excluding them from the rate and reporting the count beside it, because a job waiting for parts is a stock or planning problem rather than a technician problem. The exclusion only holds if the wait was recorded at the time, for example with an awaiting parts work order substatus. Otherwise the exclusion becomes a way to hide genuine failed visits.
Should travel time count in technician utilisation?
It depends on the question the report answers. For a capacity question, travel is usually shown separately from working time, because reducing it is a scheduling improvement. Where travel is billed under the contract it can count as productive. Either way, decide once, write it on the report, and keep travel as its own journal or time entry type so both views remain possible.
Why are my Field Service booking journals or time entries missing hours?
Usually because technicians move bookings straight from Scheduled to Completed without setting In Progress, because a custom booking status has no Field Service status mapped, or because the version and settings you run generate time entries rather than journals, or the reverse. Profile bookings by status history, check the status mappings and confirm the time generation settings against current Microsoft documentation for your version.
We have no reliable history. Can we still report first-time fix?
Not honestly for past months. Reconstructing repeat visits and exclusion reasons after the fact produces a number nobody can defend. Start the minimum capture now: status changes on the device, awaiting parts and no access substatuses, a required incident type and customer asset, and a parent work order link for return visits. The measure becomes reportable from the first full month after the change.
Can Solzet build Field Service KPI reporting in Power BI?
Yes. Solzet builds Power BI models and reports on Dataverse for Dynamics 365 Field Service, starting with a definitions workshop and a data profile, then adjusting mobile capture where needed and reconciling the first month with a field manager. We work directly with clients or white-label for Microsoft partners, and build the same reporting in custom applications for organisations that need to operate without Microsoft licensing.
Where should you go next?
Dynamics 365 Field Service implementation partner
The Field Service build: assets, incident types, scheduling, mobile and offline design.
Power BI for manufacturing: 5 reports every plant manager needs
Star schema over Dataverse, measures that divide at the end and the Dataverse connection choice.
Field Service proof of work
Booking timestamps, parts used and photos as evidence that survives an audit.
Field Service scheduling rescue
Fixing calendars, locations, skills and territories when the schedule does not work.
Dynamics 365 reporting limits
Aggregate query limits, Power BI refresh failures and moving reporting to an analytical copy.
Custom CRM Development
Field service and reporting on React, Node.js, PostgreSQL and .NET without Microsoft licensing.
Which solution is right for your business?
Tell us what you need. A senior consultant replies within one business day with a recommendation - Dynamics 365, Power Platform, or a custom-built CRM - not a sales script.