Portal do Cliente

The Customer Portal came out of a finding from the Apisul ecosystem project. Across in depth interviews with around twelve carriers, small to large and spread across different regions of the country, the same problem surfaced regardless of company size or how many services they had contracted: there was nowhere to see all the information about their own operation in one place.

To reach an invoice, a policy or risk data, customers depended on their broker or account manager. Every query was a request, and every request depended on someone else being available.

The data was there. Information moved through Apisul in volume. What was missing was any structure to it.

The hardest question in the project was which data from each service actually matters to the customer. Insurance, logistics, risk and claims generate information in different volumes and of different kinds, and the answer sat with the managers of each area.

It never came. Not for lack of willingness, but because they had no clear view themselves of what mattered to the person on the other side. The company culture was built around solving problems as they arrived, and mapping needs ahead of time was not part of how it operated.

Since waiting was not an option, I went after the information where it did exist. I worked through the system documentation for each service and put together a provisional set of what could be displayed, so there would be something concrete to discuss. It was a draft, and it was treated as one. Refining it stayed open, dependent on an involvement from those areas that the project never managed to unlock.

The same pattern showed up in the help centre. The need was clear from the research, with recurring questions about policies and invoices, but there was no structured record of those requests to start from.

The component library was not built from scratch. Together with the PM we chose an existing one and I adapted Apisul branding onto it, which cut development time for a small team. I spent six months on the project with one developer and a PO, and it was over that time that the scope revealed what was missing.

The admin area was never in the plan. It appeared during development, once it became clear the Portal needed someone on the other side managing what shows up: which notifications go out, which questions make it into the FAQ, which offers are displayed and where each customer stands.

The offers answered an explicit business goal. Apisul wanted to grow cross sell and upsell, and the Portal made it possible to present a service in the context of the customer own operational data. Someone who buys insurance but not logistics sees the offer while looking at their own numbers, rather than on a sales call.

I also explored automated support. WhatsApp was the main channel between Apisul and its customers, so we approached a chatbot company to understand what was feasible. I designed the flow and gathered market references to ground the conversation.

I left Apisul before launch, so I never saw the Portal in use. What I delivered was the product design, a definition of which data should be pulled from each service, the admin area and the groundwork for automated support.

Three measures would answer whether it worked. The volume of invoice and policy requests reaching account managers, compared against the period before launch. The number of WhatsApp messages asking basic questions about policies and invoices, which Apisul already logged and could compare before and after. And for the offers, click through and conversion into a signed service, which was the cross sell hypothesis.