This is a QuintoAndar case, a proptech that enables tenants to rent properties entirely through digital means, negotiating directly with property owners.

Think of it as an Airbnb, but for renting purposes. You can gain a better understanding of what QuintoAndar is through this Forbes article.

A bit of context

My role was in the Support and Services department, part of a multidisciplinary team that included individuals from both Product&Tech and customer experience (CX).

In this role, we frequently addressed the ongoing phase, focusing on the experience of tenants and property owners throughout an active lease agreement.

During the lease agreement there is two main problems:

1) Financial delinquency, wich is the main problem for property owners
2) A need for repairs in the property, which is the primary concern for tenants in this phase, such as faulty plumbing, non-functioning electrical components, and so forth.

Consistently, we contemplate and iterate solutions for these two categories of issues. The case presented here specifically revolves around property repairs.

Problem discovery

To improve the experience of property repairs. We explored the scenario, aiming to identify the primary opportunities.

• We explore CSAT answers

• Shadowing the support analyst with repairs requests

• Stakeholders interviews

• Repairs requests qualitative analysis

• Data and metrics analysis

How we did it?

And what did we discover?

The repair process was very slow.

This occurred primarily because the process was highly manual, complex, and relied heavily on intermediation between the parties. This intermediation also constituted a gap in the process, as users (particularly property owners) took considerable time to respond to requests.

There was no happy path, not even for simple requests with engaged users.

Until the beginning of the project, the only part of the process available in the application and productized was the repair request opening. All other aspects of the handling were conducted through email or phone, involving manual processes.

Solution discovery

We conducted a solution discovery because there were uncertainties about how receptive users would be to a possible self-service solution. In order do to that, we did:

1. Concept testing with users

2. Wizard of oz MVP

3. MVP users interviews

4. fter rollout, we discovered some experience problems and we iterate a few months later
   

Solution proposal

After thorough testing and extensive internal discussions, we reached the conclusion that the solution should entail the implementation of self-service, providing autonomy to users and automation behind the scenes.

This allows analysts to concentrate on users who do not respond promptly or require additional support.

Visual

How it was

This was the screen in place for monitoring repairs, both for tenants and property owners. It displayed repair requests, but lacked any actionable steps or guidance on how to proceed.

Given the substantial backend efforts and internal processes, major frontend changes were not prioritized. Consequently, we iterated upon the existing screen, incorporating actions and some additional information.

What we delivered

Now we have a happy path on repairs!✨

We achieved positive results with the rollout and iterations. We have a 50% user adoption rate, repairs being resolved on the same day, and improved satisfaction.

• From 0% to 22% of repairs request fully automated

• From 0% to 36% of repairs request partially automated

• Owners dispute reduced by -55% (YoY)

• Repairs ticket rate has dropped 30%

• Leadtime from 12 to 7 days

• DSAT from 42% to 18%

Metrics:

We received acknowledgement for our dedication at the company's annual awards ceremony and secured the prize in the experience category for our adept resolution of a previously intricate issue through a straightforward approach

Thanks for reading!