Network teams that create MSP contracts for their managed network services should cover delivery lead times, network performance, adds and changes, network uptime and escalation.
The typical managed network services agreement encompasses a number of areas, including application performance, support and fix times. When engaging with prospective providers and vendors, teams may wish to develop their own statement of requirements pertaining to managed services.
In this article, we consider five key areas to include in a network services agreement, along with advice on operating parameters and why they translate into predictable performance across both the network and the underlying processes with which the network is managed.
The reality of managed service provider (MSP) contract negotiation is providers and vendors typically don't establish terms and conditions in extensive legal contracts. One exception is global network provisioning, where large enterprises have legal teams that meet to create bespoke contracts and frameworks to deliver high-value contracts tailored to their specific projects. However, even if a network doesn't qualify as large or complex, IT teams should still align their specific requirements with each prospective service. When creating a network services agreement, a business is essentially producing a list of requirements it can use to shortlist prospective products and services.
IT teams should remember one critical factor when evaluating or creating network services agreements: Most teams tend to base their WAN capability on contractual service-level agreements (SLAs), rather than the actual architecture of the technology. It's always a better option to put together a comprehensive, well-architected design versus relying on service credits if downtime occurs, for example.
Network performance
The typical network performance framework offers latency and jitter guarantees across a provider's network as an average time between its points of presence (PoPs). In general, telecom operators deliver standard traffic performance SLAs, but they might add further enhancements based on their knowledge of real-world traffic performance and testing across existing customers.
When creating a network services agreement, a business is essentially producing a list of requirements it can use to shortlist prospective products and services.
When defining an MSP contract, complexity can arise as businesses look toward technologies such as software-defined WAN (SD-WAN), where traffic performance across the internet is typically given as an average between countries rather than specific PoPs. In some designs, SD-WAN access to public cloud services means network performance measurements could be largely unknown if multiple internet service provider backbones are required to move packets.
Moves, adds and changes
Service providers vary in their ability to turn around both simple and complex change requests. With any MSP, it's critical for teams to understand which elements need fast turnaround versus changes that require presales or technical design authority to consider the implications of a request.
The network services agreement is a good opportunity to consider what the business needs based on past changes or future growth. In some cases, slow change requests have a huge effect on business productivity. When speaking with IT teams, for example, one reason enterprise businesses turn to DIY SD-WAN deployment is to gain control of the change process.
Fix times and network uptime
It's often difficult to translate how fast a provider or vendor can solve issues into meaningful, real-world value. Most vendors will offer a mean time to repair, from when the fault is first detected. In other words, the clock doesn't start until the service team identifies and qualifies the fault.
In order to define an MSP contract with fix times, teams must consider the overall architecture to ensure the service technically delivers maximum uptime. Where dual circuits are provisioned, with no single point of failure, the real-world uptime should be set at 100%. If a single circuit is provisioned, however, it's not possible to reach 100% uptime, as no alternative path exists. If a service provider is willing to guarantee 100% uptime, the contract becomes a commercial proposition rather than something based on real-world technical architecture.
Delivery lead times
As with fix times, delivery times are more of a commercial proposition. The delivery of Ethernet circuits is subject to site surveys and is often governed by unforeseen elements that affect lead time. Situations that involve wayleave agreements -- in which service providers obtain approval to install equipment over private property -- are examples of when the provider cannot predict delays until the circuit is ordered and in flight. That said, a network services agreement does offer an indication of approximate delivery times, although it doesn't provide a guarantee.
When considering available technology, it is possible to deliver an offering with fast-start connectivity or a contingency if delays occur. Therefore, it may be possible to deliver a contractual agreement with the premise that connectivity of some type will be delivered within set time frames. For example, a location with strong 4G or 5G connectivity could enable a site to deliver VPN connectivity over the internet as a temporary option. SD-WAN is transforming delivery lead time SLAs by using path selection across multiple services, including 4G, 5G and superfast broadband.
Escalation
The delivery of telecoms services is often problematic due to the sheer amount of moving parts and components that can add issues and problems. A section on escalation within the network services agreement is one area teams can define with granularity.
It's necessary to consider the right escalation contacts. I typically suggest focusing on key members of the support team, which should include senior staff with 24/7 availability. While it may appear to make sense to escalate to the CEO of the provider or vendor, better results are often achieved by escalating only to senior members of the support team that can make a tangible difference.
Match your resources
Resources include project managers, technical design authority, install engineers and support teams with varying accreditations and qualifications. When developing a contractual framework, it is advisable for companies to request the resources matched to their own internal team and network scale.
Networks with global provisioning should expect either follow-the-sun support -- in respect to availability -- or a multilinguistic team. The same focus should be given to delivery and project management staff who must communicate with local site contacts. Readers should note that product service descriptions often include the number of staff assigned to each department with their respective qualifications.
