What a managed IT provider actually does all day

The confusing part about paying for prevention

Managed IT is one of the few services where the bill stays the same while the visible activity goes down. A client signs on, the first two months are noisy, and then things get quiet. The natural question follows a few invoices later: what exactly are we paying for now?

It is a fair question, and the honest answer is that the work moved. It stopped being emergencies you could see and became routine you cannot. This is a description of that routine, because a service you cannot observe is difficult to trust.

Morning: reviewing what happened overnight

Monitoring produces alerts continuously, and most of them do not matter. A workstation lost its connection because someone unplugged a dock. A backup job ran twelve minutes late. A disk crossed a warning threshold it will cross again tomorrow.

Part of the job is triage: separating the noise from the two or three items that are early symptoms of something real. A drive reporting increasing reallocated sectors is not urgent today and will be catastrophic in six weeks. A server whose memory use climbs steadily between reboots has a leak somewhere worth finding.

Tuning matters as much as watching. An alerting system that cries wolf gets ignored, and an ignored alerting system is worse than none because it creates the impression of coverage. A meaningful share of early-engagement work is adjusting thresholds until an alert reliably means something.

Through the day: tickets, and what they hide

Tickets are the visible surface. Somebody cannot print, a mailbox is full, a laptop will not join the VPN, a new hire needs accounts. Individually they are small. In aggregate they are the clearest diagnostic instrument available.

Five tickets about the same application in one week is not five tickets. It is one unresolved problem generating five symptoms. Repeated password lockouts across a department usually mean a policy that is fighting the way people actually work. A provider who closes tickets efficiently without ever asking why the same ticket keeps arriving is optimizing the wrong number.

So alongside resolution there is pattern analysis: which systems generate disproportionate load, which processes are fragile, which requests should not need a human at all.

Weekly: patching, and the judgment it requires

Patching sounds mechanical and is not. Vendors ship fixes constantly. Some close vulnerabilities being actively exploited and should be deployed immediately. Some break a line-of-business application your company depends on, and the vendor will not confirm compatibility for another month.

The work is sequencing: test group first, then the wider fleet, with a rollback path and a decision on hold for anything with known conflicts. Auto-updating everything the moment it is released is not diligence, it is abdication. So is deferring for a year, which is how organizations end up running firmware with public exploit code available.

Weekly: verifying that backups can restore

This is the item most commonly skipped by the largest margin, and the one that decides how bad your worst day becomes.

A backup job reporting success is not evidence you can recover. Jobs succeed while silently excluding a folder that was moved. Repositories fill and stop retaining new points while the dashboard stays green. Recovery media becomes unreadable and nobody discovers it until the day it matters.

Verification means periodically restoring real data to a real location and confirming it opens. It also means knowing how long a full restore takes, because a recovery plan without a measured duration is not a plan. If the answer is three days and your business can tolerate one, that is a problem to solve now rather than during an outage.

Ongoing: documentation, which is the actual product

Every environment we manage has a written record: network layout, IP assignments, credentials in a managed vault, licensing, vendor contacts, support contract numbers, and the reasoning behind non-obvious configuration choices.

This is unglamorous and it is the difference between a fast resolution and an archaeological dig. It is also the thing that protects you from us. A client who cannot leave without losing institutional knowledge is a client held in place by neglect. Documentation makes the relationship voluntary, which is the correct basis for it.

Ongoing: being the one who calls the vendor

A meaningful share of business technology problems are not yours to fix. The internet circuit is degraded. The accounting software vendor shipped an update that broke printing. The phone provider changed something and will not admit it.

Somebody has to sit in those queues, escalate, and keep a record of who promised what. When that somebody is your operations manager, you are paying an operations manager to be on hold. Absorbing that is a large and unadvertised part of what an MSP does.

Quarterly: the conversation about next year

Every environment has a set of items that are fine now and will not be in eighteen months. Warranties expiring. An operating system approaching end of support. A circuit that will not carry the headcount you are hiring toward.

Reviewing these on a schedule turns them into budget lines instead of emergencies. The goal of a business review is that nothing in your technology surprises you financially, and that the roadmap reflects where the company is actually going rather than where it was when the last plan was written.

What this adds up to

Managed IT is a large amount of maintenance performed on a schedule, plus judgment about what to do when something unexpected appears, plus taking ownership of the tedious coordination nobody wants. When it is done well the visible output is that nothing much happens.

That is a genuinely awkward thing to sell, and it is why the honest measure of a provider is not how impressively they handle a crisis. It is how few crises reach you in the first place.