No, we haven't stopped! Quite the contrary, we are working hard on issues such as regulation, development and operation, which have required us to put in effort and flexibility to reconcile with our "extra-Mutual.Life" activities,while our strategies at the moment take us on a bootstrap path.
As we said before, our first concept test was based on the validation of a smartphone protection group. And this month of October, the pilot group completed 22 months. Throughout this period, the group remained active with approximately the same number of people. This was essential so that we could confront some ideas and assumptions, making mistakes and learning through reality. Understanding what is and is not really important in the routine of the group and its members has helped us significantly in the development of the Minimum Viable Product. From this learning process, we can highlight two points that called our attention:
1. Most users do not want to get involved.
We believe in the value of moral hazard. That is why a group is formed exclusively by guests of the group members themselves. But being invited is only the first step. If a guest agrees to join the group, he or she will need to enter data on the desired protection. After that, their registration is submitted for approval, which is done by the members of the group.
This format contributed to a lesser involvement than we expected among the members of a group. We realized that once these users feel in a controlled environment, that is, a group of friends and friends of their friends, they tend to trust these people. So if any kind of event happens, they just trust each other. With this, we can assume that so far mutual trust has proved very relevant.
In practice, we realized that when a new incident was recorded, most of the members wouldn't even come forward to give their opinion. We had to ask them to enter, vote and tell whether they were for or against the repayment needed to make up for the incident. After a while, we improved the process by assuming that if a member does not vote within a day limit, it is assumed that his vote was favorable, with full reimbursement. The process got much more fluid that way.
On one hand, it seems that the group is dead, on the other, it shows that it is very alive (and very solid). If we consider our users' experience, greater involvement does not necessarily mean good news.
2. Charging only for claims is not necessarily the best way to operate.
We thought that not burdening users with monthly contributions would be a differential. We hypothesized that the initial contribution plus the contribution by events would be an excellent strategy. Not only for the commercial arguments, but mainly for the possibility of bringing savings to the users. We can say that the commercial argument was relevant and that the members of our pilot group also saved. But we have identified some events that deserve much of our attention.
To begin with, since engagement among group members is small, it often takes time for the user to make the contribution to the event (and consequently replenish their balance). Many had to be reminded with some frequency. We also noticed that when events were recorded very close to each other, the group members were caught off guard. Imagine a group that stays three months without any type of event. Members grow accustomed to non-contribution. And then imagine that the following month, three events happened, one next to the other.
Thinking about the user, we attacked these fragilities by implementing a more traditional model with a great differential: the user makes a monthly recurring contribution based on the expectation of the group's claims and the resource is the user's own. This means that if the user wants to stop being a member of a group, that is, leave the group, he withdraws the balance of what has been contributed so far.
We believe that with this model, our users will be able to have better financial planning, and in addition, they will continue to be essentially a part of the group's resources
But what to expect for the next few months?
Even before our app is made available for testing by the pilot group, we have already started implementing these improvements in the day-to-day pilot group. As we are all still working manually, that is, without a platform behind controlling what happens in the group, we still have some unwanted limitations. On the other hand, the great advantage is that month after month we have more answers and our app is being built already contemplating all these improvements.