Tag: MenuVantage

Caching the Rate Response

Every so often, I am asked to write on a specialist topic for F&I technology, like surcharge processing, term bumps, or credit life math.  Today’s topic is well known in dealer system software, but bears repeating for the new generation of digital retailers.  This is the problem of how long it takes to receive rates for protection products from the provider’s web service, also known as “latency.”

The good news is that all providers today expose their rates via web service, so they’re always up to date and tailored to the current deal.  It wasn’t always thus.  We once had to scan reams of paper rate guides, and walk ten miles in the snow.  The bad news is that the web rating call can take several seconds to run.

A savvy rate response already has Squish VIN in it, so you just smack the whole thing into Mongo and you’re good to go. 

In the typical scenario, a menu system calls the provider’s web service directly, passing the VIN and the dealer number.  The dealer number is required because product pricing and selection may vary with the dealer.  This may not be the case for digital retail.  You may have a standardized slate of products (or just one product) with a mandatory fixed retail price, and not care about dealer-specific costs and packs.

You still have to pass the VIN, in any case, because most products are risk-rated by model.  Then you wait.  At MenuVantage, we set the timeout for twenty seconds.  If a provider couldn’t respond within twenty seconds, they couldn’t be on the menu.  Digital retail, of course, requires a much faster response.

The rate response for an old-school SOAP call, returning all products for a single model, is about 500 KB, or 10,000 lines of XML.  I have seen them exceed one megabyte (you know who you are).  A well-done web service can transmit the rate response in about one second, and then another second or so for the integration hub.

Most menu systems do not interface directly with the provider.  They go through a central hub like PEN or F&I Express.  These are the main ones (full disclosure: both are clients) but there are others, and a slow rate hub can add seconds of latency.  Digital retail is more likely to be using REST and requesting a specific product.  The biggest product is a service contract, weighing in around 2,000 lines of JSON or 100 KB.

Ideally, all networks and services would be fast, and you would always send the request.  “The network is the computer.”  On the other hand, maybe you ought to cache the rate response.  To do this, simply save each response in a database, keyed by dealer number and Squish VIN.

If you’re in the “don’t care about dealer” scenario described above, then omit the dealer number.  If you expect to rate specific products, as opposed to the menu scenario, then take apart the response according to its (provider-specific) product segmentation.  A savvy rate response already has Squish VIN in it, so you just smack the whole thing into Mongo and you’re good to go.

The point to Squish VIN is that, of the 17 characters, only ten really matter.  The first eight identify the model and trim, and the tenth position encodes the model year.  This is what the provider uses to risk-rate by VIN.

Common practice for digital retail is to pull an inventory list and rate every vehicle on the lot.  That’s some redundant rate requests.  A dealer might have 500 cars on the lot, but only seventy unique VIN patterns.  Even if you’re compulsive about stale cache, and you want to rate every night, this is still a sevenfold improvement.

So, the procedure is: every time you want to rate, either in batch or on demand, go first to the cache.  If there is no matching Squish VIN in the cache, only then must you take the hit for a live rate request.

Menu systems generally do not do the lot-scan thing.  This seems to be new with digital retail.  Generally, we would just expire the cache at midnight and start rebuilding with the next day’s deals.  The first Cherokee takes a hit, and then the first Wrangler, and after that you’re rating Cherokees and Wranglers all day long from cache.

Also new with digital retail are various use cases that don’t require a dealer number.  This vastly improves the efficiency of the cache.  Instead of seventy VIN patterns per dealer, you might have seventy for the whole country.

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.

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.

Selling F&I Products in the Service Lane

Automotive News reports the success AutoNation is having, selling F&I products in the service lane.  I thought MenuVantage dominated service-lane selling, and I was dismayed to see AutoNation using a different system.  I am not with MenuVantage anymore but – old rivalries die hard.

What caught my eye was the point about service-lane buyers needing a way to finance their service contracts.  I have a few words to say on this point – Service Payment Plan.  My pal Bob Hymen offers zero percent financing, and a complete selling kit for the service lane.

Service Payment Plan is integrated with a number of menu systems including MenuVantage.  The F&I Manager can create a finance contract for any of the leading providers, as shown here:

After that, the system prompts for a credit card or bank account, and then generates all the required paperwork.

Group 1 Facing F&I Challenge

Automotive News reports that Group 1 has suffered a nine-percent drop in F&I gross, and is hiring regional directors to bring it back up.  I certainly agree with this approach.  It worked for us, when I was at AutoNation.  We called them “district finance directors” back then.

Group 1 CEO Hesterberg says tighter lending limits do not allow much for F&I product sales.  Since Group 1 is a MenuVantage user, they can address this problem using the system’s goal-seeking feature, as shown here:

This helps the F&I Manager to sell products up to the full amount authorized.