Managed IT services and infrastructure support: the complete guide

Reliable IT is invisible. When it works, nobody notices: email arrives, the finance system opens, the warehouse scanners connect. When it does not, everything stops, and the conversation turns quickly to who is responsible and how fast it can be fixed. Most organisations only think hard about their IT support arrangements after a bad week.

This guide brings together the briefings in our managed services series. It explains what good support covers, how to write service levels that mean something, what monitoring, patching and backup should look like, and how to decide between in-house, outsourced and blended support. It is written for leaders who rely on IT but do not run it day to day.

What good support covers

Managed IT support is more than a helpdesk. A complete service has five parts, and gaps between them are where problems tend to hide.

1. A service desk that resolves everyday issues quickly, with clear priorities and response times.
2. Monitoring and operations: watching servers, networks, cloud services and applications around the clock and acting on alerts.
3. Maintenance: keeping systems patched and protected, with tested backups and planned upgrades.
4. Business application support: looking after enterprise, collaboration and other business systems, including users, changes and small enhancements.
5. Reporting and improvement: monthly reports on incidents, response times and cost, with recommendations to reduce repeat problems.

Be clear about what is in scope. Many disputes with IT providers come from assumptions: that a line-of-business application was covered when it was not, or that installing new equipment was included in the monthly fee. A simple table listing each system, who supports it and what costs extra prevents most of these arguments.

Service levels in plain language

A service level agreement should say what you can expect, how fast, and what happens if it is missed. Many are written in terms that sound reassuring but mean little in practice, so it is worth reading them closely.

Response versus resolution

Response is how soon someone acts on a request. Resolution is how soon the problem is fixed. A promise to respond within fifteen minutes may only mean an automated acknowledgement. Agree targets for both, and agree how they are measured.

Priorities by impact

A system that stops a factory line or a shop’s tills is not the same as a broken mouse. Define priority levels by business impact, and list which systems fall into the highest level. A typical structure has four levels: critical, where the business cannot operate; high, where a team cannot work; medium, where work is slowed; and low, for requests and minor issues.

Hours and reviews

Check the hours that targets apply to. A four-hour fix time measured only in office hours may mean a problem reported on Friday evening is not fixed until Monday. Match cover to when your business actually operates. Then review performance monthly, with a quarterly meeting to discuss trends and improvements; regular reviews keep the service honest.

Monitoring that warns early

Prevention beats repair. Monitoring and patching reduce incidents far more than a faster helpdesk can. Good monitoring should warn you before users notice a problem: a disk filling up, a backup that failed overnight, a certificate about to expire, a server running hot.

• Watch what matters. Monitor the services users rely on, such as whether people can sign in and place an order, not just whether individual servers are running.
• Alert sensibly. Too many alerts get ignored. Tune them so each one represents something that needs action.
• Learn from incidents. After any significant outage, review the cause and fix it permanently, rather than restarting the same service every week.
• Report trends, not just events. A gradual rise in response times often signals a problem months before it becomes an outage.

Patching and backup health check

Two basics prevent many serious problems: keeping systems current and being able to restore them. Both are easy to neglect because they rarely cause visible trouble until the day they do. Use the checklist below to test your current arrangements, whether support is in-house or outsourced.

The last two items matter most. A backup you have never restored is an assumption. Pick a critical system each quarter, restore it to a test environment, and record how long it took. If the answer is two days and the business can only tolerate four hours, you have found a gap while it is still cheap to fix.

In-house, outsourced or blended

Each model has strengths, and many organisations settle on a blend.

• In-house support gives closeness to the business and quick context. Staff know the people, the systems and the history. It can be stretched thin, especially out of hours or when someone is on leave.
• Outsourced support provides coverage, depth and predictable cost. A provider can offer specialist skills and round-the-clock monitoring that would be uneconomic to build internally, but needs time to learn your business.
• A blended model keeps strategic knowledge and relationships inside, often an IT manager and a small team, while buying routine support, monitoring and specialist skills from a provider.

Whatever the model, keep ownership of decisions inside the organisation. A provider can advise on priorities, but someone in the business should decide which systems matter most, approve significant changes and hold the provider to account.

Document your environment

Clear records make support faster and reduce dependence on a few individuals. When knowledge sits only in one person’s head or one provider’s systems, changing either becomes risky. Documentation protects you.

• Keep a current list of systems, owners, suppliers and contracts, with renewal dates.
• Draw diagrams showing how systems connect and depend on each other.
• Keep access records: who has administrative access to what, reviewed at least twice a year.
• Store passwords and keys for critical systems in a managed vault the organisation controls.

When our long-serving IT lead retired, we realised half the network existed only in his memory. Writing it down took a month. We should have started years earlier.

Operations director, manufacturing client

Done well, managed support delivers fewer outages because problems are caught early, predictable cost from a clear scope, teams that spend less time firefighting and systems that stay patched, backed up and supported. A practical first step is to run the backup health check above on your most important system this month, and to read your current service agreement against the questions on response, resolution and hours.

Source: Intelliversal analysis, drawing on the briefings in this series.

Frequently asked questions

What should a managed IT contract include?

A clear scope listing systems covered, service levels by priority with both response and resolution targets, hours of cover, reporting, and terms for ending the contract and handing over documentation.

How often should backups be tested?

Test restores of critical systems at least quarterly, and sample file restores more often. Record how long each restore takes and compare it with business needs.

Can we outsource IT and still keep control?

Yes. Keep decisions about priorities, changes and spending inside the organisation, own the documentation and access records, and review the provider’s performance regularly.

Explore Managed IT services and infrastructure support