Ventaz AI

The problem: People have been trained to escape

Most chatbots can't actually help. They struggle to understand what people need, give scripted answers, make it difficult to reach a human, and they forget who you are the moment you switch channels. Over time, people have learned a habit. When a chatbot opens, they look for the way out. The 'talk to a human' button. Not because they always need a person, but because experience has taught them that the bot will probably get in the way.

Underneath all of it was one hard truth: business owners aren't sure an AI agent can handle their customers properly. And customers don't expect chatbots to solve their problems.

Better language models have improved how chatbots respond. But better conversations don't automatically mean people trust them. But the share who would use a chatbot again barely moved, from a quarter to just over a quarter, across the whole shift to modern AI. The bots got smarter. People still reach for the exit.

That was the real problem Ventaz had to design against. Not "can we build an AI agent", plenty of people can. The question was, could we build an AI agent that actually helps, so reaching for a human is no longer the first instinct?

Research statistics

71%

of consumers prefer a human agent over a chatbot

PwC, Consumer Intelligence Series

54%

say chatbots often fail to understand their problem

Forrester

55%

say they frequently have to escalate from AI to a human

Kinsta, 2025 survey

I'd seen this long before Ventaz

At a customer support product I previously worked on (Zupportdesk), I watched this behaviour firsthand.

During usability sessions, people would scan for the 'talk to a human' link before reading what the bot said. Some typed 'agent' repeatedly, hoping the chatbot would eventually connect them to someone.

They weren't necessarily dealing with complicated problems. They just didn't believe the chatbot would help.

Reaching for a human had become the first thing they tried, not the last.

What I took away from the research

Looking at the research alongside what I'd seen in previous usability sessions, I kept coming back to three problems. People didn't expect chatbots to understand them. They had little control when a conversation went wrong. And they weren't always sure whether a human could step in.

That helped shape how I approached Ventaz.

Instead of starting with a long list of features, I focused on making the agent easy to try, natural to communicate with, and easy for a business owner to control.

Those became the principles behind many of the decisions that followed.

Onboarding: Make the setup disappear

The tension: An AI agent is only as useful as its setup. And setup is where things can start going wrong. There's a lot to configure. What the agent knows, how it talks, which channels it supports, and when it should hand over to a human. Ask a small business owner to configure all of that, and there's a good chance they'll end up with a half-finished agent. Which means their customers get exactly the kind of chatbot they're already trying to escape.

The obvious move: The usual approach is a behaviour builder. You create workflows, connect steps, and tell the agent what to do in different situations. That might work for a technical team. But for the small business owners Ventaz is built for, it feels like programming. I didn't want to make the flowchart easier to use. I wanted to remove it altogether.

Conventional chat bot setup

The decision: Don't ask people to configure an agent. Build one for them and let them try it. All they need to do is enter their business website address. Ventaz reads the website, uses its content to create an initial knowledge base, and prepares an agent with most of the basic settings already in place. Instead of asking them to sign up, Ventaz then shows the agent working on a preview of their own website, with their branding, answering questions about their business. They experience the product before creating an account.

Why it works: The preview comes before signup, not after. Seeing an agent answer questions about your own business changes the experience from 'now I need to set this up' to 'it's already working, I just need to keep it.' The initial setup isn't always perfect. Website content can be incomplete, and the agent may still need corrections. But the owner has something real to work with instead of starting from an empty configuration screen.

Evidence: During early demonstrations and testing, business owners reacted positively to how quickly they could create and try an agent as well how well the agent handles queries.

“

Wait, making an AI agent is that simple?

“

Wow! it already knows about my business

“

This is so quick

“

It's already on my website

But positive reactions aren't enough to tell us whether onboarding works. What matters is whether someone can get from entering their website to testing a useful agent without getting stuck. That's the behaviour I want to measure, alongside how many people continue from the preview to creating an account. A shorter setup is only better if people can successfully complete it.

Result

Setup stops feeling like a technical task and becomes a moment of 'oh, it already works.'

Behaviour: Make it work like a helpful person, not a script

The tension: A chatbot can provide the right answer and still feel like a machine. Scripted replies become frustrating when someone asks an unexpected question or changes their mind halfway through. People don't always follow a straight path when they talk. So why should a chatbot expect them to?

The obvious move: Canned replies and predefined conversation flows. They're predictable and easier to control. But they also make people adapt to the chatbot instead of the other way around. The moment someone moves outside the script, the conversation starts falling apart.

The decision: I worked on how the agent communicates through its system prompts, response guidelines, and conversational behaviour. The goal wasn't to make people believe they were talking to a human. It was to make the experience feel natural and helpful while remaining clear that they were interacting with AI. The agent should understand questions, ask for clarification when needed, remember the conversation's context, and handle changes without making people start again. Someone booking an appointment might change the date, ask about pricing, or bring up another question halfway through. The conversation should still make sense.

Why it works: People shouldn't have to learn how to talk to a chatbot. The comparison shows the difference. The conventional chatbot keeps bringing the person back to predefined options. Ventaz follows the conversation, responds to changes, and continues toward the original goal. It's not just about sounding more natural. It's about letting people focus on their problem instead of figuring out how to use the chatbot.

Evidence: In early testing, people were surprised by how well the agent handled their questions. The comparison video shows why this matters. The conventional chatbot repeatedly brings the customer back to predefined choices. Ventaz can handle changes, answer follow-up questions, and continue the task. But a successful demonstration isn't the same as knowing how reliably the agent performs in real conversations. We still need to understand where conversations fail, how often customers need a human, and whether they actually get what they came for.

Result

An agent that can follow a conversation instead of forcing people through a script. The bigger measure of success isn't how human the agent sounds. It's whether the customer gets the help they need.

Conventional chat bot

Ventaz

Voice: Follow people to voice, and make it safe to fail

The tension: Sometimes talking is easier than typing. But voice introduces its own problems. An agent can mishear a word, misunderstand an accent, or respond to something the person never meant to say. Repeating the same thing over and over is frustrating. An agent that only supports text leaves out people who prefer voice. But an agent that handles voice badly can be even more frustrating.

The obvious move: Stay text-only because it's easier to build. Or add voice as a separate experience, where someone has to leave their conversation and start again. Neither felt right.

The decision: Make voice part of the same conversation. Someone can start by typing and continue by speaking, or switch back to text whenever they want. The conversation history stays in place. I also added a real-time transcript so people can see what the agent understood and what it said in response. If something goes wrong, they can switch to typing without losing the conversation.

Why it works: Voice is convenient, but people need a way to recover when it doesn't work. The transcript shows what the agent heard. Switching to text gives them another way to continue. The important part isn't just supporting text and voice. It's making sure people aren't trapped in either one.

Evidence: We're using a cutting edge speech-to-text model, but voice recognition still has limitations. Local accents are one of the areas where it can struggle. That's one more reason I didn't want voice to be the only way forward.

Result

People can communicate in the way that feels natural to them.

Oversight and handover: Watch your agents, and step in from anywhere

The tension: Before business owners can trust an AI agent with their customers, they need to know two things. What is the agent saying? And what happens when it can't help? Owners can't spend the day watching a dashboard. They're often away from their computers, doing several things at once.

The obvious move: Hide the hand-off or make the hand-off harder so the agent looks more capable, and build a monitoring dashboard and assume someone will always be there to watch it. Both are the norm, and neither works particularly well for small businesses. One rebuilds the thing people hate about chatbots. The other means someone has to keep an eye on the agent for most of the day.

The decision: Make it easy to see what the agents are doing and step in when needed, from web or mobile. A live conversation view brings interactions from different channels into one place. Owners can see which conversations are active, who's handling them, and which ones need attention. They can open a conversation, read its history, follow up with a lead, or take over when the AI needs help.

Why it works: I wanted to make problems visible without making everything look urgent. Each conversation shows its channel, type, and who is handling it. Conversations being handled normally stay visually calm, with green status indicators. Anything needing attention is highlighted in orange and brought to the top. 

I didn't want to treat every conversation as equally important. An owner might have several conversations happening at once, but most of them don't need attention (because the agent is handling it well). That's why the interface separates normal activity from conversations that need someone to step in. The colour, status, and position of a conversation work together to make the next action clearer. An owner shouldn't have to read every conversation to find out where they're needed. If nobody is watching the dashboard, a mobile or browser notification can alert the operator. The conversation history is there when they take over, so the customer does not have to start explaining everything again.

Evidence: Existing customer service research suggests that people value having access to a human when automated support cannot resolve their issues. However, one of their biggest frustrations is having to repeat themselves after being handed over to a human agent.With Ventaz, the AI agent hands over the conversation to a human as soon as a customer requests it or whenever the agent is unable to handle a query. Alternatively, the business owner can take over the conversation at any time, from anywhere.The best part is that, regardless of who initiates the handover or takeover, Ventaz preserves the entire conversation history, so the customer never has to start over or repeat themselves.

Result

Customer support is always under owners radar.

Channels: Meet customers on every channel

The tension: People don't contact a business in just one place. Some use WhatsApp. Others use Facebook, Instagram, website chat, or phone calls.  Owners and their customers kept telling us the same thing: questions come from everywhere, and the AI agent that only lives on a website misses a big part of those conversations. Answering on every channel was the easy part. The hard part is memory. When the same person shows up on two channels, should the agent treat them as someone it already knows?

The obvious move: Connect everything and automatically merge conversations that appear to belong to the same person. That sounds convenient. The agent remembers the customer and continues where they left off. But a wrong match could expose someone's private conversation history to another person. For a product that's all about trust, that's the one mistake we couldn't afford.

The decision: Let businesses connect their channels and manage conversations from one place, but be careful about how customer identities and histories are linked. Names, email addresses, and phone numbers can help identify possible matches. But matching information isn't the same as verifying someone's identity. We're taking a cautious approach to combining customer histories. Before allowing the AI to use sensitive information across channels, we need stronger identity verification and access controls. That's still a work in progress. And we're deliberately not rushing it.

Why it works: Business owners get one place to manage conversations and review customer information. But we're not treating every matching name or phone number as permission to share someone's history with an AI agent. A continuous experience is only useful if the information behind it is handled safely.

Evidence: We tested multi-channel answering on ourselves and with eight potential customers, and it holds up across channels. The combined memory we're still perfecting, on purpose. A careless merge is a trust problem, not just a bug. And the caution matches what customers already expect. About half of people are uncomfortable sharing personal or financial details with an AI agent, two in three are uneasy about an agent holding their full history, and nearly three in four expect a verification step like an OTP before an agent acts on their behalf. Slowing the merge down isn't us being timid. It's the product meeting people where their trust actually is.

Result

One agent, every channel, one place to manage it.

Ventaz is a more focused product. One could easily frame all the components into just a handful of categories. So I didn't want to build a design system bigger than the product needed. Rather than build a full bespoke design system, I kept it on a customised Tailwind base with the custom components it actually needed.

I could have spent weeks building a much larger component library. But with a team of two, that would have taken time away from solving the actual product problems. Part of designing a system is knowing how much system the product needs.

Ventaz was built by two co-founders, so there wasn't a separate team waiting for finished designs. I was hands-on with much of the frontend implementation, using Claude Code and Cursor while guiding the output against the design system and intended interactions. The tools helped us move faster, but I still had to make the design decisions, review the implementation, and ensure the product behaved as intended. Some parts were particularly sensitive to implementation. The branded preview, conversation states, and real-time interactions are examples where timing, feedback, and transitions matter just as much as the static interface.

Working directly on the frontend also changed how I made design decisions. A static screen doesn't always tell you whether an interaction feels right. Sometimes it's only when you see something running that you notice the feedback is too slow, a transition is confusing, or an interface needs another state. Being able to make those changes directly, without going through a separate handoff, helped us move faster. For me, writing frontend code wasn't about replacing engineering. It was about staying close to the experience and making sure the final product worked the way I'd intended.

Ventaz is still in its early stages, and we're learning as more businesses start using it. The early response to onboarding has been encouraging. Prospective customers can create and try a branded agent before committing. We're also seeing the product handle real customer conversations, capture leads, and help businesses book appointments.

8.4k+

conversations handled across businesses

450+

leads captured through conversations

250+

appointments booked for multiple services

What the numbers don't tell us yet

Conversation volume tells us the product is being used. It doesn't tell us whether every customer got the help they needed. That's the part I want to understand better. How many conversations are resolved successfully? Where does the agent struggle? When do people need a human? And how many businesses continue using Ventaz after their first month? Those questions matter more to me than making the numbers look impressive. For now, the early results are encouraging. But we're still learning what it takes to make the experience consistently useful. And that's where the next stage of product development is focused.

Seeing the Bigger System

I've spent most of my career designing products as systems. Not just the screens, but the entire experience. The first visit, the first task completed, the purchase, the feedback, and the message someone sends to support when something goes wrong.

Co-founding Ventaz made me see an even bigger system. A product doesn't exist on its own. It sits inside a business, alongside sales, marketing, pricing, customer support, and everything else that makes that business work.

You can design a great onboarding experience, but it won't matter if you're attracting the wrong customers. You can build a capable AI agent, but that doesn't automatically mean businesses understand its value or are ready to pay for it. The product is one part of that system, not the whole thing.

Saying "No" to the Obvious Feature

The decision I'm proudest the most is one where we said no. Merging a customer's conversations across channels was the feature everyone expected. It was everywhere, users asked for it, and it looks great in a demo. But a wrong merge shows one person's history to a stranger, and that cost lands on people who never agreed to take the risk. So I held it back until we could verify identity properly.

Every feature is a bet, for the business and for the user. Following a trend is easy. Making that call responsibly, and saying "not yet" when users would pay for our speed, is the harder part of the job.

The hardest part of product strategy isn't adding one feature after another. It's saying no to features that show great potential and have huge demand, but could ultimately do more harm than good to both the users and the product itself.

If you’re building a product, you need to master the art of saying no. Not “maybe,” not “later.” Just a clear, confident “no.”

Wearing Every Hat

A company of two isn't a small team. It's every team. There's no product manager, no analyst or data team, no sales or marketing team to hand things to. In the same week I could be designing the onboarding, coding the dashboard, writing/designing the landing page and planning the next campaign, while tracking where people dropped off, which channels brought the leads in, and what those leads turned into or why someone didn't convert.

Nothing was ever as tidy as a process diagram. What I carry forward is being at home in that mess. Make decisions with incomplete information, move between different problems, and still keep the customer in mind.

What I'd Do Differently

One thing I'd change is when we started learning about our buyers. We spent a lot of effort understanding why people don't trust chatbots and how to design a better experience. But we could have gone deeper, much earlier, into which businesses were most likely to buy Ventaz, what problems they would pay to solve, and how they made those decisions.

We learned more about that as we started reaching businesses and trying to convert interest into customers.

Looking back, I would have started buyer discovery alongside product discovery, from day one. I spent a lot of time thinking about how to make the experience better. But building Ventaz reminded me that good design is also about choosing which problems are worth solving in the first place. Because a good product experience isn't enough. You also need to solve the right problem for the right people. A great onboarding means little if the wrong people arrive at it.