![notion image](https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fa3667636-e7b8-4bb5-96de-01f59ae59f3e%2FChallenge_Cover_-_Schedule_Challenge.png?table=block&id=bc2f471c-2fa3-45df-8060-5ab13ac3f17b&cache=v2)
The confidential information in this case study has been altered.
“ How to help non-technical users set up the formula for compensation calculation effortlessly?“
Background
Compensation Schedules are the most challenging & essential part of the distribution module. They were used to calculate the COST that insurance companies were required to afford from collaborating with representatives.
A pain point in the current market is the lack of friendly configuration for formula which was primarily built by computer language. However, middle or small-sized companies may not always have technical supports.
Survey
“ What exactly the schedules are? ”
![notion image](https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Feb051d6e-ea47-436f-872b-c23c4f3686d4%2FSchedule_-_Gain_Understanding.png?table=block&id=44a3f905-eeb0-4d59-b56d-f05af9a76de0&cache=v2)
I conducted a survey on different schedules and how their commissions were compensated? I collected use cases for checking with our consultants, and aimed to define the scope that we would like to cover.
I went over one after another to get a deeper understanding of different types of schedules, and assessed the impact of each variable may make on the design in order to define how should our schedules set up?
Competitor Research
“ How do schedules and variables work? “
![notion image](https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fbc8d3a15-116a-48de-a697-8cb0de1c5fdb%2FSchedule_-_Insight_Analyzing.png?table=block&id=9b9a7795-bd9d-4fd3-975b-65a07d29926a&cache=v2)
From the research, I noticed that a few of the same factors re-appeared across different schedules. Therefore, I assumed that all variables in the calculation were mostly centered on agents, products, and goals.
However, I had a limited idea of how various these variables could be, given that it seems allowed to factor in almost anything. Then, I decided to verify our findings with consultants as frequently as possible.
Ideation
“ The complex structure of schedules were required to be addressed first. “
![notion image](https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fb2033524-cafc-4ac8-8d08-5ebf6a090294%2FSchedule_Entity_Chart.png?table=block&id=c55b664a-4043-42d7-be86-93ca2180a88f&cache=v2)
After use cases were verified. With no visual flow, massive function settings weren’t friendly for communicating with consultants who may not always have product-design background.
In making sure to reduce the confusion during our discussion. I aimed to create the wireframe before further discussion.
I worked on figuring out the structure of all schedules by converting their factors & variables into more intuitive settings, and at the next step to put them into user workflow.
I laid out the connection between settings and variables of each type of schedules and tried defining what should be put on which level?
Redirection
![notion image](https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F4e08a770-ff27-4368-a4b8-c06c76a71469%2FSchedule_-_Redirected_Strategy.png?table=block&id=589508c1-29d3-41ac-a4c1-8dbc496d0e79&cache=v2)
With the wireframe, I targeted to verify if final compensation rates were always aggregated by each variable from sold products. If that was correct, then I may be able to put a portion of rates on each variable, avoiding having users list out all possible combinations of variables.
On the other hand, during my design of the formula workflow, I realized how complex the formula of channels with organizational hierarchy could be. Therefore, I presented the wireframe to stakeholders and had a thorough discussion on our module scope.
To be differentiated from other solutions in the market, we decided to adjust our principles of schedule design from flexibility into simplicity. Also, narrowing the scope from channels with organizations down to digital channels that sell insurance through e-commerce platforms.
Challenge
![notion image](https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F0eb5978d-47ee-4bab-8a66-b896f9e192ca%2FSchedule_-_New_Approach.png?table=block&id=844358c4-f44f-4fcc-95b3-be614d357ee0&cache=v2)
After we redirected the module’s market position and principles, it largely reduced the complexity of designing schedules that compensate sales and agents with hierarchy, including competition and commission sharing between sales teams and agents.
Therefore, one schedule will only be applied to one target instead of multiple ones. Also, schedules could be categorized into 2 types as products-related and goal-related, which allowed me to pre-build the formula into the module.
Although, I could rely on our core platform’s logic engine to bring values into the formula according to pre-configured sheets. However, the configuration of variable sheets wasn’t friendly for non-technical users, given the way they were configured was quite similar to programming.
Interview
“ Clients — We always use excel sheets, it seems there are no better solutions in the market. “
![notion image](https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fb7fdd7c4-19f2-49e2-abf9-e409a4dab494%2FExcel_Table.png?table=block&id=751f0768-1abe-4769-9c0d-2152b4e42e5c&cache=v2)
During interviews with key clients, I learnt that a common method for logic running was using variable sheets that listed out all combinations from all variables, and let computers run the logic to check which value to use, such as use 1 if it’s A+B, use 2 if it’s B+C.
However, it concerned me that the combination row may rapidly grow if numerous variables with multiple values were all required to be checked, given that one of clients had a table with 10,000+ rows in some cases.
Consultation
![notion image](https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F9469be76-de78-48d1-b142-415650d4646d%2FConsultants_Word_3.png?table=block&id=ae904ac4-b627-4261-9839-e384377e882b&cache=v2)
The compensation negotiation between insurers and channels was mostly based on channel expertises, selling regions, and common market price. And the tables were required to clearly display in their contracts.
If tables were complex, then communication cost may increase. Therefore, insurers’ common practice is keeping them as simple as possible.
Unfortunately, insurance companies may not set up their compensation tables by separately putting a certain portion of rates on each variable, since they often have all kinds of factors used as variables in the formula.
As a result, my previous approach that based on aggregating the rates on each variables (product factors) wouldn’t work.
Inspiration
![notion image](https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F39bb8928-604b-4715-86f6-4bb0b79ec784%2FExample_Rate_Table.png?table=block&id=6447a858-7f36-4d64-a7b2-70cc7d123ed7&cache=v2)
Example from the research (Life Insurance)
“ Could users only set up repeated variables ONCE throughout all combinations, as the usual way their compensation tables were set up and displayed? ”
This question was raised during my thinking. Although product-related variables may be flexible and subjectively chosen, product variables generally won’t be too many. However, the combination rows were still challenging for users if there were 300+ rows for each schedule.
Mockup
In common variable sheets, all variable combinations need to be manually input as many times as variables were added into sheets, such as a product (variables) with 2 business types (values) x 5 age classes = 10 rows.
I noticed that all compensation tables from my research were always set up along column headers and row headers, in this way, each variable only required to be input ONCE.
With a way that users were familiar with, I could guide users to set up tables with product variables along column and row headers, and input the final rates at their cross points.
![notion image](https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F138afa91-94ce-4bb7-ae6b-824c2dc6566b%2FSchedule_Flowchart.png?table=block&id=08bee7ae-f7ec-4a96-b92a-03d71a4c8852&cache=v2)
![notion image](https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fd2dccbca-1171-417c-bb37-6ad18c360688%2FSchedule_Workflow.png?table=block&id=afd13063-d4f2-499f-ac81-a8b21b56e251&cache=v2)
Reflection
Usually, complex issues we were dealing with in our design, users in their areas had dealt with them in their common practice before. Their approaches were very likely as intuitive as our first thought.
You can also find me on 💁
- 👨🏻💻 Resume
- 🎨 Behance
- 📱 +61 493704787
- 📧 a870588@gmail.com