Ever had a phone call from a ‘prospect’ that ask for a quotation for your services but yet refused to spend 30 minutes of their time to meet up and clarify their business objectives?
How about the ‘prospect’ who are not clear about their requirements, budget and timeline?
Selling Power has a pretty good guide on some of the common mistakes that we should avoid while working on our proposals.
I am quoting it here for easy reference (source: Selling Power).
- The customer doesn’t know you or your software. Just because you submitted a proposal doesn’t mean you’ll actually be considered as a serious vendor. If you haven’t worked with the decision makers and stakeholders to make sure they know you and understand your approach, winning with just a proposal is about as likely as winning the lottery.
- The proposal doesn’t follow the specified format. Sure, the format’s arbitrary and maybe even a little silly, but if you don’t follow the format that the customer requested, he or she will figure that you can’t follow a software specification either. So make sure that you do the extra work to adapt to the most specific requests.
- The executive summary doesn’t address customer needs. Your software might be the greatest thing since C++ was invented, but if the bigwigs can’t figure out – within the first two paragraphs – what’s in it for them and their firm, your proposal is going to take a one-way trip to the circular filing cabinet.
- The proposal is filled with your own programmers’ jargon. Hard to believe, but the lingo that your programmers use may not mean all that much to the programmers in the customer’s IT group – if the customer has an IT group, that is. If not, then your programmer jargon is going to read like ancient Greek. Lose it…or lose the deal.
- The boilerplate material contains another customer’s name. Short on time? Cut and paste your way to an instant proposal! Ah, the wonders of word processing. Only one thing wrong: That boilerplate might need a bit of editing. Worst case, it might actually have the name of a competitor in it, as when Digital handed a pitch to Coca-Cola that read “Pepsi” as the customer name. Ouch.
- The writing reads like a software manual. Let’s face it: Software is dull. What it can do for a company or a business model, though, can be quite dramatic. Don’t let your proposal get as flat and technical as the latest programming manual. Write about your product and firm with the kind of passion that will help motivate the customer to buy.
- The proposal doesn’t contain an implementation plan. It’s a truism in the software-sales world: “Don’t confuse selling with installing.” Even so, if your proposal doesn’t contain some inkling of how the application will be installed, piloted, tested, and measured, you’ll be limited to selling to idiots, because only an idiot would buy software under those conditions. (Note: There are many idiots in the software-buying world, but this prospect might not be one of them!)
- The proposal contains spelling and grammatical errors. It’s easy to pretend that running a spell check is going to solve all your problems; however, spell checkers can’t find correctly spelled words located in the wrong place, and they can’t detect when a word is being used incorrectly. To the customers, your proposal is a signpost for whether your firm is meticulous and capable of creating something bug free. Best make sure the proposal doesn’t convince them otherwise.
- The software doesn’t address the key decision criteria. Even if your proposal addresses customer needs, it must still satisfy whatever decision-making criteria the buying process includes. For example, if the software MUST be installed by a certain date, your proposal better state that will take place as scheduled.
- The proposal doesn’t define an agreed-upon ROI. It’s not good enough anymore just to have an ROI. Your software project must have an ROI that makes sense to the financial powers-that-be at the prospect’s firm. That means spending some time with the CFO, or at least the accounting group, to make sure your ROI calculations will pass muster.
Top on my list is point 3 – “The executive summary doesn’t address customer needs.”
I am in the business of solving a business needs. Often, it is tie to their business process.
Having review my wins, I can clearly see that my best customers are the ones that I have shown a clear understanding of their business needs.