Itaú Unibanco · 2023–2025
IBBA 360 Mobile
66%
less time in the logging form, test group
Voice-first visit logging for advisors in the field
The problem
I was the only designer on this product. Advisors logged their client visits by hand, and those logs fed their own commercial targets. Most of them wrote things down during the conversation or right after it, on paper, and typed the same content into the Contact Report later: the information was written twice, and the second time was the one that counted. Away from the office they leaned on their assistants to look anything up, and many waited until they were back at their desk to register a visit at all. The real moment for logging was the drive back from meetings: time to spare, hands busy. Some kept Teams running on a laptop just to record the conversation and read the transcript later. The product itself came out of a web-to-mobile transition: it was not born on the phone, it was ported to it. And the constraint that decided everything: many advisors were not comfortable pulling out a phone in front of a client. It looked like they were not paying attention, and that meeting was exactly where the business got made. That constraint is not a hunch. It came out of five in-depth interviews with Middle Market officers, around 25 minutes each, run in December 2024 and January 2025. Any solution that needed a screen during the conversation was already dead.
What I ruled out
A notes app on the phone. It came from the technology team, and it did not die in a meeting: it shipped. An earlier, simplified version went to production and was measured. It only moved the rework somewhere else, it produced no reusable data, and it ran straight into the discomfort of using a phone in front of the client. Adoption stayed at 9% among officers and 19% among team leads. The reasons were not subtle: logging in took ten steps, screens loaded slowly, and a recurring answer in the interviews was that officers did not know the mobile version existed at all. Voice was not a first idea. It came from learning from a failure that had already been built, launched and measured.
The decision
The advisor speaks freely and the system structures the text afterwards. They review it and give the go-ahead before anything is submitted. They never fill in a field, and nothing enters the system without their approval. The client conversation was recorded, and the audio was kept. Consent was a requirement: the advisor had to tell the client, and the client had to agree. That produced three paths, one per situation. The client agrees, so it records. The client refuses, so the advisor narrates the conversation after the meeting (the drive-back scenario). Neither works, so the manual form on the web platform is still there.
The result
66% reduction in average time spent on the form screens, comparing the average of the previous months against the average of the first month after the test. This number covers the test group only. It is not a figure for the whole advisor base. It is the one number I can stand behind with its method attached, so it is the one I report.
What I'd do differently
I would have designed consent first, instead of fitting it around a flow that already existed. The version I would build today puts scheduling with the client inside the app itself: the meeting lands in the advisor's calendar and a form goes to the client beforehand, so the advisor is notified before they walk in. That moves the decision to before the meeting and turns a client's refusal into something actionable: knowing in advance, they can bring the assistant to take notes instead of finding out at the table.
