Category: Software

REST Primer for F&I

I have worked with more than a few APIs, both “F” and “I” – pretty much all of the product APIs, plus the original open standard for credit applications – and I write about them occasionally.  See here, here, and here.  Mostly these have been SOAP, but REST is the standard for a growing community of digital retail players.

The first thing you need to know about REST is that it’s not synonymous with JSON.  If you get this wrong, you can produce a really bad API.  I saw one once, where the developers had simply converted all their old XML payloads to JSON.  You could tell because every call was a POST, even the rate requests.

Why is JavaScript more successful on the Web than Java? It certainly isn’t because of its technical quality as a language – Roy Fielding

The key to REST, as you can read in Roy Fielding’s dissertation, is making appropriate use of the Web’s native HTTP environment.  Practically, this means knowing a little bit about HTTP and how to use its commands, URLs, parameters, and headers.  For a concise guide, see The REST API Design Handbook by George Reese.

Philosophically, it means thinking about your API in terms of resources and not services.  This is completely different from SOAP APIs, which are called web services.  For example:

  • GET rates from a product provider, but
  • POST a new contract, and then
  • PUT status codes on the contract to void or remit

Fielding’s achievement was not only to define the REST style, but to derive the style from a specific set of requirements: stateless, client-server, code on demand, etc.  If you have ever wondered why JavaScript has become so popular, it is because JavaScript satisfies the code on demand requirement.

When you build a RESTful API, you should never break existing client code. Really, never. You don’t deprecate – George Reese

The URL in a REST call looks like a path, so you can do groovy things like:

  • GET /rates/{dealer} – gets all applicable rates for this dealer
  • GET /rates/{dealer}/{product} – gets only one product
  • GET /rates/{dealer}/{product}/GOLD – gets only the Gold coverage
  • GET /text/{dealer}/{product}/GOLD – gets the rich text description for Gold

For some live examples you can run right now, check out the NHTSA Vehicle API.  It has many handy methods like:

  • /vehicles/DecodeVin/{VIN}
  • /vehicles/DecodeVinExtended/{VIN}
  • /vehicles/GetAllMakes
  • /vehicles/GetEquipmentPlantCodes/{Year}

Note that you are making the request with straight HTTP and a query string, and you can have the response as JSON, CSV, or XML.  The NHTSA site will also show you the headers, the raw data, and formatted data.  Your tax dollars at work.  You should also check out the Edmunds API, VinSolutions, and Fortellis.

  • //api.edmunds.com/api/vehicle/v2/vins/{VIN}
  • //api.vinsolutions.com/leads/id/{LeadId}
  • //api.fortellis.io/vehicles/reference/v4/vehicle-specifications/vins/{VIN}

These are all examples you can emulate if you’re just getting started.  In particular, I recommend studying how they handle authentication and versioning.  Note how they’re organized around resources and, if you have an OO mindset, think of your objects first.  You will also want to look at platform tools like Swagger and MuleSoft.

Moto Commerce Digital Retail

Moto Insight has uploaded a complete demo of their digital storefront, Moto Commerce.  This shows confidence that they’re not worried about being copied, or being anatomized by some smart-aleck software consultant.  Here’s how Moto handles the six key functions:

  • Choose a vehicle – Including accessories.  I write a lot about the importance of protection products, but accessories are important too, especially for certain brands like Honda and Subaru.  Everything is shown at MSRP but, because the site is customized for each dealer, I imagine there is some flexibility.
  • Price the vehicle – Including incentives.  No idea whose data service they’re using for this.  I usually recommend Market Scan, but it is possible to roll your own.  Rodo recently developed their own incentives engine.  I tried to coach one of my clients on this, but they wouldn’t do it.
  • Price protection products – Including digital content.  Not clear how finance term is linked to protection term.  Customer could choose, say, 36 months of GAP on a 72-month deal.
  • Value the trade – They use Trade Pending, which I mentioned here, but they also offer a condition quiz with the ability to upload photos.  This is very strong because it allows the Used Car manager to bid on the vehicle during the online experience.
  • Structure the deal – The calculator is always running and continuously updates the monthly payment.  This is one approach to the nonlinear workflow problem, but it also means the customer is looking at an inaccurate payment throughout most of the shopping tasks.
  • Organize financing – Here, again, it’s hard to have confidence in the payment until we’ve processed a credit app.  The demo shows the customer choosing term and rate, as if his credit tier is already known.  Moto pushes to Route One and Dealertrack, but it should also pull.

Overall, Moto is a solid online shopping experience.  It does not literally sell the car, in the sense of doing the paperwork, but it does produce a complete, deliverable deal.  Next, the customer can reserve the vehicle, save the deal, and make an appointment.

The in-store version of Moto uses the same pages, making a seamless “omnichannel” experience for the customer.  This means it’s a potential replacement for your desking and menu systems.  Customers can also begin the process in-store, and take the deal home.

I’ll close with Andrew’s hook from the video.  Imagine your dealership offers this experience, and the other guy has only a lead form.  Which do you think the customer would rather work with?

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.

Organizational Debt

In today’s post, I add to the copious literature on technical debt with a discussion geared to my audience of F&I entrepreneurs, and extend the metaphor into organizational design.  What I noticed, writing Maturity Model, is that software development is rich in models and metaphors that apply outside the trade.

Technical debt is incurred when software developers take shortcuts, usually because they are under time pressure.  This debt is accrued in program code, but it must eventually be paid off with real money, just like the debt on your balance sheet.  Here is a brief discussion of how that works.

Someone once insisted that my team “just code IF State = TX, and get on with it!”  Not on my watch.  We will categorize Texas, and then we will add other states to the category as we discover them.  For example, the category might be “waiver GAP states,” or “spousal consent states.”

Operating or back-office issues, often related to IT, are recurring concerns for strategic buyers. Problems with IT underinvestment have proved to be ordeals during many integration efforts.

If you go down the road of IF State = TX, then in short order you will have code with IF <list of ten states> do this logic, and for <five of them> also do this other logic, but for <three of the ten> do this instead and for <the other two> do both of those things.

Congratulations, you have saved forty hours of programmer time versus stubborn Mark Virag and some academic exercise involving categories.  Now you are married to this gnarly decision tree, and you will be debugging it forever.  The technical term is Big Ball of Mud.

One warning sign of technical debt is the “cut and paste” approach.  If your developers implemented the latest dealer, provider, lender, product, or state by copying code from the one before, then I guarantee you have technical debt.

Any developer worth his salt will, instead, make the copied code into a reusable method.  Developers are trained to do things the right way and, in my experience, only take such shortcuts because the boss told them to.

Why not cut and paste, if it gets the job done?  Because, if there are any bugs in the copied code, now they’re multiplied and scattered throughout the code base.  You will have to spend programmer time to fix each one separately, as they are encountered over time.

I could go on with examples all day.  The point I want to make is that technical debt is real money.  You may go “quick and dirty” this week, and save $5,000 of developer time, but you will be paying those same developers later when they have to fix the bugs.

You may reasonably decide that you are a little short this month, and take a loan from the invisible bank of technical debt, but you should do so consciously.  Don’t fool yourself that technical debt is free.  I have provided an example here in the form of TILA box, something my F&I readers will understand.

Now that I have that off my chest, let’s discuss investment decisions.  For example, if you’re a startup and strapped for cash, you may choose to pile up technical debt because it’s off balance sheet and may be the only kind of financing you can get.

Of course, no one actually thinks about it this way.  What they tell their developers is, “just keep patching it until we’re profitable and you can overhaul it later.”  You may even sell the company, rickety software and all, if the acquirer fails to do proper diligence.

When I was doing international software search for BMW, our due diligence guy in Munich was Dr. Dettweiler.  We would find some software that looked pretty on the outside, and then the doctor would fly in and discover it was all a façade, like a movie set held up with sticks.

McKinsey specifically warns against acquiring a company with a big ball of mud in the back office.  Like process maturity, this is a concept that goes beyond software development.

In my time as a consultant, I have designed an organization or two, and it’s a lot like programming.  You have to have the right boxes on the org chart, with the right procedures and job descriptions, kind of like designing objects that will respond to business events (except they’re people).

Organizational debt is caused by the same kinds of things that cause technical debt.  For example:

  • The structure worked fine ten years ago when we had one-tenth the number of people.
  • It was never actually “designed” to begin with, but we reorganize ad hoc every other year.
  • The structure is based on specific people instead of job functions.
  • There are processes for which no one is actually responsible, so things “slip through the cracks.”

Fortunately, people are remarkably resourceful.  They will create their own procedures and informal networks.  Good people can prop up a bad organization, like those sticks holding up the movie façade, but they can only hold out so long.  Sooner or later, they will start to slip – and customers will start to notice.

Now I feel like I really am writing a pitch for consulting services. Call now!  Free reorg with every digital transformation.  Seriously, though, my point is that organizations can harbor technical debt just as software can.  This is why I am a fan of formal methods like ISO certification and, yes, professional organizational design.

More broadly, I am starting to notice that software development concepts – like process maturity, technical debt, iteration, and agile teams – are applicable throughout the enterprise.  We’ll explore this further in an upcoming post.

Analytics for Menu Presentation

Last week, I presented a single-column format for menu selling on an iPhone, with the glib recommendation to let analytics determine the sort order.  Today, I will expand on that.  Our task is to sort the list of products in descending order of their relevance to the current deal, which includes vehicle data, consumer preferences, and financing terms.

This sorting task is the same whether we are flipping through web pages or scrolling down the mobile display.  The framework I present here is generalized and abstract, making the task better suited to automation, but ignoring the specific F&I knowledge we all take for granted.  I’ll come back to that later.

For now, let’s assume we have six products to present, called “Product One,” and so on, and four questions that will drive the sorting.  Assume these are the usual questions, like, “how long do you plan on keeping the car?”

That answer will be in months or years, and the next one might be in miles, but we are going to place them all on a common scale from zero to one (I warned you this would be abstract).  Think of using a slider control for each input, where the labels can be anything but the range is always 0.0 to 1.0.

Next, assign four weights to each product, representing how relevant each question is for that product.  The weights do not have to be zero to one, but I recommend keeping them all around the same starting magnitude, say 1 to 5.  Weights can also be negative.

For example, if there’s a question about loan-to-value, that’s important for GAP.  High LTV will correlate positively with GAP sales.  If you word that question the other way, the correlation will still be strong, but negative.  So, now you have a decision matrix that looks something like this:

Yes, we are doing weighted factor analysis.  Let’s say that, for a given deal, the answers to our four questions are, in order:

[0.3, 0.7, 0.1, 1.0]

To rank the products for this deal we simply multiply the decision matrix by the deal vector.  I have previously confessed my weak vector math skills, but I am certain that Python has an elegant way to do this:

Product Two ranks first, because of its affinity for high-scoring Question Four.  Product Four takes second place, thanks to the customer’s response to Question Two – whatever that may be.  By now, you may have noticed that this is the setup for machine learning.

If you are blessed with “big data,” you can use it to train this system.  In a machine learning context, you may have hundreds of data points.  In addition to deal data and interview questions, you can use clickstream data, DMS data, contact history, driving patterns (?) and social media.

If not, you will have to use your F&I savvy to set the weights, and then adjust them every thousand deals by manually running the numbers.

For example, we ask “how long will you keep the car?” because we know when the OEM warranty expires.  Given make, model, and ten thousand training deals, an AI will dope out this relationship on its own.  We will do it by setting one year past the warranty as 0.1, two as 0.2, etc.  We can also set a variable indicating how complete the manufacturer’s coverage is.

Same story with GAP.  Give the machine a loan amount and a selling price, and it will “discover” the correlation with GAP sales.  If setting the weights manually, set one for LTV and then calculate the ratio for each deal.

Lease-end protection, obviously, we only want to present on a lease deal.  But we don’t want it to crowd out, say, wearables.  So, weight it appropriately on the other factors, but give it big negative weights for cash and finance deals.

I hope this gives some clarity to the analytics approach.  In a consumer context, there is no F&I manager to carefully craft a presentation, so some kind of automation is required.

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.