I want to continue my comments on managed services with some insights from the service buyers. I’ve been watching the buyer side of the space for about five years now, in part to see what might be required of NFV in support of managed service deployments. Since then, I’ve kept in touch with some of the early and later adopters of managed services, and when I tallied them for this piece I was surprised by the consistency they showed.
A “portal” is the gateway for information to pass between a managed service provider (MSP) and the service buyer. It’s the constant, visible, and (hopefully) highly visual presentation of the MSP’s presence, and of their commitment to the buyer. No matter how complicated the management systems used by an MSP might be, the portal is the way the user wants to see it all.
That’s the main point I got from users; managed service providers are seen through the eyes of their portals. Whatever brought users to the MSP decision, they quickly identified their service with the management portal through which they obtained status. In fact, by the end of the second year of managed service use, almost all users lost awareness of what went on behind those portals. Clearly, from the user perspective, presentation is nearly everything.
I don’t want to leave the impression that users didn’t care about what a managed service did; that isn’t true. However, users framed their view of the service and its provider from what the portal showed. If the portal was very good, meaning it conveyed a lot of useful information, they believed the service was equally good. If the portal was less than ideal, then the service was likewise. Portal problems were at least in the top two problems cited by every user who later abandoned managed services or changed providers. That there were problems was a bit surprising to me, because what users wanted from MSP portals was pretty straightforward.
First and foremost, users wanted their portals to be the single point of contact between them and their provider. They didn’t want to interact with multiple systems, call someone on the phone, or rely on a visit from a representative. “Show me the portal!” might well have been an appropriate battle-cry for them. They wanted to be able to get instant service status and drill down to identify problems and the state of resolution. They wanted to be able to do all service ordering, and check on order status. They wanted to be able to contact key people involved in their service and its SLA directly through the portal, and they wanted the portal to keep tabs on what they’d done in past contacts.
The problem with incomplete scope of portal capability was one of the top two problems users cited as a reason for leaving an MSP. This was particularly true for users who gave senior (CxO) level people access to a portal to track the state of a far-flung operation. Even though these users didn’t typically do problem isolation or moves, adds, and changes in configuration, they ended up expecting someone down the chain of command to be able to do that, perhaps from their exposure to a portal at a higher level. “Why do you have to call them?” one user reported a CIO as asking, when told that a set of changes would require they talk to a technician, “Do it online!”
Users also wanted to be able to customize their portal display and features. This was something that came up only in about a quarter of pre-deployment requirements but was later named as critical by almost all the managed service users. The easiest way to think of what users wanted in this space was to visualize the portal as a web front-end to a business application (or applications). Users wanted to be able to diddle with widgets or other simple graphic tools to set up their portal display and they wanted to be able to do this on a per-user basis.
User customization, meaning framing the portal to the specific users/roles that would be expected to use it, comes out clearly as a requirement as users mature in their exposure to managed services. Most of the users identified at least three roles of personnel who were expected to interact with portals, and there were distinctly different requirements for what the portal showed and even what the users were allowed to do. The more different roles a user assigned to MSP-related interactions, the more likely the user was to expect to see portals edit the set of features that could be exercised by some of the roles. Usually they wanted only one role/person making any kind of configuration change, and the same with problem resolution, but they wanted everyone to be able to see the current state of the network and the state of all problems still considered open, or even recently closed.
It’s important to see how MSP portals relate to things like management consoles, which may seem to be the same thing. The major difference between a user’s view of a managed service portal and their view of network or service management overall, is the relentless focus on SLA. Here, SLA means “whatever the MSP has committed to managing”. An SLA is a contract, and that’s what buyers understand how to enforce. It starts with monitoring to determine whether it’s being violated, of course, and so that’s where the portal has to start. Almost 95% of managed service users say they want their home screen on their management portal to show them the state of their SLA.
Things like problem diagnosis and determination, in managed services and portal terms, really mean deciding whether the problem is the MSP’s or their own. Users are not interested in pursuing further problem isolation at the portal level; the SLA defines the boundaries of the contract and the functional limits of the portal. Unless the buyer of the service has contracted for desktop-to-the-world managed service support, the MSP portal is the primary tool in making what’s the biggest decision of all—is it “us” or “them?” The user will go to other tools for further refinement of the stuff in the former category.
Linking portals to user management systems is a complication, of course. If a given managed service user is using managed services as little more than a piece of a complex network, then it’s likely that user will want to be able to link the MSP portal into their own management system. That suggests a portal structure that starts with policy filtering of what can be seen and done, and then a layer of presentation that might end up in a display or app, or might end up in an API used to link information to the service user’s primary network operations tools.
Managed service users’ portal obsession may be a good thing for MSPs. First, it indicates that the service user is focused where an MSP is focused, which is providing an SLA. Second, portals are logical front-ends to any number of management systems, converging them on a common user view.
One of the challenges that MSPs face is the lack of unified management practices for the stuff their SLA covers. Over-managers like OpenView or Tivoli have been a popular strategy not only for framing the administrative functions of network management (which include SLA management, of course) but also for unifying a somewhat disconnected set of element management tools. Even some of the more modern takes on this software level (like Pandora) are probably overkill for MSPs, but there are plenty of open-source tools that could be collected under a portal-front-end umbrella.
I want to close with a recap of an earlier point. Portals are not a substitute for effective management tools and practices, but they can elevate the user’s perception of a managed service, unify the users’ view with MSP management, and even frame MSP thinking around the right points—including the SLA. There are major benefits in getting the portal story right.