ServiceNow Performance Analytics for Construction and Engineering

Field Technician and Dispatch Metrics

Construction and engineering organisations rely on field teams: electricians, plumbers, HVAC technicians, project engineers. Performance Analytics should track: technician utilisation (are they billable time), first-time fix rate (do issues get resolved in one visit), travel time and efficiency (time spent travelling versus working).

For dispatcher teams, track: mean time to dispatch (how quickly are jobs assigned to technicians), dispatch accuracy (are the right technician assigned, or is there a high reassignment rate?), and on-time dispatch (do technicians receive job information before they need to start work?).

Service Level Agreement Performance by Work Type

Different work types have different SLAs: emergency repairs need the shortest response, while routine maintenance and inspections can have longer targets. Performance Analytics should calculate SLA compliance by work type and location. Identify which work types consistently miss SLA and investigate root causes.

Construction projects often have tight timelines. SLA performance directly impacts project schedules. If inspection SLA is missed, it delays the next phase of construction. Use analytics to prioritise dispatch and staffing.

Technician Skill and Certification Tracking

Technicians must maintain certifications: electrical, plumbing, HVAC, OSHA safety. Performance Analytics should track: which technicians have which certifications, when certifications expire, and what fraction of the workforce maintains current certifications. Flag technicians with expired or expiring certifications.

Link technician skills to job assignments: ensure that complex jobs are assigned to appropriately skilled technicians. Use analytics to identify skill gaps and guide training investments.

Equipment and Asset Utilisation

Construction and engineering organisations maintain equipment: trucks, tools, testing equipment. Performance Analytics should track: equipment utilisation (is it being used effectively), maintenance compliance (is preventive maintenance on schedule), and equipment downtime (how much productive time is lost due to equipment failure).

Asset-heavy organisations can improve profitability by optimising asset utilisation. Analytics help identify underutilised assets that can be sold or redeployed.

Project-Level Impact Analysis

Service delivery issues have downstream impacts on projects. Performance Analytics should link incidents and changes to projects: if a technician is delayed, which projects are affected? If a permit is delayed, what is the impact on project timeline and budget?

Use analytics to prioritise incident resolution: incidents affecting project timelines get higher priority than incidents affecting routine maintenance.

Safety and Compliance Metrics

Construction and engineering are high-risk industries. Track: safety incidents by technician and location, OSHA compliance, training compliance (are all technicians trained in required safety procedures?). Use analytics to identify high-risk technicians or locations and target safety improvements.

Customer Satisfaction and Quality Metrics

Performance Analytics should include customer satisfaction: surveys after job completion, quality ratings (was the work done correctly?), rework rate (what percentage of jobs require follow-up?). Link these metrics to individual technicians to identify top performers and those who need coaching.

Revenue and Profitability Metrics

For service organisations, performance analytics should include business metrics: revenue per technician, cost per job, gross margin by work type or technician. Identify highly profitable work types and technicians who consistently deliver profitable engagements.

Preventive Maintenance and Asset Lifespan

Preventive maintenance extends asset lifespan and prevents costly emergency repairs. Performance Analytics should track: preventive maintenance compliance (are maintenance tasks being completed on schedule?), and impact on asset lifespan (are assets lasting as long as expected, or failing prematurely?).

Technician Training and Development

Performance analytics should identify training needs: if a technician has a low first-time fix rate, they may need additional training or mentoring. If a technician consistently gets high customer satisfaction ratings, they are a high performer and candidate for mentorship roles or advancement. Use performance data to guide individual development plans and identify high-potential technicians for career growth.

Compensation and Incentives Based on Performance

Use analytics to inform compensation: technicians with high utilisation, high customer satisfaction, and high profitability might earn bonuses or raises. However, make sure the incentives do not have perverse effects: do not incentivise only utilisation (quality and safety matter too) or only quality (business sustainability matters too). Balance metrics in incentive design.

Predictive Analytics for Demand Planning

Performance analytics can support capacity planning: historical data on job volume, types, and duration helps forecast future demand. This guides hiring decisions: should you hire more technicians, or do you have excess capacity? Which skills are in high demand and should be priorities for hiring and training?

Decide which field decisions the dashboard must support

A scorecard that a dispatcher opens at the start of the morning and a monthly pack that a director reads at month end are answering different questions. Most field service dashboards struggle because they try to answer both with one set of tiles. Before any indicator is built, write down the decision each audience makes from it. The dispatcher decides which technician goes to which job next. The site delivery lead decides whether a project phase can begin on schedule. The service owner decides whether a skill gap justifies a training budget. Each decision needs a different time window, a different grain of data and a different tolerance for lag, and Performance Analytics for ITSM is most useful once the requirements for all three are settled.

A practical test is to ask what the reader would do differently if a number moved by a meaningful amount. If nothing changes in the dispatch sequence when first-time fix falls, that indicator belongs in the monthly review and should not occupy the morning board. Five or six named decisions usually shape a whole build. Anything that does not map to one of them is a candidate for removal.

Choose the scorecard shape before the indicators

The capability register is the view most teams build last, and in construction it often matters most. A certification that lapsed last week can stop a crew from entering a site, so keep it as a separate view with its own owner rather than one tile on the dispatch board. The register is often most useful when it feeds field service management assignments directly, so a technician whose credential is about to lapse is flagged before the job is offered rather than after the visit fails.

Define each indicator so two sites measure it the same way

An indicator is a definition before it is a chart. For every measure, write the start event, the stop event, the permitted pauses and the population the measure covers. Time to dispatch shows the problem clearly. One site may start the clock when a job is logged and stop it when a named technician is assigned, while another starts when a dispatcher first opens the record. Both numbers appear identical on a dashboard, and both will be defended in good faith until someone compares them and finds that one site looks twice as fast.

Pauses need the same discipline. A job waiting on a permit inspection, a utility shutdown or a locked gate is not a failure of the field team. A clock that keeps running through that wait pushes the SLA measure into the red for reasons nobody on site controls. Agree the list of legitimate pause states in advance, give each one a reason code, and report paused time separately so the wait stays visible without being charged to the crew. For the breach side of the problem, rather than how breaches are recorded, the SLA breach prevention article is the place to look.

An ordered procedure for the first indicator set

1. Write the decision list and name one reader for each decision.
2. Identify the single source record each indicator reads from, and confirm that the timestamps it needs are captured when the event happens rather than reconstructed afterwards.
3. Draft the definitions in plain sentences covering start, stop, pauses and population. Have the dispatch lead and a site manager sign them off separately.
4. Build the dispatch board first, because its feedback loop is the shortest and it exposes data gaps quickly.
5. Run the new measures beside the existing report for a full cycle that includes the work type with the longest service window. Log every difference between the two.
6. Publish the monthly pack only after each difference has been explained and either corrected or accepted in writing.

The parallel run is the step teams skip most often. It feels like duplicated effort, but it is the only dependable way to find a definition that varies by site before a director quotes the wrong figure in a board paper.

Where field service measures go wrong

• Averages taken across all work types, so a fast result for routine inspections hides slow emergency repairs.
• Reassignments counted as new dispatches, which inflates volume and makes the dispatcher look busier than the process requires.
• Closed dates used in place of completed dates, so records sitting in an administrative queue appear to be slow field work.
• First-time fix reported without a rule for revisits caused by parts missing from the van, which penalizes the crew for a stores problem.
• Technician rankings built on raw job counts when jobs differ widely in travel time and complexity.

How to tell the scorecard is doing its job

A working scorecard changes behavior in a few identifiable places. The dispatcher reorders the morning queue before the first call. A site manager asks for a skills check before a crew is sent rather than after a failed visit. The service owner stops asking for a chart and starts asking why one job type keeps missing its window. If the dashboard is read but the schedule never changes, the measures are real but not actionable, and the decision list needs rewriting. Prettier charts will not fix that.

When a simpler report is the better choice

A firm with one dispatcher, a small crew and a single type of work does not need a full build to see what is happening. A weekly table kept in the service desk, reviewed in the same meeting each week, can produce better decisions for less upkeep. The case for a configured scorecard strengthens when sites, work types and audiences multiply to the point where people reconcile spreadsheets by hand every month. Until then, a well-defined manual report beats an elaborate dashboard nobody trusts. Where a configured scorecard already exists, a Performance Analytics health check is one way to test whether its dashboards and metrics still drive decisions.

How often should a field scorecard refresh?

Match the refresh to the decision. A dispatch board that drives same-day reassignment needs data current within the working hour, while a service owner reviewing trends over months gains nothing from hourly refreshes and can be misled by partial days. Many teams run two refresh rates from the same underlying records, which keeps the definitions consistent while giving each reader the speed they need.

Should technicians see their own indicators?

Often yes, but only the measures they can influence, with the pause reasons displayed beside them. A technician shown a low first-time fix rate without the context that half the revisits came from missing parts will reasonably conclude the scorecard is unfair, and that conclusion spreads faster than any training. Review a sample of revisits with the crew lead before any coaching conversation takes place.

Why does the same job show different results in two reports?

Usually because the reports start or stop the clock at different events, or because one includes a status the other excludes. Compare the start and stop timestamps on a single job before changing any chart. The discrepancy is almost always in the definition, and correcting it in one place is quicker than reconciling two reports line by line.

Can certification expiry count as a performance indicator?

It is better treated as a compliance control with a performance view on top. Expiry dates belong on the capability register and should trigger alerts before a technician is assigned work that needs the credential. Scoring an individual for an expired certificate tends to hide the real cause, which is usually a renewal process that depends on one person remembering a date.

Who should own the indicator definitions?

A named service owner should hold them, with the dispatch lead and a site representative as required reviewers. Log every change with its reason, its date and the old and new rules, so a trend line does not appear to move when only the definition changed. Without that log, a year of history cannot be compared honestly.

Performance Analytics for ITSM: indicator names, breakdowns and source tables

Performance Analytics turns records such as incidents and SLA rows into scores tracked over time. An indicator measures one thing, a breakdown splits it by a field such as group or location, and a scheduled data collection job stores the score from each run so trends can be charted.

These are common out-of-box names. Check them on your own instance and release, because labels and defaults change between releases.

Example (hypothetical): a dispatch lead wants late jobs by work type. The team builds one indicator that counts open work orders from wm_order, adds a breakdown on the work type field, and shows the result on a dashboard. Emergency and routine jobs then appear as separate lines. The lead can then ask why one work type slips, and the answer comes from the records behind the score rather than from a spreadsheet kept by hand.

What is the difference between an automated and a formula indicator?

An automated indicator reads records from a table on each collection run, using conditions you set. A formula indicator combines other indicators, for example a ratio of two counts, so the maths is defined once and reused across dashboards, and a change to the definition shows up everywhere it is used.

What does a breakdown add to an indicator?

A breakdown lets one indicator be sliced by a field, such as assignment group or location, without writing a separate indicator for each value. Choose breakdown fields people actually filter on, because every extra split adds collected data and makes the dashboard harder to read at a glance.

Where should I start with ITSM analytics?

Begin with one indicator that answers a decision someone makes weekly. See Performance Analytics for ITSM, reporting and dashboards and Performance Analytics implementation.