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.

Digital Transformation Playbook

I read a good book over Christmas break, The Digital Transformation Playbook, by David Rogers.  This is a good book because it has both theory and practice, plenty of research and real-life examples, and practical “how to” guides.

Just when you’re thinking, “oh yeah, when has that ever happened?” Rogers comes up with an example.  Many of the these include commentary from the people who worked on them.  It’s clear that the professor gets out of his classroom for a fair amount of consulting.

Digital transformation is not about technology – it is about strategy and new ways of thinking.

Most books like this focus on digital native startups.  That’s the sexy stuff and, in fact, where I have most of my experience.  I chose this book for its focus on digital transformation, in existing companies and hidebound industries (like auto retail).

The book is organized around five strategic themes: customer networks, platform marketing, upgrading your value proposition, data as an asset, and innovation through experimentation.

I did grow a little impatient with Rogers’ incessant enumerating: five core behaviors, four value templates, three variables, two trajectories (and a partridge in a pear tree) but I appreciated the effort to boil everything down to a foolproof recipe.  There are a number of these:

  • Customer Network Strategy Generator
  • Platform Business Model Map
  • Value Train Analysis
  • Data Value Generator
  • Experimental Design Templates
  • Value Proposition Roadmap
  • Disruptive Business Model Map
  • Disruptive Response Planner
  • Digital Transformation Self-Assessment

I was even inspired to start making value train diagrams of our business, and platform model maps:

On the theory side, Rogers reexamines familiar models from people like Drucker and Levitt.  He shows, for instance, that Christensen’s theory of “digital disruption” is a special case, and broadens it.

By the way, this discussion of digital disruption is one of the most lucid (hype-free) that I have read.  As usual, there is a checklist: analyze three features and choose one of six strategies.  If that doesn’t work then, yes, you’re disrupted.  Time to update your resume.

I read all the time, though I don’t often write book reviews (here is the last one) so Rogers’ fifteen-page bibliography was an extra treat.  That should keep my Kindle stoked for a while.

Wanted: eCommerce Product Manager

Things are going well here at Safe-Guard, and I am looking to hire another eCommerce Product Manager.  Posting is here.  We need someone who can not only manage a shopping site but, as we are in the midst of a digital transformation, also establish the required support and fulfillment processes.

The eCommerce department manages the development and support of these properties, whether they are standalone web sites, dealer-site storefronts, or web services … 

The successful candidate will have solid product management experience, and maybe some digital marketing.  Agile development experience a plus.  Self-starter.  Relocation.   Salary commensurate with experience.

Toward a Digital Auto Marketplace

Will the big public groups dominate online retail, as I predicted last week, and drive private dealers from the field?

This trend seems to have recovered, after some false starts, with the availability of fresh talent like Shift, Drive, and Roadster.  Shift has $253 million in funding, notably including Lithia.  AutoNation has recently invested $50 million in Vroom, valuing the online startup above $700 million.

How can smaller groups compete in this high-stakes contest?  One way, as I wrote here, would be to consolidate themselves online.

To defend themselves online, private dealers will migrate into the most capable of the platform sites. The winning platforms will not be mere lead providers.

I know something about platform marketing, having organized the Provider Exchange Network around cross-side network effects.  The more menu systems we added on the dealer side, the more success we had with F&I providers on the other side.

The difference between a selling platform and a mere lead provider lies in the site’s ability to deliver a completed deal.  That is:

  1. Show the true price online.
  2. Sell protection products.
  3. Provide a firm offer for the trade-in.
  4. Offer hard-pull credit approval and deal structuring.
  5. Allow the customer to save multiple deals and self-close.
  6. Sign the contracts online.
  7. Provide for home delivery.

Home delivery is not just a nice touch.  It demonstrates the capability to truly complete the deal online, with no tasks left over.  It is the acid test for online retail, even though most customers will opt to finish the deal in person.  The tasks are described here, and the workflow is here.

This capability is not so far-fetched as it was when I started writing about it, some years ago.  Delivering it on a multi-dealer site, however, poses special challenges.  The only eCommerce capable sites I can think of are run by monolithic used-car dealers Shift, Vroom, Carvana, and CarMax, or single points using digital storefronts from Roadster, Drive, and TagRail.

So, I am back to writing about the future.  In the fullness of time, someone will figure out how to do eCommerce for:

  • New cars
  • Multiple new-car stores in a group
  • Multiple unrelated new-car stores

When I started writing about the platform concept, I naturally assumed that Autotrader, et al., would be there.  Now that I have spent some time exploring Autotrader, Cars.com, Car Gurus, Edmunds, GoGo, Carfax, TrueCar, Autobytel, Kelley, and Deliver My Ride, I can tell you this is still uncharted territory.

Everybody promises eCommerce, of course, but most stumble at the first gate.  This challenge, price transparency, was supposed to be TrueCar’s edge.  In fairness, the platform model poses some special challenges:

Price Transparency – This one needs no explanation.  Despite glimmers of hope from the Rikess Group, online pricing is mostly confined to used cars.  A new car marketplace would have to disclose, on the search results page, prices from competing dealers.

Protection Products – Same story here, as regards pricing.  Also, if you want to do it right, you need to copy the dealer’s menu system setup, and ping those providers for pricing.  In fact, each step of the online process needs an interface with its “system buddy” in the dealership.

Trade Valuation – There are plenty of tools, but participating dealers must agree to honor the platform’s valuation.  This is easier if the platform happens to be Kelley.

Credit Approval – Each dealer will have their own stable of finance sources.  It’s best simply to bounce the application off the dealer’s Route One or Dealertrack credit system, and then return the results to the platform.  This data needs to be in synch with the dealership anyway.

Deal Structuring – I complain all the time about weak payment calculators on consumer sites.  The special challenge here is that data must be shared with each dealer’s desking system, and the calculations must match.

The rest of the process is pretty much unchanged from single-dealer: saving and transmitting the deal, signing (standardized) forms with DocuSign, and scheduling the delivery.

I recognize this is but the broadest broad-brush outline.  My purpose here is not to explicate the design, but to illustrate how progress toward the digital marketplace is impeded by these special challenges.

We may need to cooperate with a direct rival due to interdependent business models or mutual challenges from outside our industry.

How will these challenges be resolved?  Will competing dealers learn to cooperate, for the sake of their online survival, or will the palm go to a single online victor – like AutoNation, or Amazon?  The quote above is from Professor Rogers’ definition of “coopetition.”

Smaller groups cannot afford to invest $50 or $100 million, as AutoNation and Lithia have done.  Look a little farther down the league table, though, and it’s not hard to find four or five dealer groups which, combined, match the scale and revenue of a public group.

Joint ventures are not unheard of in our industry, especially when it comes to eCommerce.  My own brainchild (and eCommerce platform) PEN, like CVR before it, is a joint venture between archrivals CDK and Reynolds.  Route One is a creation of the Detroit three captives, plus Toyota.  Honda and GM are working together on electric cars, while BMW and Daimler collaborate on mobility services.

Combining four or five dealer groups simplifies the problem, relative to a fully open marketplace.  It reduces the number of systems, lenders, and product providers that need to be integrated.  The ideal venture partners would already have a high degree of standardization within each group, and similar choices of software among them.

Such a project might proceed “depth first” by developing core functionality in one partner, and then folding in the others, or laterally by function, or by merging the existing eCommerce capabilities of the partners.  What to aim for as “minimum viable,” and how best to expand it, depends on a number of factors.

Meanwhile, the commodity lead business is under pressure.  Damage reports and reviews do not offer adequate differentiation, whereas investments in eCommerce could yield significant new opportunity.  The Cars.com situation marks the beginning of the shakeout, consolidation, and – just maybe – the digital marketplace.

Asbury Drive in the House

Photo Credit: Nyisha MorrisKelly and I were sipping coffee at Digital Dealer, greeting participants, and speculating on how the ultimate online buying experience would come to pass.  Presenters had talked about Amazon, obviously, and the recent opening of a Hyundai digital showroom on Amazon Autos.

A while back, I organized the various offerings into categories like: online platforms where multiple dealers may list their inventory (basically lead providers) versus eCommerce plug-ins to be placed on individual dealer web sites.

One key variable was whether the site actually holds inventory, i.e., is a dealer, not just a technology play.  Carvana, for example, or Shift.  Increasingly, what I notice is that the good technology either evolved from a dealership, or – I found this intriguing – they will buy a dealership to serve as a test bed.

Your rapper name is a top twenty dealer group plus a digital retail system.

Roadster came from a concierge buying service which, as far as I know, they still operate.  A2Z Sync came out of Denver-based Schomp group.  The Gogocar people operate a Kia dealership.  This brings me to the next level of dealer technology tie-ups, those where big dealer groups choose an online retail solution and commit to it.

Roadster is working with AutoNation, Lithia just bought a big stake in Shift, and Drive is in all Asbury stores.  The Lithia deal is pure genius, because it allows Shift to handle more inventory and slashes their floorplan costs.  The many links in this post show support for my prediction using publicly available information.

We philosophically do not believe that software development is our expertise. Instead, we’d prefer to partner with third parties – Craig Monaghan

That prediction is … continuing the consolidation megatrend, we will see dominant groups taking the lead in online retail, but unable to master the technology on their own.  This is what I call the “Kodak syndrome.”  Incumbent leaders are not agile enough to ride a paradigm shift.  This means not only the dealer groups, but the traditional software vendors.

I expect to see the Sonics and Asburys of the world buying up the digital retail people, absorbing their talent, and denying access to their competitors.  I characterized this as a “land rush” in the earlier piece.  Direct to consumer is the final frontier.

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.

Organizational Debt

In today’s post, I add to the copious literature on technical debt with a discussion geared to my audience of F&I entrepreneurs, and extend the metaphor into organizational design.  What I noticed, writing Maturity Model, is that software development is rich in models and metaphors that apply outside the trade.

Technical debt is incurred when software developers take shortcuts, usually because they are under time pressure.  This debt is accrued in program code, but it must eventually be paid off with real money, just like the debt on your balance sheet.  Here is a brief discussion of how that works.

Someone once insisted that my team “just code IF State = TX, and get on with it!”  Not on my watch.  We will categorize Texas, and then we will add other states to the category as we discover them.  For example, the category might be “waiver GAP states,” or “spousal consent states.”

Operating or back-office issues, often related to IT, are recurring concerns for strategic buyers. Problems with IT underinvestment have proved to be ordeals during many integration efforts.

If you go down the road of IF State = TX, then in short order you will have code with IF <list of ten states> do this logic, and for <five of them> also do this other logic, but for <three of the ten> do this instead and for <the other two> do both of those things.

Congratulations, you have saved forty hours of programmer time versus stubborn Mark Virag and some academic exercise involving categories.  Now you are married to this gnarly decision tree, and you will be debugging it forever.  The technical term is Big Ball of Mud.

One warning sign of technical debt is the “cut and paste” approach.  If your developers implemented the latest dealer, provider, lender, product, or state by copying code from the one before, then I guarantee you have technical debt.

Any developer worth his salt will, instead, make the copied code into a reusable method.  Developers are trained to do things the right way and, in my experience, only take such shortcuts because the boss told them to.

Why not cut and paste, if it gets the job done?  Because, if there are any bugs in the copied code, now they’re multiplied and scattered throughout the code base.  You will have to spend programmer time to fix each one separately, as they are encountered over time.

I could go on with examples all day.  The point I want to make is that technical debt is real money.  You may go “quick and dirty” this week, and save $5,000 of developer time, but you will be paying those same developers later when they have to fix the bugs.

You may reasonably decide that you are a little short this month, and take a loan from the invisible bank of technical debt, but you should do so consciously.  Don’t fool yourself that technical debt is free.  I have provided an example here in the form of TILA box, something my F&I readers will understand.

Now that I have that off my chest, let’s discuss investment decisions.  For example, if you’re a startup and strapped for cash, you may choose to pile up technical debt because it’s off balance sheet and may be the only kind of financing you can get.

Of course, no one actually thinks about it this way.  What they tell their developers is, “just keep patching it until we’re profitable and you can overhaul it later.”  You may even sell the company, rickety software and all, if the acquirer fails to do proper diligence.

When I was doing international software search for BMW, our due diligence guy in Munich was Dr. Dettweiler.  We would find some software that looked pretty on the outside, and then the doctor would fly in and discover it was all a façade, like a movie set held up with sticks.

McKinsey specifically warns against acquiring a company with a big ball of mud in the back office.  Like process maturity, this is a concept that goes beyond software development.

In my time as a consultant, I have designed an organization or two, and it’s a lot like programming.  You have to have the right boxes on the org chart, with the right procedures and job descriptions, kind of like designing objects that will respond to business events (except they’re people).

Organizational debt is caused by the same kinds of things that cause technical debt.  For example:

  • The structure worked fine ten years ago when we had one-tenth the number of people.
  • It was never actually “designed” to begin with, but we reorganize ad hoc every other year.
  • The structure is based on specific people instead of job functions.
  • There are processes for which no one is actually responsible, so things “slip through the cracks.”

Fortunately, people are remarkably resourceful.  They will create their own procedures and informal networks.  Good people can prop up a bad organization, like those sticks holding up the movie façade, but they can only hold out so long.  Sooner or later, they will start to slip – and customers will start to notice.

Now I feel like I really am writing a pitch for consulting services. Call now!  Free reorg with every digital transformation.  Seriously, though, my point is that organizations can harbor technical debt just as software can.  This is why I am a fan of formal methods like ISO certification and, yes, professional organizational design.

More broadly, I am starting to notice that software development concepts – like process maturity, technical debt, iteration, and agile teams – are applicable throughout the enterprise.  We’ll explore this further in an upcoming post.