Third-party claims at San Cristóbal Seguros

Service and digital product design case study in the toughest interaction with every insurance company

Gabriel Yesuron
Jun 30 · 12 min read

In this article you’ll find the steps we took to design the third-party claims service process with its digital part. This article is part of Gabriel Yesuron’s portfolio, you can check it out at

See the Spanish version of this article here (Versión en español aquí)

Business context

In early 2017, Grupo San Cristóbal decided to take a journey in what is known as Digital Transformation whit McKinsey’s help. A big part of this journey has the intention of rethink processes and set innovation through user experience in different business areas, one of those areas is San Cristóbal Seguros

The first step of this journey was a visioning workshop where different problems and opportunities were identified on a company scale. Later, those were reformulated into value propositions that would be taken under prioritization of different stakeholders.

One of this value proposition was third-party claims

A “third-party claim” is known in the insurance industry as a request of indemnization of a non-client for the damage he had suffered from policyholder occasional accident.

Contextually: an individual asking San Cristóbal to compensate him because one of his policyholders hit or damaged him.

The challenge

The claim processing and payment from third parties is one of the main expenses of any insurance company, easily reaching the 8 figures. Beyond its bulky negative result, this type of management is impossible to avoid for insurers since it is the basic materialization of the service they offer their clients. However, digitization and streamlining of the process, reduction of judiciality with its extraordinary expenses, and the focus on the attention of a potential client becomes important in this dynamic and competitive context.

Project context

In January 2019, having reached certain objectives in the company, we continued addressing the third-parties claims.

At that time a team was formed with collaborators from other cells and the disciplines that could not be obtained in the area were sought outside. The original team was integrated by Marcelo, a lawyer who brought a lot of expertise from the company because of his career in San Cristóbal as product owner. Carla, a lawyer who had been a claim manager for several years as a business analyst, and myself, Gabriel, an industrial and service designer as product designer and user experience of the project. At the same time a remote team was contracted with front-end, back-end and full stack developers, scrum-master and QA analysts in the City of Buenos Aires.

Scope and axes of the project

We defined 3 axes of work aligned with the vision of the company.


When we started the project, most of the team (Marcelo and Carla) had extensive experience on San Cristobal’s operation. As for myself, I had little knowledge of what a third-party claim was but could contribute in management and product development, so, due to the uncertainty of any project at the beginning, I proposed to carry out one of the most recognized people-centered design process: Design thinking.

Design thinking would allow us to understand the business, the operation and the needs of the client and, to Marcelo and Carla, remove the bias of having been an executive part of the process.

Step 1: Discover

The first action we carried out was to explore the current status of San Cristóbal Seguros’ third-party claims.

We met business stakeholders and began to investigate the process: through a series of questions, those summoned told us the interactions third-parties perform throughout the management of the claim. We were able to know the perspective they had about the process, what they felt comfortable and the issues that could be improved.

While business stakeholders’ view are one of the most important we knew that it was not the only valid perspective, so we decided to interview the third-party claims managers of almost all branches. These dialogues were enriching. in each branch, the attention given were generating different kinds of experiences to third-parties. For example: in a branch, the third-party attended personally and finished the claim in the same day, and on another branch, the third-party was not allowed to enter the branch as the security guard informed her to go to the a provider’s offices to file the claim.

The more people we interviewed, the more information we got. But, at that moment, we still had to know the most important experience: the third-party one. With the support of claim managers from all branches we collect data to interview 40 third-parties and know their perspective. At the same time, we sent C-SAT and CES surveys by email to the contacts of third-parties that we had in the database to create a project baseline.

Step 2: Define

User Journey

With the information gathered we managed to assemble the user’s journey. We were able to identify the interactions that the client carries out throughout the life of their claim while linking their emotions on different steps of this journey. Doing so, We achieved an understanding of the process’ steps that provide value as well as those that generate frustrations.

Baseline metrics (C-SAT, CES y life-cycle)

In order to measure the impact of our actions, in the interviews and surveys, we asked five questions to know the current status of the claim process in a quantifiable way:

To connect numbers with the experience of the third-party we asked them to leave us a comment, therefore we could link the quantitative of his answer with the qualitative of his experience.

Problems, needs, insights and opportunities:

To visualize our discoveries we translated into post-its all the problems, needs, insights and opportunities that we had detected during the previous steps.

Some of these problems had a remarkable importance, for example, in an interview a third-party told us that an insured of our company had crashed his car and it remained immobilized, tried repeatedly to call the closest San Cristóbal’s branch but nobody answered. She made the decision to ask for a day off at work to personally attend to the branch where she was given a paper that said that, to enter a claim, she should send an email with the required documentation. Needless to say the anger she expressed when telling us her experience.

Problems and challenges:

As a conclusion of the research the team was quite in agreement that there were 6 main problems that we had to solve:

Using “how might we…?” technique we reframed these problems into challenges:

Step 3: Develop

We knew in depth the current process and the experience we provide during claim management so we decided to let our imagination run and do a very interesting prospective exercise.

We stood in front of our whiteboards and set out to imagine how claims would be on June 1st, 2020, approximately one and a half years in the future from the moment we were:

Summarizing, once the accident happens, the third-party crosses information with our insured, that will launch an SMS to the third-party with a link which allows him to upload his data and a small description of the accident with photos, artificial intelligence identifies the damage of the vehicle and at that time makes a compensation proposal. If accepted, the money would be transferred to a bank account so that the third-party is able to repair his/her vehicle.

We understood that in order to make this kind of solution we had to start with something small today that would allow us to learn, validate and capture more information towards that reality.

step 4: Deliver

With this scenario in the future we decided to prioritize the problems and generate actions towards a minimum viable product.

Using a Lightning decision Jam, we identified that working on the communication of the required documentation and providing a digital channel to file a claim were the two actions that would bring the biggest impact with the least relative effort.

We designed the user flow in low-fi wireframes of what would be the solution for a third-party to report the necessary documentation and digitally file a claim at San Cristóbal. This would automatically reach the inbox of a claim manager to process it.

Lean approach

Once understood the problem and designed the solution that seemed ideal to us we followed with a lot of intrigues, we knew that the execution of a MVP would take us a couple months, mainly because we had dependencies with other applications and services of San Cristóbal like, for example, the software that the claim managers use in a daily basis.

So the key question was:

What actions can we take that will allow us to advance towards our objectives as a team?

Since we were “blocked” at a development level, we decided to change the focus of the team: Instead of trying to deliver a product (code in production) we would put our efforts into generating knowledge that would allows us to understand if the ideas and steps we were taking bring value to our users and the business.

We looked back at the research and decide to go after the biggest problem using the Lean Startup Loop: build - measure - learn

Output: “The experiment”

In order to capture information very quickly, understand the market and users and validate the project we decided to do a pilot test. This pilot was guided by 3 hypotheses we needed to prove:

With these 3 hypotheses we decided to diagram the scope of the experiment:

The what, why, how and for what of the actions we were about to do.

As a result, we created a facade: a simple web page that would allow third-parties to know the required documentation to present and then instruct them to send all those documents by email to file the claim.

Nothing automatic happened, there was no integration with any system, behind that email were us: Marce, Carla and I answering and distributing claims to managers throughout the country for them to attend and manage.

This product was not a solution but a strategy that, for 15 days, populated us with key insights:

From the experiment we took 4 substantial learnings:

How the project continued

With the information gathered, we diagrammed the MVP and understood the key flows that we had to address and its prioritization.

At first, we focus on receiving and distributing claims to managers of all branches for them to attend and resolve.

Today, 4 months after the pilot test, we have products that cover 6 key users, such as third parties, lawyers, insurance advisors, providers, call center employees, and front desks through 3 platforms designed for their specific needs.

This project obtained a remarkable improvement in the axes that had been diagrammed at the beginning of the project but, due to confidentiality, I cannot speak about the results and their concrete impact.

Sincerely, I hope you do not need to use this product (since it would mean you had an accident), but feel invited to check the third party claims page to know how and what you will need to file a claim at San Cristóbal Seguros at any time.

Gabriel Yesuron

Written by

Totally nerd UX and service designer @ Grupo San Cristobal

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade