Category: Software

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.

Predictive Selling in F&I

We have all seen how Amazon uses predictive selling, and now this approach is finding its way into our industry.  In this article I compare and contrast different implementations, and discuss how the technique may be better suited to online than to the F&I suite.

If you read Tom Clancy, you might like Lee Childs.  If you bought a circular saw, you might need safety goggles.  To draw these inferences, Amazon scans for products that frequently occur together in the order histories of its customers.  You can imagine that given their volume of business, Amazon can fine-tune the results by timeframe, department, price, and so on.

The effectiveness of predictive selling depends on two things: the strength of your algorithms, and the depth of your database.  Automotive Mastermind claims to use “thousands of data points,” mined from the DMS, social media, and credit bureaus.  An online auto retailer or platform site (see my taxonomy here) will also have data about which web pages the customer viewed.  Your typical F&I menu is lucky if it can read data from the DMS.

The face of predictive selling in F&I is the automated interview.  We all know the standard questions:

  • How long to you plan on keeping the car?
  • How far do you drive to work?
  • Do you park the car in a garage?
  • Do you drive on a gravel road?
  • Do you transport children or pets?

A system that emulates the behavior of an expert interviewer is called, appropriately, an “expert system.”  I alluded to expert systems for F&I here, in 2015, having proposed one for a client around the same time.  This is where we can begin to make some distinctions.

Rather than a set of canned questions, a proper expert system includes a “rules editor” wherein the administrator can add new questions, and an “inference engine” that collates the results.  Of course, the best questions are those you can answer from deal data, and not have to impose on the customer.

A data scientist may mine the data for buying patterns, an approach known as “analytics,” or she may have a system to mine the data automatically, an approach known as “machine learning.”  You know you have good analytics when the system turns up an original and unanticipated buying pattern.  Maybe, for example, customers are more or less likely to buy appearance protection based on the color of their vehicle.

At the most basic level, predictive selling is about statistical inference.  Let’s say your data mining tells you that, of customers planning to keep the car more than five years, 75% have bought a service contract.  You may infer that the next such customer is 75% likely to follow suit, which makes the service contract a better pitch than some other product with a 60% track record.  One statistic per product hardly rises to the level of “analytics,” but it’s better than nothing.

Another thing to look at is the size of the database.  If our 75% rule for service contract is based on hundreds of deals, it’s probably pretty accurate.  If it’s based on thousands of deals, that’s better.  Our humble data scientist won’t see many used, leased, beige minivans unless she has “big data.”  Here is where a dealer group that can pool data across many stores, or an online selling site, has an advantage.

If you are implementing such a system, you not only have a challenge getting enough data, you also have to worry about contaminating the data you’ve got.  You see, pace Werner Heisenberg, using the data also changes the data.  Customers don’t arrive in F&I already familiar with the products, according to research from IHS.

Consider our service contract example.  Your statistics tell you to present it only for customers keeping their vehicle more than five years.  That now becomes a self-fulfilling prophecy.  Going forward, your database will fill up with service contract customers who meet that criterion because you never show it to anyone else.

You can never know when a customer is going to buy some random product.  This is why F&I trainers tell you to “present every product to every customer, every time.”  There is a technical fix, which is to segregate your sample data (also known as “training data” for machine learning) from your result data.  The system must flag deals where prediction was used to restrict the presentation, and never use these deals for statistics.

Doesn’t that mean you’ll run out of raw data?  It might, if you don’t have a rich supply.  One way to maintain fresh training data is periodically to abandon prediction, show all products, let the F&I manager do his job, and then put that deal into the pool of training data.

Customers complete a thinly disguised “survey” while they’re waiting on F&I, which their software uses to discern which products to offer and which ones the customer is most likely to buy based upon their responses.

Regulatory compliance is another reason F&I trainers tell you to present every product every time.  Try telling the CFPB that “my statistics told me not to present GAP on this deal.”  There’s not a technical fix for that.

One motivation for the interview approach, versus a four-column menu, is that it’s better suited to form factors like mobile and chat.  This is a strong inducement for the online selling sites.  In the F&I suite, however, the arguments are not as strong.  Trainers are uniformly against the idea that you can simply hand over the iPad and let it do the job for you.

No, I have not gone over to the Luddites.  This article offers advice to people developing (or evaluating) predictive selling systems, and most of the advantages accrue to the online people.  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.

Dealer Megatrends Part 2 – Fintech

Car dealers today face a growing array of new systems and capabilities.  These are primarily in F&I, thanks to disruptive new entrants in financial technology – fintech, for short.  Mark Rappaport has a nice roundup here, from a lender’s perspective, and I maintain a list on Twitter.

  • AutoFi – Auto finance plug-in for dealer web sites. See Ricart Ford for an example.
  • AutoGravity – Customer obtains financing (via smart phone) before visiting the dealership.
  • Drive – Online car selling, with delivery, from the Drive web site.
  • Honcker – Customer obtains financing (via smart phone) and they deliver the car.
  • Roadster – E-commerce platform for dealers, with full sales capability (as I anticipated here).
  • TrueCar – Customer sets transaction price (via smart phone) before visiting the dealership.

The new entrants blur familiar boundaries in the retail process.  They’re basically lead providers, but all aim to claim a piece of the F&I process.  AutoGravity, for instance, provides a lead already committed to a finance source.  TrueCar provides a lead already committed to a transaction price.  If you’re unfamiliar with the canonical process, see my schematics here and here.

In my previous Megatrends installment, Consolidation, I cited the influence of PE money.  It’s the same with fintech.  AutoGravity, to name one, is backed by $50 million.

The new F&I space is also home to “predictive analytics.”  Automotive Mastermind examines thousands of data points, to produce a single likely-to-buy score.  Similarly, Darwin Automotive can tell you which protection products to pitch.

The technology’s proprietary algorithm crunches thousands of data points, combining DMS information with … social media, financial, product and customer lifecycle information

My specialty is F&I, but it seems pretty clear that predictive analytics has a place in fixed ops as well.  In terms of the earlier article, you can see that consolidators have an edge in evaluating new technology.  Speaking of fixed ops, they’re also better positioned to obtain telematics data.

McKinsey says fintech can help incumbents, not just disrupt them.  That’s why I have focused on technologies a dealer could employ, versus apps like Blinker that are straight threats.  Of course, you have to adopt the technology.  Marguerite Watanabe draws a parallel with the development of credit aggregation systems.

Fintech will induce dealers to adopt an online, customer-driven process.  I see this as an opportunity. On the other hand, those that fail to adapt will be left behind.  This article is aimed at dealers, but the challenge applies equally to lenders, product providers, and software vendors.

Stop Using Combo Products

I have had a hand in designing a few menu systems over the years, and I have always disliked combo products.  You know what I mean: the VSA form, plus maintenance and PDR, on which Marketing has found an extra square inch to offer road hazard.

Menu people hate combo products because the whole point of menu selling is for the F&I Manager to combine products into menu columns, not the combinations defined by the provider’s form.  What if she wants to sell the factory’s VSA, but her own choice of ancillary products?

One cavil I sometimes hear is the definition of “a product,” but this is straightforward.  If it can be sold separately, like key protection, then it’s a product.  If it always rides on another contract, like car rental, then it’s not.

What I try to tell my menu clients (and reinforce with my API clients) is this:

  • The unit of work for presentation is the product
  • The unit of work for contracting is the form

The correct data structure thus has discrete products at the top level, then coverages with their rates, and form codes at the bottom.  Obviously, you can have different forms based on coverage, and you can have the same form for multiple products.  Then, in the contracting phase, you collect the products onto the forms as indicated.

combo-productsCombo products persist because providers legitimately want to reduce the number of forms they manage.  The two-phase approach solves this.  Also, there are old-timers who design products based on the form.  I have even seen F&I shops where the completed contract form is used as a selling tool.

The package discount is the only serious challenge to the menu system.  A workaround here is to include a phantom product with no display and a negative price – although that may be as much work as developing an explicit feature.  Of course, if the manager chooses to discount a package other than one subsidized by a provider, then that discount is her responsibility.

I’ll close with an exception to the rule or, rather, a refinement.  Menu systems are compromised when we mistake forms for products.  On the other hand, there is a practical limit (six) to the number of products offered on a menu.  So, I can see the logic in a product that combines dent, coatings, windshield, and road hazard – especially PDR and windshield, if you think about how the services are delivered.

In this case, we are not merely combining products based on a form.  These products hang together in the same semantic class, appearance protection, and may indeed use separate forms.

Buy Your Next Car from a Robot

110717I like Make My Deal, and I never get tired of seeing the demo.  I like Make My Deal because they have a novel solution to the key problem with selling cars online.  The problem is that, while most of the process can be put online, everything is blocked until a price is negotiated.  Make My Deal solves the problem by making price negotiation part of the online process.

My favorite part of the demo is the transcripts of online sales dialogues.  I could study these for hours, analyzing the language and style of successful dialogues.  Stop and think about that for a second.  You could, if you were a motivated sales manager, use these transcripts as a training tool.

Instead of me and the sales manager eyeballing transcripts from a single dealership, we could collect statistics on the entire Make My Deal archive.  We could set criteria such as closing ratio, or highest gross, and analyze the language most likely to produce those outcomes.

Responses were fed into Kessler’s Consumer Language Tool, which analyzed common language among the highest and lowest closers.

Jason Kessler of CDK Global has done exactly that, using data from email negotiations, and running them through his proprietary language analysis tool.  This technique, sentiment analysis, is also used by stock traders to glean market insights from social media.

The other fun thing about online negotiation is that your ace closer doesn’t have to be onsite.  She can work from home, handling leads from multiple stores.  She could even be a robot, running talk tracks from a tool like Kessler’s.

I don’t really expect robots to replace salespeople anytime soon, but I do expect to see a selling platform that integrates email and chat, with live and virtual agents sharing the work.  Many dealers already use chat systems, of which Make My Deal is a special case.

  • Integrate email and chat
  • Include virtual agents
  • Sell protection products

Virtual agents like those from Help on Click and 247 could handle routine parts of the dialogue and even help coach the weaker salespeople.  For those of you wary of sharing your desk with a robot, recall that the talk tracks came from human closers to begin with.

One process ripe for automation is selling protection products.  As I wrote in an earlier post, the in-store menu presentation will be replaced by an online interview.  Everyone knows the stock questions like, “how long will you keep the car?” and “how far do you commute?”  Aspiring robots can hone their skills here.

Owner Loyalty in the Service Department

I was asked recently to explore the service retention space.  This is a little outside my F&I comfort zone, but everyone knows why service retention is important.  Parts and service make up 40% of a typical dealer’s gross profits.  And, there is actually some overlap with F&I.  Consider, for example, a service contract with “zero deductible at original dealer.”

Here, I present my impressions of the space in workflow terms, plus some thoughts on the features I found technically interesting.  The workflow has a natural break between the onsite procedures of the service department, and marketing procedures which may be a different department (or outsourced).

The space is dominated by two recent mergers: AutoPoint, which acquired DME about a year ago, and Dealer Track’s Service Pro offering combined with Xtime.  See Cox Strategy Redux.  There are some pure play marketing firms in the space, but these two vendors cover the full cycle.  They are able to exploit not only workflow synergies but technical ones.

telematics_dashboard1

For example, you want your telematics to feed information to both the shop and the invitation process, and you want your intake procedures to include information from the accepted invitations.  Also, if the vendor has analytics that can drive a marketing program, maybe they can optimize shop loading as well.

If you are looking at a full-cycle vendor, then the distinction I am making about workflow may seem arbitrary.  Here are features and functions commonly associated with software support for the service department:

  • Greeting boards and RFID tracking
  • Mobile greeting/CRM tools with write-up capability
  • Service menu with “loyalty products” as well as shop services
  • Scheduling and shop loading
  • Status tracking with text alerts for customers and technicians

Pure marketing, on the other hand, brings in additional vendors and different offerings.  In addition to the usual mailers and campaigns, these might include a box of cookies, owner loyalty “membership” programs, and prepaid maintenance.

If you’re in F&I, you may have sold the Ultra Care prepaid maintenance product.  The provider of Ultra Care is not a normal warranty company, however.  Performance Loyalty Group (PLG) offers this product as a service retention play.  Here are features and functions on the marketing side:

  • Multichannel marketing campaigns including call center support
  • Analytics to plan and evaluate the campaigns
  • Telematics interface
  • Geo-fencing and mobile apps

The service invitation process is well established, and now understood to include all media from cookies to WhatsApp.  What is interesting is the use of analytics to make best use of the media.  Text messages may be cheap compared to mailers, but there is a cost in terms of the customer’s attention.  AutoPoint has an advantage here, because they do original research on aggregated data.  Analytics is only as good as the data you put in.

Strategically, telematics is not only a powerful tool but a barrier to new entrants.  It reminds me of how the big DMS vendors once had a lock on OEM dealer communication systems.  For updates on the “battle for telematics data” follow Bob Chabot.

The holy grail of owner loyalty marketing is having the customer run your app on his smartphone.  This may even compensate for not having telematics data.  You can push invitations to it, and then manage service visits from scheduling through payment, along with geo-fencing and notifications.

Owner loyalty, of course, is not confined to the service department.  An app can be the touchpoint for new and used vehicle marketing as well.  Here, I am thinking specifically of the “velocity” method, in which the dealer is actively seeking vehicles to remarket.  For a list of popular app functions, look at AutoPoint or My Own Auto.