In the constantly evolving world of the MSP, the need to partner with other providers continues to grow. Yet, gone are the days where a partnership was something agreed upon over a couple of drinks with a logo and link being placed one each other’s websites, and with both sides essentially then forgetting about it.
Partnerships between MSPs now require solid thought, planning, and implementation. Without ensuring that all the ‘i’s are dotted and the ‘t’s are crossed, chaos can ensue, which can then result in damage to both partners’ credibility.
What makes a proper partnership?
First, both sides must buy into the idea. A true partnership may mean teams working together from both sides. Indeed, it may be that employees from one company work at the premises of the other. If this is the case, both sides need to watch out for the employee ‘going feral’ – that is, ceasing to see themselves as part of their employer’s company and instead viewing themselves as part of the partner’s company.
This may lead to a need for rotation of staff on short (quarterly or so) stints, with staggered timing to enable proper handover between the incoming and outgoing staff. Both sides must also beware of the ‘rock star’ employee – the loss of a single person who can damage the partnership should not be allowed to happen. Always make sure that there is more than a single individual covering key areas.
Where code development is involved, ensure that suitable collaborative tooling is in place. For example, make sure that help desk tickets can be fed in from both partner’s systems, and that the right developer(s) are made aware of issues that have been raised. Also, it is important that reporting is made to both sides so that each company aware of any situations that arise.
Finger pointing must be avoided at all costs. In a working partnership, the customer should see the system as a single solution – they will not be interested in trying to understand when and why your support staff try place blame on a different group.
Change management
Sure, both sides must have the freedom to improve their own products. However, finding that an improvement in one system breaks the overall functionality between dependent systems does not help either side of the partnership. As such, the partnership agreement must allow for early disclosure of planned changes to the other side (under agreed non-disclosure) and must also allow for suitable testing of the overall system to be carried out before any changes are made.
Even where the change stands a chance of ‘breaking’ the functionality of the overall system, early warning systems may make it possible for the other party to provide a workaround that will suffice until they can change their code to fully support the change.
It is also important to note that sales teams must buy in to the idea of a partnership between MSPs. This is often one of the hardest areas to deal with. Unless the salesperson is compensated for any deal they bring in that includes a partner, then there is no incentive for them to bother. This means that any partnership must cover compensation, alongside marketing areas such as shared collateral, market development funds (MDF), events, and so on.
Support staff must also have a strong working knowledge of what the partnership means. A problem may occur in a part of the solution that they are not responsible for. The first thing that the help desk staff must be able to do is to narrow down where the problem is, and either provide a first-level fix or workaround, or to be able to transparently and efficiently hand the problem over to a second or third level agent who can deal with the problem. In cases where the problem crosses over between partnership members, then an agent may need to respond as if they are part of the other member’s team, or at least be able to rapidly describe to the problem owner why they are now dealing with a different company.
Further, escalation procedures also need to be put in place, monitored and reported on. Should you feel that the partner is not pulling their weight, how can you remediate this? Who within the partner’s environment can you go to in order to expedite an issue? Never go for a name, but for a role – and where possible, make this two or more roles, so that there will always be someone you can find to help out.
The need for co-working around support and in dealing with customer data also brings up issues around data security and legal management. If information on customers and problems are being shared across two or more partners, then it is important (actually, a legal necessity) to ensure that this is acceptable to the customer. Contracts must cover how information and data will be managed across the MSP partners involved, how a customer can gain access to all information about them that is on file, how they can request that all information about them be deleted, and how you as the prime contract holder will prove that this has happened.
Planning for the unthinkable
What happens to the partnership if one partner is acquired by another company, particularly one you don’t want to deal with? How about what happens should one partner go out of business? There must always be a Plan B in place – is there another potential partner that can be plugged in easily and effectively should that be needed? If so, how rapidly can this be done?
How can a customer’s data be moved from the outgoing partner to the new one if that is required? This may involve much deeper architectural planning, such as maintaining a live mirror of customer data that normally resides on the partner’s equipment, on your equipment.
It is likely that a dynamic and successful MSP will have a raft of possible partnerships, and each one will require its own agreement. However, by creating a base template that covers the common areas where real partnership issues may arise, such discussions can be expedited.
Photo: Valeri Potapova / Shutterstock
