Why MSPs sometimes need to go deeper than incident response to solve an IT issue

Mervyn Jackson, founder and principal consultant at IT ICU explains why the root cause is hard to find for MSPs.

Managed service providers (MSPs) have the ability of resolving incidents quickly, but struggle when it comes to finding the root cause, according to Mervyn Jackson, founder and principal consultant at IT ICU.

Speaking to CRN Australia, he explained why MSPs need a clear escalation point between support and diagnosis.

To understand why MSPs might miss the root issue, Jackson said he would look at the workflow and available evidence before blaming technical ability.

“A process that rewards closing individual tickets, without reviewing recurring faults together, can overlook the larger pattern,” he said.

Evidence can also be fragmented, Jackson added.

“One supplier sees the application, another the network, and another the identity platform. Each may establish that its own component is healthy without explaining why the customer’s complete workflow is failing,” he said.

“The practical correction is to build one timeline, compare affected and unaffected cases, and test hypotheses against logs and observed behaviour. ‘The fault disappeared after we changed this’ is useful evidence, but not conclusive proof of the cause. There may also be several contributing factors rather than one defective product.”

Jackson said the distinction between support and diagnosis is about the work, not the technician’s job title.

“Routine support already involves diagnosis; the escalation point is where the problem needs a more deliberate investigation, protected time or broader expertise,” he said.

“I would also look beyond ticket-closure speed and ask whether the same customer disruption is returning. If it is, keep the problem visible and owned, even after the immediate incident is closed.

“A closed ticket is evidence that the immediate issue was dealt with. It is not, on its own, evidence that the underlying problem has been understood.”

For partners who see this as additional work, Jackson said they should avoid this as a “sales objection to overcome”.

“The customer is entitled to understand why the work is needed and whether it is already included in the service they purchase,” he said.

“Make the boundary clear at onboarding and in service reviews: what routine support covers, how recurring problems are escalated, and when separately scoped work might be appropriate. Deeper investigation is not automatically an extra charge.”

Where additional scope is genuinely needed, propose a bounded first stage with a defined output, evidence gathered, explanations tested, remaining uncertainty and recommended action, Jackson explained.

“Relate it to the customer’s actual disruption rather than speculative savings,” he said.

“Not every minor fault warrants a major investigation. The effort should be proportionate to the impact, recurrence and risk. That makes diagnosis an accountable service decision rather than a request for an unlimited budget.”

Other emerging issues for MSPs

Jackson sees two other areas of concern for Aussie MSPs. These are responsibility across cloud services, and how automation is used in support.

“Moving to software as a service does not remove the need to manage identities, permissions and customer-controlled settings,” he said.

“I would encourage partners to make those responsibilities explicit, particularly where several providers support different parts of the same business workflow.”

AI-assisted support and automation can help gather diagnostic information, correlate events and reduce repetitive work, Jackson said.

“The important distinction is between automating a known, controlled action and treating a plausible generated explanation as a verified diagnosis,” he added.

“My preference is to automate evidence collection and repeatable checks, while keeping production changes subject to appropriate permissions, validation and rollback arrangements. Faster troubleshooting is useful; faster execution of an untested assumption is not the same thing.”