Introduction
Sharing is caring. Well, this is tricky for service providers. Naturally, as an MSP, your first inclination may be to share everything. You want to keep your clients happy, right? While there may be nothing inherently wrong with this mindset, it can be a slippery slope, because there may be proprietary and other private information within your customer’s documentation. In this article, we will break down this complex matter and look at what you should and should not share.
Share Away
Let’s first look at what to share and why it’s important. Documentation is vital for any IT department, and MSPs are no different. If your client’s environment is not properly documented, your business and the client will suffer.
While it is easy to say, “Share your documentation,” it depends on what type of documentation and what is stored within it. For example, you need to redact personal information, cell phone numbers, and passwords if these were recklessly entered into the document. Another item to remove would be technicians’ names and other specific information tied to your staff.
Why is this important? To better answer the question, you need to consider the possibility that your client may leave to work with another MSP. If this happens, this could come back to bite you. The safest bet is to plan accordingly and only have high-level information in the diagrams that describe the customer’s environment, without compromising personal data. High-level information, such as analysis conclusions, recommendations, and tactics, will provide the necessary information to the client and their new MSP and will assist the client in moving forward.
There may also be outlier scenarios. One example is if the customer or the new MSP asks for an export of the ticket log, which includes every ticket and its resolution. These types of questions are harder to answer and there are several variables to consider. What works for one MSP may not work for another. Be aware of these different scenarios and think how your business can address them.
Sharing No-Go
Next, we explore what should not be shared with clients. Some clients may perceive your refusal to share as a breach of contract, but the fact of the matter is that you, as an MSP, own a lot of the proprietary information. For instance, the following belong to you and should not be provided to the client or the new MSP:
-
- Third-party software installs
- Scripts
- Policies
- Procedures
- Detailed infrastructure diagrams
These are all proprietary to the creator and not the customer. All of these documents have secure internal information about your business practices that the customer or anyone from the outside should not be privy to.
There are, of course, outlier scenarios with this as well. There could be a script that runs once a month that resolves an obscure issue your team discovered. If this script doesn’t run, it causes the server to crash or become unresponsive. While you wouldn’t normally provide such details as scripts that perform patching activities or have another function, you can work with the client or new MSP to review on a case-by-case basis.
Conclusion
When looking at the big picture, transparency is a high-value add in the service business. The key is balancing client-facing and confidential documentation. An example of this is making sure technicians include all client-facing notes in tickets, which are then put on invoices at the end of the monthly report. Doing so enables you to consistently provide transparency to your customers. Depending on your knowledge base or internal database, you can also create a section for public documentation and internal documentation. This makes it crystal clear with the staff where the proper documents are stored.
On a final note, it’s always a good idea to work these details out ahead of time in your service agreements or contracts. When you go this route, if the client ever has any questions, you can refer back and verify all the necessary details.
Read our free guide to learn about:
- Challenges posed by personal devices;
- Best practices for managing personal devices;
- Establishing governance rules;
- Deploying MDM software, and a lot more.