GPS Trackers and OBD Ports

While I was working at Safe-Guard, in 2018, we adopted and co-branded a GPS tracker from ZAZ.  Shortly thereafter, we learned that our crosstown rival, EasyCare, was backing another such product, called SAVY.

Of the two, SAVY had more consumer-friendly features in their mobile app, which I feel is decisive.  This point of strategic positioning is the focus of today’s post.

Neither hookup did well, demonstrating that providers of “paper” F&I products are ill-equipped to deploy hardware.  I took the installer training, just for grins, with Hector Delgado.  So, at least I have a useful skill to fall back on.

I also consulted briefly for LoJack, in 2012, helping them sort out issues around preloading – issues they solved, ultimately, by selling the brand to Spireon.  Old-timers will recall LoJack used to work on radio.  It’s GPS now, like all the others.  “New LoJack by Spireon” is, in fact, old Spireon plus the stronger brand name.  The field today consists of:

    • Ikon
    • LoJack
    • Recover
    • SAVY
    • ZAZ

The model for all of these is that the dealer installs the tracking devices and uses them for lot management, and then sells them through to customers as theft protection.  They’re often sold as a nonnegotiable “preload,” which makes sense from the dealer’s perspective because it would cost another $50 of technician time to remove the device if the customer doesn’t want it.  You can see how consumer mobile app-appeal figures into our story.

If the device is drawing power from an OBD port, it can report the vehicle’s battery condition along with its location.  There’s a lot more you can do with OBD data, but manufacturers can be prickly about connecting to those other pins.  The typical device consists of the GPS chip, a cell modem, and an accelerometer.  You may have noticed that your iPhone also includes these parts, but not the OBD plug.

Speaking of those other pins, subprime lenders and BHPH dealers can wire the device to do starter interrupt.  That is, the OBD-powered devices.  The Recover device I saw at NADA is battery powered.  The argument for a battery-powered device is that it’s easier to install.  The opposing argument is around battery life, especially if you are selling it through, and the advanced capabilities available to an OBD scanner.

Connected Car Features

This brings me to the consumer features:

    • Service reminders
    • Teen driving
    • Driver performance
    • OBD health scan
    • Dealer inventory
    • Service scheduling
    • Credit application
    • Trip history
    • Recall notification
    • Digital glovebox

The astute reader will note that many of these features also aid the dealer in customer retention.  On the other hand, dealer-friendly features don’t mean a thing if the customer doesn’t use the app.  So, preloading can work against you if F&I fails to upsell the device properly.

Also, as mentioned above, your iPhone can support most of these functions on its own.  I run Life 360, which adds “insurance referral” to the driver performance feature.  The advantage to the dealer-installed device is that it’s physically attached to the vehicle.  By the way, you can buy a home OBD scanner for $30 at Walmart.

The dealer-installed GPS tracker is an amalgam of all these capabilities.  The key to success is exploiting them creatively and packaging them in ways that appeal to the consumer.

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.