Aircall · AI · Product design · 0→1
Designing trust into Aircall's first AI voice agent
Built from zero: from a first, fully assisted beta to ~45% self-serve adoption, cutting the time to go live from two weeks to four days.
- Role
- Design Lead, AI Voice Agent
- Team
- Core team of 1 PM + 2 engineers, growing to 10+ engineers, with Sales, Solutions Engineering and training involved
- Timeline
- 2024 – now
I set the design direction and guidelines for the agent experience, partnering with designers across other product areas where it touched their scope.
Context
Aircall's AI Voice Agent answers and makes phone calls on behalf of a business. It handles support, reception and scheduling, reads from a knowledge base, takes actions like updating the CRM, and hands off to a human when needed.
Unlike a chatbot in a widget, it goes live on a real phone line, talking to real customers in the company's name. Once it's live, you have very little control over what it says. That made trust, not capability, the main barrier to adoption.
We started as a very small team, and we had to move fast. The goal was to deliver value from day one and get a product into customers' hands as early as possible, so we could learn from real use.
How I worked
Designing the beta as a learning system
We started with a hand-picked group of companies. At first, the PM and I worked alongside them directly, reacting to every issue and learning what setup really required. Then we turned that into a playbook and partnered closely with Forward Deployed Engineering and Solutions Engineering, so they could run onboarding without us.
What it changed: our roadmap was heading toward giving the agent more skills, like writing to a CRM or connecting to other systems. The beta showed us that trust had to come first. Instead of adding skills, we spent a lot of time polishing the interaction itself, like how the agent handled interruptions, and proposing ways for people to keep control, starting with a reliable handoff to a human. The same signal led us to make prompting a first-class part of the experience from the start.
Findings
What we learned from 30 beta customers
"For non-deterministic AI, design's job isn't to be clever. It's to generate confidence. What you expose, how you frame it, and how it connects to what users already trust, is everything."
They were afraid of two things: the agent inventing answers, and not knowing when it would hand off to a human.
They didn't know what "good" looked like. Once live, there was no clear way to tell how well the agent was doing or how to make it better.
They wanted to write, not configure. I expected people to want structured options for more control. From the first sessions, they reached for natural language: an open-ended interface where they could describe what they wanted in their own words, instead of picking from menus.
Key decisions
Natural language where it behaves, controls where it acts
I started from the assumption that admins would want structured options for more control. Research said otherwise: they wanted to instruct the agent the way it would speak. So we split the model:
- Behavior (tone, how to handle conversations) → free-text instructions.
- Anything that touches our deterministic systems (call transfers, actions, integrations) → explicit configuration. When the agent hands off a call or writes to a CRM, how it works has to be unambiguous.
Templates as a starting point. Writing a good prompt from scratch is hard, and you never know if you're doing it right. Each template is a working agent for a common use case (support, sales, reception, after-hours) that performs acceptably from day one. Users start there and refine, instead of facing a blank field.
Make quality visible, before and after going live
Users didn't know what a good agent looked like, and a phone line gives you no second chance. So we built confidence into every stage.
Before going live: test it.
- Test calls, available from day one: hear the agent exactly as your customers will.
- Simulated scenarios: another LLM generates realistic caller situations and runs them against your agent. An agent testing an agent, at a scale no one could test by hand.
After going live: see how it's doing. Resolution rate and performance against the goals you set for the agent.
And know what to fix.
- Knowledge gaps: questions callers asked that your knowledge base doesn't answer, ready for you to add.
- Configuration gaps: specific recommendations to improve how the agent is set up.
Outcome
From assisted setup to self-serve
At launch, every agent was set up with help from our internal teams. That worked for learning, but it couldn't scale. Getting to self-serve took several things working together:
- Templates that give a working agent from the first minute.
- Build from a prompt: describe the agent you need and get a first version.
- Embedded guidance and training, built for both customers and our internal teams, so the knowledge that lived in a few people's heads became part of the product.
Impact
What design moved
of customers set up their agent self-serve, up from fully assisted at launch
Driven by: Templates (decision 1), build from a prompt and embedded guidance (from assisted setup to self-serve).
from first setup to a live line
Driven by: Self-serve setup, plus test calls and simulated scenarios before going live (decision 2).
NPS from admins
Where the product went
- MRR, 4 months after the project started
- $50K
- MRR today
- $2M+, backed by a major company investment in voice agents
What I'd do differently
I'd document conversational design decisions earlier. We made hundreds of micro-decisions about agent language and behavior that lived in our heads or in Slack threads. A lightweight decision log would have accelerated productization and made onboarding new team members much easier.
Get in touch if you want to go deeper.