Tactical Logic

Bozoing Measurements VII

noreply@blogger.com (Edmund Freeman) — Sun, 16 Aug 2009 21:50:00 +0000

A while ago I saw a consultant give a presentation. He had been given 20 campaigns to analyze. He spent a lot of time discussing the one campaign that was significant at the 5% level.

Bozoing Campaign Measurements VI

noreply@blogger.com (Edmund Freeman) — Sun, 12 Jul 2009 18:03:00 +0000

And the hits keep coming.

This story involves a tracking database. The database was tracking long-running campaigns, where the process was that a customer 1) contacted the company via customer care 2) at that point, was randomized on a by-campaign basis. Once there was customer activity, that customer was tracked for three months.

Here's where it gets tricky. On the next customer contact the treatment group was given the pitch again if they still qualified whereas the control group was automatically not given the pitch. That means in the treatment group the next contact generates a campaign-relevant data point whereas in the control group it doesn't. Remember the three month-tracking? After three months any control group customers are dropped out of the database, whereas treatment group customers that are still in contact with the company are still tracked. These are long-running campaigns. So the control group was composed of customers that had at most a three-month window to take the offer whereas the treatment group had a potentially unlimited time to take the offer. What a clever way to make sure the results are excellent!

I was once reviewing analysis of campaigns from this system. I was originally asked to make sure the T-Test formula was right, and poked around in the data a little. I saw a weird thing: the campaign results were a linear function of the control group size. The smaller the control group the better the results. I commented that they really shouldn't publish results until they had figure out what the Weird Thing was. Looking back, I can see how the database anomaly aboce could account for the effect. As time goes on, customers are going to be dropped out of the control group. Also, the treatment group will be given longer and longer to take the offer. So as time goes on, the control group numbers will fall and treatment group takes will rise.

So all the positive results that were being ascribed to the marketing system could have been due to the reporting anomalies.

Customers are Weird

noreply@blogger.com (Edmund Freeman) — Sun, 28 Jun 2009 04:57:00 +0000

Really, really weird.

Imagine a company with 2mm customers. Reasonable-sized, not huge.

How many people do you know well? Maybe 100 people? Think about the absolute weirdest person you know. That company has customers that are literally 100 times weirder than the weirdest person you know. In fact, they've got 200 of them.

It's a bad idea to think you know what customers are going to do without testing, measuring, and finding out.

Bozoing Campaign Measurements V

noreply@blogger.com (Edmund Freeman) — Sun, 28 Jun 2009 04:29:00 +0000

Here's a classic: toss all negative results.

Clearly, everything we do is positive, right?

Nope. Anything that can have an effect can have a negative effect.

(I've met a number of marketing people that really truly believe that people wait at home looking forward to their telemarketing calls. And that calling something 'viral' in a powerpoint is enough to actually create a viral marketing campaign).

There's another factor. Depressingly, a lot of marketing campaigns do absolutely nothing. Random noise takes over; half will be a little positive and half will a little negative. Toss the negative results and you're left with a bunch of positive results. Add them up and suddenly you've got significant positive results from random noise. This is bad.

I've seen an interesting variant on this technique from a very well-paid consultant. Said VWPC analyzed 20 different campaigns and reported extensively on the one campaign that had results that were significant at a 5% level.

Bozoing Campaign Measurements - IV

noreply@blogger.com (Edmund Freeman) — Sun, 07 Jun 2009 17:49:00 +0000

Another installment in the "How to Bozo Simple Campaign Analysis". I've got a lot of them. It's amazing how inventive people get when it comes to messing up data.

Anyway, this is from a customer onboarding program. When the company got a new customer, they would give them a call in a month to see how things were going. There was a carefully held out control group. The reporting, needless to say, wasn't test and control. It was "total control" vs. "the test group that listened to the whole onboarding message". The goal was to enhance customer retention.

The program directors were convinced that the "recieve the call or not" decision was completely random; and given that it was completely random the reporting should be concentrated on only those that were effected by the program (that again -- it's amazing how often the idea comes up).

Clearly, the decision to respond to telemarketing is a non-random decision, and I have no idea what lonely neurons fired in the directors brains to make them think that. To start with, someone who is at home to take a call during business hours is going to be a very different population that people that go to work. More importantly, a person that thinks highly of a company is much more likely to listen to a call than someone who isn't that fond of a company.

Unsurprisingly, the original reporting showed a strong positive result. When I finally did the test/control analysis, the result showed that there was no real effect from the campaign.

Statistics and DBAs

noreply@blogger.com (Edmund Freeman) — Mon, 01 Jun 2009 01:12:00 +0000

Statistics and DBA work really are two different disciplines, although from the outside we're both numbers people. I've learned the hard way that there's a lot that I don't know about how to set up a database. Likewise, I've had some database people push some very strange ideas about how to do analysis.

Take random samples. Unless I can actually see the code used to make random samples, I'd rather do random sampling myself. My favorite example of the problem was "we randomly gave you data from California".

Time sensitivity is another issue. I was making a customer attrition study for a cell phone company. We wanted to look at attrition over a year, so we needed customer data from the start of the year and we see how it effects attrition. What happened was that the database people, instead of following our instructions gave us customer data from the end of the year instead of start.

Why? "Don't you want the most current data possible?" It's the nature of reporting to get the most current data possible for the report, and understanding statistical analysis that will often require data from the past is a little alien to that way of thinking.

Bozoing Campaign Measurements - III

noreply@blogger.com (Edmund Freeman) — Sun, 31 May 2009 23:49:00 +0000

I've got another story from the customer cross-sell system I was talking about in Bozoing Measurements I

We're taking about doing basic reporting on the system. Remember, we're keeping out a control group. We were changing the control group process from keeping out individual control groups per each campaign (which caused a lot of problems actually -- more in a later post).

Now, the dead obvious comparison is treatment and control. There are a couple of nuances we can add on. We can compare

Total treatment vs. total control

The treatment and control that contact the company

The treatment and control that have an opportunity to be marketed to

All happy, all treatment vs. control.

But then the senior DBA in the project says "We shouldn't on report the control group that could be marketed to. That's a biased number".

Huh?

"That number is biased by the fact that we're taking out the customers that didn't contact us and that we couldn't market to."

His plan was to compare 1) Treatment group that contacted us and that we could market to (because the others clearly weren't effected by the program) to 2) The total control group. This would create a huge unfair effect favoring the treatment group, simply because the customers that are actively contacting the company are much more likely to purchase new products. That may have been the hidden agenda that the DBA had: create reporting that would have a large built in bias.

About that word bias: there's no such thing as a biased number. The number is what it is. Bias happens with unfair comparisons. We want the treatment and control factor to be the only factor in the comparison.

Bozoing Campaign Measurements -- II

noreply@blogger.com (Edmund Freeman) — Wed, 20 May 2009 04:57:00 +0000

Our next contestant comes from the telecom world.

What the group was doing was evaluating marketing campaigns over the course of several years. Does an attrition-prevention campaign have any effect after three years? This is an absolutely wonderful thing to do, of course, but not the way they went about it.

The campaigns were in a series of mailings that went out to customers that were about to go off contract, and the offer was a monetary reward to renew their contract for a year. Each campaign had a carefully selected control group.

The dead-obvious thing to do is to compare the treatment group vs. the control group, but that's not what got done. What happened was the analysis compared the whole control group to the customers in the treatment group that renewed their contract, because clearly "customers that didn't renew their contract weren't effected by the campaign".

Sound familiar?

Why doing analysis this way is a bad idea: before the mailing on contract renewal, customers are going to have a certain basic affinity towards the company. Some are going to love it, some are going to hate it, some are going to be on the fence. When the customers get the offer the ones that already hate the company will toss the offer, the ones that love the company will take free money for staying with a company they like, and the ones on the fence may or may not take the offer and have their future behavior change. So, to a good extent a retention program like this isn't changing behavior but instead is sorting the customers into buckets based on how they already feel about the company. Comparing "total control group" to "contract renewers" confounds two effects, one effect of the customers predisposition to the company and the second effect of having some customers renew their contracts for a reward. Moreover, this comparison doesn't actually answer the real question: does the program have a meaningful, measurable impact on churn? To answer the real question in the right way Keep Things Simple and Statistical and do a straight treatment vs. control.

How to Bozo Campaign Measurements

noreply@blogger.com (Edmund Freeman) — Tue, 19 May 2009 04:57:00 +0000

You know, at their heart statistical measurements are basically the easiest thing in the world to do, especially when it comes to direct marketing. Set up your test, randomly split the population, run the test, measure the results. It pretty much takes serious work to mess this up. It's amazing how many bright people leap at the chance to go the extra mile and find an inventive way to bozo a measurement.

The first exhibit is a database expert working for a customer contact project at a bank. A customer comes in, talks to the teller, and the system 1) randomly assigns the customer to the control group or not if this is the first time the customer has hit the system, otherwise it looks up the customer's status and then 2) makes a suggestion for a product cross-sell. The teller may or may not use the suggestion, depending on how appropriate the teller thinks the offer is for the customer and/or how busy the branch is and if there is time available to talk to the customer.

So now, we've got the simplest test/control situation possible. What the DBA decided was to toss out all the customers where no offer was made, on the theory that if no offer was made then the program had no effect. So, all the reporting was done on "total control group" vs. "treatment group that received the offer", creating a confounding effect. The teller decision to make the offer or not was highly non-random. The kind of person that comes in at rush hour (where the primary concern of the teller is handling customers and keeping wait times down) is going to be very different from the kind of person that comes during the slow time in the middle of the afternoon.

The project team understood this confounding, that in their reporting they were mixing up two different effects, and talked for over two years about how to overcome this confounding when all they had to do was be lazier and report on the random split.

The Data Daemon

noreply@blogger.com (Edmund Freeman) — Fri, 13 Feb 2009 20:36:00 +0000

Appropos of "Murphy's Laws of Data" , I find it useful to imagine that data is created by a little deamon and his job is to make me look like a durn fool.

Learning from LTV at LTC: It's About Understanding

noreply@blogger.com (Edmund Freeman) — Sun, 04 May 2008 03:46:00 +0000

Ultimately, success is about understanding. Build teams that will take the time to understand the business and all parts of the project, where every member of the team understands all parts of the projects as a whole, share this understanding in full with anybody who wants to learn, and carry this detailed understanding forward in the enterprise.

Learning from LTV at LTC: Build Complete Teams

noreply@blogger.com (Edmund Freeman) — Sun, 04 May 2008 03:45:00 +0000

ypically projects are done by assembling cross-functional teams from different areas, each person with a narrow responsibility. This is a very efficient way of handling day-to-day business but an ineffective way of getting business-changing projects done. This is especially true is the project is going to be going on for a while.

The key to our success was having a complete team that could handle all phases of the project. There was no point in the project that we threw the project over the wall to another team, or caught something that another team was throwing at us. When we were working with other teams we established working relationships with them and brought those teams into the project. Every member on the LTV team could speak to all aspects of the project and have meaningful input into all aspects of the project.

Let me give an example of what can happen with fragmented, siloed teams. I was working on updating a project that had been launched several years before. There was one team that extracted the data from a datamart, another that took the data and loaded it into a staging area, and a third team that loaded the data from the staging area into the application. I asked the question “who can guarantee that the data in the application is right”? Thunderous silence. No one could guarantee that the final data was right, or even that their step was correct; all they could promise was that their scripts had run without obvious error.

If I had to give a name to this approach I'd call it the “A-Team” approach: complete functional teams that understand each other's areas.

Learning from LTV at LTC: Tell Everything

noreply@blogger.com (Edmund Freeman) — Sun, 04 May 2008 03:42:00 +0000

In a project like this the team gains a great deal of understanding about how the business works and there is always the temptation to keep that understanding within the team. The argument I have heard is that by keeping all the details hidden then the team will maintain control over the results of the project. What I've seen actually happen is that when a team tries to keep secrets others just don't believe them.

In the LTV project we made the decision to explain every detail to anybody who asked. The result was that people had a great deal of faith in what we produced. Even if people disagreed with the decisions that we made in the project, they understood and could respect the decisions.

Learning from LTV at LTC: Build Understanding

noreply@blogger.com (Edmund Freeman) — Sun, 04 May 2008 03:41:00 +0000

Projects that change an organization demand that the project group build a substantial understanding of that the business is, what it could be, and how the project can help the business get there. That understanding needs to stay withing the organization after the project is officially complete. There is a vast difference between the understanding that comes from seeing a presentation on a project and the understanding that comes from actually doing the work.

Projects that are important to the company need to be living, evolving things and that means that the detailed understanding of the project needs to stay accessible to the organization. With LTV, as soon as it came out people wanted additional work and we could do it because we knew the nuts and bolts.

LTV at LTC: Learning from it: Design Rules

noreply@blogger.com (Edmund Freeman) — Sun, 27 Apr 2008 01:06:00 +0000

In software it's all about the implementation – actually writing the code. In business intelligence projects actually doing the implementation isn't that big a deal. There are lots of packages to make implementation easy compared to writing software from scratch. What that means is that business intelligence projects are all about the design, and the design team needs to be in control and actively involved in all stages of the project.

LTV at LTC: The Large Activity Based Costing (ABC) Project

noreply@blogger.com (Edmund Freeman) — Fri, 25 Apr 2008 04:43:00 +0000

During and after the LTV project, there was yet a fourth value-based project at LTC. The Finance department brought in a large consulting company to design a database for activity-based costing to help LTC get a handle on their operational expenses. The goal was to build an ABC database where a manager could look at expenses, drill down into the specific line items, and then drill into the company and customer activity that was causing those expenses and so have a clear grasp of the actions needed to manage expenses.

The project started out by having the consultants come in and have roughly a year of large meetings on what should go into the system. This was done without considering implementation issues. At then end of the meetings a large and detailed specification was developed, which was then handed off to the LTC IT department. The LTC IT department estimated that implementation would cost several million dollars and the project was killed right then and there.

In many respects, the ABC project was the antithesis of the LTV project.

Instead of identifying a group within the company to build the project, an outside consultant was brought in to run the project. This meant that the understanding that comes from doing a project like this left LTC with the consultants.
There was a complete disconnect between the design and implementation teams. This meant that implementation issues were not considered during the design, and that the design could not be modified later to take implementation factors into consideration.
Instead of a small group working to understand the business, ABC had large meetings to poll people on their issues. This meant that every possible issue was included in the project design. Because the design was simply thrown over a fence to implementation there wasn't any negotiation over project scope to achieve what was reasonable.

LTV at LTC: The International Consulting Company (ICC)

noreply@blogger.com (Edmund Freeman) — Wed, 23 Apr 2008 04:10:00 +0000

At the same time as our project was going going an International Consulting Company was brought in to do pretty much an identical project, Lifetime Value for customers. We were able to work fairly closely together and our projects wound up being very similar. The ICC team was very valuable to us in that ICC was working with the CMO directly and so our project was able to gain tremendous credibility through association and to some degree confusion with the ICC project.

ICC and our group had slightly different methodologies; ours was adopted because we had resources to deploy the results in the data warehouse and the ICC didn't.

Pay Close Attention to What Everybody Tells You to Ignore

noreply@blogger.com (Edmund Freeman) — Fri, 18 Apr 2008 04:21:00 +0000

Organizations develop blind spots. The drill is: people decide something isn't important, so all of the reporting ignores it, so nobody thinks about it, so nobody gets it put on their goals, and the cycle reinforces itself. Opportunities develop that everyone ignores.

A good example is involuntary attrition (attrition due to bad debt) at LTC. People concentrated on voluntary attrition and ignored involuntary attrition, and forgot that involuntary attrition was very much the result of a voluntary choice on the customers part. As a result, there were actually more opportunities for helping LTC with respect to involuntary attrition than voluntary attrition.

LTV at LTC: After the Project -- Education and Explanations

noreply@blogger.com (Edmund Freeman) — Thu, 17 Apr 2008 05:18:00 +0000

When the LTV project was rolled out and data was being published I immediately found myself with two new tasks: educating the company about the LTV project and explaining why particular customers got negative value.

I anticipate that education will be part of any analytic project. The most important decision we made about education was to explain everything. There was no part of the LTV system that we did not discuss and even give specific parameters for. Explaining everything allowed people to understand the LTV system.

What really made people accept the LTV system was being able to answer why particular customers had negative scores. In particular we got a number of calls from Customer Care. LTV had been integrated into the Customer Care system and it effected what kind of equipment offers could be made to customers. The Customer Care department needed to know why some high-revenue customers were getting low or negative value.

We were able to answer questions like this easily and convincingly. As it turned out, the usual reason high revenue customers had negative LTV was because they hadn't actually paid their bill in a number of months. Being able to answer these questions went a long way to establishing our credibility.

LTV at LTC: Building the System

noreply@blogger.com (Edmund Freeman) — Thu, 17 Apr 2008 05:17:00 +0000

Building the LTV system took a small team approximately two months out of a year spent on the project, from building the lifetime models to coding the formulas to finally building a system of monthly HTML reports. Ironically actually building the LTV project was the simplest part of the whole project.

LTV at LTC: Alarms and Diversions; the New Media Department (NMD)

noreply@blogger.com (Edmund Freeman) — Tue, 15 Apr 2008 05:02:00 +0000

In LTC, we had a department dedicated to exploring new technologies and new media applications. The technology to really make NMD's projects really go wasn't slated to go live until the year after the LTV project, but they were still very interested in the LTV project. Their interest culminated in a meeting that nearly ended the LTV project.

NMD had segmented the customer base, and had identified the segment they wanted to market to. NMD was horrified that one of their potential customers might get a poor score, and so perhaps not get the best possible service. Never mind the equal possibility that their potential customers might get good scores and receive preferential treatment – NMD was terrified at the possibility of anything bad possibly happening to their potential base. The most vivid quote of the meeting was “We have to stop this!”

If NMD really tried to stop the LTV project, I am fairly sure that we could have overcome their resistance but I'm certain that if the meeting ended there we would have a lot of unnecessary turmoil. What I did was I put back on my Project Designer hat and let NMD specify a value formula just for them that would identify the customers NMD most wanted. This approach was successful because I was able to promise right then and there that NMD could design the formula the way NMD wanted and that it would be published along with the other LTV scores.

In a typical project situation there would have been an initial meeting with NMD, their concerns would have been taken back the the larger group, possible solutions discussed, project forms filled out and signed off on, and all this over a course of several weeks. During these weeks NMD would have solidified their position and the LTV project would have been threatened by a protracted political fight that would weaken the project at best and conceivably stop the project all together.

Effective vs. Efficient Teams

noreply@blogger.com (Edmund Freeman) — Sun, 13 Apr 2008 23:57:00 +0000

There's a difference between 'effectiveness' and 'efficiency'

An organization is efficient when each person knows their job, does their job, and there is no slack in the organization. Every person knows exactly what they need to. No less and no more.

This is typically what enterprises drive for: efficient organizations. Typically there will be a communication layer that has minimal understanding of technical details in general and almost no understanding of the technical details in the enterprise. This layer will then communicate to the technical teams, that have almost no knowledge of the business details of the enterprise. The technical teams are actively discouraged from having contact with anyone in the enterprise aside from their designated contacts in the communication layer.

An extreme case is the production team. Every one on that team has a very precise job description and come what may they do not want to deviate from that job description. Each member of the team knows only what is necessary in order to do their job, and quite intentionally does not have any knowledge beyond that.

An efficient team like this is almost completely ineffective at doing anything new. To start with, they have no time. Moreover, no one on an efficient team has the kind of overview necessary to tackle a project that is at all innovative. Depressingly, "something new" can be "getting the data right". If a field may or may not have correct data, then it requires a great deal of research to verify the problem, identify the true problem, and fix the problem. If the data problem does not prevent any of the efficient team's scripts from running, then the efficient team won't care very much one way or another about the data being right or wrong. They can do their job the way they were told, and by the design of the team that is all they care about. More than once and at more than one company I've had a production team simply refuse to fix data problems in their systems.

An effective team should have members that have specialties but each can engage on every other person's areas. The managers and business contacts should be able to effective talk to and in a pinch do the technical aspects; the more technical people should have a good grounding in the overall enterprise and should be able to represent the effective team in meetings.

Effective teams often do not make good efficient teams. People that can be on effective teams are rare and valuable, and the grind of production work can easily grind on them. Enterprises need efficient teams to get the work done, but in budget pressures effective teams can often get pushed aside and that's a mistake.

LTV at LTC: The LTC IT Department

noreply@blogger.com (Edmund Freeman) — Sun, 13 Apr 2008 21:58:00 +0000

During this same time we were going through a long series of meetings with the LTC IT department. The motto of the LTC-IT was “we will give you anything you want, just tell us what columns you need in your flat file”. For instance, the LTC-IT project documentation had extensive sections for listing data elements extracted and the databases they were extracted from – but only a minimal project memo section to describe what to do with those data elements. A project that didn't involve extracting data into a file was almost impossible to describe using the IT project documentation.

The LTC-IT department and my group had a very contentious relationship from the start. For instance, the LTC-IT was maintaining a marketing data warehouse, but they refused to allow marketing employees to access the data warehouse. We had to fill out data requests that a small group of data pullers would fulfill. Quite quickly my group found a back door into our own data warehouse simply to do our jobs.

The organizational interface between LTC-IT and the rest of the company was a Project Management Office – the PMO. PMOs were in theory supposed to have neither an understanding of the business nor an understanding of technical details but were supposed to facilitate communication between the business and technical side. In practice, because the PMOs wrote the project documents before technical IT got involved they ended up making critical technical design decisions and setting business objectives.

The LTV project was going to be unique for LTC. Employees in the marketing department were going to be developing formulas and code for the IT department to implement instead of giving the IT department high-level business concepts for design and implementation. The project manager (PM) and I spent a number of months working out the details of the interaction between our departments. When the project got to upper PMO management it was soundly rejected. According to the PMO office the LTC-IT did not have the technical competence to support model implementation and that the Marketing Department would have to supply the technical expertise to implement the LTV models.

I was overjoyed at this news. It meant minimal contact with the LTC-IT and PMO and that I could have direct oversight over the most critical matters.

The next issue we had to resolve with the LTC-IT department was where to run the LTV system. If we were going to be putting scores into the data warehouse, the LTV-IT insisted that the code be run on a server (not a problem). They also pointed out that instead of getting our own server it made a lot more sense to share a server with another department (again, not a problem). The LTV-IT found a server for us – with 275MB available disk space. Now we have a problem. Considering the potential impact of the LTV project 275MB was fairly ridiculous. Fortunately, we were able to design a trimmed-down process that fit in 275MB.

This was where wearing multiple hats on the project became very handy. A design group that was separate from implementation would have made sure that the design was complete enough and robust enough to cover all contingencies, and it would have been a lot larger that 275MB. Because design and implementation were the same we knew exactly where to cut corners.

LTV at LTC: Difficult Allies

noreply@blogger.com (Edmund Freeman) — Sat, 12 Apr 2008 05:08:00 +0000

A particularly long and difficult set of meetings that we had was with the LTC Finance Group (FG).
These meetings were, of course, difficult. LTV projects by their nature are focused on customers and their value and that makes LTV projects in the Marketing Department's area; but LTV also involves financial impact and financial data and that makes it part of the Finance Department's area. I suspect that if there is an LTV project where Marketing and Finance are not arguing about the details then the project isn't being taken seriously by either department.

The FG was currently managing an LTV-like project and had been for a number of years. What FG did was to look at revenue and cost data and then give profitability data by rate plan. Profitability by rate plan really wasn't that useful to LTC. It gave no understanding of the 'why' behind customer value or how to treat individual customers.

We needed the FG for was to understand the cost metrics associated with customer activity. In particular, our executive sponsor insisted that we have FG's approval for out LTV project. We went to the FG with the question “What is the right formula to calculate customer related costs?” -- and they refused.

Well, they didn't refuse, exactly. What happened after that was a long series of meetings with various financial people, getting one small piece of data from each. Then came time to put all the pieces together and life started getting difficult.

The FG refused to either accept or reject our meeting requests, meaning we could never be sure if a meeting was actually on or not until we made the call. They would also invite themselves to other meetings, so we had to be ready to talk about LTV issues at any time. Our questions got answered obliquely. For instance, when we asked about the best way to handle network minutes the reply was “What would happen if all of our customers leave?”

As it developed, the FG and our group did develop a substantial difference of opinion in how to value customers. It revolved around how to handle capital expenses. The FG was adamant that any customer valuation include capital expense; I felt strongly that the customer LTV should not. I had two reasons. First, no future customer activity could effect capital projects that had already been purchased. LTV should be about customer impacts to LTC, not things that individual customers had little impact on. Second, including capital expenses would mean that 25% of the customers would have negative value; without capital expenses 7% of the customers would be have negative value.

Let me digress here on negative LTV. By and large, in any company there will be some customers that cost more in company resources than they bring in in revenue. One of the best goals of any LTV project is correctly identifying customers of negative value so they can be understood, targeted, addressed, and if necessary 'fired'. It is absolutely natural to take customers with negative LTV and take them out of customer retention programs.

Cutting 7% of the base out of marketing programs at LTC designed to increase retention would have minimal impact on the overall attrition results. Taking 25% of the customer base out of retention marketing programs would have a definite impact on the corporate retention efforts.
LTC lived and died by retention and attrition. If LTV hurt retention then LTV would be quickly and quietly abandoned.

We spent months in rounds of inconclusive meetings with FG, asking again and again about the correct formulation. Suddenly, they agreed with us and we could go forwards. As we found out later, their agreement was by accident. The FG simply misread the formula we were laying out and thought it included capital expenses. By the time the FG realized they had made a mistake the LTV system was already in production and going forwards.

There is a bit of an irony here. If the FG had simply worked with us and given us their cost formula we would have taken it uncritically and not done the research to discover the issues around capital expenses.

Despite our differences the two groups did come to an understanding and became allies on many issues. Both groups wanted to move LTC from gross revenue to sustainable profit. We both realized that two areas that LTC had ignored, off-net expenses1 and bad debt expenses, were critical to profitability.

Blog in your native Indic Script!

noreply@blogger.com (Edmund Freeman) — Thu, 10 Apr 2008 04:22:00 +0000

Blogger somehow wants me to start blogging in Indic. It somehow thinks I'm a native Hindi.

I'm still tring to figure out how it came to that conclusion. Really bad data mining I guess :-). Or maybe it's just asking everybody to blog in Indic.