Category: F&I Products

Analytics for Menu Presentation

Last week, I presented a single-column format for menu selling on an iPhone, with the glib recommendation to let analytics determine the sort order.  Today, I will expand on that.  Our task is to sort the list of products in descending order of their relevance to the current deal, which includes vehicle data, consumer preferences, and financing terms.

This sorting task is the same whether we are flipping through web pages or scrolling down the mobile display.  The framework I present here is generalized and abstract, making the task better suited to automation, but ignoring the specific F&I knowledge we all take for granted.  I’ll come back to that later.

For now, let’s assume we have six products to present, called “Product One,” and so on, and four questions that will drive the sorting.  Assume these are the usual questions, like, “how long do you plan on keeping the car?”

That answer will be in months or years, and the next one might be in miles, but we are going to place them all on a common scale from zero to one (I warned you this would be abstract).  Think of using a slider control for each input, where the labels can be anything but the range is always 0.0 to 1.0.

Next, assign four weights to each product, representing how relevant each question is for that product.  The weights do not have to be zero to one, but I recommend keeping them all around the same starting magnitude, say 1 to 5.  Weights can also be negative.

For example, if there’s a question about loan-to-value, that’s important for GAP.  High LTV will correlate positively with GAP sales.  If you word that question the other way, the correlation will still be strong, but negative.  So, now you have a decision matrix that looks something like this:

Yes, we are doing weighted factor analysis.  Let’s say that, for a given deal, the answers to our four questions are, in order:

[0.3, 0.7, 0.1, 1.0]

To rank the products for this deal we simply multiply the decision matrix by the deal vector.  I have previously confessed my weak vector math skills, but I am certain that Python has an elegant way to do this:

Product Two ranks first, because of its affinity for high-scoring Question Four.  Product Four takes second place, thanks to the customer’s response to Question Two – whatever that may be.  By now, you may have noticed that this is the setup for machine learning.

If you are blessed with “big data,” you can use it to train this system.  In a machine learning context, you may have hundreds of data points.  In addition to deal data and interview questions, you can use clickstream data, DMS data, contact history, driving patterns (?) and social media.

If not, you will have to use your F&I savvy to set the weights, and then adjust them every thousand deals by manually running the numbers.

For example, we ask “how long will you keep the car?” because we know when the OEM warranty expires.  Given make, model, and ten thousand training deals, an AI will dope out this relationship on its own.  We will do it by setting one year past the warranty as 0.1, two as 0.2, etc.  We can also set a variable indicating how complete the manufacturer’s coverage is.

Same story with GAP.  Give the machine a loan amount and a selling price, and it will “discover” the correlation with GAP sales.  If setting the weights manually, set one for LTV and then calculate the ratio for each deal.

Lease-end protection, obviously, we only want to present on a lease deal.  But we don’t want it to crowd out, say, wearables.  So, weight it appropriately on the other factors, but give it big negative weights for cash and finance deals.

I hope this gives some clarity to the analytics approach.  In a consumer context, there is no F&I manager to carefully craft a presentation, so some kind of automation is required.

All about Surcharges

Now here is an article for specialists only.  Menu system developers must know how to correctly acquire and present service contract rates, and surcharges are the most difficult feature.  Integrators and product providers also struggle with this, and I am writing today in hopes of establishing some industry norms.

We start with surcharge policy, from the provider’s perspective, and then data transfer and presentation issues for the menu system.

A surcharge represents an ad hoc increase to the claims risk, and therefore the price, of a service contract.  It lies outside the conventional pricing model, which is:

  • Risk Class – it costs more to service a Camry than a Corolla
  • Coverage – which parts and services are covered
  • Term – contract duration in months and miles
  • Deductible – claims risk is mitigated by a higher deductible

A surcharge is an extra feature tacked on to the pricing model.  For instance, the provider might want an extra $200 to cover a vehicle having a modified suspension, a turbocharger, or four-wheel drive, or if the customer intends to use the vehicle commercially.

Adding a flat dollar amount to the price is straightforward, but not especially accurate from a claims perspective.  That turbocharger will grow more risky as time goes on, so it is smart to have the surcharge amount increase with the term.

Note that you do not need to stipulate a four-wheel drive surcharge for Subaru.  They are all four-wheel drive, and so you can account for this risk in the vehicle classification.  Fixed (irremovable) features of the vehicle may be treated either as surcharges or risk classes.  In this example, four-wheel drive is handled as a class code bump.

Likewise, deductibles can be treated as surcharges.  This is an efficient way to represent them in a printed rate guide, where a choice of deductibles would mean many additional pages.  In the example below, the rate guide is printed with a base deductible of $50 and four more as surcharges.  Note that the surcharge amounts vary with the term mileage.

Warranty Solutions uses a similar approach, except that the surcharge amounts vary with the cost of the base contract.  They reckon that the risk associated with the vehicle, coverage, and term is already reflected in the cost, and so the surcharge should be higher on a higher-cost contract.  In my time as a consultant, I have seen everybody’s rate guide, and every possible way to handle surcharges.

It is important to recognize that a printed rate guide is just one way to represent the provider’s evaluation of risk.  As with Sapir’s theory of language, the provider’s actuary can only evaluate risks that can be expressed by the pricing model.

Where rates are returned via web service, there is no need to treat deductibles as surcharges.  They should be an explicit part of the pricing model, as above.  Where the VIN is supplied as input, likewise, there is no need to specify vehicle surcharges.

Many rate guides distinguish between “mandatory” and “optional” surcharges, but all surcharges are required to be levied where applicable.  Therefore, the usage I prefer is:

  • Mandatory Surcharge – We know it from the VIN, like a turbocharger
  • Optional Surcharge – We have to ask, as with commercial use

The user experience for a mandatory surcharge is simply to notify that we have already applied it to all rates in the web service response.  For optional surcharges, the menu system must provide a checkbox or some other way to apply it.

In either case, it is best for the web service to apply the surcharge to all rates in the response.  This allows for a smaller payload, and no chance for error.  The only reason to send rates both with and without an optional surcharge is if the menu system lacks the ability to request it up front.

Menu systems today already have user controls for the well-known surcharges, like commercial use, lift kit, snowplow, van conversion, warranty preload, synthetic oil, and rental coverage.  As a developer, I don’t like the idea of hardcoding these controls.  I would rather the menu system generate the controls at deal time, using a separate web service to obtain the list.

There is one kind of surcharge that must be included separately in the rate response.  These are additions to coverage which the F&I Manager may upsell at deal time.  The mockup below shows the addition of optional electrical to one grade of coverage, which is included with the higher grade.

Because the F&I Manager may toggle this surcharge dynamically, there is no alternative but to include it in the rate response.  This means an extra branch at the coverage node, assuming a tree structure, or else sprinkle the surcharge among the leaf nodes and make the menu system do the math.

  • Upsell Surcharge – We may choose it dynamically at deal time

Either way, dynamic surcharges will bloat the rate response.  The workaround we used at MenuVantage was to treat them as optional surcharges, above, and ask the F&I Manager to choose prior to rating.  I frankly hate dynamic surcharges, a prejudice from my menu days, but people evidently find them useful.

That about does it for surcharges.  If anyone has anything to add, in the spirit of setting industry norms, please write in.

Wanted: eCommerce Product Manager

Gartner Group says “the API is the product.”  I am looking for an experienced product manager who knows what Gartner Group is and why they say that.  The API in question is Safe-Guard’s collection of dealer-facing web services.  This is a topic I have worked on and written about extensively, as here, and now I plan to try the product manager approach.

The successful candidate will have solid product management experience, preferably with an API, and maybe some pragmatic marketing or agile development.  Software development experience a plus.  Self-starter.  Relocation.   Salary commensurate with experience.

Wanted: Experienced F&I Trainer

I am in the process of creating an eCommerce department for Safe-Guard.  Regular readers know that I specialize in creating new organizations, and my record is pretty good.  The training function, which is also a kind of sales function, is likely to grow.  So, this is an opportunity to get in early.

The job is to train all of the F&I managers who sell products administered by Safe-Guard, and ensure they know how to present them properly using any of the top ten menu systems.  For one person, at least to begin with, this will be a challenge.  We are in thousands of dealerships.

Thus, the successful candidate must have the skill and temperament to leverage the resources of our affiliated agents, vendors, manufacturers, and dealer groups.  Self-starter.  Travel.  Proficiency in F&I procedures and software, notably menu systems.  Salary commensurate with experience.

Stop Using Combo Products

I have had a hand in designing a few menu systems over the years, and I have always disliked combo products.  You know what I mean: the VSA form, plus maintenance and PDR, on which Marketing has found an extra square inch to offer road hazard.

Menu people hate combo products because the whole point of menu selling is for the F&I Manager to combine products into menu columns, not the combinations defined by the provider’s form.  What if she wants to sell the factory’s VSA, but her own choice of ancillary products?

One cavil I sometimes hear is the definition of “a product,” but this is straightforward.  If it can be sold separately, like key protection, then it’s a product.  If it always rides on another contract, like car rental, then it’s not.

What I try to tell my menu clients (and reinforce with my API clients) is this:

  • The unit of work for presentation is the product
  • The unit of work for contracting is the form

The correct data structure thus has discrete products at the top level, then coverages with their rates, and form codes at the bottom.  Obviously, you can have different forms based on coverage, and you can have the same form for multiple products.  Then, in the contracting phase, you collect the products onto the forms as indicated.

combo-productsCombo products persist because providers legitimately want to reduce the number of forms they manage.  The two-phase approach solves this.  Also, there are old-timers who design products based on the form.  I have even seen F&I shops where the completed contract form is used as a selling tool.

The package discount is the only serious challenge to the menu system.  A workaround here is to include a phantom product with no display and a negative price – although that may be as much work as developing an explicit feature.  Of course, if the manager chooses to discount a package other than one subsidized by a provider, then that discount is her responsibility.

I’ll close with an exception to the rule or, rather, a refinement.  Menu systems are compromised when we mistake forms for products.  On the other hand, there is a practical limit (six) to the number of products offered on a menu.  So, I can see the logic in a product that combines dent, coatings, windshield, and road hazard – especially PDR and windshield, if you think about how the services are delivered.

In this case, we are not merely combining products based on a form.  These products hang together in the same semantic class, appearance protection, and may indeed use separate forms.

Full Lifecycle API for F&I Products

I have just wrapped up design work on a web service to cancel and refund F&I product contracts.  Whether a refund is owed to the customer, from an early termination, or to the lender as recovered funds, it is in the provider’s interest to support an efficient automated process.  On the lender side, it is also a compliance issue.

This job was rewarding for me because it completes the lifecycle I began automating, ten years ago, with electronic rating.  MenuVantage was a leader in rating and originating product contracts, and many providers adopted our model specification.

I then did related work at GMAC Insurance, which was to include claims processing.  Sadly, the crash of 2008 ended that project.  GMAC also had the bright idea to check for an earlier contract, and apply the refund to the results of the rating call.

product-lifecycle

The industry has been developing web service support piecemeal.  First, there was a need for rating and contracting, supported by companies like MenuVantage.  Now, there is financial and regulatory pressure to automate terminations, supported by companies like Express Recoveries.

In hindsight, a savvy provider would have looked at the core processes and developed web service support for the whole lifecycle.  It would look something like this:

  1. Dealer and vehicle information  Return customized rate structure
  2. Deal information with chosen rate  Originate contract
  3. Form request Return contract as PDF
  4. Form with digital signature Store in secure archive
  5. Blank form request  Return blank form
  6. Void request Void contract, if eligible
  7. Remittance query Return remittance log
  8. Remittance notify ⇒ Post pending payment
  9. In-force query Return contract data
  10. Claim diagnosis Verify coverage
  11. Claim estimate Approve/deny claim
  12. Claim entry Issue payment
  13. Vehicle data from contract Return cancellation quote
  14. Contract data plus authorization Cancel contract, issue refund

You could do one big API to manage the product from cradle to grave, and build provider portals and such on top of it.  This would have the usual benefits of decoupling the back-end from the presentation layer, and it would facilitate integration with dealer and lender software.

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:

Fig1This 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:

Fig2… 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:

Fig3

Or, you could simply work the algebra problem:

Fig4Now, 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:

Fig5

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

Fig6The 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.