Skip to content

Where the line falls between an MSP and a business applications partner

If we come into your client, what stops us taking the whole relationship? A specific answer: what belongs to the managed services provider, what belongs to a business applications partner, and the three areas that genuinely overlap.

3 min read September 27, 2026

ShareEmailLinkedIn

This question comes up in every conversation we have with a managed services provider, usually about twenty minutes in, and usually phrased carefully. The honest version is: if we bring you into our client, what stops you taking the whole relationship?

It is a fair question and it deserves a specific answer rather than a reassuring one. Here is where we think the line falls.

What is naturally yours

Anything about the environment your client works in. Identity and access. Endpoint and network. Acceptable use policy. End-user AI tooling, including the Copilot that sits in Word and Teams. Shadow AI and the security conversation around it. Backup, continuity, patching, the help desk.

That is the relationship. It is daily, it is trusted, and it is not something a business applications partner can replicate or should want to.

What is naturally ours

Business applications. The systems that run the operation rather than support it. ERP and CRM. Financial and operational reporting. Process redesign, which is mostly a business conversation rather than a technical one. Agents and automation running inside a business process rather than on a desktop.

This work needs people who have implemented it repeatedly and who can say what usually breaks. It is a different skill set, and most MSPs who have tried to add it have found the economics difficult, because the utilisation model does not fit.

The overlap, which is where the honesty matters

Three areas genuinely sit in between: governance, data readiness, and adoption.

Governance because AI and automation policy touches both the environment and the process. Data readiness because getting a client’s data into a state where anything useful can be built on it is partly infrastructure and partly business definition. Adoption because a system nobody uses is a shared failure regardless of who implemented it.

These need a conversation before the engagement, not after. The reason to have it early is not politeness. It is that your client should never hear two different plans from two people they trust.

What that looks like in practice

When we work behind an MSP, the arrangement we prefer is the one where you stay the primary relationship. We are introduced by you, we report through you where you want that, and we do not touch anything in your column.

Some MSPs want to be in every meeting. Some want to hand it over and hear about it monthly. Both are fine and the only wrong version is the one nobody agreed to in advance.

On the commercial side, referral arrangements exist and we are happy to talk about them, but the more valuable thing for most MSPs is not the referral fee. It is being the person who solved a problem their client had, in a category they could not serve themselves, without losing the account.

How to know when it applies

The signals are usually operational rather than technical. A client says month end takes two weeks. A client mentions a spreadsheet that three people maintain and nobody trusts. A client asks whether their accounting software can do something it cannot. A client is growing and the system that got them here is visibly not getting them further.

None of those arrive as an ERP question, which is exactly why they get missed.

If one of them sounds like a client you already have, the useful next step is a conversation about that specific situation. We will tell you honestly whether it is a real opportunity or a client who should stay exactly where they are.

Want the next one?

Get new articles, newsletter issues, podcast episodes, and videos from the people doing the work.

Subscribe to The Nova Effect

Free, and low pressure

Book a conversation

Loading the calendar…