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.
Virag Consulting 