Tag: API

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.

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.

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.