Why Do Technician Efficiency Figures Differ Between the Workshop and the DMS?

Ask a workshop manager how efficient the technicians were last month and you will get a figure from the workshop management system. Ask the group aftersales director and the DMS will produce a different one. Ask finance, working from payroll hours, and you will get a third. None of them is necessarily wrong. Each measures something slightly different, and nobody wrote down what.

This matters because technician productivity reporting drives real decisions: staffing levels, bonus payments, labour rate reviews, which sites get investment, and which managers get difficult questions. When the inputs disagree, the monthly review becomes an argument about whose spreadsheet is right instead of a discussion about what to do with the workshop.

This article explains why billed hours and clocked hours drift apart, how to diagnose the gap in your own group, what it costs, and which fixes work with the systems you already own. It then covers how The Ninjaz Group approaches the problem.

Efficiency, utilisation and productivity are different measures

Much of the confusion starts with vocabulary. Definitions vary between vendors and between groups, which is the point, but the most common usage looks like this:

• Efficiency: billed (sold) hours divided by clocked hours on jobs. It shows how quickly work is done compared with the time sold.
• Utilisation: clocked job hours divided by attendance hours. It shows how much of the paid day went onto jobs.
• Productivity: billed hours divided by attendance hours. It combines the two, since it is efficiency multiplied by utilisation.

The workshop efficiency vs utilisation distinction is where reports mislead. A technician can post 120% efficiency and 55% utilisation. On an efficiency report that person looks excellent. On a utilisation report the same person looks like a capacity problem. Both are true, and neither tells you enough alone.

Now add the denominators. The workshop system usually takes clocked time from job clocking. The DMS may take attendance from a payroll import. Payroll holds paid hours, which include breaks, training, absence and overtime. If each system calculates "efficiency" with a different denominator and a different cutoff, the reports will never agree, however carefully each was built.

Where the numbers drift apart

The drift rarely comes from one big error. It builds up from small differences at each handoff:

• Clocking: Technicians clock onto jobs through terminals, tablets or an app. They forget to clock off, run two jobs at once, or book time to a generic "general work" job. If the technician clocking system is separate from the workshop management system and syncs overnight, corrections made in one place reach the other late, or never.
• Job allocation: The scheduler moves jobs between technicians during the day. The workshop system credits clocked time to whoever clocked on. The DMS may credit billed hours to whoever the job was first booked to, or to the person named when the invoice was raised. Split jobs and apprentice work add more ambiguity.
• Billed hours: Sold hours depend on labour time guides, fixed-price menus, warranty rates, goodwill gestures and internal work. A discount may reduce the hours recorded or only the value. Quoted time and sold time can also differ.
• Timing: One system recognises hours when the job is closed, another when it is invoiced. Around month end, a job closed on the 30th and invoiced on the 2nd lands in different periods.
• Payroll: Attendance hours depend on how shifts, overtime and absence are coded, and often on employee IDs that do not match the technician codes in the workshop system.
• Reporting and BI: Each extract applies its own filters. A BI layer then adds its own joins and rules, and a technician who changed site mid-month can be counted twice or not at all.

Each of these is individually reasonable. Together they produce figures that cannot be reconciled without detective work.

A twelve-location example

Consider a group with twelve locations. Eight sites use the workshop system's clocking terminals. Four still use paper job cards that an advisor types in at the end of the day. The DMS receives billed hours from invoices. Payroll sends a weekly attendance export. Group BI joins everything on technician code and produces a league table of sites.

Site A reports 108% efficiency in the workshop system and 94% in the DMS. The cause is the scheduler. Jobs were moved between technicians during the day. The workshop system credited time to whoever clocked on, while the DMS credited the hours to the technician on the original repair order. The total hours are the same, but they sit against different people and different days.

Site B shares a senior technician with a neighbouring location. That person has two technician codes and one employee ID. Attendance is attached to one code and job hours to both, so one site's utilisation looks poor and the other's looks inflated.

Site C uses paper cards. Start and finish times are rounded to the nearest quarter hour and keyed in later, so clocked hours run consistently higher than reality and efficiency looks lower than it is.

The group director sees a ranking. Part of that ranking reflects workshop performance, and part reflects how each site's data happens to be captured. Nobody can tell which part is which from the report.

How to diagnose the gap in your own group

You do not need a new tool to find out how bad the problem is. You need one site, one closed month and some patience.

1. Write down each system's definition. For efficiency, utilisation and productivity, record the numerator, the denominator, the period rule and the source system.
2. Pull technician-level figures for one closed month. Take them from the workshop system, the DMS and payroll, for a single site.
3. Reconcile billed hours by repair order. Match the workshop system to the DMS job by job. Count the mismatches and sort them: reallocated jobs, timing differences, discounts, warranty, internal work.
4. Compare clocked hours with attendance. Look for overlapping entries, jobs left open overnight, and clocked time that exceeds the shift.
5. Check identifiers. Confirm that technician codes, employee IDs and site codes map one-to-one across systems, including for people who work at more than one location.
6. Trace one BI figure back to source. Follow a single number through every extract, filter and calculation, and note where it changes.
7. Repeat at a second site with a different setup. Do this before drawing group-wide conclusions, ideally one that uses paper cards or a different clocking method.

The result is usually a short list of causes ranked by size. That list is more useful than any dashboard, because it tells you what to fix first.

What the gap costs

The cost is real even when it is hard to see on a single line of the budget.

Time. Service managers and analysts rebuild reports in spreadsheets each month. Reviews begin with reconciliation instead of decisions.

Mistakes. Bonuses, technician targets and hiring decisions rest on figures that may reflect data capture instead of performance. A good technician can be marked down because jobs were reallocated away from their code.

Lost revenue. If utilisation looks high, a site may turn away bookings or stretch lead times while bays sit idle in practice. If it looks low, managers may push more work than the team can deliver and miss promised times.

Burnout. Technicians who are held to numbers they cannot influence lose trust in the process. Those whose numbers flatter them tend to get the most work, whether or not that is sustainable.

Customer frustration. Poor visibility of real capacity shows up as late handovers, vague promise times and repeat calls to the advisor.

Parts and planning. Parts ordering and stock planning rely on expected workload. If workload and capacity are misread, you get urgent orders, delayed jobs and stock that sits unused.

None of this requires an unusual failure. It is the normal outcome of numbers that look precise but are not comparable.

Fixes that work before any new technology

Most of the damage can be reduced with decisions, not software.

• Agree one written definition for each KPI and publish it, including the denominator and the cutoff rule.
• Give every technician a single identity that maps across the workshop system, the DMS and payroll, with an explicit rule for people who work at more than one site.
• Decide who gets credit when a job is reallocated or split, and apply that rule everywhere.
• Set clocking standards: clock to the job, never to a generic bucket, with automatic or supervised clock-off at breaks and shift end.
• Review an exceptions list daily (open jobs overnight, overlapping clocks, clocked time over shift) rather than waiting for month end.
• Name one owner for each KPI, with authority to resolve disputes.

These rules only hold if the systems apply them consistently. In many groups, they do not, because each system was configured separately, at a different time, by a different team.

How Ninjaz approaches it

The Ninjaz Group is a managed-services partner for multi-location businesses, and this is the kind of problem it is set up for. The work usually starts with a Blueprint: mapping the operation to find where data is created, where it is retyped, where it goes stale and where work is done twice. For this problem that means following a job from the schedule through clocking and invoicing to payroll and the report. The client keeps the map, whether or not it goes further.

From there, Build & Link works without rip-and-replace. Software you have already paid for stays. The Ninjaz Operating Platform connects to the workshop management system, the DMS, finance and the other systems in use, through the Managed Link integration layer that Ninjaz builds, owns and maintains. Its unified data layer holds one record per customer, asset and order, so a job means the same thing in every view. Agreed definitions can then be applied once, in one place, instead of separately in each report. The Command Center gives live KPIs and alerts across locations, and roles and an audit trail show who changed what.

After go-live, Managed Business Operations covers the day-to-day running, so a system update or a changed export does not quietly break the numbers again.

To be clear about the limits: a platform does not decide your definitions or change clocking habits on the workshop floor. Those remain management decisions. What it can do is make the data consistent, make the exceptions visible and keep the reconciliation from becoming a monthly manual task.

Make the numbers match what happens in the workshop

If your efficiency figures differ depending on who produced them, treat that as a design problem. Start with the seven-step diagnosis above on a single site. It will show how large the gap is and where it begins.

If you want help mapping it across the group, book a consultation and we will walk through your current systems and reports. If you would rather see how a connected view of operations works first, take a look at the platform demo.