从陪标到单一来源：售前的价值不是传说

This is a presales story from my own experience. The opportunity started with us being asked to "bid as a formality" (陪标), but after one face-to-face meeting and one workshop, we completely turned the situation around—ultimately winning the project as a "single-source" deal. There's not a drop of exaggeration in this story. If you don't believe me, you can ask around in the IBM alumni groups—you'll find the account manager, the services sales rep, and the Northern China services sales director who worked on this project back then.

I've been involved in many opportunities where more than half ended in failure, and I've also won plenty. But this project stands out as one of the most dramatic experiences of my career. I'm sharing it now because I want more salespeople, sales directors, and company executives to understand: the potential value of presales is far greater than you can imagine. Your presales team deserves your investment, your development, and your trust. Don't get lost in the illusion that sales is all about relationships and kickbacks—that's a drug that will addict you. Why not try a different approach?

#The Value of Presales Is No Myth

Follow the "PresalesChina Community" (售前青云荟) video channel to watch the story video "From Formality Bid to Single Source":

Here's the full story:

Excerpted from the PresalesChina Community course "The Professional Presales Playbook: From Beginner to Master," Lesson 14: Developing Internal Champions and Sponsors within the Customer Organization.

...Let me tell you a story from my own experience about developing key stakeholders in a project. Many years ago, I worked at a large multinational company as a presales engineer for a product line in the services division.

One day, an account manager came to us and said, "I have a client who just issued an RFP for your product line. I have a great relationship with the client's leadership. You need to prepare your bid right away!" My services sales colleague and I immediately refused. Why would we bother? The RFP was already out, and we were only finding out about it now. There was no way we could win. It was almost certainly a case of the client—or our own account manager—dragging us in as a free "formality bidder" (陪标). This kind of thing happened all the time back then. We weren't stupid, and we weren't on the account manager's payroll, so why should we work for free?

But this account manager wouldn't take no for an answer. She insisted we participate, saying she had already promised her boss that she would win this deal. At the time, I had just closed a few big wins myself, so I was feeling pretty confident and stubborn. I still refused.

The dispute escalated to her boss. I laid out my case: First, we only found out about this opportunity when the RFP was already issued—there's no precedent for winning a deal under these circumstances. Second, the RFP content is almost entirely written around our competitor's strengths, which clearly means they've already done their homework. Third, many of the requirements in the RFP would cost us at least 10 times the client's budget to actually deliver. Her boss finally said, "Alright, go visit the client and explain why we can't participate. If they understand, then we're done with it."

I was young and cocky back then—who's afraid of who? Fine, I'll go. I wasn't about to let them push me around for free! But how was I supposed to convince the client? I couldn't use those three reasons directly. If I said we hadn't communicated with them before and therefore couldn't win, they'd just say, "As long as your solution and price are competitive, we'll pick the best." If I said the RFP was written by our competitor, they'd never admit that either.

So I decided to pick a technical, easily quantifiable issue. For example, the RFP required the system to achieve 99.99% availability—what we call "four nines." Let me explain: availability is the percentage of time a system is operational. 99.99% means the system can't be down for more than about one hour per year. Even by today's standards, that's extremely demanding. The best cloud service providers only guarantee three nines for a single server. So this requirement is exceptionally high. If a legitimate company like ours were to bid and commit to meeting it, the cost would be enormous.

When I arrived at the client's office, the account manager had brought in the client's project manager. I told him, "We can't participate in this project because there are requirements we simply can't meet." The project manager looked at me with confusion and said, "We discussed the RFP with other vendors, and they all said it was no problem." See that? In the very first sentence, he revealed the truth. I glanced at the account manager, thinking, "There's no more room for you to spin this." I then zeroed in on the four-nines requirement and said, "Just this one requirement alone could blow your entire budget. Your data center power supply and servers almost certainly can't meet this standard either. Theoretically, there isn't a data center in China that can deliver this level of availability. Even if you only measure the availability of this single system, you'd need to buy at least two software licenses. Have you considered any of this?"

The project manager looked a bit shaken and said, "No one told us it was this complicated!" Then he asked, "Besides this, what else can't you do?" I could understand his reaction. In this industry, if my company said we couldn't do something, it was a safe bet that no one else could either. And to discover such an obvious problem after the RFP had already been issued was no small matter in any company's procurement process.

I said, "There are many things in the RFP that need detailed discussion. But here's one thing: I've worked on many similar projects, and I've never seen a company try to implement this many modules all at once. Getting the system up and running is easy—but successful rollout and real-world adoption? That's going to be very difficult." I wasn't trying to scare him; honestly, I just wanted to wrap this up and get out of there.

The project manager pressed on: "So what do you suggest?" I patiently gave him a few recommendations. I could see a different light in his eyes. Then our account manager chimed in, "This is our company's expert in this field. If he says it can't be done, then it really can't be done." See that? Even our own account manager was trying to back out now.

The project manager quickly said, "Everything you've just explained—no other vendor has ever mentioned any of this to us. I think you make a lot of sense. Would you be willing to come give us a training session on what we should watch out for on this project? I'd like to invite our leadership to attend."

At that moment, my mindset shifted. Why? Because the client's technical team was starting to rethink their requirements—which meant there might be an opportunity for us. I asked, "Who from your leadership would attend?" He replied, "At least our general manager in charge of technology. Let me go report this and get approval." I figured that level would be the Economic Buyer (EB). So I said, "If leadership at that level will be there, then I'd be happy to present."

As we walked out of the client's office, I told our account manager, "I think we should give this opportunity a shot." She was completely baffled: "First you refuse to participate, and now you want in?"

A week later, I was invited back to give a presentation. Since senior leadership would be in the room, I chose the topic: "Typical Causes of Failure in XX Projects and the Path to Success." When I arrived, the room was packed—I was told even the head of HR came. I walked through several examples of similar projects that had failed in the industry and analyzed why, then concluded: this is fundamentally a management project, not just a technical system implementation. Therefore, leadership needs to do X, Y, and Z, and the project should be phased in several steps, etc.

After the session, the client's GM of technology invited us into his office and asked, "If we were to hand this project to you, how would you approach it? Who would you staff? Could you serve as the project manager?"