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.
Virag Consulting 