• United States

How to handle IT vendors’ worst bad habits

May 03, 20237 mins
Data Center

Enterprises hate it when the companies they buy gear from pass the buck when issues arise, over-hype their sales pitches, and don’t give a heads-up about new products.

rivalry tug war compet conflict challenge determin

Most enterprises have what they describe as a cordial relationship with their network vendors, but roughly a third say their relationship is guarded, and more than a few say it’s suspicious. That’s a pretty broad range of views, but every enterprise I’ve chatted with says there are things they don’t want their vendors to do, and don’t like it if the vendors do them. Most also say they take steps to prevent these things, and the steps they recommend are really interesting.

Vendors shouldn’t finger-point

The top don’t-do for vendors by far is finger-pointing, meaning trying to deflect responsibility for an issue by blaming someone else. I remember well a meeting where the CIO of a healthcare company sprained his shoulder when he threw a ten-pound, bound listing of problem proofs at a network vendor VP who didn’t want to admit responsibility. (He him square in the chest, by the way.)  This is surely an extreme reaction, but every single enterprise in the over-200 I’ve talked to about this in the last year said that their network vendors had evaded a problem or obstructed problem determination at least once.

Every one also said that when it happens, it lengthens network outages, widens their scope, and makes problem isolation and resolution more difficult.  Enterprises also say that vendors often finger-point even when there’s no other network vendor involved, instead blaming the enterprise network operations staff or perhaps some past sales or technical support person now conveniently not working for the vendor any longer.

Get well-crafted SLAs

There’s good news here, though.  Enterprises have two strategies to address finger-pointing: carefully authored service-level agreements (SLA) and strategic monitoring. They say that once a vendor starts blaming someone else for a problem, it’s almost impossible to get things back on track, so their goal is to ensure the first finger is never pointed. To do that, they nail down what’s expected, monitor compliance, and mandate escalation.

Most enterprises use SLAs to guarantee services like VPNs and cloud computing, but equipment deals are a mixture of services and products, and so a contract is usually the legal basis of the relationship. Enterprises say that this contract has to spell out not only what’s expected from the vendor in terms of performance, but also what’s expected in terms of behavior. 

Too many contracts call for a specific response to a problem, but don’t indicate what the response will be. Saying, “Vendor will respond to a report of a failure within four hours,” admits the possibility the response will be, “Gee, you need to look at your operations process over there.” Instead, say, “Vendor will, within four hours, demonstrate the cause of the problem, and should the vendor have any responsibility for the problem, provide a specific time at which a remedy will be provided.”

In addition, management notification and escalation should be specified. It’s best to require any problem that impacts network users be immediately escalated from vendor technical support to both sales and sales management, and after a given period (usually at the end of the specific remedy period) be escalated up the organizational chain in both service and sales. Get the people who earn commissions on the deal involved quickly!

Monitoring to isolate a problem and establish responsibility is also critical.  Be sure network management systems log any event that can impact services or that’s covered by the contract/SLA. If necessary add monitoring at boundary points (where vendors change, technologies change, or management responsibilities change) and have the conditions that would indicate a violation of the contract specified in terms of the alerts or log conditions that will be considered to have validated it and assigned responsibility for it.

Vendors should forewarn customers about new products

The second vendor don’t-do is failure to regularly meet with the buyer to discuss ongoing problems or inform them of new products or technology options. Large network buyers want weekly meetings, period. Many will accept the possibility that an email exchange or call might be used to defer a regular meeting if there’s nothing to discuss, but most enterprises say that no more than one meeting in a row should be deferred. The meetings should cover any outstanding issues with the vendor, any changes in vendor support of those issues (including scheduled fixes), and any new product/technology announcements that can be expected.

This last point is increasingly important to enterprises. Five years ago, only 13% of enterprises said they didn’t get a heads-up on a pending major announcement and lost planning time and wasted resources as a result. In 2022, that number had increased to 47%, and companies said that they often had no warning of changes that impacted their product plans. That’s a particular problem between roughly October and February when technology planning and budgeting is underway. Regular meetings, according to enterprises, with “what’s coming down the pike” as a specific agenda item, helps considerably.

Vendors should warn of changing support staff

The third item on the don’t-do lists for vendors is don’t change sales or support personnel without providing notice to the enterprise and without offering transition plan. Companies almost always work out a relationship with the vendor personnel who sell and support their network products, and personnel changes can create a major headache. What enterprises want is a transition plan, a period during which the replacement and the original worker appear together and participate in any activities. Enterprises realize that sometimes both notice and opportunity for paralleling original and replacement workers will be limited, and in those cases they want some higher level support during the transition period. This should be spelled out in the contract, too. Finally, there should be some guarantee of special transition assistance should a personnel change occur during a period of critical network operation, such as year-end or the introduction of a technology or product change.

Vendors shouldn’t promise the undeliverable

The final item on the list is “don’t jive me in your sales pitches”. All enterprises (rightfully) believe that vendor salespeople tend to push the boundaries of accuracy in their presentations. Usually these are harmless to buyers who are skeptical about claims to start with, but sometimes they’re material to a sales decision and even to successful network operation. One buyer in eight said that they had at least one incident where a vendor promise during a sales pitch wasn’t kept, and it created a condition that required a specific remedy. The solution enterprises offered was simple: Tell vendors in advance of the sales pitch that when they give it, any promise or claim they make will be accepted by them as a contract term subject to all the protections mentioned above. If they’re not ready to make this commitment, they can’t make the presentation.

Despite the fact that enterprises have such a long don’t-do list, they’re not always at odds with their vendors.  In fact, most of them say that their relationship is good, in no small part because they’ve taken the kind of steps I’ve described to keep everything in line. Do the same, and you may save yourself a sprained shoulder.


Tom Nolle is founder and principal analyst at Andover Intel, a unique consulting and analysis firm that looks at evolving technologies and applications first from the perspective of the buyer and the buyers’ needs. Tom is a programmer, software architect, and manager of large software and network products by background, and he has been providing consulting services and technology analysis for decades. He’s a regular author of articles on networking, software development, and cloud computing, as well as emerging technologies like IoT, AI, and the metaverse.

More from this author