Tackling Other Peoples’ Problems: A New Look at MVS
by Bill Rose, SSPA Founder/Executive Director

One nice thing about writing a weekly column is that I can change my perspective on an issue as often as we publish SSPA News. While that’s possible, I don’t run around changing my opinion on important issues without a lot of thought -- and I’ve been thinking a lot about multi-vendor support (MVS) – and I’ve got a new way of looking at things.

First of all, let’s simply define MVS as the situation where the customer has a problem that could belong to more than one vendor. In a lot of cases, that customer will call more than one vendor in an attempt to get the problem resolved. Over the past months, I’ve been on a quest to understand more about MVS and help our members discover for themselves how big a problem this is.

Like a lot of issues, the biggest challenge is that we don’t really know much about the problem and don’t have effective ways to measure it. I looked at it much the same way we looked at issues like abandon rate. Not all that long ago, most companies really didn’t know how many customers were getting busy signals when they called in, how many hung up after being on hold, and so on. They didn’t know how many customers simply abandoned their efforts to get support or went somewhere else for answers. Over time, we got better at tracking and measuring abandon rates and today, no support center would think of operating without that critical information.

That’s how I saw MVS. I’d ask members if MVS was a critical issue for them and most would answer, “No, not really, we don’t have a lot of those issues.” When I asked how often they involved other companies on support issues, most said, “not very often.” But when I’d ask them how they KNEW they didn’t have MVS issues and how they measured the number of MVS calls and the associated costs, they didn’t have any answers. They didn’t really know.

I still believe MVS is a big issue when customers are deflected from one vendor to another or when two or more vendors spend time independently working on solving the same problem. On top of that, MVS issues are typically pushed to the back end of support, where developers get involved and a lot of costs are incurred. Not only is that cost to the company high, imagine how much the industry spends on those calls when multiple vendors have highly-paid developers working on the same problem.

I also have a new perspective. I’m convinced that MVS isn’t the right term for the real issue here. The real issue is other peoples’ products (OPPs) and the cost of supporting those products.

What I’ve come to realize is that the issue isn’t one of how many MVS calls come in or how often your support organization has to go to another vendor to resolve an issue. The question is: How much time, effort, and money do you spend supporting OPPs? If you have people in your organization with specialty skills you needed to support platforms, environments, or someone else’s products, you have an OPP issue. If you have a lab that you’ve outfitted with the most sophisticated technology possible just to make sure your products run on or with other peoples’ products, you have an OPP issue. If you’re sending people to training on products that aren’t yours, you have an OPP issue.

My new perspective on the problem is: How much do you spend supporting other peoples’ products and do you have an effective way to measure the amount?

On the surface, supporting OPPs might seem like a bad idea -- It isn’t. In talking about MVS with members, most vendor members would rather have customers call them with questions about OPPs than bounce those calls to someone else. That’s because those members are the ones with whom customers have relationships with. Those members want the opportunity to nurture the relationship, and generate revenue through those relationships, and welcome those customer calls.

The bottom line isn’t to figure out how not to spend money supporting OPPs because, as a vendor, you’re going to make that investment. It’s become part of being in the tech support business. You’re going to train your support organization on things like Windows or UNIX. The issue is to understand how to become more efficient in supporting OPPs and reduce the costs.

To help us all understand the problem better, I’d like to know more about your support practices. I’d like to know how much you spend supporting OPPs and how you determine that spend. I also want to know what elements we should include as we build a model to help members understand how to calculate the cost of supporting OPPs? If you’ve done any analysis on how you measure the cost of supporting OPPs, please drop me a line – bill.rose@thesspa.com. I’ll share the results of this informal poll as well as more thoughts on OPPs in a future column.

Sincerely,


Bill Rose
SSPA Founder/Executive Director