Would better proposal software have saved the Death Star? (How to write a killer proposal)

A lot of small business owners are much better at “doing what they do” than selling. I’ll count myself among them. But all is not lost. For many of us in the business-to-business world, the better you get at selling, the less it feels like selling, and the more it feels like collaborative problem solving. After you get used to talking to prospects and customers about their problems, devising solutions, and getting psyched to start, comes the dreaded moment when the customer asks “can you send me a proposal?” Why is this a moment of dread, and what does this have to do with the Death Star?

Of course, you say “yes”, and then you spend hours, maybe even days, and occasionally weeks putting together a tedious document that has none of the vibrancy of your original conversations. You try to figure out exactly what to sell them, and how much it should cost, often by pointing a finger into the wind coming from your spreadsheet application. (See the Pricing Battle Plan for Services post for more thoughts on how to prepare for this part of the process.) Then you gather a collection of Word documents representing past proposals (or, gasp!, your’re writing your first one), and start copying and pasting. Then you start finding and replacing, to remove references to the last customer, and update the names to reflect the current deal. You realize you don’t have all the information you need, so you call the customer back, and then wait a couple of days for responses. This lack of information is one of the main causes of dread– you don’t know what really need to do, so when you try to put a plan on paper or on screen, you realize you don’t really have a plan. When you are finally ready to send the proposal, you print it to PDF, or perhaps just send the raw Word document over to the customer in an email. Then you try to schedule a time to chat. At this point, you don’t even know if the customer has read your proposal. Eventually, you connect, the customer has some questions or objections (you deftly handle price objections without giving things away, because you have a Pricing Battle Plan, right?), and you go through another iteration. Two weeks later, you finally close the deal. Let’s be optimistic, right? Sometimes you go through all this effort for nothing.

Is there a better way?

You can tell by the fact that there’s a bunch of text below this question that there is. It’s a long post, but if you’re like me, it pales in comparison to the time spend on proposals. I think you’ll get a good return on your time.

So let’s talk about how to write a killer proposal. We’ll divide this into two parts.

1. Having the right conversations with the right people so you get the information you need to really solve the customer’s problem.
2. Handling the proposal itself– creating, sending, and winning.

First, you need to have the right conversations with the right people. In some cases, you can get lucky, and you only have to convince one decision maker, who has already called you, eager to discuss her problem. Let’s start with the simplest case, right? First, let the customer describe her problem, in her words, on her terms. Resist the urge to jump in and start solving the problem in the middle of the conversation. Resist the urge to ask leading questions. This will put the customer on the defensive and prevent you from uncovering the very information you need to win the business. Instead, ask open-ended questions, starting with very high level issues like

• What is the impact of problem X? (If they can’t talk about the problem is business terms, you may need to talk to someone else. In this case, since we are talking to the business owner, we will assume they have a reasonable handle on the impact, which is why they are calling you. When talking to a large company, the person calling you, who may actually have budget and approval for the project, may not know what the real business drivers are, so even if you solve the stated problem, your proposal can get shot down higher up the chain of command.)
• How have you tried to solve this problem previously?
• Why is this problem important right now?
• How does this problem’s priority compare to other personal and company priorities?
• What would you like to see in a solution?
• How will you measure the success of the project?
• What would you like to preserve about the current process?
• If you could change one thing with a magic wand, what would it be?
• And so on and so forth.

If you have never taken a sales training course, or perhaps more importantly, if you have, check out Barry Rhein’s website, SellingThroughCuriosity, and take his online sales challenge. It only takes a few minutes, and it will help a lot with these kinds of conversations. Even better, sign up for one of his 2 days sales courses. This is the guy who trains the Salesforce.com sales team, after all.

These open-ended questions help the customer describe their problem to you in their terms. You’ll need to understand and use these terms to win the business and successfully complete the project. Don’t forget to ask about how they make their decisions and allocate their budget. However, instead of asking things like “have you allocated budget?” and “when are you making a decision?”, use the open-ended method:

• How will you and your team make a decision about whether to move forward on this project? This may get you all the information you need, but often you’ll need to probe a bit more to really understand what happens, so you can follow-up with questions like:
• How have you made decisions like this in the past?
• What other reviews do we need to do to make sure your team is on board? (Even though we think we are talking to the sole decision maker, they may have a right hand man, who always signs off on important projects, or a lawyer who reviews contracts, etc.)
• How do you see us working together?
• If you haven’t got any inkling of budget yet, you can ask things like, “how does budget get allocated for these types of projects?”, or “what are your high-level expectations of commitment of both time and money from your team?”

Take careful notes, because as much as the whole thing seems very memorable when you’re having the conversation, it will seem a lot muddier when you’re back at the office, or even trying to remember a conversation from last week.

When you have multiple stakeholders, things get more complicated, but you can take the same general approach. You just have to make sure that your open-ended questions provide the names of all the stakeholders, and you’ll need to have these conversations with all of them. It takes work, but it will actually be fun.

Once you have the high-level landscape, you can drill into lower-level questions, using the same general approach. (“What is the impact of having an onsite database behind your firewall instead of a cloud-based datastore?” Never assume that you know their answer, just because you know an answer.)

As you go, confirm what you think you have learned. (“So the single most important issue with the onsite database is peak load capacity?” “Oh, OK, that’s a problem but you can work around it, the real issue is that our team in Asia has to connect over a really slow VPN.”)

When you have confirmed the problem and decision making process, you can talk a bit about the solution and benefits. Resist the temptation to talk about the solution too much. Focus on the benefits, while confirming things that are critical to the project (“how can we get your database administrator to help with this project if he thinks his job is going away?”).

Part of the solution is the price. You don’t need to quote down the penny at this point, but you should be able to give a range, with a set of high-level assumptions that determine which part of the range applies. (“If your database administrator can handle the data export for us, that would save a lot of time and money.”) Even though you aren’t quoting an exact price, be confident in how you discuss price. You should already know the value from your earlier discussions of the problem. If the value is lower than you expected and makes your price seem unrealistic, you can discuss your typical pricing and then discuss ways to save money by reducing the work you have to do (not simply by discounting for nothing!). Note that if you feel the customer is missing part of the value equation, dig deeper when discussing the problem. Perhaps they don’t perceive some pain points that your other customers do. This is a great thing to understand, especially if it helps you keep the budget competitive while pushing the other issues to a potential future project. If the value is much higher than you expected, make sure you consider ways to help the customer reduce risk, even at a higher price. After all, a project with a $1M payoff can neither afford nor justify the same level of risk mitigation as a project worth $100M in benefits.

Now you have a recapitulated the problem, the basic solution, the approximate costs, and how you’re going to work together. Make sure you ask “what else should I consider?” There’s a temptation in sales, especially for business owners (especially, especially for technology-focused owners) to want to leave before you here more objections. You’ll often be able to deal with objections easily at this stage that could kill the deal later. It’s much better to get things on the table when you can deal with them, than have issues blind-side you after you’ve spent a lot of time writing your proposal. So you have just gone over an informal “proposal” with the customer. They have nothing else for you to consider, and they say “can you send me a proposal?”

You can just say “OK”, right? Not just yet. You can tell them that you think you have a good feel for the problem and solution, but you want to make sure you’ve captured the essence of the conversation in the proposal. In case you haven’t got good answers yet about how they’ll make this decision, how the proposal will be used, what are the concerns of the people who will see the proposal, how would they like the proposal laid out, etc, ask now. The important thing is that the proposal will have no surprises. It summarizes and clarifies the discussion, but adds nothing new. If you get back to the office and discover you want to add something new, call the customer and discuss it first, don’t just stick it in the proposal and throw it over the wall.

Now you can actually go back to your office and you already have the proposal, just not in quite the right form.

This leads us to part 2, on creating, sending, and winning.

Organize your notes and thoughts. If the company has requested a specific format or flow, make sure you follow that. No surprises, right? If you’re using an app like Mimiran, you’ll have a standard template (or perhaps several) that will help you organize your proposal and drop in information quickly, while still individualized to the particular needs of the decision maker. My standard template has these sections:

• Situation Summary. Make sure everyone knows exactly what is at stake, in business terms, and why the customer needs your offering.
• Solution and Timeline. What are you going to do? When are you going to deliver? What does the customer have to do along the way?
• Pricing. What does this cost, and when are payments required.
• Terms and Conditions. A relatively short boilerplate specifying terms and limiting liability.
• Acceptance. A brief section at the end that indicates what they need to do to kick off the project, especially if payment is required upfront. (Always ask for at least some upfront payment.)

(There’s a link to a sample proposal at the end of this post, to give you an idea.)

Keep it short. You are dealing with busy people. Provide the information that you need, but no more. This is not high school english class, where you are trying to fill up 10 pages. Shorter is better. You can always include links to other materials– product brochures, training videos, videos of speeches or talks, case studies, and more.

Use the customer’s terminology whenever possible. If they call a “product” an “offering”, or vica versa, use their language. Even if your language is the industry standard. Unless the project is to teach the customer industry standard terms. Remove jargon that isn’t specifically used by the customer. The simpler the language that accurately conveys your meaning, the better and more authoritative your proposal sounds. The more you fill it up with MBA-speak, the less it seems like you know what you’re doing. (Note there may be some audiences that want MBA speak. Try to avoid them.)

While you are using the customer’s terminology, resist the urge to make the proposal about you, your company, and your products. Keep focused on their company, their problem, and their benefits. You, your company, and your products are supporting actors, they are the leads. It’s not about you, it’s about them.

Instead of typing up a Word document, log into Mimiran (free trial link) and create a new proposal based on your favorite template. Fill in the appropriate sections, for example, the Current Situation and Solution. When you add your offering(s), Mimiran will compute a price based on your rules. No second-guessing. Be confident in your pricing. If the customer wants a discount, they can earn it by ordering more, paying earlier, or making a longer commitment. They can’t get a discount simply by asking for it. If you quote beyond their budget, find a way to remove value from the proposal, along with reducing the price. You can’t get a Ferrari for the price of a Kia. You shouldn’t be selling Ferrari’s for the price of a Kia, but many small business owners do just that. You can also set up configuration rules in Mimiran to help guide your selling. For example, many services businesses want to offer retainers or follow up services, but have trouble actually doing that. So you can setup a rule to recommend doing that as part of the sales process. You can even require certain products be sold together, like software with setup, or coding services with project management. These are business rules that in theory you are always following, but sometimes need a gentle reminder to actually execute.

If applicable, add images that clarify the language of the proposal, both for the problem and the solution. These days, you can even snap a picture of a whiteboarding session (with the customer’s permission, of course) and add it to your proposal. If you need video to illustrate a concept or process, embed some video. Rich media are especially helpful if the proposal will be reviewed by people who may not have been part of all the discussions and don’t have intimate knowledge of the proposed solution.

If you were creating a Word document, at this point you would print it to a PDF file and send it as an attachment to the customer (or just send the Word document). Since we’re doing this online, though, we can just click the “Send” button. The customer will get a nice email telling them you want to share a proposal with them. You have told them to expect this email. They can click on the link and start going over the proposal. Best of all, you get a notification email when they open your proposal. No more wondering if they’ve read it. You also get a notification if they comment on the proposal. You can also see how long they spend looking at each section of the proposal. Now you can call them when they are looking at your proposal, which greatly reduces time to close. I’ve done this, fielded questions on the proposal, made edits, and got customer acceptance during the call. So much better than spending a week trying to get on each others’ calendar, then having to go back and repeat the process when the customer has questions.

What does this have to do with the Death Star, a colossal investment destroyed because no one bother to put screens over the exhaust port leading to the main reactor? Here’s a humorous example of how online proposal software can create a simple proposal that could have saved the Death Star.

Here are a few comments on the proposal:

• Note the strong problem introduction. There’s a bold graphic at the beginning, and detailed descriptions of the business value of the solution.
• The company’s logo is the main graphic element in the prime upper left corner.
• The solution includes the customer’s obligations and assumptions about how to keep the project on schedule and budget. This should be something you have already discussed with the customer (no surprises), but it’s important to document, not just to CYA, but also to make sure people involved with the project know what their commitments are.
• Pricing, product information, and customer/contact names are pulled automatically from merge fields, inserted with the proposal editor.
• You can introduce project personnel with a picture– faces mean more than words (hopefully you have a better picture and better personnel, but this is humor) and provide company background.
• Comments are captured with the proposal, along with the history of when the customer viewed each section.

With the right tools, you can spend less time creating proposals and trying to close deals, and more time actually solving customer’s problems. And since you’re not guessing about pricing and discounting excessively, you can make more money doing it.