Bad Metrics Can Doom Your CRM Project

With the scope and amount of data in modern CRM systems, it’s easy to ask for reports and get nice-looking dashboards, and get them in short order. Unfortunately, you could ask for lots of meaningless data on these dashboards, and subordinates aren’t likely to say no to your requests. How do you avoid the trap of reports that practically beg the users to game the system?

Step 1: Don’t ask users to rig the game

It’s easy to ask for weekly indicators that sound meaningful, but aren’t. For example, the number of leads produced each week. Leads are like Web site traffic: they are better indicators of visibility and vague interest than they are of a solid pipeline. In another example, activity management indicators (such as “number of dials” or “customer support call volume”) are very easy to get, but the numbers are rarely very meaningful. Artificial indicators of activity are easy to fake, and putting a financial reward on these indicators is like sending an engraved invitation to the rank and file to game the system.

Before you ask sales reps or customer support people to enter any new data items (which they’ll view as a tax and an intrusion), walk a mile in their shoes. If you’re just curious about an action, don’t ask them to enter a bunch of new data so you can measure it in the CRM system.

Figure out what you would do differently if you already had that magic report in front of you. How often would you actually review it and understand the underlying business dynamics? How would that report relate to the things that you are measured on? Which decisions would you actually make differently?

While it’s easy to ask for reports that you won’t actually use, it’s dangerous to ask for metrics and reports that you will use to bad effect. Metrics shouldn’t be microscopic, because that leads to micromanagement and sub-optimization. Measurements of a business process shouldn’t focus on things outside the company’s control, as that misdirects attention. Instead, focus metrics should on things that reflect the real health of your business. These are the kinds of CRM measurements that are meaningful, particularly when compared over time:

Marketing

• Size of house database or online community
• Percentage of leads converted
• Number of leads accepted by sales
• Percentage of nonresponsive or stale leads

Sales

• Number of sales cycles started
• Average time in stage (or, alternatively, number of stalled deals)
• Percentage of wins, losses, and no-decisions
• Number of new customers
• Average deal size
• Percentage renewals/retained customers

Pipeline

• Forecast sales versus quarterly goal
• Actual bookings versus expected bookings by week
• Percentage of opportunities “moving backward”
• Number and dollar value of deals dropping out of the quarter
• Forecast accuracy
• Number and value of unforecasted deals

Customer Support

• Number of new problems identified vs solved by week
• Customer-perceived “time to resolve”
• Percentage satisfied customers
• Number of highly dissatisfied customers

Customer Base

• Cost of customer acquisition
• Percentage of revenue coming from repeat business
• Percentage of customer base that’s still active/current
• Customer lifetime revenue

Step 2: Make it tougher to game the system

When people game a CRM metric, it not only undermines the system’s credibility (and data integrity), it also insidiously undermines your authority. So if you’re going to lay down the law, make sure that gaming the system carries the biggest penalty of all.

The first way to make it tougher to game the system is to set metrics that directly reflect achievement of business goals, as discussed above. Whenever possible, the evidence of the metric should come from externally-verifiable events or actions, and not be exclusively under your workers’ control. For example, it’s easy to fake “improved customer sat scores,” but harder to fake “customer renewal rate.”

The metrics should be direct, avoiding high levels of detail or interpretation. Any metric that involves footnotes, subtleties, or weighting factors is a sign of trouble. If the metric spreadsheet reads like a Wall Street prospectus, there’s going to be some fakery.

Create metrics that are related to one another so they provide automatic “reality checks.” Look for metrics that are part of a linked business process (such as “quote to cash” or “order to delivery / installation”) and develop a back-of-the envelope model of how these metrics interact in your normal course of business. For example, if 100 quotes have been made, within 4 weeks there should be 60 contract negotiations and 35 orders.

When possible, the metrics should be triggered by things that the customer cares about (or at least would notice). “Number of Sales Rep lunches” or “% of emails bounced” may be something your management team wants to know, but the customer is more interested in “time to resolve priority-1 bug” or “% of mis-configured orders.”

Don’t get too fancy with the analytics too early in the CRM system’s life. Metrics, particularly the kind that suggest micromanagement, scare employees. If employees see the CRM system as a spying machine, they’re not going to genuinely adopt it. Besides, the system data and supporting criteria often aren’t very good early in the system implementation process. Test the data and the assumptions behind it for a month or two before you put new metrics into public view. Gradually add a new report, dashboard, or analytic every six weeks or so, and listen to feedback from every level of the organization to improve the quality and relevance of the metrics you are using.

If the users view metrics as something that helps them avoid waste and make more time, they won’t have the temptation to game the system.

David Taber is the author of the new Prentice Hall book, “Salesforce.com Secrets of Success” and is the CEO of SalesLogistix, a certified Salesforce.com consultancy focused on business process improvement through use of CRM systems. SalesLogistix clients are in North America, Europe, Israel, and India, and David has over 25 years experience in high tech, including 10 years at the VP level or above.

Follow everything from CIO.com on Twitter @CIOonline