Two Ways to get VoIP Support

San Jose, CA — I had wondered in the past whether GS did any VoIP engineering or support, and I got my answer yesterday at VON. I learned about IBM Global Services’ Support for VoIP Systems.

The Global Services VoIP support offering that I learned about is focused on supporting technical staff at enterprises. (NB: “Enterprise” is jargon for for any customer that’s not a government, a carrier, or a residential consumer. These are folks with more than a couple of telephones, and they often have their own technical staff. ) In particular, businesses using Cisco VoIP gear running SIP.

IBM is trying to compete directly with Cisco here. IBM claims to be less expensive than the equivalent product from the TAC. They seem to be competing with SmartNet directly. Doing that would seem pretty strange — because IBM’s customer would not have the same direct access to bug fixes. To resolve a software defect, the customer will first have to first convince IBM, who will have to convince Cisco. Then IBM has to get (and presumably test) the bug fix, then provide it back to the customer. Likewise, can IBM’s VoIP customers get access to Cisco documentation that requires a Cisco login?

IBM also brings its bigness to everything — and by that, I mean its Jabba the Hut type of qualities. If you call in and there’s no formally documented and distributed process that already answers your question, you’re likely to have to wait a while to get to someone more senior who can actually solve novel problems. A junior technician might not be allowed to even try to resolve your problem, if they’re too junior.

Another oddity here is the fixed price that IBM can charge. That is, if you sign up for IBM’s support, I understand that you’re going to be offered a fixed contract price for that support. You can call them with problems or with general questions about your system. If your network was put together terribly, then IBM is going to get a lot of calls from you. And if they’re competing with SmartNet, they’re likely to get customers using non-supported, out-of-warranty Cisco (i.e., spawn of ebay).

In effect, IBM is accepting risk for their customer’s network. They’re also accepting risk for Cisco’s product quality. If you call a lot or if Cisco has a lot of bugs, their costs to support you are higher; if the product just works and you call only a little, then their costs are low. The only way to control their costs it to limit what they support by a strictly-defined scope of responsibility. The corollary is that they’ll be glad if a problem is in a device outside their scope.

I have used Lucent’s product like this, which competes with BroadSoft’s support. Using this product, a user of the BroadSoft BroadWorks platform can call Lucent to get support on the BroadSoft platform. Similarly to IBM, Lucent’s intention is to keep the support work internal. This can have a similar effect of delaying or reducing the customer’s access to new software, and reducing their access to documentation.

Lucent and IBM want to build a pool of expertise, then sell access to that expertise. That’s a good goal, and could be a good service. But they don’t make the software, and I doubt they have the source code, so they can’t possibly know all of the ins-and-outs of the systems they’re supporting. For this reason, they can’t effectively replace the original vendors. Both of these large companies want to do everything by process and procedure, based on the principle that the systems are deterministic; in reality, the human inputs and the “open” nature of their protocols complicate these systems immensely. Both of them add a barrier between the user and makers of software, effectively reducing software and documentation access.

My point is that you really do need the product developer’s support. They’re the only ones that really know their product — all its gory details and subtle bugs. But each vendor only supports his own product, only up to its own interface. For example, if you have a Cisco phone having trouble talking on a Netgear Ethernet switch, Cisco doesn’t have a responsibility to ensure the Netgear is working right, nor does Netgear have a responsibility to ensure the Cisco is working right. So if you only work with the equipment vendors, you’re largely on your own at the point of interface. (NB: Cisco SmartNet support engineers often do help beyond the edges of their equipment, but the extent of that help is naturally limited.)

So how do you get support for a VoIP platform? My strong opinions come from years of doing exactly that at a different kind of support company. We just help technical folks solve their problems; we don’t pretend that we can supplant the original deveopers. If that means calling the original vendor, or re-engineering a piece of the system, so be it. My goal representing you is to solve the problem, regardless of the source. Yes, we develop some special pools of knowledge. In this way, I’m more like “temporary staffing” than a vendor representative. The point of this blog isn’t to shill, but I did want to explain a different model.