Making AI agents something a small business can set up and trust
Kalcend started as a WhatsApp support tool for small businesses. As its only designer, I worked with the founder to rebuild it around AI agents: a business describes the job in plain language, tests the agent, and runs it on the channels its customers already use.
The short version
Context
When I joined, Kalcend was a WhatsApp tool. Small businesses used it to run support chats, send campaigns and manage contacts on WhatsApp, with an AI assistant that answered common questions. It had paying customers and a clear niche.
It also had a pattern in its feedback notes. Customers kept asking for the same thing in different words. A clinic wanted its assistant to answer calls. A brand wanted it on Instagram. An agency wanted it to handle email. WhatsApp was where Kalcend started, but it wasn’t where every business’s customers were.
The channel changed from business to business. The job didn’t.
My role
I was the only designer, working directly with the founder, who was also the engineer. A second cofounder ran marketing and distribution. My job was to look at what customers were asking for, decide with the founder what to build, and design it.
Over seven months that came to most of the product: the home and builder, agents and testing, channels, the app around them and billing. This case study covers the work that changed the product’s shape.
Timeline
The product moved fast. These are the stretches of work this case study follows, and the public launches they fed into.
Research
Before redesigning anything, I checked whether the feedback was a real pattern or a few loud customers. It was a pattern. I worked through three sources: the founder’s notes from sales calls and demos, feedback and support chats from WhatsApp customers, and usage data on which features businesses used each week.
Three things came out of it.
They described jobs: answer customer questions, follow up on leads, report on sales. None of the requests were about the inbox itself.
About a third of the feature requests I reviewed named a channel other than WhatsApp. Often the same business needed two: WhatsApp for customers, email or Slack for the team.
Setting up the WhatsApp assistant usually meant a call with the founder and two to three days of back and forth. That doesn’t scale with one engineer.
Chapter 01
I proposed building the product around the agent, instead of adding an inbox for each channel.
The obvious move was to add channels one at a time: an Instagram inbox, an email inbox, a voice inbox. That would have meant one engineer maintaining four inboxes, and businesses learning four tools that did the same job.
Instead, the agent is the thing you build, once. It gets a job, knowledge and tools. Channels attach to it. WhatsApp becomes one channel among many instead of the shape of the whole product.
One thing couldn’t change: the WhatsApp tools that paying customers relied on had to keep working. So campaigns, contacts and templates stayed, moved into the app around the agent rather than at its center.
Constraints
The founder built everything. Every design had to fit what one person could ship in two to three weeks, so I designed in small releases and reused patterns wherever I could.
Our customers ran clinics, shops and agencies. Words like webhook, schema and trigger had to stay out of the main path.
Agents ran on paid models, billed per use. A busy agent could empty a wallet without anyone noticing.
Two big launches in three months. Designs had a short shelf life, so I kept the system simple enough to change.
Chapter 02
Building became the first screen, and that screen took three versions to get right.
The WhatsApp product opened on an inbox. For an agent product, that’s the wrong front door. An inbox is empty until you’ve built something.
The new first screen has a greeting, one input and a plain question. What would you like to build? Everything else, agents, knowledge, integrations, contacts, campaigns and billing, moved into an app you open from the side when you need it.
Iteration 01
The first version, for the first launch, was just the input. In the first weeks, usage data showed many new users either typed nothing or just typed “hi”. A blank box assumes people already know what an agent can do. Most didn’t.
Iteration 02
Rotating examples helped people start. But many copied an example word for word and ended up with an agent that didn’t fit their business, and most of those didn’t come back.
Iteration 03
I replaced examples with templates for jobs our customers already ran: an ERP, payroll, a sales CRM, a data analyst in Slack and a content marketer. Each card shows the tools it uses and how long setup takes. The setup time helped more than expected. It told people this was real work with a clear end, so they were more likely to finish.
Why it won
A blank box asked people to imagine what an agent could do. Templates showed them. The list wasn’t invented. It came from the jobs businesses kept describing in sales calls and support chats, like running a sales pipeline, answering questions from their data or handling payroll. So the home screen spoke the way customers already talked about their work.
Templates were also the easiest choice to keep right as the product changed. A template isn’t a separate flow. It’s a starting configuration for the same builder: a job, plus the tools it needs. Every improvement to the builder improved every template, and adding a new one was a content change, not engineering work. With one engineer, that leverage mattered as much as the design.
The risk is that templates shape what people build, and some will bend their idea to fit one of the five. That’s why the input stayed directly below them.
Within a few months, more than a third of first agents started from a template, and those were more likely to reach a working test than agents started from a blank prompt.
Chapter 03
I couldn’t make builds faster, so I made the wait readable. Abandonment during builds fell from 31% to 12%.
Building an agent takes minutes, not seconds. The system checks what already exists, sets up tools and puts the pieces together. At first this was a single line, “Thinking…”, sometimes for ten minutes. People refreshed, retyped their request or left. 31% of builds were abandoned during the wait.
I replaced it with a build card. Five named stages. A live line saying what the system is doing right now. A timer, and a range: usually 3 to 12 minutes. We showed a range because build times varied too much for a single estimate to be reliable.
Together with templates, this cut the median time from first message to a tested agent from 41 minutes at launch to 16.
One thing I’d change: the live line still shows internal step names like get_resource_schema. I’d replace them with plain language. It was planned but not shipped when I handed over.
Chapter 04
I put cost in view on every screen, so people could see what an agent cost before it went live.
Pay as you go made Kalcend cheap to try. It also made it easy to be surprised. Early support chats after the first launch included people asking where their balance had gone.
I made two small changes. The wallet balance sits in the top bar on every screen, and it updates while the builder works, so you watch setup cost money as it happens. And every reply in the Playground shows how long it took and how many tokens it used. Testing an agent tells you what running it will cost before it goes live.
People kept paying: the wallet passed 100 top ups within weeks of the relaunch.
Chapter 05
With the agent as the unit, a channel became a setting on it. I designed channel setup so a business could connect WhatsApp, webchat, email, voice or Slack to the same agent, with the same knowledge and the same escalation rules. The composer on the home screen carries the most used channels, so you can say where an agent should live while you describe it.
The call I lost
I designed all five channels together so the model would hold. I wanted email in the first release too, because agencies asked for it more than anyone. The founder chose to launch with fewer channels and add the rest over the following months.
The founder was right. Every channel brought its own approvals, limits and setup failures. One engineer couldn’t have shipped five well at once. What I did hold on to was the model. Because channels attached to agents, each new one was a few weeks of work, not a redesign.
Within months of adding channels, 2 in 5 active agents ran on a channel other than WhatsApp. It suggested the demand was for the right channel, not a better WhatsApp tool.
Chapter 06
By the last stretch, the problem had moved. People could build agents. Now they couldn’t always tell what their agent had actually done.
When I ran a full build myself, start to finish, I found five places where two status messages contradicted each other. Among them:
And this one, in a single reply:
Each message described a different part of the system, but nothing told the user which one mattered. So I mapped every status in the product onto one scale, from the weakest claim to the strongest, and wrote one rule: the interface only claims what the system can prove.
This was my focus in the last stretch. I handed the scale, the status rules and these screens to the founder. Support chats gave the reason to finish it: one of the most common setup questions was some version of “is my agent live?”
Outcome
After the relaunch, Kalcend passed 5,000 users within three weeks, with 60 or more new signups a day, all from organic channels and no paid ads. It landed its first enterprise deals and paying customers in the same period.
That was the whole team’s work. The numbers below are the ones my work moved most directly.
Reflection
Settling on the agent as the core unit gave every later feature a place: templates, channels, billing and status.
Build times didn’t change. Showing each stage is what cut abandonment.
When every reply costs money, the balance and the cost of each test belong on screen while people build.
We designed how agents get built months before we designed how they report back. Next time I’d set the status rules in the first month.
Next case study
Airport Operations Platform