Skip to content

Stop Using Combo Products

January 25, 2017

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.

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: