How should you measure fully managed IT support performance?

Fully managed IT support performance is measured most effectively through a balanced scorecard that combines service data, risk indicators, user impact and progress against agreed business objectives. No single figure gives a reliable view: a provider may close tickets quickly while recurring faults remain unresolved, or maintain strong technical controls without improving the systems that staff depend on.

Start with documented measures and definitions. Before reviewing results, agree what each measure means, how it is calculated, which systems provide the evidence and who is responsible for acting on it. For example, “resolution time” should distinguish between the time an issue is logged, the time work begins, periods awaiting information and the point at which the user confirms that normal work has resumed. Without consistent definitions, month-to-month comparisons can be misleading.

The scorecard should also identify exclusions. Planned maintenance, duplicate tickets, requests awaiting a third party and incidents caused by an unmanaged system may need to be reported separately rather than mixed into the same result. Exclusions should be transparent and agreed in advance; otherwise, they can make performance appear better without improving the service.

Use a combination of lagging and leading indicators. Lagging indicators describe what has already happened, such as closed incidents, repeat faults or completed recovery tests. Leading indicators show whether future performance is likely to improve, such as overdue patches, unresolved configuration weaknesses, incomplete user access reviews, ageing hardware and actions from previous service reviews. Reviewing both types helps distinguish a temporary good result from a controlled and sustainable service.

Trend analysis is generally more useful than an isolated reporting period. Compare results with the agreed baseline, target and previous periods, then investigate material changes. A rise in support requests may indicate system instability, a business change, new staff, improved reporting by users or a change in how tickets are classified. The number alone does not explain the cause, so the report should include commentary and an action owner.

Measure incidents by impact, not only volume. Ticket counts can be useful for identifying demand, but they should be segmented by priority, affected service, business function, root cause and whether the issue recurred. A small number of high-impact incidents may matter more than many routine requests. Useful analysis can include:

• the proportion of incidents resolved at the first point of contact;
• the age and status of open tickets;
• the number of reopened or repeated incidents;
• the business services and teams most often affected;
• the underlying causes identified through problem management; and
• the actions taken to prevent recurrence.

Requests should be separated from incidents where practical. A request may involve a new user, access change, device provision or software requirement, whereas an incident represents an interruption or degradation. Combining both can obscure workload patterns and make service quality harder to assess.

Assess security through control effectiveness and exposure. A useful security section does not simply list alerts. It should show whether agreed controls are operating, whether exceptions are known, how long weaknesses remain open and whether corrective actions are completed. The evidence may include access review outcomes, endpoint protection status, patch compliance, security event investigations, backup test results and the status of staff training or policy actions. Any exceptions should record their business owner, reason, compensating measure and planned review date.

Security reporting should distinguish activity from outcome. The number of alerts investigated does not, by itself, show whether risk has been reduced. A more meaningful review considers the severity of findings, the systems affected, the time taken to contain and remediate them, and whether the same weakness has appeared again. This gives decision-makers a clearer basis for prioritising investment and accepting or reducing residual risk.

Test resilience rather than relying on written procedures. Backup status, recovery point objectives and recovery time objectives are only useful when they are supported by evidence. Performance reviews should record when recovery tests took place, what was restored, whether the restored data was usable, which dependencies were identified and whether remedial actions were completed. A backup that has not been restored successfully should not be treated as a proven recovery capability.

Include the user and business perspective. Technical results need to be connected to the work the organisation is trying to perform. Review whether important applications are supporting productive workflows, whether recurring technology problems are affecting particular departments, and whether planned changes have delivered the intended operational improvement. User feedback can be collected through ticket closure comments, periodic surveys or structured meetings, but it should be interpreted alongside technical evidence rather than treated as a standalone score.

For growing organisations, it can be useful to segment results by location, department, service or device type. This can reveal that an overall result is masking a problem in one office or business process. It also supports more precise decisions, such as replacing a problematic class of device, redesigning an access process or reviewing connectivity at a particular site.

Turn reporting into a management process. A performance review should end with prioritised actions, not just a collection of charts. Each action should state the issue, expected benefit or risk reduction, owner, priority, dependencies and review point. Actions that require a business decision, such as accepting a security exception or funding an upgrade, should be clearly separated from routine technical work.

A practical review cycle may include regular operational reporting, a deeper service review at agreed intervals and an annual reassessment of the measures themselves. The measures should change when the organisation changes. New locations, cloud services, regulatory obligations, major applications or working practices may require different evidence and targets. Retaining obsolete measures can create reporting activity without providing useful control.

Finally, performance data should be checked for quality. Compare service desk records with monitoring, security and asset-management information where appropriate, and investigate missing or contradictory records. Keep an audit trail for reported figures and decisions, particularly where the results influence risk acceptance, investment or contractual discussions. This makes the scorecard a dependable basis for improving fully managed IT support rather than a retrospective summary of activity.