Pay Plan Math

Feeling quantitative again today, so … suppose you have an F&I Director, or a menu trainer, or somebody, and their goal is to move product index from 1.0 to 1.2 over some time period.  To keep the numbers simple, let’s say the variable comp component is \$10K.

One way to do this is to say that 1.2 pays \$10K and the current performance, 1.0, pays zero.  This makes sense, right?  Why pay for no improvement?  This only works, however, if you place a cap on it.  As the salesman, I could come back and say, fine, if the two points of product index are worth \$10K to you, what happens if I hit 1.4?  Are you willing to pay me \$20K for that?

Most people resist the idea of capped pay plans.  Mathematically, you are making a linear relationship between compensation and performance, and you should be willing to honor that relationship up and down the line.  The problem here is that the line is too steep.

So, let’s try a shallower slope.  Once again, 1.2 pays \$10K, but this time the zero point is 0.0.  That means the current performance, 1.0, still pays \$8,333 and the salesperson doesn’t go hungry unless the index actually falls all the way to 0.0.  Obviously, this plan is too weak.

The weak plan may be desirable if your sales force is really counting on some of that money, and the “variable” is not as variable as advertised.  It also protects the company on the up side.  In this example, I can achieve a 1.5 index and it only earns me an extra \$2,500 (on top of the \$10K).

Now we have examples of two pay plans, one too strong and one too weak, as in the story of The Three Bears. The key to making the pay plan just right is to observe that the zero point is arbitrary. In the papa bear case, too strong, we set the zero point at 1.0, the current performance.  In the mama bear case, we set it at an index of 0.0.

Recall that a line on a graph is determined by two points.  One point is fixed by the target and the bonus (1.2, \$10K) the other point is set by where you place the zero (z, \$0) and between them they determine the slope:

If you’re making this chart right now remember to place the independent variable, product index, on the x-axis.  All that remains is to compute the y-intercept of your line.  The point where the bonus is zero, z, is the x-intercept.  A little algebra gives the y-intercept as:

Now we are ready to start plotting.  This time, let’s split the difference and set the zero point at 0.5.  This seems to be just about right.  Comp for standing still, 1.0, is \$7,143; for 1.5, only \$14,286, and our guy doesn’t starve until 0.5.

If you have this set up in a spreadsheet, you can tweak the zero point until you have the desired amount of exposure for both parties.  Below is the chart for my “goldilocks” line, with the mama bear case for comparison.

We always give careful thought to the target, but sometimes neglect the slope of the payoff line.  Next week, we will talk about two-dimensional pay plans, combining product index and PVR.

I felt like doing something quantitative, so this week we look at seasonal adjustment factors.  Everybody always talks about SAAR, and you probably know that it stands for “seasonally adjusted annual rate,” but what does this really mean?

Well, suppose it’s March 2017, and you are wondering what total sales will be for the year.  The industry sold 1.55 million vehicles that month so, if you multiply by twelve months, you might estimate 18.6 million for the year.

You would be wrong, though, because March is always a strong month.  Here are the estimates produced by the simple “times twelve” method, relative to the actual total for 2017, which was 17.2 million.

Using data from Fred for the five years 2013 through 2017, and converting everything to a percentage, you can see how March always overestimates the year’s results.  Each year’s dots are a different color, though it doesn’t really matter which is which.

Some months are highly variable, like September.  Not a good gauge of anything.  Remember to distrust any SAAR figures published in September.  April, oddly, is a tight group and bang on the annual rate.  April 2018 sales were 1.4 million, so a good guess for the year is 16.8 million.

Taking an average across the five years, we find that March, May, August, and December each overshoot the annual rate by roughly 10%.  Finally, we convert these percentages into monthly adjustment factors.

Instead of multiplying last month’s sales by 12, multiply by the monthly factor to predict the year’s total.  Of course, we have more data than just a single month.  We can also look at cumulative sales since January.  For example, do a quarter of the year’s sales occur in the first quarter?

No.  It takes a while to make up for the weak January and February, and then the actual historical cumulative pace slowly comes into alignment with the idealized linear cumulative pace.  I made that chart, too, but it’s not pretty.  That’s enough quantitative stuff for this week.

Life (Credit Life) without Recursion

I was chatting with Tim Gill the other day about auto finance math, and the topic of recursion came up.   Tim is one of the few vendors in this space with his own “calculations engine.”  Otherwise, there are not many people who will talk to me about esoteric math problems.  That’s why I write a blog.

People commonly describe Credit Life as a recursive calculation or, more properly, an iterative one.  This is because the premium must cover the amount financed, and the premium is itself financed.  So, if we write the premium as CLP, a function of the amount financed, A, then:

This is generally how people solve it.  They run a few iterations, and CLP converges quickly.  This is a preference, however, not a requirement.  Assuming that the premium calculation is distributive over addition, which it is, we can just as easily set the problem up as:

… which can be solved analytically.  This approach will work for most of your popular recursive calculations, like GAP insurance.  For an example, let’s take a typical “cost per thousand” insurance calculation, where f works out to ten percent.  You could go the infinite series route, which looks like this:

Or, you could simply work the algebra problem:

Now, I know what you’re thinking.  You’re thinking that credit life calculations are far too complicated for this approach.  You may also be thinking that the premium is based on the monthly payment, M, not A.  In fact, these complaints are related.  The payment is directly related to the amount financed, through the PV annuity factor, which combines the term and the APR into this handy relation:

So, when you see a payment formula like this one:

The insurance carrier is actually helping you, by combining the calculations for premium and monthly payment.  By the way, the last time I checked, C# did not have the payment and related methods from VB and Excel.  You are much better off coding your own PV annuity factor, and using it as described here.

Now, if you are designing a calculations engine, you may still prefer to use iteration, for the same reason that you may not want to algebraically reverse all your tax and fee calculations.  It is better, though, to use your algebra and know your options, than to rely blindly on iteration.