Help people trust their AI agent without babysitting it
Overview
Problem
An AI agent makes mistakes and can’t read a room, so someone has to check on it. The old call log offered a transcript and a recording, which only helps if you already know which call to open.
Solution
I turned it into an activity log that keeps calls and texts in one history per person, with better filters and export. I also designed data capture, which sends the agent’s findings to the CRM.
- Contact conversations thread
- Trust without babysitting
- Data capture to the CRM
Role
Product & UX design: research, user flows, UI, design-system components. Proposed by our project manager and directed by stakeholders, with limited room to explore.
The agent can't read a room
By this point the agent exists and it's running inside a workflow dialing real customers. The open question is whether it's any good at it.
An AI agent makes mistakes, and it has no emotional read on the person it's talking to. It can't hear that someone has gone quiet or got annoyed and change tack the way a person would. All it can do is guess. A lot of work goes into training the model behind the scenes, but the customer on the other end of the phone belongs to our user, not to us, and they have a reasonable interest in knowing how those conversations are going.
The trap is obvious once you say it: nobody wants a product that requires them to supervise an AI all day. So the goal was never to get people into the logs. It was to make sure they could get in, enough to learn that the agent is trustworthy, and enough to train it when it isn't, then leave.
Finding the call that matters
Filtering got substantially better, which sounds minor until you remember the alternative to good filters is scrolling.
More usefully, you can now export with the filters applied, which is something that wasn't possible before. That's the tell that this became a tool people do real work in: they don't only want to look at the activity, they want to take it somewhere and use it.
A transcript, a replay, and not much else
There was already a call log. You could read a transcript of the call and play back the recording, and that was essentially the extent of it.
Which is enough to examine one call, if you already know which call you want. It's no help at all with the actual questions people have: is this agent working, is it getting better, what has this particular customer actually been put through?
One thread per person
The call log became an activity log. It covers both channels now, so phone calls and SMS sit together, and each entry carries activity details in addition to the transcript.
The bigger change is that it threads by person. A contact who's been through four AI calls and a handful of texts has one continuous history you can read start to finish, along with every workflow they've been enrolled in. You can see the whole arc: where they stalled, where they finished, what was said along the way instead of reconstructing it from separate rows.
We explored an inbox-style version and cut it for bandwidth. It earned its keep anyway: thinking about the problem as a conversation you'd read, not records you'd query, is what produced the threaded view that shipped.
Capturing what the call actually said
Everything in that log is what the agent did but never what it found out. A call is full of answers that used to vanish the moment it ended. “Custom properties” had always promised to collect them but was never actually built; data capture is the bet that made it real, and honestly, the one I almost overlooked while chasing the flashier mid-call-lookups project I was also working on.
- Set up once then let your agent use it. You choose what to capture in Settings, then link it to an agent. The answers go to the customer’s CRM via a webhook and appear in this log.
- Instructions keep the answers clean. The backend does its best to guess how to extract the values, but if you need something specific for your CRM to process it, this is the place to inform the backend you’d rather have a 1-10 scale for customer satisfaction than getting values like: mildly disgruntled, happy, or blue.
- Private when it needs to be. A sensitive answer can go to the customer’s CRM without being saved on our side.
What I learned from all of this
For now, CX is still the main user. A customer notices something isn't working, tells our team, and our team makes it work. That's the same pattern as agent creation, and for the same reason: people want an agent that performs, not a project to manage.
I really enjoyed working on multi-layered projects like this. Collaborating with team members to find solutions to problems that users were having was exciting. One day, I hope SalesAi becomes something that users won’t need CX for in order to use easily, but I think all of these steps take us closer and closer to that day.
Where I'd take it next
I’d make everything more auditable. While these experiences are all greatly improved, the experiences still feel somewhat disjointed and overwhelming to users. A continued effort to make this simple, easy, and effective for the user would be my priority. Allow the users to access SalesAi more natively through APIs and MCPs, and have AI built in more natively into the app would allow people to think less and less about how to achieve their goals inside of SalesAi, and more about how SalesAi can help them achieve their goals.
New screens are Figma mockups with made-up data. Older screens are captures of the previous product with customer details removed. The real product keeps changing with business decisions and user needs.