In the Amazon Wilderness

I concluded Car Dealer Megatrends with the clear and present dominance of consolidated groups, which I like to call the Best Buy phase.  Today, I will indulge in a little futurism, and explore the Amazon phase.  In the Amazon phase, it will be possible to buy a new car enitrely online and have it delivered.

By 2025, experts estimate 30-40% of car sales will be online.  The high end of that range is from Mark O’Neil.  Used cars are easier to sell online, witness Carvana, Vroom, and Shift, but new cars will be there too.  An estimated 25%, and that’s only seven years away.

The industry is rapidly solving problems like pricing and trade valuation.  The only challenge people still talk about is the test drive.  Carvana solves this with its seven day return policy, and Shift will bring the car to you for a test drive.

 “The current dealer model is not a dying breed,” Benstock said. “It’s dead. It’s absolutely dead.”

I will order a new BMW sight unseen, because I know the product and I trust the manufacturer.  Their online configurator is awesome, and I really would press the “build and ship as shown” button, although the process isn’t quite there yet.  We’ll come back to BMW later, but for now let’s assume a test drive is required.

The tension between Best Buy and Amazon centers on a practice known as “showrooming.”  This is where you sample the product at Best Buy, interrogate the Best Buy sales associate, and then turn around and order the product from Amazon.  Amazon even makes a clever app you can use to scan product codes while you’re in Best Buy.

As auto retail moves into its Amazon phase, I can imagine the same challenge for dealers.  You have invested in a monument to your manufacturer’s brand image, where customers can sample the product and then go order it online.

I had been pondering the showrooming challenge for a while when I ran across this piece in the Wall Street Journal.  Nordstrom is opening stores with no stock, where shoppers can try on clothes and accessories, and then have them delivered.

It will contain eight dressing rooms, where shoppers can try on clothes and accessories, though the store won’t stock them.

The Nordstrom story reminded me of the old “catalog showrooms” operated by mail order retailers like E.L. Rice and Service Merchandise.  Ironically, this was the last gasp of mail order, put out of business by brick and mortar retailers – including, ultimately, Best Buy.

All of this goes to show that, in the Amazon phase, showrooming and fulfillment can be disconnected.  Where the customer goes, to test drive and learn about the vehicle, does not have to be the dealership or even affiliated with the dealership.  This opens up a world of new possibilities.

I can think of several applications for standalone test drive centers.  For instance, suppose a manufacturer wanted to enforce its ideas about how to present its vehicles, and also – since this is the Amazon phase – protect its own position online.

Were it not for U.S. franchise laws, manufacturers would run their own retail outlets.  In Europe, they have company stores, where ideas about brand image, sales training, and product positioning do not depend on a network of autonomous dealers.

An OEM test drive center would bypass the dealer network (or complement it, if you prefer).  It would be staffed by salaried, factory-trained product experts with no other objective than to educate customers in the finer points of their company’s vehicles.

There would be minimal inventory, attractive video displays, simulators, and samples of paint and fabric.  No transactions would take place, but there would be plenty of Wi-Fi bandwidth and gourmet coffee for the online shoppers.

As I said, this is just one scenario.  The new techniques of digital retail will create untold opportunity for dealers willing to adapt.  Our exploration of the Amazon phase has just begun.

Seasonal Adjustment Factors

I felt like doing something quantitative, so this week we look at seasonal adjustment factors.  Everybody always talks about SAAR, and you probably know that it stands for “seasonally adjusted annual rate,” but what does this really mean?

Well, suppose it’s March 2017, and you are wondering what total sales will be for the year.  The industry sold 1.55 million vehicles that month so, if you multiply by twelve months, you might estimate 18.6 million for the year.

You would be wrong, though, because March is always a strong month.  Here are the estimates produced by the simple “times twelve” method, relative to the actual total for 2017, which was 17.2 million.

Using data from Fred for the five years 2013 through 2017, and converting everything to a percentage, you can see how March always overestimates the year’s results.  Each year’s dots are a different color, though it doesn’t really matter which is which.

Some months are highly variable, like September.  Not a good gauge of anything.  Remember to distrust any SAAR figures published in September.  April, oddly, is a tight group and bang on the annual rate.  April 2018 sales were 1.4 million, so a good guess for the year is 16.8 million.

Taking an average across the five years, we find that March, May, August, and December each overshoot the annual rate by roughly 10%.  Finally, we convert these percentages into monthly adjustment factors.

Instead of multiplying last month’s sales by 12, multiply by the monthly factor to predict the year’s total.  Of course, we have more data than just a single month.  We can also look at cumulative sales since January.  For example, do a quarter of the year’s sales occur in the first quarter?

No.  It takes a while to make up for the weak January and February, and then the actual historical cumulative pace slowly comes into alignment with the idealized linear cumulative pace.  I made that chart, too, but it’s not pretty.  That’s enough quantitative stuff for this week.

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.

Speculation on fractal based programming language

We flew east out of Panama City, and I looked down on the faceted green hills of the Cordillera de San Blas, perhaps for the last time.  In the sky were statistically similar puffs of white cumulus cloud.  Naturally, I was thinking of fractals.

I had spent the past few days coding technical analysis indicators in Python, which reminded me of coding same in C#.  This, in turn, reminded me that although the TA community talks a lot about geometric repetition, we have yet to invent a single fractal indicator, much less a trading strategy.

I write my trading strategies in C# on the MultiCharts platform.  Its procedures for time series data look a lot like the vector-oriented syntax of Python.  Here is how to do Bollinger bands in each:

  • StandardDeviationCustom(length, devs)
  • df[price].rolling(length).std() * devs

I have to admit not having much intuition about vector operations.  Matrices and summations just look like for loops to me – clearly an obstacle to the proper appreciation of Python.  I have worked with SAS and SYSTAT, though, so Python at the command prompt seems natural.

What I noticed with the Python exercise is that the classic TA indicators were designed with an iterative mindset, reflecting the programming languages of the day – Sapir’s theory, again – and so I imagine that the reason we have no fractal indicators is that our language can’t express them.

Here are some basic things I would expect from a fractal-oriented programming language:

  • Create a dataset from a generator function
  • Derive fractal metrics, like the Hausdorff dimension
  • Compare two datasets for statistical similarity
  • Compare a dataset to subsets of itself

Admittedly, I have only a cursory notion of how this would work.  That’s why this piece has “speculation” in the title.  Meanwhile, I will continue plugging away in C# and Python.

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.

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.

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.