Tag: mobile

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.