Salesforce.com Secrets of Success: Best Practices for Growth and Profitability
Chapter 1, Planning Ahead
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
This chapter excerpt outlines steps for building a Salesforce.com CRM business case. Estimating costs is a big part of this process. Learn about the three main cost areas: procurement, implementation and ongoing user expenses and get tips for managing these expenses.
Planning Ahead, Chapter 1
Table of contents:
Beginning a Salesforce.com CRM or SFA project
Managing CRM project requirements
Creating a Salesforce.com CRM business case
Developing a CRM implementation schedule
Creating a Salesforce.com CRM business case
Making the Business Case
Most companies will require a formal business case for an investment in SFDC. Even if yours doesn't have a formal review meeting for the decision, it's a good idea to go through the exercise of cost, benefit, and ROI analysis so that the team understands the financial implications of what they are doing. Understanding the things that really make a big financial difference—and the things that really don't—helps everyone make better decisions throughout the life of the project.
When evaluating Software as a Service (SaaS) systems such as Salesforce.com, it is tempting to think that cost analysis isn't critical. After all, it's just a monthly fee and you pay only as long as you're receiving value . . . right? That's what the salesperson wants you to think, if only to make you stop thinking. Life isn't that simple.
The big three cost areas are procurement, implementation, and ongoing user expenses. Procurement costs for SFDC, like most SaaS products, consist of a monthly fee. The fee varies based on the following factors:
- The number of users (internal "full feature" users, platform users, partner users, and customer users)
- The version you buy (most readers of this book will purchase Enterprise edition, but many will also want the Mobile edition, the Sandbox, or other extra-cost items)
- The length of the contractual commitment (one year is the minimum; more than three years seems to make little difference to the discount)
- Your willingness to prepay (prepaying one year makes a difference, but longer prepays seem to make less of a difference)
Who Should Pay?
The best decisions will happen when the departments that benefit the most pay the most for the system. This typically means sales should pay at least 50% of the total, with marketing and support sharing the remainder of the cost. Of course, this split depends entirely on your company's organizational structure and system usage.
Another funding formula is to have the project be financially sponsored by the executive suite—at the corporate or business unit level, which shows executives' level of commitment.
The only funding model that doesn't work is to have central IT foot the bill. While this works with infrastructure, in SaaS applications—and particularly those that directly benefit only a part of the company—this model doesn't work in either the short run or the long run. Check out Chapter 6 for more on this topic.
Because you're gong to be delivering the system in phases, make sure to activate only the number of seats you'll actually use at any one time. In the negotiations for a large deal, this aspect of incremental deployment may save your company a significant sum.
Include add-on products in your procurement cost estimates, thinking through phasing effects that will affect the number of users and timing of activation for each product separately. Most add-on products for SFDC are also SaaS, but a few are on-premises products with hardware requirements and perpetual licenses. For those products, don't forget to include the cost of hardware procurement.
Do not neglect support fees. The basic support level that's included in SaaS products will be insufficient for at least your first year. You'll need speed of access to in-depth expertise that is available only through premium support. Premium support is really good, but pretty expensive: make sure to negotiate for premium support only for the number of users you actually expect to have during the initial deployment phases. Your team members (particularly developers and system administrators) will also need technical training classes (typically $2500 each) to become rapidly productive. Do not negotiate for these items piecemeal if you want the best discount.
If your company will have more than 100 users, the annual fees for SaaS can be a surprise. While it's true that you aren't paying for upgrades, patches, hardware, and operating staff, SaaS fees can easily exceed $100,000 per year, and the amount climbs to more than $1 million per year for the very largest deployments. Don't assume that you'll have a lot of bargaining power once the deal is signed: the only way you can get a better discount is to buy even more or to commit for an even longer period. Downgrades are not allowed. The vendor knows you don't have a credible threat of changing the system, as the real cost of a changeover can be quite large even with the flexibility provided by SaaS's Web services technology. As your users grow accustomed to features and your developers become experts at using SFDC's APIs, you will be just as locked in to the vendor's technology as you would be with any Microsoft product.
To get a significant discount on the procurement, you'll need to get a budgetary allocation for the multi-year commitment. Work with your Finance department to develop the business case, making sure those personnel understand that the number of users will go up over time even if the per-seat price is stable.
In contrast to "procurement costs," implementation costs for SFDC and other SaaS products are one-time fees. You will almost certainly need consulting and other services required to convert legacy data, integrate with other systems, write custom APEX and Visualforce software, test the system, deploy it, and train users. Do not assume that your internal IT people are interested in SaaS projects or that they have the required skills and experience (but check out Chapter 13 anyway). Some of the implementation costs are easy to identify and are "fixed fee" in nature (e.g., training classes). Most of the big elements of implementation, however, are highly customized and can be brought to a fixed-price bid only after significant analysis by your vendor. Of course, every Finance department will want a fixed price, but there is significant gamesmanship in the bidding process. It is very easy to get caught up in the engineering change order (ECO) trap, where "fixed price" contracts create an avalanche of over-runs.
When the Price Isn't Right
At the beginning of a project, all you can see is price. At the end of the project, all you'll remember is the value of benefits, the quality of the work (or lack of it), the pain (or lack of it), and the over-runs (large or small). It's easy to be "penny wise and pound foolish." It is far more important to choose a vendor that you can trust, rather than one that bids low. You need to see proven experience, skills in project management, actionable communication, and references from other customers.
One of the advantages of the phased deployments we recommend in this book is that the vendors can give you a more accurate bid for the immediate phase (which will be very tightly defined) than they can for the project overall (which may suffer from scope creep and extensions). Best practices are to use hourly rates with a tightly managed cap rather than fixed-price engagements because this practice (1) exposes the scope creep that hurts overall chances of project success, (2) avoids the bickering, administrivia, and gamesmanship of fixed-price "change orders," and (3) prevents vendors from hiding large margins in their bid.
Explore your consultant's willingness to work using performance incentives. If they are designed properly, these types of contracts can yield the best possible deal for you because your goals and metrics are tightly aligned with the consultant's. As wondrous as pay-for-performance contracts are, they're equally rare. But give it a shot.
The first step in quantifying the implementation costs is drawing up the statement of work and development/integration requirements for each of the projects. The more homework you can do yourself, the more accurate the vendors' bids will be. Some of the project areas will require analysis that you can't do, and the bidding vendors will have to analyze this themselves. The vendors are unlikely to do enough "drill-down" analysis for free, but there's good news: this scoping project will be short and should be fixed-price. This is money well spent before you make a large commitment. Some vendors will do this scoping project only after you have signed on with them for the main project. My own experience with this kind of vendor is not good, but don't treat that issue as a show-stopper. If the vendor is very well qualified and you trust the consultant, proceed.
Note that the cost of implementation talent for serious SaaS projects isn't that much different from the corresponding costs of conventional on-premises software packages. Skills and deep experience in SaaS implementations are fairly rare (particularly outside the United States), and fees can be $300/hour or more for the best people. Many customers have experienced overall implementation costs that exceed the software fees they pay to their SaaS vendors in the first year. Although this amount is significantly fewer dollars than customers paid for classic enterprise software (where implementation was typically projected to be 1.5 or more times the cost of the software licenses), it may still come as an unpleasant surprise if proper allocation for it has not been arranged.
Do your cost estimates only for the initial implementation, but know that the happier your users are, the more likely they will be to ask management for further system enhancements. It is not uncommon for companies to have multiyear engagements before they reach the management nirvana of the 360-degree view of the customer.
Don't forget the costs of your internal people. It's not unusual to have five people be involved on a full-time basis in an SFDC implementation (even with consultants), with another five involved intermittently. Even though these people's salaries are already budgeted for, the effort they put into SFDC will be time that won't be available for other company priorities.
After estimating total first-year costs—first-year fees, add-on procurements, and implementation expenses—the ongoing costs for SaaS basically consist of the annual subscription fees. There may be some one-time costs in the out-years (such as a data recovery exercise or temporary use of SFDC's Sandbox), so put a placeholder in those budgets. The more interesting ongoing costs are related to people: follow-on implementation or expansion work, training costs for new users or administrators, travel and fees for power users attending technical conferences (a good investment), and time for any consultants working on the system.
As with any large system, data pollution is an inevitability and is poisonous to the system's credibility. Business analysts and others will discover corrupted or duplicate data creeping into the system over time. Whether it's a temporary coder, a data-entry clerk, or overtime hours of internal people, some corner of the budget should be set aside for a health check and cleanup session at least once a year. You'll almost certainly want a deduping or data cleansing tool, which will cost at least $3,000 per year, which is money well spent (see Chapter 7 for discussion of this). Furthermore, identifying the source of the problem, rectifying it, and cleaning up the data are often tasks carried out in collaboration with contractors.
These ongoing costs are likely to be most pronounced in year two of the system, but some budget should be set aside every year after the initial deployment.
Quantifying the Return
Any project this size has to be justified with improvements to the bottom line. The two components of achieving this goal—lowering costs and increasing revenues—are hard to quantify. But they can at least be modeled to provide a credible SWAG.
To counterbalance all of the costs outlined previously, it's important to identify areas of cost saving. Because SFDC is a salesforce automation system, you'd expect to find some. But that's rarely the way it works—after all, many of the expense areas are sunk costs that cannot be recovered or labor that is taken for granted. You may have to be a good detective to ferret out the labor savings.
The first obvious place to look is cost avoidance for the system SFDC is replacing. It won't be much, but at least it can be immediately quantified. Next, look at ancillary systems that can be decommissioned because SFDC makes them less relevant. For example, you may have a large number of spreadsheets for the marketing group with macros that won't need to be maintained or extended any more.
The next place to look is wasted labor. Whether the waste takes the form of contractors or employees, the hourly rate should be quantified. The first waste-avoidance item will be system administration and maintenance for software and hardware that can be retired. This will probably amount to at least 32 hours per month; for large systems, it can be much more. Another source of wasted labor is sales administrators who—even in small companies—may spend 8 or more hours per week preparing the weekly forecast, and order operations people who spend 20 hours or more in order entry, correction, and reconciliation. Some business analysts also have to spend huge chunks of time trying to piece together spreadsheets from fragments of customer data. In addition, order fulfillment people (license generation, shipping, distribution, and expediting) may spend their entire day doing things that could be 80% automated. Finally, customer support people can easily waste 10 minutes per call trying to find data, correct erroneous entries, or fix problems that could have been avoided by automation. These areas of direct waste add up, as they occur every week and may become much larger in the closing weeks of the quarter. Even though employees' time is a "sunk cost," quantify the savings as if those workers were paid by the hour.
The larger cost savings are more difficult to quantify because they involve missed opportunities or avoidance of wrong decisions. What would it mean if the cost of customer acquisition were 5% lower? How would it lower costs if the sales cycle were a week shorter? What would be the impact of reducing sales representative turnover by just one rep per year? What percentage of marketing dollars is spent on marketing to the wrong people or participating in the wrong events? How much could be saved if you could quantify which marketing activities really produced revenue, rather than just "visibility"? How much travel expense and labor could be saved by avoiding just one unproductive tradeshow, sales call, or proof-of-concept project? If you knew more about which prospects were (or weren't) going to yield the most profit, which other improvements could your company make?
Focus on quantifying external waste that could be reduced, rather than on internal jobs that could be eliminated, as the latter will bring the project nothing but political strife. You'll need to interview people in sales, marketing, and pre-sales support to make this determination. Nevertheless, as you develop an effective model for estimating the cost savings, the amount saved can turn into big money.
There is also value to the risk reduction that SFDC will bring. Hits to customer reputation, knocks to brand value, and even Wall Street embarrassment all cost the company money—and all can be improved by a really solid SFA system. Avoiding just one unreliable forecast or a few irate customers can save enough to pay for the whole of SFDC. The problem, of course, is quantifying this value.
Watch out for finance groups that try to use your estimates as a justification for cutting the budget of other departments. They may say, "Well, if you do such a great job detecting unproductive marketing activities, we'll just cut their budget by 10% now to make sure you actually achieve that goal." This kind of budgetary reasoning can get poisonous in a hurry, so always couch cost savings as potential and as a way of increasing the leverage of the money that will be spent anyway. In other words, describe the change in terms of improved ROI or getting more value for the company's money, not in terms of spending less money.
The flip side of lowering costs is increasing revenue. To develop credible estimates, it's important to interview several sales and channel managers, discounting the opinions of people who are not directly responsible for revenues. It is political suicide to present your revenue conclusions without having first reviewed them with the Sales VP.
Develop a spreadsheet that shows the value of extra deals that could be closed with the aid of better prospect and customer information, better lead quality, tighter qualification, and higher conversion/win rates. What if a hot prospect never "fell through the cracks"? What would be the value of the extra deals you could do if the sales cycle were shorter? What kind of extra revenue might the channel produce if leads were handed off and managed more effectively? What would be the value of doing one additional "upsell" per year or of closing a deal with one more customer? What if your customer loyalty or retention rate increased by 10%? For the sake of credibility, keep the estimates conservative.
It's also a good idea to identify opportunities to increase sales leverage—that is, getting more yield from the same cost structure. How would it change the company if a sales rep could manage twice as many deals without slip-ups? Or if a sales manager could manage 50% more sales reps? How would the company operations change if the forecast were really reliable in week 10 of the quarter? These issues could mean better scalability for the company and ability to respond to market changes more quickly. These speed and scalability advantages increase both the profitability and the value of the company.
Beware of politics surrounding revenue estimates. It's tempting to say something like, "We could increase revenue 10% if only . . ." Sales executives may be very sensitive about this topic, and ornery finance executives might say, "We'll approve this project if only the Sales department is willing to increase its quota by 10%." To avoid this downhill spiral, focus your estimates on quantifying the increased probability of making the revenue targets the company already has. This approach is a less direct way of making the business case for SFDC, but it avoids the political traps and still makes the point.
Finally, beware of blatant double-counting of cost savings or revenue improvements. While some double-counting is almost unavoidable, if it's too obvious it simply lowers your credibility.
Continue to the next section: Developing a CRM implementation schedule
Download Chapter 1, Planning ahead
Read other excerpts and download more sample chapters from our CRM and call center bookshelf
SalesLogistix is a trademark of SalesLogistix, Inc. All rights reserved. This work contains other companies' trademarks; when the publisher was aware of a trademark claim, the designations have been printed with initial capital letters. Those trademarks are the property of their owners.
The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. The procedures and methods contained in this book are provided on a strictly "as-is" basis, and their use is entirely at the reader's own risk. The author and publisher will not be liable for any incidental, indirect, punitive, special, or consequential damages (such as data loss or system problems) in connection with or arising out of the use of the information, methods, or procedures described in this book. The author and publisher make no representations that the procedures or methods herein do not infringe on existing patents or proprietary rights of any third party, or that they will work in every system configuration. We hereby disclaim any obligation for indemnifying or otherwise compensating the reader.