Why Your MSP Should Never Say "I'll Look Into It" Again
Every phrase in customer service carries a hidden second meaning, and "I'll look into it" is one of the more honest ones — because what it actually means, most of the time, is "I don't know yet, and I'm about to go find out." Said kindly, it buys time. Said too often, it starts to sound like a company that's always one step behind its own network.
For an MSP, that phrase is doing more damage than it looks like on the surface. Every time a technician says it, they're implicitly telling a client something the client already suspected: that nobody was watching until they called. NetMon exists to make that sentence unnecessary — not by responding faster, but by making sure there's rarely anything left to look into by the time someone asks.
The trust economics of managed services
Here's the uncomfortable truth about the managed-services business model: clients are paying for a promise they can't directly verify. They can't see the monitoring dashboard, can't audit the alert thresholds, can't check whether anyone actually looked at their network yesterday. All they have to go on is what happens when something goes wrong — and that single moment carries a disproportionate amount of the relationship's total trust.
If the answer, every time, is "we already caught that, here's what we did," the invisible work becomes visible through its results. If the answer is "let me look into it," the client learns — correctly — that the invisible work either isn't happening or isn't catching much.There's no marketing copy that fixes that impression once it's formed. The fix has to happen upstream, in what the monitoring actually catches and how fast it turns into action.
What NetMon changes about that moment
NetMon's alert-to-ticket policy is built specifically around removing the gap between "something's wrong" and "someone's already on it." A rogue, unrecognised device showing up on a network that's supposed to be locked down raises a ticket immediately — no one has to spot it in a device list. A NAS, VOIP phone, printer, or router whose response quality drops out of healthy territory — packet loss climbing, latency creeping up — raises a ticket, whether or not it's crossed the much blunter line into fully offline. A printer or router that actually goes dark raises one too. All of it lands in the right organisation's queue automatically,
soped correctly, with the device, the metric, and the timestamp already attached.
That last part matters more than it sounds like it should. A ticket that says "packet loss on the second-floor NAS, currently at 42%, started fourteen minutes ago" is a fundamentally different starting point than a phone call that says "the shared drive feels slow today." One gives a technician somewhere to start. The other gives them a scavenger hunt. When tickets arrive with that context already in place, "I'll look into it" gets replaced by something more useful and more honest: "we saw that fourteen minutes ago and we're already working on it" — which, notably, requires no chasing, no wondering out loud, and no clock running against the technician from the moment the client noticed.
Automatic doesn't mean noisy
The obvious objection to automatic ticketing is the one every MSP has learned the hard way from some other tool: automation that fires on everything just relocates the noise from a phone line to a ticket queue. NetMon draws its line deliberately narrow. A device simply going offline gets an email, not a ticket — most outages resolve themselves inside a few minutes, and turning every blip into a ticket would train technicians to stop trusting the queue at all, which defeats the entire purpose. Only the alerts that genuinely warrant a person's judgement — degrading hardware, rogue devices, a printer or router that's actually down — earn a ticket automatically. And if the same underlying issue keeps re-alerting, it lands as a new message on the existing open ticket rather than spawning a fresh one every time, so a queue stays a true reflection of what's actually going on, not a pile of near-duplicates burying the one thing that matters.
That distinction is the difference between automation that earns trust and automation that erodes it. A ticket queue a technician can rely on — where every item genuinely needs a look — is worth more than a queue that's merely comprehensive. Comprehensive and noisy is just a slower version of not watching at all.
What this does to a technician's day
There's a version of this that's purely about client-facing polish, and there's a version that's about how an MSP's own team actually works, and the second one might matter more. Technicians who spend their day reacting to phone calls are, structurally, always behind. Every call is a task they didn't choose the timing of, interrupting whatever they were doing, carrying whatever urgency the caller's frustration adds to it. A queue built from monitoring instead of complaints is different — it's prioritised by what actually needs attention, not by who called loudest or who called first, and it doesn't come with someone on the other end of
the line getting more annoyed by the minute while a technician figures out what's even wrong.
That's not a small quality-of-life difference. Reactive support is exhausting in a way that proactive support simply isn't, and teams that operate mostly reactively burn out faster, churn faster, and — not coincidentally — sound more like they're always one step behind, because they usually are.
The sentence that replaces it
"I'll look into it" isn't a bad sentence because of the words. It's a bad sentence because of what it reveals about timing — that the looking is starting now, triggered by the asking. The goal isn't a better way to say the same thing faster. It's making the sentence obsolete, often enough that when a client does need an update, the answer is already sitting in a ticket, timestamped from before they ever picked up the phone. That's not a script change. It's a monitoring change — and it's the one NetMon was built to make.
About the Author: Stephen Richards
Bio for Stephen Richards: Born in Colwyn Bay North Wales, Steve's introduction it Computers was at secondary school in 1974. That first year, Machine Code was hand written onto gridded paper and sent to Connah's Quay Technical College where is was copied to punch card and then entered into a mainframe computer. The results printed out were sent back for the following week!
Steve left School in 1976 joining the Royal Air Force to work on RADAR and communications equipment. His last 5 years involved working in an Automatic Test Equipment (ATE) department on the System Management Team and also writing models for Microchips. It was a good job that he had kept up with computers which had become rather a passion by the time he started in ATE.
During that time the main Mainframe we replaced in a £3.9 million upgrade reducing the run time of the biggest ATE program from just under 2 weeks to the time it took for a finger to come off a depressed return key!
Leaving the RAF after 18 years service Steve worked for a Charity (Apex Leicester Project) before returning to electronics at Sonatest in Milton Keynes which after 3 or 4 years led to a Job at Telematica the then development arm of Trafficmaster PLC (Tm). Eventually brought in-house at Tm he worked moved into the IT Support Team with his last project moving email from a Linux Box to Microsoft Echange for the 300 users in the company each of whom typically had 5 email addresses.
In 2006 Steve left to start his own company back in North Wales, Computer Technical Solutions was an MSP and moved to become an MSSP following another of Steve's passions Cybersecurity. Officially retiring in 2025, by May 2026 that overactive mind started thinking about all of the software he had seen not just for MSSPs but also for his clients that was either extremely expensive or that didn't exist with a complete answer to the needs of the SME.
By August 2026 two significant pieces of software have been created. Netmon the Network Monitoring Software and the second release Parkcore aimed at Caravan/Lodge Holiday Parks..... And so it begins!
