Most businesses have some form of IT support in place. Fewer have a plan — a documented, structured approach that sets out what good looks like, how performance is measured, and what happens when things don’t meet the standard.
The difference matters more than it might seem. Without a plan, IT support defaults to reactive. Issues are handled as they arrive, priorities are set informally, and there’s no clear basis for assessing whether the service is genuinely working. With a well-built plan — backed by meaningful SLAs and KPIs — your IT support becomes a managed, measurable function that improves over time and genuinely supports the way your business operates.
This article walks through how to build that plan, what to include in it, and how to use SLAs and KPIs to make it work in practice rather than just on paper.
Start With What the Business Actually Needs
The most common mistake in building an IT support plan is starting with technology rather than business requirements. A plan that’s built around what your IT team or provider finds convenient to measure is far less useful than one grounded in what your business actually needs from its IT function.
Before writing a single SLA, it’s worth spending time with the people who depend on IT across your organisation and understanding what matters to them. What systems are genuinely business-critical? What does downtime actually cost — in lost productivity, missed revenue, or client impact? How quickly do staff need issues resolved to maintain their effectiveness? What’s the cost of a slow response versus no response?
These conversations often surface priorities that differ from what IT teams assume. Finance teams may have month-end windows where system reliability is non-negotiable. Sales teams may depend on specific applications that the IT function has historically treated as lower priority. Client-facing staff may have much lower tolerance for downtime than their internal counterparts.
Our article on IT service management explained provides a useful framework for structuring these conversations and translating business requirements into a service design that reflects them.
The Structure of a Proactive IT Support Plan
A well-built plan covers several distinct areas. Each one plays a different role in making the overall service function.
Service scope and responsibilities
The plan should define clearly what is and isn’t included in your IT support arrangement. Ambiguity in scope is one of the most common sources of friction in IT support relationships — particularly when an incident arises that sits on the boundary between what’s managed and what isn’t.
Define which systems, platforms, and locations are covered. Define what activities your provider is responsible for versus what falls to your internal team. Define how third-party vendor relationships are managed — who owns the conversation with your ISP, your SaaS vendors, or your hardware suppliers when something goes wrong.
For businesses operating across multiple countries, scope definition is even more important. Your plan should be explicit about which offices and regions are covered, what the coverage model looks like in each location, and how support is coordinated across time zones. If you rely on global it support company services to cover your international operations, the scope of that coverage should be documented with the same level of detail as your UK provision.
Proactive activities and schedules
A proactive IT support plan isn’t just about how issues are handled when they arise — it’s about the ongoing activities that prevent issues from arising in the first place. These should be documented, scheduled, and tracked.
Proactive activities typically include:
- Patch management — which systems are patched, on what schedule, and within what timeframe following release
- Monitoring thresholds — what triggers an alert, and what action follows
- Capacity reviews — how often storage, compute, and bandwidth capacity are assessed against usage trends
- Security reviews — how often security configurations, access permissions, and vulnerability posture are formally reviewed
- Hardware lifecycle management — how aging devices are tracked and replacement cycles planned
Each of these activities should have a named owner, a defined frequency, and a way of evidencing completion. If your current IT support arrangement doesn’t include documented proactive schedules, you’re likely more reactive than you realise. Our post on the hidden costs of reactive IT illustrates the financial case for getting this right.
Escalation paths and communication protocols
Your plan should define exactly how issues are escalated — from first-line support through to specialist intervention or senior management involvement — and how communication is handled at each stage.
This means documenting who is notified when a critical incident occurs, how frequently updates are provided during an active incident, what constitutes a major incident requiring senior escalation, and who the named contacts are on both sides of the relationship.
Clear escalation paths are especially important in international environments. When a significant incident occurs in your New York office at a time when your London team isn’t at work, the escalation path needs to work across time zones without depending on someone being awake in the wrong time zone to take action. Our article on building a follow-the-sun IT support model covers what this looks like in practice for businesses with teams across multiple regions.
Designing Meaningful SLAs
SLAs — Service Level Agreements — define the minimum performance standards your IT support is committed to meeting. They’re the contractual backbone of your plan, and they’re only useful if they’re designed to reflect what actually matters to your business.
The SLAs worth including
Response time — how quickly a support request is acknowledged after being raised. Response time is not the same as resolution time, but it matters — staff who raise a critical issue and hear nothing for two hours are already experiencing a failure of service.
Resolution time by priority — how quickly issues are resolved, differentiated by priority level. A critical outage affecting multiple users needs a different resolution target than a low-priority configuration request. A sensible priority framework typically runs from P1 (critical, business-impacting) through P4 (low, no operational impact), with different response and resolution targets at each level.
Uptime and availability — for critical systems under your provider’s management, what uptime percentage is committed? 99.9% sounds high until you calculate that it still allows over eight hours of downtime per year. For truly critical systems, the target and the measurement methodology both matter.
First contact resolution rate — the percentage of issues resolved on first contact without escalation. This is a quality measure as much as a speed measure, and including it in your SLA creates an incentive for your provider to invest in first-line capability rather than defaulting to escalation.
Time to escalate — when a first-line engineer can’t resolve an issue within a defined period, how quickly does it escalate to the appropriate level? This prevents issues from stalling in the queue while someone tries to solve something outside their competence.
SLAs for international locations
Make sure your SLAs apply equally across all your locations — not just your UK headquarters. A contract that guarantees a one-hour response for London but “reasonable endeavours” for European offices is not a global IT support contract. If your european it services provision doesn’t carry the same SLA commitments as your UK provision, that’s worth addressing explicitly rather than assuming parity.
Making SLAs enforceable
SLAs are only useful if they’re measured and if there are consequences for consistent failure to meet them. Service credits — where your provider provides a credit against your invoice when they fall below a defined threshold — are the most common enforcement mechanism. Whatever the mechanism, it should be documented in your contract rather than left to negotiation after the fact.
Choosing the Right KPIs
KPIs — Key Performance Indicators — are the operational measures that tell you whether your IT support and management plan is working, beyond the minimum thresholds defined in your SLAs. Where SLAs define the floor, KPIs help you track progress towards a higher standard.
The KPIs worth tracking monthly include:
Ticket volume by category — how many tickets are raised each month, broken down by type. Trends here reveal whether recurring issues are being fixed permanently or repeatedly resolved temporarily.
Mean time to detect and respond — for security incidents specifically, how quickly threats are identified and contained. We covered these metrics in detail in our article on endpoint security metrics, but they belong in your overall IT management KPI set too.
Proactive vs reactive activity ratio — what proportion of your IT team’s time is spent on proactive management versus reacting to incidents? A healthy managed service should see this ratio moving over time towards a higher proportion of proactive work as monitoring and maintenance reduce incident frequency.
User satisfaction scores — periodic surveys of your staff on their IT support experience. Technical metrics tell you how the service is performing against defined standards; satisfaction scores tell you whether that performance translates into a good experience for the people who depend on it.
Patch compliance rate — what percentage of your estate is current on operating system and application patches. Falling compliance is an early warning signal for increased vulnerability risk.
Security posture indicators — combining patch compliance, endpoint coverage, MFA adoption, and open security findings into a monthly security posture score gives you a single headline metric that tells you whether your security position is improving or deteriorating.
For businesses using Microsoft 365 as their primary platform, your microsoft 365 support services london provider should be contributing specific M365-related KPIs — secure score trends, admin alert volumes, licence utilisation, and configuration compliance — as part of the overall reporting framework.
The Review Cadence That Makes It Work
A plan without a review process is just a document. The rhythm of reviews is what turns a written plan into a living service.
Monthly operational review — a working-level review covering the previous month’s metrics, open issues, and short-term priorities. This is where SLA performance is reviewed, KPI trends are discussed, and immediate actions are agreed.
Quarterly service review — a broader review with senior stakeholders on both sides covering service performance over the quarter, progress against improvement plans, upcoming changes to your business that affect IT requirements, and any strategic recommendations from your provider.
Annual plan review — a full review of the plan itself: is the scope still right? Are the SLAs still appropriate? Do the KPIs still reflect what matters? Have business priorities shifted in a way that should change how IT support is structured?
For businesses with international operations, the quarterly and annual reviews should explicitly address how each region is performing — not just roll regional data into an aggregate that might mask significant variation. A global it support london based provider managing your international estate should be bringing region-specific data and recommendations to these reviews, not just a headline figure.
Connecting Your Plan to Security and Compliance
A proactive IT support and management plan doesn’t exist in isolation from your security posture. The two are deeply connected, and your plan should reflect that.
Patch management, access control, and monitoring — all of which belong in your proactive plan — are also foundational security controls. Security-specific activities should be integrated into the plan rather than treated as a separate workstream.
Your plan should define how security-related activities are handled:
- How dark web alerts are escalated and responded to. Working with a dark web monitoring london service as part of your managed IT arrangement means these alerts feed directly into your support process rather than sitting in a separate inbox.
- How phishing incidents are reported, investigated, and followed up. Your relationship with an anti phishing company should connect to your wider incident response process, not operate independently of it.
- How platform migrations and significant infrastructure changes are managed from a security continuity perspective — making sure platform migration services engagements are scoped with security maintenance explicitly included throughout the transition period.
For UK businesses, there’s also a compliance dimension. UK GDPR requires appropriate technical and organisational measures to protect personal data. A documented, actively managed IT support and management plan — with evidence of regular reviews, proactive security activities, and prompt incident response — is one of the strongest demonstrations that you’re meeting that obligation seriously.
Why Outsourcing Makes a Proactive Plan Easier to Execute
For many small and mid-sized businesses, building and sustaining a genuinely proactive IT support and management plan internally is difficult. The resource requirements — monitoring infrastructure, specialist expertise across multiple domains, coverage across time zones — are simply beyond what most internal IT teams can realistically deliver.
This is one of the strongest practical arguments for working with a managed service provider. A well-structured MSP brings the tooling, the processes, the specialist expertise, and the operational discipline that makes a proactive plan executable rather than aspirational.
Our article on unlocking the power of outsourced IT support covers the case for outsourcing in detail, and our post on why businesses should consider an MSP for their IT needs goes further into what to look for when selecting a provider. The core point is that outsourcing works best when it’s structured around a clear plan — not as a substitute for one.
For businesses with international operations, multinational it support services london based providers who can deliver consistently across your full estate offer the additional benefit of a single plan, a single accountability structure, and a single review process — rather than coordinating between multiple local providers each working to different standards.
Frequently Asked Questions
What’s the difference between an SLA and a KPI in an IT support context?
An SLA is a contractual commitment — a minimum standard that your provider is obligated to meet, with defined consequences if they don’t. A KPI is an operational measure used to track performance and drive improvement, typically going beyond the minimum SLA thresholds. Both are necessary: SLAs define the floor, and KPIs help you track whether you’re genuinely moving above it.
How specific should SLAs be for different priority levels?
Very specific. Vague SLAs — such as “critical issues will be resolved promptly” — are difficult to enforce and easy to interpret differently by each party. Specific SLAs — such as “P1 issues will receive a first response within 15 minutes and be resolved or escalated within two hours” — are measurable, accountable, and meaningful when things go wrong.
What should I do if my provider is consistently missing SLA targets?
First, raise it formally in your service review and request a written remediation plan with timelines. If the pattern continues without genuine improvement, you should be reviewing your contract for the exit provisions and service credit clauses, and considering whether a change of provider is in your best interests. Consistent SLA failure isn’t just a performance issue — it’s a signal about the provider’s underlying capability or capacity.
How often should KPIs be reported?
Monthly is the right cadence for most operational KPIs. This gives you enough data points to identify genuine trends rather than reacting to month-to-month variation, and it creates a regular rhythm for reviewing and acting on the data. Some security-specific metrics — such as open vulnerability counts or active alerts — may warrant weekly or even daily visibility.
Is it worth having a proactive IT plan if we’re a small business?
Absolutely. The principles of proactive IT management apply at any scale — the specific activities and the sophistication of the tools may differ, but the discipline of defining what good looks like, measuring against it, and improving over time is just as valuable for a business of 20 people as for one of 200. A good managed IT provider will right-size the plan for your business rather than applying a one-size-fits-all approach.
How do SLAs work across international locations?
They should apply equally across all your locations, with the same response and resolution commitments regardless of where a ticket is raised. If your provider applies different standards to different offices, that should be explicitly documented and the reason should be understood — not left as an implicit assumption that the UK office gets priority treatment.
Ready to Build an IT Support Plan That Actually Works?
If your current IT support arrangement operates without a formal plan, or if the SLAs and KPIs in place don’t reflect what your business actually needs, it’s worth investing the time to build something better — before the next incident makes the gap visible.
Northern Star works with businesses across the UK and internationally to design, implement, and actively manage proactive IT support plans that are genuinely tailored to how each business operates and grows.
Get in touch with our team today — we’re happy to have a straightforward conversation about how your current IT support is structured and what a more proactive, better-measured approach would look like for your business.
