Meeting SLAs and fixing incidents are important, but they do not show the full value of a managed service. A modern service should prevent repeat problems, automate routine work, improve business-service visibility and make technology easier to run and change.
Yet, twelve months later, the same problems may still be recurring. The same manual tasks may still be required. The same weak integrations may still be slowing down change.
This raises a more useful question:
If a managed service keeps dealing with the same problems, what is it actually improving?
A modern managed service should not only run today’s technology well. It should help make the environment easier, safer and more cost-effective to operate tomorrow.
SLAs are the baseline, not the full measure of value
Availability, response times and recovery times matter.
When an important service fails, the customer needs a clear response, effective communication and fast recovery. A provider that cannot deliver these basics is unlikely to build trust over time.
However, traditional service measures often describe activity:
- incidents raised and closed;
- response and resolution times;
- service availability;
- changes completed;
- requests fulfilled;
- SLA compliance.
They do not always show whether the environment is improving.
A service can close thousands of tickets efficiently without removing the causes of those tickets. It can report that individual applications are available while the complete customer or business process remains broken.
Deloitte has argued that next-generation managed services should move beyond narrow operational measures. It suggests reducing low-value work, limiting technical debt and linking performance to business goals. Deloitte also provides managed services, so this should be treated as an informed industry view rather than independent evidence. However, the central point is valid: activity and value are not the same.
A more complete service model could move through five stages:
Run → Prevent → Improve → Accelerate → Create value
Run the service reliably
The first responsibility is straightforward: keep the agreed service running.
This requires monitoring, incident management, service requests, patching, maintenance, recovery plans, supplier coordination and clear communication.
It also requires clear ownership.
Complex environments often include multiple teams, applications, platforms and suppliers. Without clear responsibilities, an incident can move between organisations while the business remains affected.
A well-run service should define:
- what is supported;
- when support is available;
- who owns each component and dependency;
- how incidents are prioritised;
- how suppliers work together;
- when and how issues are escalated;
- how recovery decisions are made;
- what evidence is included in service reviews.
These are essential foundations. But they should begin the value conversation, not end it.
Prevent the same problems from returning
Fixing an incident restores the service.
Preventing it from happening again improves the service.
A modern managed service should distinguish one-off failures from recurring signs of a deeper problem. This means looking at trends across incidents, applications, integrations and operating processes instead of treating every ticket as an isolated event.
For example, repeated data-processing failures may initially appear to be unrelated support incidents. Viewed together, they may reveal an unstable interface, poor error handling, a capacity problem or a manual reconciliation task that needs to be redesigned.
AWS describes proactive incident management, trend analysis and automatic remediation as ways to support operational excellence. Its guidance also links automation with fewer manual errors, greater consistency and improved reliability.
Useful measures should therefore include more than mean time to restore. They should also show:
- repeat incidents per month;
- recurrence rate;
- known problems permanently removed;
- incidents caused by technical debt;
- avoidable support demand;
- time spent dealing with repeat causes.
The goal is not to hide incidents from reports. It is to remove more of them from the environment.
Reduce repetitive operational work
Every technology environment includes routine administration.
The risk is that repetitive work grows until it consumes the time that could have been spent improving the service.
Google’s Site Reliability Engineering guidance calls this type of work toil. Toil is manual, repetitive and short-term work that can often be automated and creates little lasting value. Google recommends limiting toil so that SRE teams have time for engineering and improvement. This is guidance for SRE teams, not a universal contract measure for managed services.
A useful principle is:
A managed service should measure how much time is spent on work that could be simplified, automated or removed.
One practical approach is to maintain an automation backlog. Each quarter, the customer and provider could identify repetitive tasks and rank them according to their likely operational or financial benefit.
Possible candidates include:
- repeat remediation steps;
- routine monitoring and health checks;
- certificate or credential management;
- deployment tasks;
- data checks and reconciliation;
- repeated service requests;
- alert review;
- standard recovery actions;
- reporting and evidence collection.
Automation should not be used simply because a task can be automated. The expected reduction in effort, risk or delay should justify the investment.
Useful measures could include manual tasks removed, hours saved, fewer errors and the proportion of routine work handled through automation.
Make continuous improvement part of the service
Many managed services have an incident backlog.
Far fewer have a clear, shared improvement backlog.
This is a problem because operational evidence often shows where the next investment is needed. Incidents, failed changes, performance issues, user complaints and manual work all provide information about the health of the environment.
Microsoft’s Operational Excellence maturity guidance presents operations as a continuous improvement journey. It recommends using production monitoring to improve processes, address technical debt and identify further opportunities for automation.
Every service review should answer two questions:
What happened?
Incidents, service requests, availability, changes and current risks.
What are we making better?
Repeat-problem removal, automation, monitoring, resilience, technical debt, cost and change capability.
The improvement backlog should be ranked by business value, operational risk, cost and effort. Without this discipline, useful improvements can remain behind urgent support work.
Some organisations may also reserve part of the service capacity for improvement. This creates a practical technical-debt budget instead of requiring a separate project to fund every repair.
Measure whether the business service is working
Infrastructure and application monitoring are still necessary, but they do not always show the experience of the business or customer.
An application may be online while transactions fail later in the process. An API may respond while incorrect data prevents the process from completing. Every technical component may report as available while a customer cannot join, pay, book or update an account.
A modern managed service should therefore monitor complete business journeys.
Instead of reporting only:
Application availability: 99.9%
the service might also report:
99.7% of customer onboarding transactions completed successfully within the agreed processing window.
This requires the organisation to identify the services and transactions that matter. It must then connect monitoring across the applications, integrations, data flows and third parties that support them.
Google’s guidance on service-level objectives recommends measuring services from the user’s point of view. Microsoft also recommends linking operational information to business context instead of simply collecting more infrastructure data.
This changes the question from whether the technology is running to whether the service is achieving its purpose.
Make change easier, not harder
Managed services and transformation are sometimes treated as opposites.
Projects make changes. Operations protect stability.
This split can create a service that becomes harder to change, even when the organisation needs new products, better customer journeys or modern technology.
A modern managed service should protect reliability while making useful change safer and more repeatable.
This may involve:
- improving automated testing;
- standardising deployment processes;
- strengthening monitoring before release;
- keeping environment information accurate;
- reducing weak dependencies;
- practising recovery;
- using operational evidence to guide future design;
- involving support teams earlier in delivery.
DORA’s software delivery research provides a useful framework because it considers both delivery speed and instability. Measures such as change lead time, deployment frequency, change failure rate and recovery time can show whether an organisation can make changes efficiently without causing unacceptable disruption. These measures do not, by themselves, prove business value or service quality.
The aim is not change for its own sake.
It is to reduce the cost, effort and operational risk of making the changes the business needs.
Keep the customer in control
A managed service should reduce operational dependence, not create commercial lock-in.
The customer should retain enough knowledge and access to understand how the service works, question decisions and move the service if necessary.
Documentation, runbooks, configuration records, repositories, service history and ownership information should remain current throughout the engagement. Knowledge transfer should be part of normal operations, not something left until the contract ends.
A useful test is:
Could the service be transferred without first having to rebuild an understanding of how the environment works?
A service that is ready to transfer is not a sign of a weak supplier relationship. It shows that the customer remains in control of an important business capability.
Is the environment becoming easier to operate?
A monthly report usually shows how much activity took place.
Leaders also need to know whether the operating environment is becoming healthier.
A simple managed-service improvement scorecard could track the direction of travel:
| Indicator | Desired direction |
|---|---|
| Repeat incidents | Down |
| Manual operational activities | Down |
| Failed integrations or data jobs | Down |
| Incidents attributable to technical debt | Down |
| Change failure rate | Down |
| Recovery time | Down |
| Deployment lead time | Down |
| Automated processes | Up |
| Business-journey monitoring coverage | Up |
| Successful business transactions | Up |
| Capacity available for improvement | Up |
These are not universal measures. Each service should choose indicators that match its business goals and technical environment. Definitions, measurement methods and targets should also be agreed so that trends are interpreted consistently.
The key question is:
Is the managed service coping with complexity, or steadily reducing it?
A managed service should leave the environment stronger
The value of a managed service should not be judged only by how well it responds when something goes wrong.
It should also be judged by whether:
- recurring problems are being removed;
- manual effort is falling;
- monitoring reflects business outcomes;
- technical debt is being addressed;
- recovery is being tested;
- change is becoming safer and easier;
- the customer retains knowledge and control.
This is especially important in application, enterprise integration and data environments. One component can appear healthy while the connected business process fails.
DigX provides Application Managed Services and Data Integration Services alongside its enterprise integration, data and Microsoft platform capabilities. This may be useful for organisations that need to run connected technology services while improving the integrations, data flows and operating processes around them.
Reviewing the value delivered by your managed service?
Look beyond the number of tickets closed. Ask whether the environment is becoming more reliable, less manual and easier to change.
To review your managed service requirements – Contact us:
Frequently asked questions (FAQs)
What is a modern managed service?
A modern managed service combines reliable daily operations with continuous improvement. It should fix incidents, prevent repeat problems, reduce manual work, improve business-service visibility and make technology safer and easier to change.
How are modern managed services different from traditional IT support?
Traditional IT support often focuses on tickets, incidents and SLA compliance. Modern managed services use these foundations while also measuring automation, technical-debt reduction, business outcomes, resilience, change performance and long-term service improvement.
What should a managed service provider measure?
A managed service provider should measure both operational performance and improvement. Useful indicators include repeat incidents, recovery time, change failure rate, manual interventions, automation levels, successful business transactions, technical-debt reduction and monitoring coverage across key business journeys. Measures should be relevant to the service and agreed with the customer.
Can application managed services support digital transformation?
Yes. Application managed services can support transformation by improving reliability, strengthening monitoring, reducing technical debt, automating operational work and making application changes safer and more repeatable. The service should help the organisation evolve rather than simply preserve the current environment.
How can a business assess the value of its managed services?
Businesses should look beyond ticket volumes and SLA reports. They should ask whether repeat problems are declining, manual effort is being removed, business transactions are succeeding, technical debt is being addressed, change is becoming easier and the customer retains enough knowledge and control.
