Tag: F&I Products

Workflow for Online Car Buying

A few years ago, I published a precedence diagram for the key operations of online car buying.  I was arguing against a linear process, and calling attention to some deadlocks.  Since then, I have been following the industry’s experiments with new process models, and coming to realize that these deadlocks are the great, unanalyzed, obstacle to process reform.

Practices that seem unfair, deceptive, or abusive may actually be crude attempts to solve the deadlock problem.

One example of a deadlock is that you can’t quote an accurate payment until you know the buy rate, and for that you need to submit a credit application.  This is usually solved by iteration.  You do a pre-approval or quote the floor rate, and then change it later.

Likewise, you can’t price protection products until you know the vehicle, but the customer wants to shop by payment.  Protection products are also priced by term, and you don’t know the desired term until you finish structuring the deal.

In fact, even the customer’s choice of vehicle depends on the monthly payment, which is downstream of everything else.  Virtually the only operation that’s not blocked by another operation is valuing the trade.Like an interlocking puzzle, “we don’t know anything until we know everything.”  Choosing any one item to lock first, without iteration, will result in a suboptimal deal – buying too much car, for too long a term, or overlooking the protection products.

Practices that seem unfair, deceptive, or abusive may actually be crude attempts to solve the deadlock problem.  For instance, quoting a payment with some leg in it, or goal-seeking the full approval amount.

Can you see how this ties into current debates about the hybrid sales model?  F&I presents a menu with a six-month term bump, which might not be optimal, just to compensate for too tight a payment from the desk.

Fortunately, in the world of online car buying, the customer is free to resolve deadlocks through iteration.  This means:

  1. Set up the deal one way
  2. Change any feature, like the term
  3. The change “cascades,” undoing other features
  4. Revisit those other features
  5. Repeat until all features look good together

The in-store process does not support iteration well, and probably never will, but an online process can.  All you need is the well-known concept of a “dirty” flag, to keep track of the cascading changes, along with navigation and a completeness gauge to guide the customer through steps #4 and 5.

You could analyze step #3 at the level of a dozen individual features.  I made that chart, too, but I believe it’s more useful to collect them into the canonical five pages shown here.

By the way, I have previously described the products page in some detail, along with the analytics to drive it.  Discussion of the “random survey question” is here.  Today’s diagram contemplates a mobile app, as do my recent posts, but the same approach will work for a web site.

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.

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.

Cancellation Refund for Service Contracts

The last time you turned in your car, did you remember to get the refund on your service contract?  Me neither, and I have been in this business a long time.  The only way I know to get the refund is to dig up the paper contract and phone the provider.  It’s like the “breakage model” behind rebates and gift cards.

The first time I tried, professionally, to account for the refund was at GMAC Insurance prior to the bankruptcy.  I was working on an interface to do rate quotes.  Our plan was to detect the existence of a prior GMPP contract, and then apply the refund as a discount to the new contract.

Imagine how many vehicles are traded or repossessed and never see the end of their VSA or GAP contracts.  Actually, I don’t have to imagine, because I have statistics from Rich Apicella, who runs Express Recoveries.  This is an ingenious business model, leveraging the provider relationships of F&I Express to automate VSA refunds for lenders.

In case of a repossession, the refund from a product contract will reduce the deficiency balance.  What began as found money in the recoveries department is now a compliance requirement.  It never hurts to review the CFPB Examination Manual.  This is from page 42:

Recoveries

This is a great business for F&I Express, because it’s countercyclical.  Their main business is originating product contracts and then, when times are bad, they can earn some money cancelling them.  It’s also handy as a leading economic indicator.

Disclosure:  Intersection Technologies is a client and, although I am not working with Express Recoveries, they are just down the hall.  

How to Save TrueCar

My title is somewhat facetious, but “how to position TrueCar so that it makes dealers less hostile and invites fewer lawsuits” was too long. The Auto News forum is not exactly laden with objectivity. People see the headlines and the share price, and then they crow about TrueCar going out of business.

Complaints or negative publicity about our business practices, our compliance with applicable laws and regulations … could diminish users’ and dealers’ confidence in our products and adversely affect our brand

Investors are more objective, as in Why I’m Buying TrueCar despite the Sell-Off. You can look at the Morningstar rating (undervalued) and the quarterly report. TrueCar is making twice the revenue of Autobytel, and growing faster. Still, there is the hostility. Here are my thoughts:

  • Enhance the site to support online buying, as I have described previously.
  • Add features like the ability to sell protection products. This feature alone would compensate for foregone gross on the front end.
  • The platform should help individual dealers to compete with consolidators. Make it a “community” that includes dealers, affinity groups, and finance sources.
  • Prepare for a world of one-price dealers. Look at Scion, for example. The histogram for a Pure Price dealer has only one bar.
  • Use out-of-market data, consumer data, and statistical inference to provide a more detailed pricing picture. This feels less like “ratting out” the dealers.
  • Make the database a research tool, as Zillow is for homes. TrueCar owns ALG, so they already have the machinery.
  • Update the revenue model, to avoid legal classification as a broker. The current model, ironically, becomes less effective as more dealers adopt it.
  • Think about pay per lead, or monthly. I can’t share the details, but I understand the AutoNation deal could have been saved.

These measures should allay the hostility that some dealers have toward price transparency, and the TrueCar business model. If all else fails, and litigation persists, there is the “nuclear option.”

I can think of a few ways to end price obfuscation, for good. The practice is obsolete anyway (not to mention unfair and deceptive) and would not survive six months of concerted attack. Of course, that would also damage the TrueCar model, as presently constituted. I recommend doing the strategy alignment first.

TRUE