Plenty of businesses have “IT support”. Someone answers the phone. A laptop gets replaced. A password is reset. That can be useful. It is not the same as having the technology environment managed.
Managed IT is the difference between waiting for something to break and having a partner who already knows what the business runs on, who is responsible for keeping it healthy, and who stays with a problem until it has a clear owner. The point is not more tickets. The point is less technology work landing back on the customer.
Reactive support is a queue. Managed IT is an operating relationship.
Reactive support starts when someone notices a problem. Managed IT starts earlier: with an agreed picture of the environment, a baseline of controls, and the unglamorous work of keeping that baseline current.
If the relationship only exists when something is on fire, the business is still doing the coordination. Staff decide who to call. Someone has to remember which supplier owns the firewall, which one owns Microsoft 365, and which one sold the backup. That is not a partnership. It is a directory.
A good managed IT relationship should reduce the amount of technology the customer has to coordinate themselves. Radius should know the landscape well enough that you are not the person holding the map.
Day-to-day support still matters — it is just not the whole job
People still need help. Printers jam. New starters need accounts. Laptops fail on a Monday. A managed service that cannot support the people using the technology is not managing much.
The difference is what sits behind that help. Is there a defined way to request it? Does the person answering already know the environment? When the same issue returns, does anyone look at why — or is it closed again and forgotten?
Supporting your people is part of keeping the business moving. It should sit inside the same relationship that patches devices and watches backups, not in a separate “helpdesk product” with no view of the rest.
What “managed” should actually include
No two businesses are identical, so the exact scope should be agreed, written down and reviewed. The categories below are a reasonable expectation of what managed technology involves — not a promise that every environment needs the same tools.
- Day-to-day support for the people using the systems, with a clear way to ask for help.
- Monitoring of the things that matter, so a failed backup or an offline server is not discovered by accident.
- Maintenance and patching of devices, Microsoft 365 and other agreed systems — planned work, not a hope.
- Documentation that a competent engineer could use: what you have, how it connects, who supplies it.
- Device visibility: what exists, who uses it, whether it is current, and when it should be replaced.
- Security work as part of operations: identity, access, updates and the controls you have actually agreed to run.
- Backups that are in scope, monitored, and treated as recovery capability rather than a nightly tick.
- Onboarding and offboarding that is prompt and complete, including access as well as the device.
- Supplier coordination when Microsoft, an ISP, a landlord or a software vendor is in the path — without pretending Radius controls them.
- Lifecycle planning: what is ageing, what is risky, and what should be replaced in an order the business can live with.
- Recurring issue analysis: the same ticket three times is a design problem, not three unrelated events.
- Technology planning: priorities for the next quarter, not only the last incident.
Documentation, visibility and ownership
If nobody can tell you what you have, nobody is managing it. Inventories go stale. Admin passwords live in a notebook. The “network diagram” is a photo of a cupboard.
Documentation is not bureaucracy for its own sake. It is how a small team stays effective, how cover works when someone is away, and how a conversation about risk stays factual. How we work is built on that habit: understand the environment, set a baseline, then maintain it.
Ownership is the other half. When an email issue involves Microsoft, the broadband provider and a firewall rule, someone still has to stay with it. Managed IT means the customer is not the project manager for that chase.
“A useful test: if the usual contact disappeared for a fortnight, could the environment still be supported from the documentation that exists today?”
Security, backup and planning are not extras
Some proposals treat security, backup and “strategy” as bolt-on packages. For a small business they are part of running the place. Identity that is not maintained becomes an incident. A backup that is never restored is a story you tell yourself. A technology plan that only appears after a failure is just an invoice with nicer language.
None of this requires enterprise theatre. It does require someone to notice drift: licences nobody uses, devices that missed a patch cycle, a recovery test that has not happened in a year.
Keeping the business running is the daily expression of that work. Planning is how you avoid paying for the same fire twice.
What this is not
Managed IT is not unlimited project work. Replacing every laptop, moving office or rebuilding a line of business application is a project. It should be scoped as one.
It is not an SLA printed as a marketing claim. Response times, if they exist, belong in a contract you have actually agreed — not on a website.
It is not a price list. Costs depend on scope, complexity and the starting point of the environment. Anyone quoting a single number before they have looked is guessing.
And it is not the customer remaining the glue between five suppliers while the “managed” provider only resets passwords.
How to judge a managed IT conversation
Ask what they will actually own. Ask how they document. Ask how they handle a problem that sits with another supplier. Ask how they know devices are patched and backups are recoverable. Ask how they will tell you when something is drifting, not only when it has failed.
If the answers are vague, you are being sold a queue. If they are specific, you can decide whether the relationship fits.
A Technology Review is a practical way to start that conversation: a structured look at the environment, not a score and not a scan.