Most IT professionals hate doing telecom RFPs. No surprise — much of the effort is process and paperwork, two things that many find tedious and boring.

But there are compensations. One is the sheer entertainment factor of the "dog and pony show" as carrier salespeople and sales engineers present their responses to the RFP and field questions. Carriers often invest a lot of time and energy in these presentations, typically bringing a half-dozen employees in to extol the wonders of their company and the virtues of their network. That's if everything goes well.

Related story: Writing a winning telecom RFP

If it doesn't, participants are treated to the spectacle of extremely smart people making fools of themselves. Over the years I've collected a few stories to share, with one caveat: Because no carrier has a monopoly on goof-balls, I'm not going to name names.

First off, as a group, carrier salespeople seem incapable of following instructions. Screw-ups in proposal format and content are routine (I advise clients to toss out responses that aren't correct after two tries, because the carrier obviously isn't paying attention). But that's kid stuff. Sometimes the carriers can pull off stunts that are, quite simply, jaw-dropping.

My all-time favorite was the salesperson from a major wireless provider who couldn't figure out how to power on and open up her laptop (the client had to do it for her). For some strange reason, this failed to convince us of the carrier's technical expertise: They didn't win the bid.

Another favorite: When we asked a carrier salesperson to document in writing the terms and conditions we agreed to, he refused. When pressed, he got testy. Finally he said, "You must have talked to a lot of lying salespeople." My reply: "Yep. And most of them worked for your company." (The carrier ultimately got the deal, but only after its lawyers and those of the clients spent an extra six weeks hashing out the terms and conditions —and ensuring we got them in writing.)

My favorite recent blooper: A client was looking to migrate to MPLS in order to support a planned VoIP migration. among other things. The goal was to ensure that VoIP traffic could benefit from MPLS's class-of-service capabilities. Internet access was also a requirement.