Provider Support for Digital Retail

A couple of press releases caught my attention last week.  The first one was APCO Acquires Strategic Diversified.  So, what’s new about that?  F&I providers have been acquiring agencies ongoingly, in parallel with consolidation among car dealers.  What caught my attention was this, from CEO Rob Volatile, “the additional resources APCO will provide, particularly in digital retailing, will help our dealers thrive in the changing times ahead.”

“The additional resources APCO will provide, particularly in digital retailing, will help our dealers thrive in the changing times ahead.” 

By now, everyone understands that small dealer groups don’t have the resources to compete effectively in digital retail.  This includes even the mighty Larry Miller group.  As CEO Steve Starks said of the Asbury sale, “we had grown the business about as large as we could without having an over-the-top digital retail strategy.”

Product providers, agents, and finance sources must have value-enhancing digital skills – which brings me to the second press release, Assurant Unveils Omnichannel Sales Optimization Suite.  This, again, is not new.  All providers have some kind of digital outreach program.  I served on the digital retail team at Safe-Guard.  In addition to my main job of growing the API business, we provided research, content, and coaching to our clients – not unlike Assurant’s offering.

What caught my attention was the high-profile announcement including, as McKinsey recommends, senior leadership for digital transformation.  This same SVP, Martin Jenns, is quoted here in an Automotive News roundup.

How F&I Providers Can Support Digital Retail

So, what can a product provider do to support “omnichannel sales optimization?”  I asked some of my pals in digital retail.  Definitely the training and API capabilities, plus digital content.  Cited as leaders were Assurant and JM&A.

“Providers should pay specific attention to how their products will present on a digital retail platform.”

The best advice came from AutoFi’s Matt Orlando, who told me, “providers should pay specific attention to how their products will present on a digital retail platform.”  That is, instead of the (completely different) experience on a portal or a menu.

For example, a service contract may have more than one hundred combinations of coverage, term, deductible, and other options.  That doesn’t work for an online consumer.  Providers should apply some analytics, Matt said, and transmit only the most-likely rates.

Short, snappy videos are the preferred digital content.  Digital retail vendors will generally set these up on request although, in my experience, it’s better if the provider can transmit the latest content via API and in various formats.  See my REST Primer for F&I.

  • White papers – Do some research, find success stories, and write informative long-form articles. Also, promotional content like newsletters, roadmaps, infographics, and this eBook.
  • Coaching – For your non-reading clients, be prepared with live-delivery content – and people.
  • API capabilities – Invest in advanced API capabilities like real-time analytics and digital content. Push the envelope of what digital retail can present.
  • Digital content – Produce digital content as video, image, and rich text (not HTML) for each level of your product hierarchy.
  • Resource center – Make all of this available to your clients using a purpose-built microsite – and people.

I remember back when the old-timers used to say that protection products “are not bought, they’re sold.”  Well, digital F&I results now exceed those in-store, with some platforms reliably above 2.0 product index.

In the midst of an inventory shortage, dealers must sell more product on fewer vehicles – and product providers must be part of the solution.

REST Primer for F&I

I have worked with more than a few APIs, both “F” and “I” – pretty much all of the product APIs, plus the original open standard for credit applications – and I write about them occasionally.  See here, here, and here.  Mostly these have been SOAP, but REST is the standard for a growing community of digital retail players.

The first thing you need to know about REST is that it’s not synonymous with JSON.  If you get this wrong, you can produce a really bad API.  I saw one once, where the developers had simply converted all their old XML payloads to JSON.  You could tell because every call was a POST, even the rate requests.

Why is JavaScript more successful on the Web than Java? It certainly isn’t because of its technical quality as a language – Roy Fielding

The key to REST, as you can read in Roy Fielding’s dissertation, is making appropriate use of the Web’s native HTTP environment.  Practically, this means knowing a little bit about HTTP and how to use its commands, URLs, parameters, and headers.  For a concise guide, see The REST API Design Handbook by George Reese.

Philosophically, it means thinking about your API in terms of resources and not services.  This is completely different from SOAP APIs, which are called web services.  For example:

  • GET rates from a product provider, but
  • POST a new contract, and then
  • PUT status codes on the contract to void or remit

Fielding’s achievement was not only to define the REST style, but to derive the style from a specific set of requirements: stateless, client-server, code on demand, etc.  If you have ever wondered why JavaScript has become so popular, it is because JavaScript satisfies the code on demand requirement.

When you build a RESTful API, you should never break existing client code. Really, never. You don’t deprecate – George Reese

The URL in a REST call looks like a path, so you can do groovy things like:

  • GET /rates/{dealer} – gets all applicable rates for this dealer
  • GET /rates/{dealer}/{product} – gets only one product
  • GET /rates/{dealer}/{product}/GOLD – gets only the Gold coverage
  • GET /text/{dealer}/{product}/GOLD – gets the rich text description for Gold

For some live examples you can run right now, check out the NHTSA Vehicle API.  It has many handy methods like:

  • /vehicles/DecodeVin/{VIN}
  • /vehicles/DecodeVinExtended/{VIN}
  • /vehicles/GetAllMakes
  • /vehicles/GetEquipmentPlantCodes/{Year}

Note that you are making the request with straight HTTP and a query string, and you can have the response as JSON, CSV, or XML.  The NHTSA site will also show you the headers, the raw data, and formatted data.  Your tax dollars at work.  You should also check out the Edmunds API, VinSolutions, and Fortellis.

  • //api.edmunds.com/api/vehicle/v2/vins/{VIN}
  • //api.vinsolutions.com/leads/id/{LeadId}
  • //api.fortellis.io/vehicles/reference/v4/vehicle-specifications/vins/{VIN}

These are all examples you can emulate if you’re just getting started.  In particular, I recommend studying how they handle authentication and versioning.  Note how they’re organized around resources and, if you have an OO mindset, think of your objects first.  You will also want to look at platform tools like Swagger and MuleSoft.

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.

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.