Category: F&I Products

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.

Six Month Term Bump for Menu Selling

Whenever I design a menu system, I always include a second finance term that defaults to the base term plus six months. When I did the first menu system for AutoNation, I was coached on this by Arthur Knosala who learned it, I believe, at JM&A.

We had an object lesson when I was working on Route One’s menu. The team was just getting into this requirement when the product owner happened to buy a new car, and took the term bump. She was able to maintain the agreed payment, and still buy some good products.  Even a three-month bump is significant.

My spreadsheet, below, shows how this works. The idea is to goal-seek the amount of product that maintains the original monthly payment, at the longer term. The input values are blue. Everything else is calculated. This allows the possibility that the APR may be higher with the longer term.

Term Bump

If your menu system won’t do this, you can download my spreadsheet. It automatically calculates the finance amount which, with the term bump, results in the same payment. Remember, only type in the blue cells.

Magic tricks are easy once you know the secret — Marshall Brodien

When I was at MenuVantage, one of the guys put together a demo in which he used the term bump to sell a raft of products, and then a biweekly payment program to ratchet the term back down.  It was like a magic trick.  Same payment, same term, and presto!  He pulls two thousand dollars’  gross out of his sleeve.  Dealers couldn’t sign up fast enough.

Lenders Outsource Forms Management

About a year ago, I did an informal survey of F&I product providers.  They were, and still are, moving toward a service-oriented architecture that prints forms and originates contracts online.  For providers who do not have a forms service, Provider Exchange Network will host forms at a nominal charge.  We offer this as a convenience, even though providers are moving away from it.

Lenders, however, are not moving in this direction.  This is mainly due to stricter regulation of finance contracts, and also the disparate experiences of the two groups.  In the late nineties, finance sources – both captive and independent – developed online credit systems. They subsequently moved to aggregators like Dealer Track, and many single-lender systems shut down.

So, while product providers have retained their online systems, and support their own services for e-contracting, most lenders do not.  This is why my colleagues in Lender Services are busy loading their forms library, while we are unloading ours.