The Manager's Dashboard: The Indicators You Actually Run Operations On

The Manager's Dashboard: The Indicators You Actually Run Operations On

In part six we closed the last operational loop: parts became something issued against a work order, and the technician van became a stock location with a balance and an owner. That completed what the series promised — a request entering through one channel, a visit dispatched to the right technician, a preventive plan that generates its own work, cost charged to a job number, and inventory that is actually known.

What remains is that all of this produces data nobody reads. Companies that reach this stage hit the exact opposite of their original problem: they no longer suffer from missing information but from a flood of it. Too many reports, crowded screens, and a manager who opens the system in the morning and closes it a minute later because there is no obvious place to start. This part is about the fix: a short list of indicators, each with a decision attached.

Why most dashboards fail

A dashboard built to impress does not get used; a dashboard built to decide with gets opened daily. Four recurring mistakes separate them:

• Too many indicators. A screen with forty numbers means, in practice, that none of them is being looked at. Attention is a limited resource, and spreading it across forty items is the same as not spreading it at all.
• Indicators with no action attached. If a number will not change a decision however it moves, it is general information rather than a management indicator, and it belongs in a monthly report rather than on a daily screen.
• A number without context. A standalone metric with no trend, no stated target and no comparison to the previous period says nothing. Numbers acquire meaning by comparison.
• The total that hides the problem. A company-wide average swallows the loss-making contract, the struggling technician and the city where every visit runs late. A healthy average sitting on top of a specific problem is the most dangerous number on the dashboard.

One practical rule covers all of it: no indicator goes on the dashboard until you can answer two questions. Who owns it by name, and what decision gets taken when it breaches its threshold. An indicator with no owner does not improve, and an indicator with no decision behind it turns into decoration everyone gets used to and stops seeing.

The six that are enough

After working with companies in this sector, six indicators cover most of what an operations manager needs daily. Everything else can be a report you open when you need it.

• 1. Response time against the contractual commitment. The gap between logging the request and actually starting work on it, measured against what the contract promised rather than what the team considers reasonable. Read it as a compliance rate, not an average: the share of requests completed within the contracted window. Averages flatter the picture, because a visit closed in an hour offsets one that ran three days late — and the customer whose visit ran late does not care about your average. Action when it breaks: review request distribution and shift coverage in the window where delays cluster, and separate delays that started at intake from delays that started in the field.
• 2. First-time fix rate. The share of work orders closed in a single visit with no return trip. This is the indicator that measures everything built before it at once: diagnosis quality at intake, correct skill assignment, and part availability before dispatch. Action when it breaks: classify the reasons for the return, because there are always only three — a missing part, a mismatched skill, or a wrong diagnosis at intake. Each has a completely different remedy, and merging them into one number prevents all three from being fixed.
• 3. Repeat visits to the same asset. The other face of the previous indicator, but viewed from the asset rather than the visit: how many times you returned to the same unit over a short period. Repeatedly returning to one specific asset does not necessarily mean a weak technician — more often the asset itself has reached the end of its economic life. Action when it breaks: move the asset out of the repair cycle and into a replacement decision backed by its own history, which is exactly what part four enabled when we tied every visit to the asset record.
• 4. Billable utilisation of crews. The share of working hours charged to a contract or project out of total paid attendance hours. The gap between the two is not all waste: travel between sites, waiting on a part, internal work, training. What is useful here is not the number but its breakdown across those buckets. Action when it breaks: if the largest bucket is travel, the problem is the geographic scheduling we covered in part three; if it is waiting, the problem is inventory from part six. One necessary caveat: read this at team level to improve operations, because turning it into a published individual race produces technicians who rush to close, which drives repeat visits up — you win one indicator and lose two.
• 5. Margin per contract or project. The difference between what was billed and what was actually spent, per individual contract as built in part five, not for the company as a whole. Action when it breaks: a contract whose margin approaches zero is a negotiation file at renewal rather than an operational problem, and handling it starts from the cause of the drift — scope expanding without change orders, pricing built on lower consumption than reality, or repeat visits eating the margin one visit at a time.
• 6. Payment application and invoice aging. How long each payment application has been submitted without approval, and how long each invoice has been issued without collection, distributed across age buckets rather than shown as one number. Action when it breaks: escalate follow-up by age bucket, and more importantly go back to the reason for the block — most stalled payment applications are stalled over a missing document or a disputed line item, and both were preventable back in part two when we covered documentation and on-site customer sign-off.

How to read the dashboard without fooling yourself

Having the indicator does not mean reading it correctly, and three habits separate a dashboard that works from one that falsely reassures:

• Segment before you judge. Every one of the six should be breakable by contract, city, team and asset type. The real problem is almost always in one slice, and the total has exactly one job: telling you there is something worth slicing.
• Look at the trend, not the snapshot. Today's number without a comparison to previous weeks cannot distinguish a steady decline from a one-off incident, and the required action in those two cases is completely different.
• Watch indicators in opposing pairs. Any metric can be improved by damaging another: closing speed at the expense of repair quality, lower inventory at the expense of part availability. Always read response time alongside first-time fix rate — together the two tell the truth, while either one alone tells you what you want to hear.

A final point decided by usage rather than design: the dashboard should be read in a short fixed meeting — fifteen minutes at the start of the week, with each indicator having an owner who explains what moved and what they will do about it. A dashboard with no meeting reading it stops being updated within a month and becomes a screen everyone points at and nobody acts on.

Where AI genuinely helps today, and where it is still marketing

This sector is targeted by a lot of AI pitches, most of which sell an outcome that depends on infrastructure the buyer does not have. Sorting them is simple: ask what actually requires data you already own today.

What genuinely works, because its inputs exist in a disciplined operation:

• Workload forecasting. A year of work order history is enough to reveal clear seasonal patterns: the summer HVAC peak, certain request types rising in specific seasons. That translates directly into planning labour and buying parts before the peak rather than during it.
• Anomaly detection in consumption and cost. The system learns what is normal and flags what departs from it: a site whose consumption jumped without more work, or an asset whose maintenance cost broke its previous pattern. This does not give you a verdict — it gives you a question at the right time, which is the more useful thing in practice.
• Classifying and routing incoming requests. Reading a free-text fault description and proposing its category, priority and required trade, which shortens intake time and reduces the diagnosis errors whose effect we saw in the second indicator.
• Summarising an asset or contract history. Instead of reading forty work orders before a replacement decision or a renewal meeting, a one-minute summary with links back to the source documents.

What is still closer to marketing than operations for most small and mid-sized companies: predictive maintenance driven by live sensor readings on equipment. The technology itself is real and mature, but it needs connected equipment, a high-quality documented failure history, and an instrumentation cost only justified by high-value assets whose downtime is expensive. The honest starting point for a mid-sized company is condition-based maintenance with simple tools, as covered in part four: periodic readings entered by the technician during the visit and compared against known limits. That delivers most of the benefit at a fraction of the cost.

Two conditions apply before any of this. First, output quality never exceeds input quality: a model fed incomplete work orders will produce high confidence in a wrong conclusion, which is worse than having no model. Second, a regulatory one: any processing of personal data — including technician location and attendance data — falls under the Personal Data Protection Law and the controls of the Saudi Data and AI Authority. We raised this in part three, and it returns here more sharply, because analysis and inference reach further than plain recording does.

The Origami view

When a client asks us for a dashboard, the first thing we do is reduce the request rather than fulfil it as received. The list that reaches us usually has twenty indicators; we come out with six, and the rest become reports opened on demand. The reason is that a crowded dashboard fails silently: nobody objects to it, and nobody uses it.

As a technology company serving the Saudi contracting and maintenance sector, three rules apply in every implementation. No indicator enters without a named owner and a decision defined in advance for when it breaches its threshold. No indicator is built on data entered manually into a separate file, because any number that depends on extra data entry will stop within six weeks — an indicator is generated by the work itself or it is not generated at all. And we defer the AI layer until the data has stabilised, because running it on incomplete records burns the team's trust in the whole tool, and that trust does not come back easily.

One observation keeps repeating for us: the companies that genuinely improved were not the ones with the most indicators, but the ones that held a short weekly meeting where six numbers were read and two decisions came out. Discipline in reading is worth more than richness on screen.

Closing the loop: back to the seven leaks

This series opened with seven leaks draining profit from contracting and maintenance companies, and six parts have closed them one by one. The circle now closes:

• The request that was never logged was closed by the work order in part two, and is now watched by the response time indicator.
• The repeat visit was handled by scheduling and assignment in part three, and is watched by both the first-time fix rate and repeat visits.
• Extra work done without a change order was handled by the documentation in part five, and its effect shows up in contract margin.
• Inventory living on sites rather than in the system was handled in part six, and its failures surface as waiting time inside utilisation and as missing parts inside the first-time fix rate.
• The late payment application was handled by tying work to documents in parts two and five, and is watched by the aging indicator.
• The contract whose obligations nobody tracks was handled by preventive plans and response commitments in part four, and is watched by response time against the contractual commitment.
• Knowledge that leaves with the employee was handled by recording diagnosis and asset history in nearly every part, and it is the one leak not measured by a single number — its effect shows when a technician leaves and nothing stops.

The thread running through all of it is one sentence: work that is not recorded as it happens cannot be measured, billed, or defended. You are not expected to implement the whole series at once — close your single biggest leak first, as we said in part one, then measure its effect with a number before moving to the next. That is how this series ends: not with a system you buy, but with an operation whose numbers you know before the client tells you about them.

Sources

• Saudi Data and AI Authority — the Personal Data Protection Law and controls on responsible AI use when analysing individual and employee data.
• Ministry of Human Resources and Social Development — working hours and overtime provisions that govern how crew hours and utilisation are measured.
• Zakat, Tax and Customs Authority — e-invoicing requirements tied to the invoice issuance cycle and its aging.
• Monshaat, the Small and Medium Enterprises General Authority — programmes on operational efficiency and digital transformation for SMEs.
• Saudi Vision 2030 — the national direction on private sector efficiency and technology adoption in contracting and maintenance.