Take control of discounts

Translation of my story oryginally published at Gazeta Ubezpieczeniowa

In the world of sales systems

Anyone who has worked with sales systems can name a few things that change relatively often but are permanently sewn into the software. Changing them means waiting in the IT tasks queue, re-testing the entire software, releasing a new version, and associated risks.

Unfortunately, a typical example of a “sewn permanently” thing is a discount. It is often treated during implementation as another field that simply exists and cannot be managed. If you want to introduce a discount, e.g., for a specific region of the country, you need to place a change order, and then we all know how it works. As it is changed relatively frequently, different approaches are used in various companies.

Maybe an open field?

One solution is an open field that will patiently accept whatever an agent enters. At first glance, this seems like a great idea. The regional sales manager will explain what promotions we have now, what discounts we give and, above all, to whom and why.

The problem is that human memory is unreliable and worse, we are slaves to our habits, so if we’ve been giving this discount for the past three months, chances are we’ll continue to give it, even though plans have changed.

There is no agent bad will in it, but only our human nature. Therefore, the software should support the intermediaries, especially when the switch occurs frequently.

What if you had a rules engine?

The second possible solution is to introduce a rules engine. We configure and validate what discounts are available, in what amount, and whether the discount will be granted automatically by the system or it will be an agent’s decision.

An essential point in the entire solution is that a business person, manager, or specialist can independently control these parameters. It cannot be an engine in which only the programmer finds himself in the rules, and that after a long search. Such rule engines only add extra cost and no benefit.

Typical rules for granting discounts depend on the attributes of the subject of insurance or customer parameters, e.g., his address, sum insured, insurance scope, or other products owned. A good rule engine will allow you to base your decision on all information collected about the client and the characteristics of a specific agent: type of network, results, or individually negotiated contracts.

When selecting the rule engine, attention should be paid not only to the user-friendliness of the system. Essential features are also: the full history of changes, the ability to create different versions of the configuration, testing the configuration, and finally, the ease of transferring changes between different servers. Nobody wants to test changes on the production server, right?

We cannot do this with our tools

Each company has already implemented a sales system in which the tariff is built-in or is a separate tool. Just because there is no way to manage discounts today doesn’t mean you can’t make the change by hooking up the rules engine.

At the moment that system would display a field for entering a discount, it will ask the rules engine, providing the context with customer data from a given calculation.

The rules engine will decide which field to display. For the tariff, it will simply be another calculation feature that will or may not be taken into account when calculating the final premium.

The implementation is less complicated than it seems at first glance. Besides, it is performed once, and then each subsequent configuration change is just a configuration change, not the entire system release.

Next steps

After achieving the fundamental configurability of discounts, we can activate our creativity and start granting discounts to specific customers recognized by the personal id, such as a tax or document number.

We can prepare a pool of codes that will give a discount of a specific value. It is effortless to extend the software to consume such code to make it one-time. The sales manager, having a pool of codes, can precisely allocate discounts to agents for specific offers.

The whole solution begins to resemble an advanced concept of discount management by budget, in which the headquarters divide it into regions, and they allocate it further. However, it is a solution that requires special software and significant modifications in the sales path related to the reservation of the budget, its consumption, and possible return if the policy did not take place.

Using the rules engine, you can get the light version of such a system relatively cheaply.

As can be seen from the example of discounts, the potential for transferring power to business in sales systems is enormous, and such a change does not necessarily mean rewriting the entire system from scratch. You can successfully make the most needed functionalities one after the other.