Sarvaswa AI Labs
Chatbot Development

Most chatbot projects quietly fail. Here is what we build instead.

Teams rarely regret wanting a chatbot, because the underlying problem is usually real: customers ask the same questions at all hours, the support queue grows faster than the team, and somebody has to answer at two in the morning. What teams regret is shipping something that answers politely and cannot actually do anything, so every conversation still ends with a person going into a system to make the change. We build conversational AI that completes the request rather than describing it, grounded in your own content, connected to your real systems, and honest enough to hand over to a human when it should.

Book a callSee what we ship

Voice, web, and messaging · Built on your systems, owned by you

Why they disappoint

Three reasons the last one did not work.

These are the three failure modes we see when a team tells us their previous chatbot was switched off or quietly ignored, and it is worth recognising which one applies to you, because each has a different fix and only one of them is about the model.

It could talk, but it could not act

The most common disappointment by a wide margin. A customer asks to change their delivery address, and the assistant explains, accurately and pleasantly, which menu the setting lives under. The customer either does it themselves, which they could have done without asking, or gives up and contacts a person anyway, which means the interaction added a step rather than removing one. Nothing was resolved, and your support volume is unchanged.

It did not actually know your business

A model without access to your material answers from general knowledge, which produces replies that sound confident and are subtly wrong about your policies, your pricing, or your process. This is where reputational damage comes from, because a customer who is told the wrong returns window does not conclude that the software was mistaken, they conclude that your company said it.

It had no way out

When a bot cannot answer and cannot escalate, the customer ends up in a loop, rephrasing the same question with steadily decreasing patience. A system that cannot recognise its own limits and hand over cleanly to a person will damage relationships faster than having no automation at all, because the customer experiences it as being deliberately kept away from help.

What we build instead

An assistant that finishes the job.

The change that matters is giving the system tools and the permission to use them, which converts a conversation from an explanation into a transaction. When a customer asks to change a delivery address, the assistant looks up the order, confirms it is still in a state where the change is possible, makes the update in the system that owns it, and gives back a reference the customer can quote. The conversation was the interface, and the work was actually done, which is the entire difference between a support cost and a support saving.

The second change is grounding, which means the assistant answers from your material rather than from general knowledge. Your policies, product documentation, pricing rules, and past resolutions are retrieved at the moment of the question and the answer is built from them, with a link back to the source so a person can verify it. This is what makes the difference between an assistant that is confidently wrong about your returns window and one that quotes it correctly because it just read it.

The third change is knowing when to stop, and it is the one most implementations skip. We build an explicit escape route so the assistant recognises the questions it should not attempt, whether that is a complaint, an unusual account situation, or anything involving money and entitlements, and hands over to a person with the conversation summarised so the customer does not have to start again. Handling that transition well does more for customer satisfaction than any improvement in the model.

What we ship

Five conversational systems we build most often.

These are the shapes that work in practice, and each is defined by what it can actually do rather than by the channel it happens to appear in, because the channel is the easy part and the tool access is what determines whether anybody keeps using it.

Customer support assistants

Assistants that resolve the routine portion of your support volume end to end while escalating anything sensitive with the full conversation attached. The design work is mostly in deciding the boundary, since the value comes from the assistant confidently handling what it should and cleanly declining what it should not.

For example

  • Order status, address changes, and subscription adjustments completed in the system rather than explained
  • Policy questions answered from your actual documentation, with the source linked for verification

Voice agents and AI receptionists

Conversational systems for the phone, which remains the channel customers reach for when something matters. Latency is the difference between a conversation and an awkward exchange, so the voice runtime we built is engineered around a 95ms speech-to-speech round-trip target, with speech recognition, synthesis, and the language model all swappable through the same pipeline.

For example

  • Lisa, our AI receptionist for clinics, which books the appointment and updates the CRM during the call
  • After-hours coverage that handles routine calls and takes a proper message for everything else

Internal assistants for your own team

Often the highest-return place to start, because your colleagues are more tolerant of an imperfect first version than your customers are, and the data is already inside your perimeter. These assistants answer questions about internal systems and process, which removes the interruption load from whoever currently holds that knowledge.

For example

  • Our Slack Data Copilot, which answers plain-English questions about Airtable and Google Sheets with sourced links
  • An operations assistant that answers process questions from your own runbooks instead of the person who wrote them

Messaging and multi-channel assistants

The same underlying assistant reachable wherever your customers already are, whether that is WhatsApp, web chat, or SMS, sharing one set of tools and one definition of correct behaviour. Building the channels separately is how organisations end up with three assistants that answer the same question three different ways.

For example

  • WhatsApp-led conversations for markets where that is the primary channel, as in our real estate work
  • One assistant across web, messaging, and voice, with consistent answers and a shared escalation path

Qualification and intake conversations

Conversations that gather what is needed before a human becomes involved, which shortens the first real interaction considerably. Rather than a form that people abandon, the assistant asks what is relevant given what has already been said, and writes structured output into your CRM or case system.

For example

  • Qualifying an inbound enquiry and creating the CRM record with the context already captured
  • Structured intake for a claim or application, with missing information requested conversationally

What makes it reliable

Six things that keep it from embarrassing you.

A demonstration can be assembled in an afternoon, and the gap between that and something you would put in front of paying customers is made up almost entirely of the work below. This is also the part that determines whether the project is still running a year later.

Grounded retrieval

Answers are built from your documentation, policies, and past resolutions retrieved at the moment of the question, with the source available so anybody can check. Getting retrieval right is more consequential than model choice, because an assistant that fetches the wrong policy will answer the wrong question fluently.

A real refusal boundary

The assistant is built to recognise what it should not attempt and say so plainly rather than improvising. Deciding that boundary is a business conversation rather than a technical one, and we run it with your team early, because the cost of a confident wrong answer about money or entitlements is not symmetrical with the benefit of one more resolved query.

Clean human handover

When the assistant escalates, the person picking up receives the conversation, what was attempted, and what the customer actually wants, so nobody is asked to repeat themselves. This is a small piece of engineering with a disproportionate effect on how the whole system is perceived.

Evaluation on real conversations

We build a graded test set from your actual transcripts, including the awkward ones, so a change can be shown to be an improvement rather than assumed to be. Without this, every adjustment is a guess and the team ends up arguing about whether last week's version was better.

Tone that sounds like you

Voice and register are configured against your own material and reviewed by whoever owns your customer communication, since an assistant that is technically correct and tonally wrong still damages the interaction. This is quick to get right and surprisingly often skipped entirely.

Privacy and data handling

Personal data is identified and handled according to your existing obligations, conversations are retained on your terms rather than a vendor's defaults, and the whole system runs inside your infrastructure where your rules require it. For regulated work this is usually the first question asked and the one that decides whether anything ships.

Honestly

Sometimes a simple bot is genuinely the right answer.

We are not arguing that every conversational interface needs to be sophisticated, and it would be self-serving to pretend otherwise. If your requirement is answering a stable set of twenty common questions on a marketing site, a well-organised help centre with search, or an off-the-shelf tool configured properly, will serve you perfectly well and cost a fraction of a custom build. We will tell you that during the first call rather than after you have paid for something more elaborate than the problem warranted.

The case for building properly begins when the conversation needs to reach into a system to complete something, when a wrong answer carries real cost because it concerns money, health, entitlements, or legal obligations, when the knowledge involved changes often enough that maintaining scripted responses becomes its own job, or when the volume is high enough that a few percentage points of resolution rate translate into meaningful money. If none of those apply to you, the honest recommendation is the cheaper path.

The pattern underneath all of this is covered in more depth on our AI agent development page, and if the work you have in mind is internal rather than customer-facing, the AI automation page is the better starting point.

How we build

Start with the conversations you already have.

The most useful input to this work is the record of what your customers actually ask, which almost every organisation already holds and very few examine before commissioning a chatbot. Everything below is built on that evidence rather than on assumptions about what people will want to say.

  1. Read the transcripts

    We analyse your existing support conversations, call logs, or enquiry records to establish what people genuinely ask, in what proportions, and which of those requests could be completed automatically given the systems you run. This usually reshapes the brief, because the questions teams expect to dominate are frequently not the ones that actually do.

  2. Draw the boundary together

    We agree explicitly what the assistant will handle, what it will always escalate, and what it must never attempt, and we write that down before any building starts. Doing this with your team early converts the anxious version of the conversation, which is about what the AI might say, into a design decision everybody has signed.

  3. Build grounded, with the tools connected

    Retrieval over your real content, integration with the systems where the work actually happens, the refusal boundary, and the escalation path, all built together rather than added later. The evaluation set from your transcripts is assembled alongside so that quality is measured from the first week.

  4. Pilot narrow, then widen

    The assistant goes live on a limited set of conversation types, often with a person reviewing responses before they send, which builds evidence and trust at the same time. Coverage widens as the evaluation numbers justify it, and the boundary moves deliberately rather than drifting.

  5. Hand over

    Your team receives the source code, the retrieval pipeline, the prompts, the evaluation set, and the runbook, all running inside your own infrastructure. Most builds reach production between eight and fourteen weeks, and your people can change how the assistant behaves as your policies change, which matters because policies always change.

Questions worth answering

Chatbot development, answered.

We build conversational AI that completes requests rather than describing them, which most people mean when they ask for a chatbot even if the word suggests something simpler. In practice that means an assistant with access to your real systems, grounded in your own documentation, with an explicit boundary around what it will not attempt and a clean handover to a person when it escalates. What we do not build is a thin wrapper over a public model with no tool access, because that produces polite answers while leaving the underlying work exactly where it was.
Almost always one of three reasons. It could talk but not act, so customers were told which menu to use rather than having the change made for them, which added a step instead of removing one. Or it answered from general knowledge rather than your material and was confidently wrong about your policies, which costs more in trust than it saves in effort. Or it had no escalation path, so people looped through rephrasings while becoming steadily more frustrated. Each has a different fix, and only the second is really about the model.
A chatbot in the traditional sense receives a question and returns text, whereas an agent holds tools and decides which to call, so it can look up an order, update a record, open a ticket, and verify the result before replying. The distinction shows up in the outcome rather than the interface: both can be a chat window, but only one of them means the customer stops needing a person. Our conversational work is built on the agent pattern, with the additional design attention that customer-facing systems require.
Three mechanisms working together. Answers are grounded in your own documentation retrieved at the moment of the question rather than recalled from general training, with the source available so any answer can be checked. An explicit refusal boundary, agreed with your team before the build, defines what the assistant will not attempt, which matters most for money, entitlements, and anything with legal weight. And a graded evaluation set built from your real transcripts, including the awkward conversations, means changes are demonstrated to be improvements rather than assumed to be.
Web chat, WhatsApp and other messaging platforms, SMS, email, and voice, with the same underlying assistant sharing one set of tools and one definition of correct behaviour across all of them. Voice deserves particular mention because latency determines whether it feels like a conversation, and our voice runtime is engineered around a 95ms speech-to-speech round-trip target with the speech recognition, synthesis, and language model components all swappable through the same pipeline.
Most builds reach production between eight and fourteen weeks, beginning with an analysis of your existing conversations that usually reshapes the brief. Cost is scoped after that first call, once we know which systems the assistant has to reach and how wide the initial boundary is, and the running cost is modelled at your real conversation volumes with models selected per step rather than defaulting to the largest one. If the analysis suggests a help centre with good search would serve you just as well, we will say so, because that outcome costs you far less.
When the requirement is a stable set of common questions on a marketing site, a well-organised help centre or a properly configured off-the-shelf tool will serve you perfectly well at a fraction of the cost, and we would rather tell you that on the first call. The case for building properly begins when the conversation must reach into a system to complete something, when a wrong answer carries real cost, when the underlying knowledge changes often enough that maintaining scripts becomes its own job, or when volume is high enough that small changes in resolution rate matter financially.
You own all of it, including the source code, the retrieval pipeline, the prompts, the evaluation set, and the runbook, and it runs inside your own infrastructure where your requirements call for that. Conversation retention follows your policies rather than a vendor default, personal data is handled according to your existing obligations, and for regulated work the whole system stays within your perimeter. Nothing continues to depend on us afterwards, so your team can change how the assistant behaves as your policies change.

Send us a week of your real conversations, and we will tell you what is automatable.

Fifteen minutes and a look at what your customers actually ask is usually enough to say which portion could be resolved end to end, which should always reach a person, and whether a custom build is warranted at all. If a well-organised help centre would do the job, you will hear that instead of a proposal.

Book a call