Category: Online F&I

What is a Digital Storefront?

A digital storefront is a complete car buying experience that can be bolted onto the dealer’s existing web site, and integrated with the dealer’s instore process.  It must support all six of the canonical car-buying tasks:

  1. Choose a vehicle
  2. Price the vehicle
  3. Price protection products
  4. Value the trade
  5. Structure the deal
  6. Organize financing

This is not always a linear process, as I explained in Workflow for Online Car Buying, and not all customers will use the full process, as Andrew Tai explains in this video, but the storefront must support whichever tasks the customer chooses.  Details about the six tasks are given here and here.

… delivering an omnichannel experience that is unmatched and, we believe, will be the future of car buying – Bill Nash

When you think of a good online process, like the CarMax omnichannel sales experience, these tasks are a native part of the web site.  Dealers that don’t happen to be CarMax can offer an online process by bolting a storefront onto their existing web site.

As far as I can tell, this innovation is due to Roadster, but they are no longer alone.  Roadster’s Express Storefront went up at Longo Toyota two years ago.  TagRail, Modal, and Moto also compete in this space.  TagRail and Modal both brand their offerings as “digital checkout.”

By “bolted on,” I mean to include the various techniques used to move the customer from the dealer’s web site into the online buying process.  Modal is actually named for a programming technique, the modal window, and Roadster uses a link.

The transition, however, must not look like it’s bolted on.  Roadster shows a good example, here, of preserving the dealer’s original site design.  I can tell it’s Roadster by looking at it, and programmers will notice the “express” subdomain, but this is a seamless transition for the customer.

Also seamless should be the transition across platforms and into the dealership, an experience known as “omnichannel.”  Think of a credit plugin like Auto-Fi.  It allows the customer to apply for credit on the dealer’s web site, and also updates Route One in the dealership.  You never want to redo a task the customer has already done online.

For a storefront there are multiple potential integration points – inventory, CRM, desking, menu, and credit.  The customer may start a deal on the web and then walk in to finish it, or vice-versa.  They may engage the storefront on a tablet or kiosk in the dealership, and finish it at home.  The goal is to support all six tasks wherever the customer chooses to do them.

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.

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.

Menu Selling on an iPhone

Followers of my Twitter feed know that I have lately been looking at mobile apps, to see if anyone can present protection products on an iPhone.  I wrote about this three years ago and, according to my informal survey, the field is still open.

I don’t think anybody has a good way to present a menu on a consumer web site, much less an iPhone.

Not only is the iPhone a restrictive form factor but we must assume that the customer, not an F&I person, is operating it.  We would like to apply our Best Practices for Menu Selling, but the app must be able to apply them on its own.

For example, if we want to retain the package concept with the carefully chosen payment intervals, we can use an accordion control.  I proposed this for a client once, in an F&I context, but it doesn’t make sense for consumer use.

No, the best way to “present all the products, all the time,” is simply to make one long column with everything in it.  The iPhone presents challenges, but there are offsetting advantages.  We can show fifteen products in one column, and the customer has his leisure to scroll through them.

I prefer scrolling to swiping for a few reasons.  In the prototype shown here, we have the obligatory vehicle photo.  After the first scroll, that’s gone and the screen space is devoted to products.

The prototype shows monthly prices for the vehicle and the products.  This assumes the finance process is settled, and the app can choose products matching the finance term.  Touching any of the products will open up a full page with details, coverage choices, and a “sales tool” as in the earlier article.

I recommend using analytics to determine the sequence of products in the column, and even to A/B test the format of the product blurbs.  I have in mind a few different formats:

  • Text with graphic and price, as shown here.
  • No price ‘til you open it.
  • Lead with the sales tool.

I discuss analytics here, but I am not a fan of the full “ownership survey.”  Of the eight standard questions, maybe you can sneak in one or two elsewhere in the process.  Apart from that, we’re counting on data points found in the deal itself.

I also think “less is more” when confronting the customer with choices.  As you can see in the mockup above, there must be no complicated grades of coverage (or deductible).  If you’re configuring the app for a specific dealer, you may want to filter some options out of the dealer’s product table.

Depending on who’s managing the app, the products themselves may be rethought.  If you want to offer chemical, dent, key, and windshield as a combo product, then that’s a single choice.  Alternatively – since we have unlimited  column space – you can offer each one individually.  What you do not want is a product having fifteen different combinations.

Coming back to my informal survey of mobile apps, and the workflow given here, I believe there are already good examples of vehicle selection, credit application, trade valuation, and payment calculator.  Menu selling has been the only missing link, until now.

Best Practices for Menu Selling

I was asked recently to opine on this topic, which I do today with some reservation, for I can see the venerable four-column menu approaching its sell-by date.  The image shown here is a MenuVantage prototype from 2003.  Don’t get me wrong.  As I wrote here, this is still the best tool for the traditional setting in the F&I office … for as long as that setting prevails.

Best practices for menu selling split into two broad categories: those that are good for selling, and those that are good for compliance.  I will present them in that order.

Every product appropriate to the transaction type and “car status” of the current deal (i.e. Used Lease) should appear in column one.  Some menu systems use deal templates, making it easy to select the proper layout every time.

The home court advantage in the F&I suite is that you can do a four-column menu, and there is a professional there to present it.

For most systems, column one automatically drives the layout of the accept/decline “waiver” form.  This is best practice for compliance, and it’s good selling too.  Why have a product that you only present on special occasions?

The practical limit for products in column one is six, maybe eight, so choose wisely when laying out the menu template.  Using bundles will allow you to squeeze in more products.  I generally don’t like bundled products, as I wrote here, but this is a reason to use them.

Every menu should include a second, longer term, with the correct APR for that term.  There is a charming story about this in Six Month Term Bump, plus a downloadable spreadsheet.  Twelve months is overkill, and likely to raise an objection.

The amount of product you can finance without changing the monthly payment is given by this formula.  Without doing the annuity math, a good approximation is: base payment times five.The monthly payment in column four should be roughly $30 more than the base payment without products.  That way, you draw the customer’s attention into the menu without a big price barrier.  Likewise, payments should increase in small increments from right to left across the bottom of the menu.

Obviously, the increments will be larger for more expensive deals, say 10% of the base payment.  This is easy to do, if you are manually setting up each menu.  It takes a little more planning to do this with templates.  You can either tweak the individual products at deal time, or you can set up a different template for highline vehicles.

For example, offer the platinum VSC coverage in column one and the gold in column two.  By the way, do not reuse the VSC coverage choices (like gold, silver, and platinum) as your column headings.  That’s an obvious source of confusion.  Finally, your menu system should feature sales tools and custom content for each product, like the famous depreciation chart for GAP.

I have a few more recommendations, related to compliance.  If you already have a good grasp of unfair and deceptive practices, you can skip this part.  Be warned, though, that consumer watchdogs and regulatory agencies are looking over your shoulder.

The chart below (and the pull quote) is from the National Consumer Law Center.  You can tell that the dealer in green is using a menu system with a fixed markup over dealer cost.  The dealer in red is certainly making more PVR but he is also courting a federal discrimination charge.

Menu trainers like to say, “present all the products to all the customers, all the time.”  They might add, “at the same price.”  The NCLC report goes on to show that minority car buyers are systemically charged more for the same products.  Some dealers simply don’t allow the F&I manager to vary from the calculated retail price.  In states like Florida, that’s the law.

Giving F&I managers the discretion to charge different consumers different prices for the same product … is a recipe for abuse.

The menu should display the price of each product, not just the package price.  Some turn this into a selling feature by also showing the price as a daily amount.  It makes a good layout to have the most expensive product at the top, with prices descending down the column.

All of these measures require some kind of audit trail.  I have seen some very strong systems that track exactly what was presented, by whom, when, for how much, and whether the price was changed.  At a minimum, you should collect the customer’s signature on the waiver form, with all the products, their prices, and your standard disclosure text.

Next week, I will resume writing about the brave new world of flow selling, self-closing, and predictive analytics.  We may find that many of these practices – especially regarding compliance – are still relevant.

The Automotive eCommerce Ecosystem

Around the turn of the century, I was helping RouteOne to build their now-ubiquitous credit system.  Then, I moved on to aggregation models for the “I” side of F&I.  It was a lot of work.

We had to develop scores of unique interfaces for lenders and product providers.  We had to develop deal calculation engines, and then reverse engineer each DMS so our payments would match.  There were no automated sources for finance or product rates.  We had to walk ten miles in the snow …

Today’s eCommerce startups have it easy.  All of the key tasks are supported by readily available services, leaving the entrepreneur to focus on user experience and dealer support.

When I started writing about this space, the key challenges were price negotiation and trade valuation (and the test drive, but I’ll cover that in a later piece).  Today, you have reliable online trade valuation from Kelley, Trade Pending, and others.  Price negotiation can be handled through chat or one-price, generally on used vehicles.

You can have payment calculations, including incentives, from MarketScan, provider networks from PEN or F&I Express, and finance networks from RouteOne or Dealertrack.  Everything in this paragraph is an API, not to mention passing data from your eCommerce platform into the corresponding dealer system. Finally, even the old faithful DMS now exposes a variety of databases, like inventory.

A few months ago, I described the role of venture capital in driving process change.  I think this eCommerce ecosystem is equally important.  Entrepreneurs can enter the space at a very low cost, relative to ten years ago, and meet most of their requirements through interfaces.

Worry about Mobility, Continued

This week, we examine the fourth piece of McKinsey’s automotive revolution, shared mobility.  This is really a collection of trends including car sharing, ride hailing, and mass transit.  I will show how to gauge whether a new program has the potential to be disruptive.  But first, let’s dispense with mass transit.

From Munich, you can ride the U-Bahn to the Schnellbahn, and get anywhere in Europe by fast rail.  This is where McKinsey’s analysis shows its European bias.  Europe’s population density is three times that of the United States, and her various rail systems carry twenty times the passengers.

American cities are linked by air, of course, but relatively few have commuter rail systems.  When you deplane at Las Vegas, for example, or Orlando, you are headed for the car rental counter.

“What’s happening in general, millennials, younger people, car ownership in and of itself is not the most important thing.”

When I worked at BMW, twenty years ago, they were already styling themselves a “mobility” company, and not solely a car company.  At the time, that meant mass transit.  If you look at BMW today, their investments tell a different story.  I won’t try to categorize Fair, Shift, Skurt, Scoop, and ReachNow – not today, anyway. Today I want to talk about capacity utilization.

If you’re like most people, you drive your car to and from work, plus errands and recreation.  Let’s call it 20 hours of use for the 112 hours per week you’re awake, or 18%.  In theory, any mobility scheme that increases capacity utilization will cause a proportional decrease in car sales. There is a variety of schemes, known collectively as Mobility as a Service.

“The success of a MaaS provider will be determined by how much utilization they can gain from their accessible fleet.”

Uber is the obvious example.  It increases utilization for the drivers, and reduces the riders’ inclination to buy a car of their own.  I meet people every day who won’t buy a car, or won’t buy a second car, because Uber meets their occasional driving needs.  In major urban areas, people have long gotten by without cars.  The way I see it, Uber has widened this circle out into the suburbs.

Uber will also take a bite out of traditional car rental, as will hourly rental services like Maven. Maven is basically Uber without the driver, good for business travelers who just want to attend their meeting and go back to the hotel.  Business travelers I know will often choose Uber over Hertz, depending on the city.

“Millennials like having an easy process, but they hate commitment,” Bauer said. “I think the next step for leasing has to be no fixed term, or a different way of term.”

Here in Atlanta, we have two subscription car programs, Flexdrive and Clutch.  It is wonderful to live in the nexus of so much new-auto activity.  Flexdrive is a joint venture of Cox Automotive and Holman Auto Group.  You choose from a variety of vehicles, and your monthly subscription includes insurance, maintenance, and roadside assistance.

The average car payment in America is $500.  Depending on the figures you use for gas, insurance, and maintenance, your car costs at least $7 per hour of use.  This may sound fanciful, accounting for the car as a utility, but this is exactly the way a new generation of mobility providers look at it.  A monthly subscription of $500 is the price point advertised by Fair.  Zipcar and Maven hourly rates start at $8.

The chart above shows that car sales per capita have declined, in fits and starts, by about one in six over the last forty years.  This reflects trends like gradually increasing urbanization and longer-lived cars, which are minor worries for our industry.  Increasing utilization, through various forms of renting and sharing, has the potential to be a major worry.