How should managed IT support services be measured?

Managed IT support services should be measured through an agreed scorecard that links operational evidence to business outcomes. The scorecard should show not only how much support activity has taken place, but whether technology is dependable, risks are controlled, improvements are being completed and staff can work effectively.

Start with a defined measurement framework

Before selecting metrics, the organisation and its IT provider should agree what good service means, how each measure is calculated, who owns the data and how often the results will be reviewed. Definitions matter because apparently similar measures can describe very different things. For example, the time taken to acknowledge a request is not the same as the time taken to resolve it, while the average result may conceal a small number of serious or long-running cases.

A useful framework normally separates measures into four groups:

• Service performance: whether agreed support processes are operating as intended.
• Technology health: whether infrastructure, applications and connectivity are stable and usable.
• Risk and control: whether security, backup, access and change processes are reducing exposure.
• Business value: whether IT is supporting productivity, continuity and planned growth.

This structure prevents the scorecard from becoming a list of helpdesk statistics with no connection to the organisation’s priorities.

Measure demand in context

Ticket volumes can be useful, but volume alone is not a reliable measure of service quality. A rise in tickets may indicate an accessible support process, a new system rollout, seasonal demand or a recurring technical fault. A fall may indicate improved reliability, but it could also mean that users are avoiding the support process or reporting problems informally.

Reports should therefore distinguish between incidents, service requests, access changes, advice requests and planned work. They should also identify recurring faults, affected departments, business-critical systems and the age of unresolved cases. Trends are generally more informative than a single reporting period, particularly when they are examined alongside changes to the organisation, its systems and its user base.

Assess service desk performance fairly

Support measures should reflect priority and impact rather than treating every request as equivalent. A problem affecting one user’s peripheral device is materially different from an issue preventing a department from accessing a core application. Useful analysis can include:

• the proportion of cases handled within the service levels agreed for each priority;
• the time between updates, where a case cannot be resolved immediately;
• the number of cases reopened after being marked complete;
• the number of cases transferred between teams or escalated;
• the age and business impact of outstanding work; and
• the proportion of recurring issues that have an identified corrective action.

These measures should be interpreted together. A low resolution time is less meaningful if cases are closed prematurely, transferred repeatedly or reopened by users who still cannot work.

Use technical measures that explain business impact

Infrastructure and application monitoring can provide evidence about service stability, but technical data needs to be translated into operational significance. The relevant questions include whether an interruption affected a critical process, how many users were affected, whether a workaround existed and whether the underlying cause has been addressed.

Measurement should distinguish between planned maintenance, isolated device faults, supplier outages and failures within the managed environment. It should also record repeated degradation, such as intermittent connectivity or application slowness, which may not appear as a complete outage but can still reduce productivity. A technically available system is not necessarily performing adequately for its users.

Evaluate security and backup controls through evidence

Security measurement should focus on the operation of controls, not simply on the number of alerts generated. Relevant evidence may include the handling of security events, outstanding vulnerabilities, the status of protective controls, privileged access reviews, completion of user access changes and the age of unresolved risks.

Backup measurement should go beyond confirming that a scheduled job completed. It should consider whether protected data is within the agreed recovery requirements, whether failures are investigated, whether restore tests have been completed and whether results are recorded. A backup that cannot be restored within the organisation’s needs does not provide dependable resilience.

Risk reports should make clear which items require a management decision. For example, an unsupported system, an unremediated vulnerability or an exception to an access policy may be acceptable temporarily, but only if the owner, rationale and review date are documented.

Track change quality and prevention

Effective managed support should be assessed by how well it prevents avoidable disruption, not only by how efficiently it fixes faults. Change-related measures can include the number of failed or rolled-back changes, incidents linked to recent changes, completion of post-change checks and the proportion of changes supported by current documentation.

Recurring problems should be reviewed separately from individual incidents. If the same fault appears repeatedly, the provider should record the underlying cause, proposed remedy, owner and target date. This helps distinguish a service that is merely treating symptoms from one that is improving the technology environment.

Include user and management evidence

Objective technical data does not capture every aspect of support quality. Short, consistent user feedback can identify communication problems, unclear ownership or solutions that technically close a case without resolving the practical difficulty. Feedback should be analysed for themes rather than treated as an isolated popularity score.

Management reviews should also consider whether IT activity reflects business priorities. Questions may include:

• Are technology risks visible and assigned to named owners?
• Are planned improvements progressing against agreed priorities?
• Are technology costs and renewal decisions understandable?
• Can the organisation accommodate new users, locations or systems without avoidable rework?
• Are strategic decisions being supported by accurate information about the existing environment?

Review the measures through a regular governance process

A useful report should show the current position, movement since the previous review, explanation for material changes, open actions and decisions required from the customer or provider. It should avoid presenting data without interpretation. The discussion should identify whether a result is a one-off event, an emerging trend or evidence that an agreed control is not working.

Measures should also be reviewed periodically. As the organisation changes, some indicators may become less relevant while new risks or business requirements emerge. A managed IT support provider can contribute by maintaining the reporting structure, explaining technical findings and proposing corrective actions, but the business should retain ownership of its priorities and risk decisions.

The strongest measurement approach combines operational records, monitoring data, security and continuity evidence, user feedback and business review. It avoids rewarding high activity for its own sake and instead tests whether the support arrangement is making technology more controlled, dependable and aligned with the organisation’s requirements.