In the technology world, many people think they easily understand the term “managed services,” but when they’re prompted to define it, they have a hard time doing so. What does it mean to receive managed services for a system or set of systems? What does a managed services provider (MSP) do when they manage your environment for you?
Typically, I’ve found that the definition of a “managed service” is widely different depending on who you ask, which actually makes a lot of sense.
In the customer’s mind, they think, “I am going to outsource the management of 10 pieces of networking gear.” To the customer, that means the setup, installation and configuration of the equipment will be handled by the service provider. The provider will configure the items to best practices, provide ongoing patching and monitoring, harden the configurations from a security perspective, fine-tune the settings for performance and dynamically change the configuration state to meet business needs on the fly. If there is a connectivity or functionality issue, they will work to resolve it after having identified it through their systems, with or without the customer telling them to. The provider will also repairreplace hardware as needed and perform all items under a strict service licensing agreement (SLA) and then provide reporting that proves adherence to that SLA.
Those are all legitimate assumptions of what a “managed service” is, but the finer points often differ from reality.
In the MSP’s mind, we are going to take over management of the customer’s 10 pieces of networking gear. To us, that means the initial setup has already been completed. If new installations are required, that is the responsibility of the customer — or a new, separate, out-of-scope project can be executed for the initial deployment and configuration of those new items. The equipment will be documented for “current running state,” and a baseline will be established for the customer’s normal operating performance. “Best practices” is an ambiguous term, so configuration changes will be made to ensure the steady running state in accordance with known operating issues and recommended vendor configuration settings. A runbook or order of operations will be generated to establish triage and tasks for maintenance as well as escalation paths for incidents, either related to performance or remediation. The ongoing patching, securing and monitoring will be executed in accordance with the runbooks, and incidents and anomalies will be triaged through ticketing. In the event of physical repairreplacement, if the customer’s equipment is under warranty and support contracts are current, we will work with the associated vendor to facilitate services requests. All activities and management will be executed under a strict SLA with reporting that proves adherence.
It is immediately clear that the customer’s goal-based objectives are different from the operational and sandboxing mindset of the MSP.
Often, the parties try to perform reconciliation of these two mindsets through contracting or within statements of work. That typically fails, as the interpretation of both parties differs in the same way that their mindsets differ.
If we think of an MSP managing a server for a customer, the scope of the statement of work may indicate that the MSP will ensure the healthy running state of the server’s operating system environment (OSE). What is healthy? Does the MSP also manage the virtual host that the server sits on? What if it is in the cloud and the cloud provider controls the virtual host? What if the MSP performs work on the virtual host, but that is out of the scope of the statement and the customer is charged extra? Then, the customer will argue that they shouldn’t be charged because all they want is for their system to be running in a healthy state.
That is why, from the MSP’s perspective, it must be all about baselines. If the customer agrees this is the baseline for typical operations, the MSP can capture that, improve it with efficiencies, maintain it and keep it up to date. Again, this is very different from the goal-based objectives of an MSP’s customers.
So, what is the best way to reconcile these two mindsets?
Understanding each other’s perspective and building a partnership is the first step. The customer must understand they are purchasing a maintenance service, and the MSP must provide frictionless paths for the customer to meet their goals.
The second step is to use contracting. Agreements must be explicit, and both parties need to use the agreements to validate their mindsets. The customer must point to the sections that validate their goal-oriented mindset, and the MSP must push back where there is scope creep. Also, whether it is part of deliverables or not, the customer’s goals and reasoning for receiving services must be documented.
Communication is also crucial. All too often, a customer who purchases services to meet a goal doesn’t tell the service provider that their goals are not being met. They often point to times to resolution (TTRs), SLAs or other metrics that they didn’t care about previously. As soon as they impact a goal, though, they use service metrics as a manifestation point for their frustration. On the flipside, the MSP must clearly communicate what is in their scope and what is outside of it, and they must do so often. Many times, the MSP will execute out of scope tasks to help a customer meet an objective. That should be communicated. Even if there is no extra charge, expectations need to be continuously level-set.
As long as there is a buyer and seller, there will be confrontation and the epic pushpull of negotiation. When it comes to MSPs, though, we can all stand to clarify and communicate more and push the transactional negotiations to the surface right away for everyone’s mutual benefit.