One of the common criticisms of lifetime value is that it has no practical applications. You and I know this is false, but some people still need convincing. The APQC formerly American Productivity and Quality Council) recently published “Insights into Using Customer Valuation Strategies to Drive Growth and Increase Profits from Aon Risk Services, Sprint Nextel, and a Leading Brokerage Services Firm,” which provides three mini-case histories that may help.
Aon created profitability scorecards for 10,000 insurance customers. The key findings were variations in customer service costs, which had a major impact on profitability. The cost estimates were based on surveys of customer-facing personnel. Results were used for planning, pricing, and to change how clients were serviced, and have yielded substantial financial gains.
Sprint Nextel developed a lifetime value model for 45 million wireless customers, classified by segments and services and using “a combination of historical costs, costing assumptions, cost tracing techniques, and activity-based allocations”. The model is used to assess the financial impact of proposed marketing programs and for strategic planning.
The brokerage firm also built a lifetime value model for customer segments, which were defined by trading behaviors, asset levels, portfolio mix and demographics. Value is determined by the products and services used by each segment, and in particular by the costs associated with different service channels. The LTV model is used to evaluate the three-year impact of marketing decisions such as pricing and advertising.
The paper also identifies critical success factors at each company: senior management support, organizational buy-in and profitability analysis technology at Aon; model buy-in at Sprint Nextel; and the model, profitability analysis and customer data at the brokerage firm.
My own take is that this paper reinforces the point that lifetime value is useful only when looking at individual customers or customer segments: a single lifetime value figure for all customers is of little utility. It also reinforces the need to model that incremental impact of different marketing programs, or of any change in the customer experience. Although the Aon and brokerage models are not described in detail, it appears they take expected customer behaviors as inputs and then calculate the financial impact. This is less demanding than having a model forecast the behavior changes themselves. Since it clearly delivers considerable value on its own, it’s a good first step in a larger project towards a comprehensive lifetime value-based management approach.
Showing posts with label lifetime value model. Show all posts
Showing posts with label lifetime value model. Show all posts
Monday, July 09, 2007
Wednesday, June 20, 2007
Using Lifetime Value to Measure the Value of Data Quality
As readers of this blog are aware, I’ve reluctantly backed away from arguing that lifetime value should be the central metric for business management. I still think it should, but haven’t found managers ready to agree.
But even if LTV isn’t the primary metric, it can still provide a powerful analytical tool. Consider, for example, data quality. One of the challenges facing a data quality initiative is how to justify the expense. Lifetime value provides a framework for doing just that.
The method is pretty straightforward: break lifetime value in its components and quantify the impact of a proposed change on whichever components will be affected. Roll this up to business value, and there you have it.
Specifically, such a breakdown would look like this:
Business value = sum of future cash flows = number of customers x lifetime value per customer
Number of customers would be further broken down into segments, with the number of customers in each segment. Many companies have a standard segmentation scheme that would apply to all analyses of this sort. Others would create custom segmentations depending on the nature of the project. Where a specific initiative such as data quality is concerned, it would make sense to isolate the customer segments affected by the initiative and just focus on them. (This may seem self-evident, but it’s easy for people to ignore the fact that only some customers will be affected, and apply estimated benefits to everybody. This gives nice big numbers but is often quite unrealistic.)
Lifetime value per customer can be calculated many ways, but a pretty common approach is to break it into three major factors:
- acquisition value, further divided into the marketing cost of acquiring a new customer, the revenue from that initial purchase, and the fulfillment costs (product, service, etc.) related to that purchase. All these values are calculated separately for each customer segment.
- future value, which is the number of active years per customers times the value per year. Years per customer can be derived from a retention rate or a more advanced approach such as a survivor curve (showing number of customers remaining at the end of each year). Value per year can be broken into the number of orders per year times the value per order , or the average mix of products times the value per product). Value per order or product can itself be broken into revenue, marketing cost and fulfillment cost.
Laid out more formally, this comes to nine key factors:
- number of customers
- acquisition marketing cost per customer
- acquisition revenue per customer
- acquisition fulfillment cost per customer
- number of years per customer
- orders per year
- revenue per order
- marketing cost per order
- fulfillment cost per order
This approach may seem a little too customer-centric: after all, many data quality initiatives relate to things like manufacturing and internal business processes (e.g., payroll processing). Well, as my grandmother would have said, feh! (Rhymes with ‘heh’, in case you’re wondering, and signifies disdain.) First of all, you can never be too customer-centric, and shame on you for even thinking otherwise. Second of all, if you need it: every business process ultimately affects a customer, even if all it does is impact overhead costs (which affect prices and profit margins). Such items are embedded in the revenue and fulfillment cost figures above.
I could easily list examples of data quality changes that would affect each of the nine factors, but, like the margin of Fermat’s book, this blog post is too small to contain them. What I will say is that many benefits come from being able to do more precise segmentation, which will impact revenue, marketing costs, and numbers of customers, years, and orders per customer. Other benefits, impacting primarily fulfillment costs (using my broad definition), will involve more efficient back-office processes such as manufacturing, service and administration.
One additional point worth noting is many of the benefits will be discontinuous. That is, data that's currently useless because of poor quality or total absence does not become slightly useful because it becomes slightly better or partially available. A major change like targeted offers based on demographics can only be justified if accurate demographic data is available for a large portion of the customer base. The value of the data therefore remains at zero until a sufficient volume is obtained: then, it suddenly jumps to something significant. Of course, there are other cases, such as avoidance of rework or duplicate mailings, where each incremental improvement in quality does bring a small but immediate reduction in cost.
Once the business value of a particular data quality effort has been calculated, it’s easy to prepare a traditional return on investment calculation. All you need to add is the cost of improvement itself.
Naturally, the real challenge here is estimating the impact of a particular improvement. There’s no shortcut to make this easy: you simply have to work through the specifics of each case. But having a standard set of factors makes it easier to identify the possible benefits and to compare alternative projects. Perhaps more important, the framework makes it easy to show how improvements will affect conventional financial measurements. These will often make sense to managers who are unfamiliar with the details of the data and processes involved. Finally, the framework and related financial measurements provide benchmarks that can later be compared with actual results to show whether the expected benefits were realized. Although such accountability can be somewhat frightening, proof of success will ultimately build credibility. This, in turn, will help future projects gain easier approval.
But even if LTV isn’t the primary metric, it can still provide a powerful analytical tool. Consider, for example, data quality. One of the challenges facing a data quality initiative is how to justify the expense. Lifetime value provides a framework for doing just that.
The method is pretty straightforward: break lifetime value in its components and quantify the impact of a proposed change on whichever components will be affected. Roll this up to business value, and there you have it.
Specifically, such a breakdown would look like this:
Business value = sum of future cash flows = number of customers x lifetime value per customer
Number of customers would be further broken down into segments, with the number of customers in each segment. Many companies have a standard segmentation scheme that would apply to all analyses of this sort. Others would create custom segmentations depending on the nature of the project. Where a specific initiative such as data quality is concerned, it would make sense to isolate the customer segments affected by the initiative and just focus on them. (This may seem self-evident, but it’s easy for people to ignore the fact that only some customers will be affected, and apply estimated benefits to everybody. This gives nice big numbers but is often quite unrealistic.)
Lifetime value per customer can be calculated many ways, but a pretty common approach is to break it into three major factors:
- acquisition value, further divided into the marketing cost of acquiring a new customer, the revenue from that initial purchase, and the fulfillment costs (product, service, etc.) related to that purchase. All these values are calculated separately for each customer segment.
- future value, which is the number of active years per customers times the value per year. Years per customer can be derived from a retention rate or a more advanced approach such as a survivor curve (showing number of customers remaining at the end of each year). Value per year can be broken into the number of orders per year times the value per order , or the average mix of products times the value per product). Value per order or product can itself be broken into revenue, marketing cost and fulfillment cost.
Laid out more formally, this comes to nine key factors:
- number of customers
- acquisition marketing cost per customer
- acquisition revenue per customer
- acquisition fulfillment cost per customer
- number of years per customer
- orders per year
- revenue per order
- marketing cost per order
- fulfillment cost per order
This approach may seem a little too customer-centric: after all, many data quality initiatives relate to things like manufacturing and internal business processes (e.g., payroll processing). Well, as my grandmother would have said, feh! (Rhymes with ‘heh’, in case you’re wondering, and signifies disdain.) First of all, you can never be too customer-centric, and shame on you for even thinking otherwise. Second of all, if you need it: every business process ultimately affects a customer, even if all it does is impact overhead costs (which affect prices and profit margins). Such items are embedded in the revenue and fulfillment cost figures above.
I could easily list examples of data quality changes that would affect each of the nine factors, but, like the margin of Fermat’s book, this blog post is too small to contain them. What I will say is that many benefits come from being able to do more precise segmentation, which will impact revenue, marketing costs, and numbers of customers, years, and orders per customer. Other benefits, impacting primarily fulfillment costs (using my broad definition), will involve more efficient back-office processes such as manufacturing, service and administration.
One additional point worth noting is many of the benefits will be discontinuous. That is, data that's currently useless because of poor quality or total absence does not become slightly useful because it becomes slightly better or partially available. A major change like targeted offers based on demographics can only be justified if accurate demographic data is available for a large portion of the customer base. The value of the data therefore remains at zero until a sufficient volume is obtained: then, it suddenly jumps to something significant. Of course, there are other cases, such as avoidance of rework or duplicate mailings, where each incremental improvement in quality does bring a small but immediate reduction in cost.
Once the business value of a particular data quality effort has been calculated, it’s easy to prepare a traditional return on investment calculation. All you need to add is the cost of improvement itself.
Naturally, the real challenge here is estimating the impact of a particular improvement. There’s no shortcut to make this easy: you simply have to work through the specifics of each case. But having a standard set of factors makes it easier to identify the possible benefits and to compare alternative projects. Perhaps more important, the framework makes it easy to show how improvements will affect conventional financial measurements. These will often make sense to managers who are unfamiliar with the details of the data and processes involved. Finally, the framework and related financial measurements provide benchmarks that can later be compared with actual results to show whether the expected benefits were realized. Although such accountability can be somewhat frightening, proof of success will ultimately build credibility. This, in turn, will help future projects gain easier approval.
Monday, January 15, 2007
Types of Lifetime Value Models
Consultants love 2x2 matrices. So in organizing my thoughts on the topic of lifetime value modeling, it’s natural that I ended up building one.
The question I’m wrestling with is, just how detailed must a lifetime value model must be to be useful? This is raised by my claim last Friday (here) that lifetime value is the essential measure needed to manage customer experience. My logic in a nutshell: the only way to judge whether an experience change is working is whether it improves lifetime value. Nothing else really counts.
You may or may not agree, but let’s assume that’s true for sake of discussion. The question then becomes, what does it take to build a lifetime value model that’s adequate for the purpose? Actually, the answer is obvious: the model must be able to estimate the impact of any experience change on final lifetime value. But this just leads to the equally obvious observation that “any” experience is too broad a goal, and what we really need is make tough choices about which experiences to include or exclude.
Now, being a consultant, I don’t make tough choices unless someone pays me a lot of money. But 2x2 matrices? Those you can have for free.
So let’s think about lifetime value models in two dimensions. The first is complexity. This ranges from simple to, um, complex. A simple model would be something you could do with math functions in a spreadsheet. A complex model involves polynomial formulas and multi-variate regression and such. It can incorporate many more factors than a simple model and allows for subtle relationships among them. In practical terms, a simple model is something a business analyst can create while a complex model needs a statistician.
The second dimension is scope. This indicates which experiences are included in the model and ranges from partial to full. A partial model might include only one experience such as acquisition or renewal, while a full model would include all experiences from prospecting through product use to customer service. In general, experiences map to business functions (marketing, sales, service, operations, etc.) which in turn map to departments. So even though what we really care about is experiences, we can think of a partial model as dealing with activities in one or several company departments, while a full-scope model deals with all departments. This departmental orientation makes sense because the input data will usually be held in departmental systems. So expanding the scope of a model will usually be done on a department-by-department basis.
Now we have a nice 2x2 matrix, with four types of models: simple/partial, simple/full, complex/partial and complex/full. What use can you make of each type? I think I’ll save the answer for tomorrow.
The question I’m wrestling with is, just how detailed must a lifetime value model must be to be useful? This is raised by my claim last Friday (here) that lifetime value is the essential measure needed to manage customer experience. My logic in a nutshell: the only way to judge whether an experience change is working is whether it improves lifetime value. Nothing else really counts.
You may or may not agree, but let’s assume that’s true for sake of discussion. The question then becomes, what does it take to build a lifetime value model that’s adequate for the purpose? Actually, the answer is obvious: the model must be able to estimate the impact of any experience change on final lifetime value. But this just leads to the equally obvious observation that “any” experience is too broad a goal, and what we really need is make tough choices about which experiences to include or exclude.
Now, being a consultant, I don’t make tough choices unless someone pays me a lot of money. But 2x2 matrices? Those you can have for free.
So let’s think about lifetime value models in two dimensions. The first is complexity. This ranges from simple to, um, complex. A simple model would be something you could do with math functions in a spreadsheet. A complex model involves polynomial formulas and multi-variate regression and such. It can incorporate many more factors than a simple model and allows for subtle relationships among them. In practical terms, a simple model is something a business analyst can create while a complex model needs a statistician.
The second dimension is scope. This indicates which experiences are included in the model and ranges from partial to full. A partial model might include only one experience such as acquisition or renewal, while a full model would include all experiences from prospecting through product use to customer service. In general, experiences map to business functions (marketing, sales, service, operations, etc.) which in turn map to departments. So even though what we really care about is experiences, we can think of a partial model as dealing with activities in one or several company departments, while a full-scope model deals with all departments. This departmental orientation makes sense because the input data will usually be held in departmental systems. So expanding the scope of a model will usually be done on a department-by-department basis.
Now we have a nice 2x2 matrix, with four types of models: simple/partial, simple/full, complex/partial and complex/full. What use can you make of each type? I think I’ll save the answer for tomorrow.
Subscribe to:
Posts (Atom)
