Thursday, February 28, 2013

Winning The RFP Game


How to Increase Your Win Rate and Decrease Your Costs
 
The standard small to mid-range technology company expends over 15% of all customer facing pre-sales time in responding to RFPs. Most of these companies do not have a centralized bid response team, so the workload falls upon the field sales engineers to balance RFP work against what they view as “real and worthwhile” sales activity.
 
A two-year study conducted by a larger software company within one of its areas concluded that they spent €2m per year in direct time and materials to capture €9m in revenue. However, the opportunity cost of the time was €18m (meaning potential sales made if that time had been spent selling instead of responding), leading to a net loss of €11m.

Simple mathematics shows that there are only two ways to improve your RFP win rate. Firstly, by responding to fewer, more qualified, RFPs; and secondly, by increasing the quality of your responses. So how, when leads are rare, when customer relationships are precious and when revenue is everything, do you inject some discipline into the RFP response process yet still maintain the morale of the field sales engineering team?

Respond to Fewer RFP Documents.

Just because you receive an RFP doesn’t mean that you have to respond to it. You could be column fodder or the request may be outside your sweet spot.

1.       Fire your worst customers. Almost every company has customers who send them multiple RFPs every year, yet you derive zero revenue from them. A previous employer of mine had a ‘strategic’ customer who sent us 11 RFPs in a 26-month period – and we won exactly zero. Time for a tough conversation with that customer instead.

2.       Score the RFP. Figure out a way to assign a score to each incoming RFP, corresponding to how likely you are to win it. A sample scorecard can be found here. This isn’t a win percentage, but it gives you a way to compare RFPs and prioritize, and also to correlate your score against eventual outcome.

3.       Set the bar higher. Set up an RFP intake process and ask the account team (sales and presales) to justify why there should be a response. Do not make this complex and bureaucratic – it needs to be just enough to put some skin in the game. I am sure you could look at 25% of the RFPs you completed last year and throw them out because you knew you wouldn’t win. Presales leaders around the world routinely quote me estimates of those 25-33% guaranteed “no-win” responses. I’m not making it up! 

4.       Use the Sales Process. Any sales process is the best friend of the Sales Engineering community as it injects discipline into the opportunity. Agree with your SFA/CRM guru at what point in the cycle an opportunity needs to be at, before you respond to it. Hint: it needs to at least be at the Qualified stage. 

5.       Put in a System. Any system! One company instituted a “three strikes” process to restrict the unlimited resource checkbook attitude of sales. Each manager was allowed three RFP losses in a year. A win reset the count to zero. After three strikes, the account team had to present a full justification up to the Regional VP to obtain the OK to proceed.


Improve the Quality

Once you have decided to respond, take a good look at your finished product. Pass a couple of RFPs to someone in Marketing and Technical Writing and ask for their honest feedback. Then think carefully about roles, responsibilities and execution. You will notice that I do not recommend purchasing an automated RFP response tool – they can save a lot of duplication, but require considerable upfront effort and ongoing maintenance to make them viable.

1.       So exactly who is responsible? My belief is that the account manager is ultimately responsible for the RFP, as she owns the customer relationship. There may be a centralized response team if you are an Oracle or SAP, or the work may fall upon local field sales engineers, or there may a local project manager running the response. Yet ultimately, the salesperson owns the final product and delivery.

2.       Paint the boilerplate. Customers do read the boilerplate about company history, corporate support, headcount, financials etc. Take care over it and have it professionally written, formatted and updated every quarter. Boilerplate should still actively sell your solution and your company.

3.       Build a ‘rigged’ RFP. I am constantly amazed by the number of technology vendors who do not have a pre-written RFP stacked with highly favorable questions they can provide to a customer when asked. Unless you have ever written an RFP yourself, you have no idea how tedious and mind numbing it can be to collect requirements and write the document. Offering someone a short cut, even if they only take a few questions, can help out both sides. Just make sure the questions are reasonable and defendable. Twenty years ago, customers would accept pre-written RFPs, now they just accept a few suggestions. It’s much harder to “write” or “wire” an RFP – but be prepared just in case.

4.       Think about alternate responses. Sometimes you will receive an RFP asking for a solution outside of your sweet spot, yet with a little tweaking and vision, you can suggest an alternative way to accomplish the end goal. Tell the customer that, and write up/document your alternate response. At worst, you will lose anyway; at best, you will disrupt the process and cause them to rethink their strategy. I’ve seen the technical and business agenda reset on multiple occasions using this approach.

5.       The executive summary and the delivery. The executive summary is your shortcut to the recommender and/or decision makers within the customer. Treat that one page the same way you would a meeting with that individual. This is 100%, undeniably the responsibility of the account manager. Even better, ask for a meeting to deliver the RFP and present its highlights as to why your company is uniquely qualified to win the business.


Measure the Results


After expending all this effort and incurring the costs, you should track and measure the results. Over 50% of technology companies surveyed while researching the Mastering Technical Sales book indicated they didn’t track any of this information. So how do you know if you’re any good? More importantly, how do you know if you’re getting better?


1.       Define the win-rate.  Make an early decision on defining your win rate. Some RFPs are cancelled before a contract is awarded, others are postponed etc. Use a simple rule: Win Rate = Number of RFPs awarded / Number of RFP responses. No special cases, exceptions or asterisks.  

2.       Why did we lose (or win)? You will lose some RFPs – it happens. Learn from the experience and ask the customer why you lost so that you can improve the next time. Don’t accept weak and vague answers such as “too expensive” or “not enough functionality”. Drill down into the details – although be warned it is tough for most sales teams to explore a perceived failure.

3.       Publish a league table. Based upon your own business model, publish a league table every month showing wins, losses, responses , costs and revenue by individual rep, sales manager or product line – whichever way makes sense for you. The important fact is publicizing what is working and what is not. 

4.       Track your costs.  Track both the direct and indirect costs for every response. Direct costs are time and materials for the RFP. Include any time spent by marketing, support or engineering in answering questions on your behalf. Indirect costs are the opportunity costs lost by completing the RFP. For example, if you are an SE supporting two reps with a combined quota of $6m, your time is worth $24,000 of quota achievement a day (6,000,000/250).

Summary

Make the RFP response a part of your sales process and apply Solution Selling to it, just as you would any other sales interaction. Throw out your bad customers and your “no-win” RFPs and do not be suckered into “we have to respond just for the sake of the account relationship”. Put into place a RFP intake mechanism if you don’t already have one, and then measure and report on key metrics. Never let RFP stand for Really Fast Paperwork.

Wednesday, February 13, 2013

The Built-In Advantage Of The Sales Engineer



I was listening to a recent Dan Pink lecture as part of the Authors@Wharton series. He said three things that just struck a chord.

  1. The first was that 1 in 9 US workers are in Sales.
  2. The second was that for all workers, on average they spend 41% of their time in a “sales-like” mode (defined as convincing or persuading people to give up something they value for what you can offer).
  3. The third was that the profession of sales has a stigma attached to it – see the nearby word cloud.

OK – so #3 is no big surprise, but the first two were. I’m not sure I know what I thought the numbers would be, only that these stats are larger than I expected.

So what does that have to do with being a Sales Engineer? Well – no question that we are in sales and it is our responsibility to assist the salespeople in “making the sale”. It’s a question of how we go about it. The great thing about being an SE is that you have immediate trust and credibility – at least relative to your sales partner. All else being equal, if you and the rep walk into a room, who is the customer more likely to believe? Exactly! You!!

That trust comes at a steep price in that you can never afford to lie or mislead a customer, or even give the perception of doing so. What is interesting is that very often the questions that may trip you up are not technical in nature (the “do you support iOS 6.1?” type) but are business related.  The trust test is with a question like “will this really work in my environment?” or “will this really save me all the money he says it will?” or the infamous “can you get this up and running in 6 weeks?”.

Your customer will believe you (at least the first time) – so be careful what you say and how you say it. I joke that you know you are an SE when everyone in the room turns to look at you after the rep finishes speaking - but take the test of trust seriously.

Wednesday, January 30, 2013

The Wizard Of The Whiteboard 1


If you are a regular reader of the blog, or my newsletter, you know I am a big fan of Visual Selling and of closing the laptop during a sales call. So far, I’ve had over 6,000 Sales Engineers go through my whiteboard training and I often start with a quick go-up-to-the-board and draw-out-pros-and-cons exercise. One of the top items we discuss is that of credibility.

Why is using a WB related to credibility? It’s because it’s YOUR WHITEBOARD (actually it’s a jointly owned WB if you do it right – but that’s another story). Think about it. The idea goes from your brain straight to your pen and onto the board. It’s not a PowerPoint that some marketing dweeb has created that you are reusing. The degree of personalization and therefore credibility is immense. Just the fact that you can draw out the solution rather than depend on PPT gives you the aura of being a subject matter expert. Since Credibility is one vital factor in building Trust and becoming the Trusted Advisor SalesEngineer, it is an important skill to learn.

Having bad handwriting, no apparent artistic ability, no idea how to get started, or even claiming that you cannot possibly explain something so complicated as your solution on a little sheet of paper (or even an iPad screen) are NOT excuses to put down the pen and give up. My elementary school teacher would be stunned that I make a living teaching people how to draw. I could probably justify my claim that I had the worst handwriting and the least art talent in my class – yet for over 25 years in the presales business, I have readily picked up a pen and drawn “stuff”! When I joined Oracle, as a $80m company, you were required to sketch out the Oracle database architecture on a blackboard or via transparencies. If you couldn’t draw the infrastructure and illustrate it – you couldn’t do your job.

So how do you start? Remember that the best whiteboard of all is one that you plan beforehand, rather than create ad-hoc. You’d never give a demo or a presentation without running through it first, would you? Pick just a couple of PPT slides, a question you are always asked, or even a concept your audience struggles with – and create a 5-8 minute board. Focus more on imagery and icons and less on words – words kill whiteboard time. Have some fun.

(Then sign your company up for one of my classes!)

Monday, January 21, 2013

Better .. And PreSales ...

I can guarantee that whenever I run one of my Business Discovery For Sales Engineers workshops and examine the results of a "why should people buy your stuff?" exercise .. I will see the word BETTER a half-dozen times. The trouble is that hearing "better" doesn't really help you conduct better discovery!

Some examples:

  1. A Business Intelligence / Analytics company promising "better decisions"
  2. A Backup/Recovery company promising "better backup times"
  3. A Security Company promising "better compliance"
Google will give you over 2.8 bllion hits for "better". These range from the Better Business Bureau to Better Homes and Gardens to A Better Recipe for almost anything. Who defines better?

The three basic reasons (The Three Wise Men) why people buy is to increase revenue, reduce costs and mitigate risk. So when you say your product / service / solution makes something better - it tells me nothing (as I wouldn't expect it to make them worse!!). How am I going to be able to make "better decisions" and what will that yield me in revenue/cost or risk. Maybe I can change my product mix in a store on a weekly basis instead of a month - and capture three extra weeks of selling a hot item. Maybe I run a promotion and can tell within a day that the only people using it are my existing customers (so I'm losing money) and that I'm not gaining any news ones - so I stop the discount.

Better doesn't cut it. Any time you read the word better in one of your slides or some marketing collateral - ask yourself specifically how something is made better, and what the client gains as a result. Otherwise you have a soft and fuzzy benefit with no clear ROI. It's incredibly hard to get controllers to spend money based on those criteria. Remember the grandiously named "Care's First Law Of Business Discovery" which states that "Every business issue ultimately can be reduced to a number. That number is either too small and needs to be made larger, or its too large and needs to be reduced." The art of being a great SE is to find out what that number is, which way it needs to go, who cares about it, and how much its worth.

That's a much better way to look at better!
 

Friday, January 4, 2013

2013 New Year Resolutions

One of my New Year Resolutions for 2013 was to blog and tweet more often to both raise my social profile and to share useful content (in my opinion) with others. So here is my first contribution for 2013 - and what better way to start than to lay out some great 2013 Resolutions for the Sales Engineer, The SE Manager, in fact for anyone who deals with the complex technical sale.

Here are a dozen positive resolutions, six things to avoid - all packaged with some wonderful resolution advice from NY Professor of Psychology Peter Gollwitzer. (pdf file)

At this time of year (or next month for those celebrating the Chinese New Year) it's a great time to assess your skills and compare them with last year. What has improved - what has declined, and what haven't you even started on? One of the best things you can do is to publicize your major goals/resolutions to others so that you cannot backslide.

Here are a couple of mine:

1. I am gloing to finish the manuscript for "The Trusted Advisor Sales Engineer"
2. I am going to gain one more major client this year.
3. I am going to blog and tweet more ( more = 100% increase )
4. I am going to revamp my website.

That's enough for now. What are you going to do?
 

Friday, December 21, 2012

The Fallacy Of "Fine!"


 "How did the sales call go?"
“it went fine.”

“How was the demo?”
“It was fine”

“How are we doing on the RFP response?”
“It’s all going fine”

As both a former pre-sales leader and former IT executive, the word “fine” sends shivers down my spine. Fine is supposed to be a term of praise relating to excellent quality as in a fine wine, or a fine-looking horse – however, it seems to becoming one of those indeterminate words that can be either good or bad. For those of you who don’t have English as a primary language I apologize for the nuances of the spoken word, because “fine” is downright dangerous in the profession of Sales Engineering. Let’s take a real life example.

“How was the sales call?” I ask.

It went fine”, replies my SE.

I pause, raise a quizzical eyebrow, and use the power of silence.

After 5 seconds he continues, “Well, they seemed to like what we were saying, although they didn’t ask very many questions and I’m not sure that they 100% got our message.”

So what are the next steps?” I prompt him.

Well, we really don’t have any. They said they did not need any further information at this point while they were figuring out their budget. They’re going to get back with us for a demo date.”

Just so I’m clear, we don’t know any of their business drivers, they really don’t see a fit for our technology solutions, they probably have no budget and there are no next steps that we can drive? That’s your definition of fine?”

Silence

I first learnt this lesson when I was teenager out with my girlfriend. I learnt that when she said everything was “fine” it really wasn’t – and after a while I could judge just how fine she was not by counting the number of “f”’s the word started with and the degree of snarl in her voice.  We are not that extreme in the business world, yet the next time someone tells you that everything is/was/went/will be fine – push back and ask the next question, as there is way more than meets the eye to a fine SE.

Tuesday, November 27, 2012

Why Selling Solutions Is Only Half The Sales Story



As a CIO, the only “Products” I ever bought cost $299 or less and got some user or department off my back by providing them with some helpful utility. More importantly, I never,ever, ever bought a Solution!

Yes. Everything that your marketing and sales enablement teams have been telling you isn’t exactly true. Surprise! Most of those “solution” methodologies miss the mark if you take them purely at face value.

Stunned Silence? So what do IT and Business Unit leaders actually buy from a vendor? There is relationship, security, relief from pain etc. .. but what we really buy are ..   results and outcomes.
In case you think I am playing with words, let me explain.
Many years ago I needed to make my programmers more productive, so we did the usual thing. That was build an RFP with our wish list, and send it out to 4-5 vendors with a really tight deadline for responses. The vendors all whined and complained, the smart ones got on the phone with some of my department heads, and the RFPS were submitted. The next week we paraded the vendors in for their pitches .. five of them .. so that by the end of the week our brains and our behinds were numb. Fortunately I had smart people working for me, they created an Excel score sheet, and voila!! Vendor #1 had a score of 73 points, Vendor #2 had 71, and the rest were in the mid to low sixties. Technically there wasn’t that much to choose between vendor #1 and #2, although #1 had a few more features and functions.
I had to make a decision – and chose Vendor #2, despite the lower score. Why? Two reasons – firstly I felt they had done a much better job of discovery, and secondly they didn’t try to sell me a solution that made my programmers 39.2% more productive. The sales team was smart and sold me an outcome. The back story is that my company was coming out with a new product, and that IT was on the critical path as we couldn’t reprogram our internal systems fast enough to support the launch. We would delay by a month, and that would cost us $8,000,000. I was also tired of going to executive meetings about the project and having the finger of shame pointed at me. Enough! So the outcome the sales team from Vendor #2 sold me was that of accelerating development by 5 weeks so that we could launch in time and gain an additional $8m in revenue, PLUS .. my IT department was no longer holding things up and my political risk disappeared in the executive suite. Sweet indeed.
The solution was software and processes that would make my programming staff more productive (as I’d said I want them to be more productive). But the result was those magical five weeks and some major political clout.

A more mundane example is this .. an aspirin is the solution to a headache (a literal pain!), yet what I am really buying is relief from pain – the outcome is a clear head. Don't sell aspirin (and especially don't talk about dosage levels, uptake values and side effects to a man with a bad headache).
So what do you sell – products, solutions, or results and outcomes?