Chatbot Development Services in India
We build customer-facing assistants that answer from your own content, call your own systems for anything factual, and hand off to a human the moment they should. Chatbot development services in India, run for product and support teams in the US, UK, Canada, Australia and New Zealand, with the evaluation work done before a customer ever sees it.
Where Chatbot Projects Actually Go Wrong
Almost nobody calls us because they cannot get a language model to reply. That part is a weekend. They call because the thing they already built is confidently wrong about the refund window, or because it answers beautifully and their ticket volume has not moved, or because legal saw a transcript where it invented a discount.
The pattern repeats. A demo built in a fortnight impresses the executive team, gets pointed at the help centre, and goes live. Then real traffic arrives. Customers do not ask the clean questions from the demo script. They arrive mid-problem, half-informed, often annoyed, and they ask things like "you charged me twice again" or "the guy on the phone said Tuesday". None of that is answerable from a documentation page. It needs the order record, the billing history, and a rule about what the bot is allowed to promise.
The second failure is quieter and more expensive. The bot answers everything, refuses nothing, and the support team starts finding tickets that open with "your chat told me...". Every one of those costs more to resolve than the ticket it deflected, because now you are also repairing trust. We have seen teams switch a bot off entirely rather than work out which of its answers were safe.
Then there is the measurement problem. A dashboard reports 74 percent containment. Nobody notices that containment was defined as "the conversation ended without a handoff click", which counts every customer who gave up and phoned instead. Real deflection shows up in your helpdesk volume, not in the chat tool, and the two frequently disagree by a factor of two.
What all three have in common: the hard parts of a chatbot are not the conversation. They are grounding, tool access, refusal behaviour, escalation design and honest measurement. That is what this page is about.
What Chatbot Development Services in India Cover
Scope varies by use case, but a project that reaches production without unpleasant surprises contains most of the following. We write the scope this way in the proposal so there is no argument later about what "a chatbot" included.
Conversation design and scope definition
Before any code, we go through your last three to six months of tickets or chat logs and sort them by volume and by whether a bot could safely close them. That sort produces three buckets: answerable from content, answerable only with a live system lookup, and never let a bot near this. The third bucket is the important one. Cancellations with retention offers, complaints heading toward a chargeback, anything involving a vulnerable customer, anything with regulatory advice in it. Those get a fast, obvious route to a person.
The output is a scope document listing what the bot handles, what it refuses, and the exact words it uses to refuse. Refusal copy sounds trivial and is not. "I cannot help with that" makes people angry. "I cannot change a booking after check-in, but I can get you to someone who can, right now" does not.
Knowledge ingestion and retrieval
Your content becomes a searchable index: help centre articles, PDFs, policy documents, product pages, past resolved tickets where they are clean enough to use. The pipeline handles chunking, embedding, incremental re-indexing when a source changes, and deletion when a document is retired. That last one gets forgotten constantly, and it is how a bot ends up quoting a policy you withdrew in March.
Tool and system integration
Anything factual and current comes from an API, not from the model. Order status, subscription state, appointment slots, account balance, shipment tracking, entitlement checks. Each tool is a typed function the model may call, with its own auth, its own timeout, and its own behaviour when the upstream system is down. A bot that says "I cannot reach our order system right now, let me get you to an agent" is doing its job. A bot that guesses is not.
Escalation and helpdesk handoff
The handoff into Zendesk, Intercom, Freshdesk, Salesforce Service Cloud, HubSpot or your own queue, carrying the full transcript, a short generated summary, the detected intent, the customer record if authenticated, and the reason the bot escalated. Agents hate handoffs that arrive naked, because the customer then repeats everything and the deflection you claimed becomes a longer contact than if the bot had never spoken.
Guardrails and safety
Input filtering, prompt injection defence, PII redaction before anything is logged, topic boundaries, and an output check on high risk answers. Plus the boring ones people skip: rate limiting per session so nobody runs up your model bill, and a maximum spend alarm.
Evaluation suite
A golden set of real questions with expected behaviour, an adversarial set, retrieval metrics and answer grading, wired so it runs on every prompt change. This is the deliverable that decides whether you can safely change anything after we leave.
Analytics and the review loop
Conversation-level logging, containment and escalation reporting broken down by reason, a queue of questions the bot failed to answer, and a weekly review ritual for whoever owns the content. Without that queue the bot never improves, because nobody knows what it is failing at.
Definition of done
We call a chatbot done when the eval suite passes at the agreed thresholds, the escalation path has been tested end to end with a real agent, PII redaction has been verified against a sample of live-shaped transcripts, the runbook covers a model provider outage, and your team has run one content update through the ingestion pipeline unaided. Not when the widget appears on the site.
Should Your Bot Use RAG or a Fine-Tuned Model?
This question comes up in almost every kickoff, usually because someone senior read that fine-tuning makes a model "know your business". It mostly does not, and the distinction matters enough to be worth two minutes.
Retrieval grounding is the default, and it is the right default
Retrieval-augmented generation searches your content at question time, puts the matching passages into the prompt, and instructs the model to answer only from them. Your knowledge stays in a document store you control. Change a refund policy at 10am and the bot is correct at 10:05, because you re-indexed one document rather than retrained anything. Answers can cite the source article, which turns out to matter more to customers than smooth phrasing. And when retrieval finds nothing relevant, you have a clean signal to refuse rather than improvise.
The work in RAG is not the concept. It is the retrieval quality, and it is unglamorous. Chunking strategy first: fixed windows of roughly 400 to 800 tokens with 10 to 15 percent overlap work fine for prose, but they destroy tables and step-by-step instructions, so structured content gets split on headings and kept whole. We keep the parent document available so a chunk that matches can be expanded before it goes to the model.
Then hybrid search. Dense vectors alone miss exact strings, which is fatal when a customer types an error code, a SKU or a product name your embeddings have never seen. BM25 alone misses paraphrase. Running both and fusing the results with reciprocal rank fusion is the pragmatic answer, and on most support corpora it is worth more than any model upgrade. On top of that a cross-encoder reranker, bge-reranker-v2-m3 or Cohere Rerank, takes the top 30 candidates down to the 4 or 5 that actually go into the prompt. Rerankers are the single highest-value component people skip.
Storage: pgvector if you already run Postgres and your corpus is under a few million chunks, which covers most support and documentation use cases and saves you an extra system to operate. Qdrant or Weaviate when you need filtered search at scale or heavy metadata routing. Pinecone when nobody on your side wants to run infrastructure. The vector store is rarely the bottleneck, so pick the one your team can maintain.
When fine-tuning is genuinely the right call
Fine-tuning teaches form, not facts. It is the right tool when you need a consistent house voice that prompting keeps drifting away from, when you need reliable structured output in an unusual schema, when you have a narrow classification job such as intent or urgency tagging where a small tuned model is faster and far cheaper than a large one, or when you are trying to get a 7B open model to behave well enough on your domain to run on your own hardware for data residency reasons.
LoRA and QLoRA adapters make this cheap enough to be reasonable now. A few thousand well-labelled examples, a few hours on a rented GPU, and you have a model that formats the way you want. What you do not have is a model that knows today's stock level.
The trap is using fine-tuning as a knowledge store. Facts baked into weights cannot be corrected without another training run, cannot cite a source, and fail silently and confidently when they go stale. If your policies change more than once a year, put them in retrieval.
What we usually build
Retrieval grounding for knowledge, tool calls for anything live, and prompting for voice. Fine-tuning enters the picture on the small classifier models around the edges, or when a client's compliance position rules out sending text to a hosted provider at all. That last case is real, particularly in health and financial services, and it changes the cost shape of the whole project because you are now operating GPUs.
Intent Handling: Deterministic Flows and Generative Answers
There is a fashion for throwing away intent classification now that models can follow instructions. It is a mistake for anything transactional, and the teams who did it are quietly adding it back.
Here is the split we use. Open-ended questions get a generative answer grounded in retrieval. Transactions get a deterministic flow with a state machine behind it, and the model is used only to understand what the customer said and to phrase the next prompt. Cancelling a subscription, rescheduling an appointment, raising a warranty claim, changing a delivery address: these have required fields, validation rules, an order of operations and a point of no return. A free-running model will skip a step under pressure from a persuasive customer. A state machine will not.
Slot filling still applies. A booking change needs the booking reference, the new date, and confirmation. The model extracts what it can from the first message, the flow asks only for what is missing, and each slot is validated against the live system rather than accepted on trust. If someone gives a date the calendar does not offer, the flow says so and offers the nearest three.
On tooling: if you already run Rasa or Dialogflow CX and it works, we usually keep it and put the generative layer alongside for the long tail rather than rip it out. Rasa's DIET classifier on a well-labelled dataset is accurate, fast, cheap to run and completely predictable, and predictability has value in a flow that moves money. Where there is no existing NLU, we build intent routing with a small classifier or with the main model's structured output, and we keep the routing decision logged so you can audit why a conversation went where it went.
One detail that saves grief later: keep intents shallow. Teams build 140-intent taxonomies where 30 of them overlap, then spend months arguing about which one a message belongs to. Twenty to thirty well-separated intents plus a generative fallback outperforms a sprawling tree, and it is far easier to evaluate.
How Do You Stop a Chatbot From Making Things Up?
You cannot reduce hallucination to zero with prompting, and anyone who says otherwise has not tested at volume. You reduce it in layers, and you make the residual failures visible instead of silent.
Take facts out of the model's hands
Every number a customer might act on comes from a live system through a tool call. Price, balance, delivery date, remaining allowance, appointment slot, warranty expiry. The model's job is to read the API response and say it in a sentence, not to remember it. This single rule removes the majority of the answers that cause real damage, because those are almost always numeric.
Refuse when retrieval is weak
Every retrieval carries a score. Below a floor we tune per corpus, the bot does not attempt an answer. It says it does not have that information and offers a human or a search link. Setting that floor is a judgement call you make with the business: raise it and containment drops but wrong answers nearly vanish, lower it and the reverse. We tune it against the golden set and show you the trade-off curve rather than picking silently.
Check the answer against its sources
For high risk topics, the drafted answer goes through a second, cheap model call that asks whether each claim is supported by the retrieved passages. Failed sentences are dropped or the whole answer is replaced with a handoff. This costs about 200 to 400 milliseconds and a fraction of a cent, and it catches the plausible-sounding embellishments that a single generation pass produces. We do not run it on every answer, because on "what are your opening hours" it is waste.
Make citation mandatory where it matters
On policy and how-to answers the bot links the article it used. Two benefits: the customer can check, and your reviewers can spot a bad answer instantly by seeing that a plausible reply cites an unrelated document. Citation turns silent retrieval failure into an obvious one.
Defend against injection, including the indirect kind
Direct jailbreak attempts are the easy case and mostly a nuisance. The dangerous one is indirect injection: instructions hidden inside a document your pipeline ingested, a product review, a PDF a customer uploaded, or a support ticket that gets indexed later. Retrieved text is treated as data and never as instruction, tool access is allowlisted per conversation type, and anything the bot ingests from an untrusted source is stripped of markup and control sequences before it goes anywhere near a prompt. Injection tests sit in the standing eval set, not in a one-off penetration test.
Log everything a reviewer needs
For each answer we store the retrieved chunk IDs, the scores, which tools were called with what arguments, the model and version, and the final text. When somebody escalates a bad answer three weeks later, you can reconstruct exactly why it happened in about four minutes. Without that trace you are guessing, and guessing about a probabilistic system is how teams end up rewriting prompts at random.
Escalation to a Human, and When It Should Fire
Escalation design is where a support bot earns or destroys its reputation, and it gets about a tenth of the attention it deserves. The goal is not to minimise handoffs. It is to hand off before the customer has decided your company is wasting their time.
The triggers we implement, roughly in order of how often they fire:
Explicit request. The customer types agent, human, representative, or anything close. This fires immediately with no attempt to talk them out of it. Retention gates on the human handoff are the fastest way to turn a mild query into a complaint, and every team that tries one removes it within a month.
Low retrieval confidence. Nothing relevant found, or found below the floor. The bot says so plainly.
No progress after N turns. Usually three. If the customer has restated the same problem three times, the bot has failed regardless of what its confidence scores say. Semantic similarity between consecutive customer messages is a decent proxy for "you are not listening to me".
Frustration signals. Profanity, all caps, repeated punctuation, sentiment falling across turns. Tune this carefully. British customers signal annoyance with politeness rather than volume, and a naive sentiment classifier misses it completely, which is a genuine reason to test with regional data rather than a generic model.
Restricted topic. Anything on the never-let-a-bot-near-this list from conversation design. Complaints, cancellations, legal or medical questions, suspected fraud, bereavement. These route straight through, often to a specific queue.
Tool failure. The order system timed out. Say that and route, rather than apologising vaguely.
Then there is the question of what happens when no human is available, which is most of the night. The pattern that works: the bot says clearly that the team is offline, gives the hours in the customer's own timezone, offers to raise a ticket with everything already captured, and confirms the ticket number in the chat. What it must not do is pretend to transfer someone into an empty queue. Customers wait, then leave, and that shows up in your CSAT weeks later without an obvious cause.
The handoff payload matters as much as the trigger. We pass the transcript, a two-line summary written by the model, the classified intent, the customer or order record where the session was authenticated, the escalation reason as a structured field, and any tool responses already fetched. That last item saves the agent from re-running the same lookup. The structured escalation reason is what lets you report on why the bot is failing rather than just how often.
Containment, Deflection and the Numbers That Lie
Three metrics get quoted in chatbot projects and two of them are usually measured wrong.
Containment is the share of conversations the bot resolved without a human. The naive definition counts any session that ended without a handoff click, which rewards a bot for being so unhelpful that people give up. We define it harder: no handoff, plus no ticket or call from the same customer within 72 hours, plus not a repeat of a question asked in the previous session. That definition needs your helpdesk joined to your chat logs on customer ID or email, which is a day of integration work and the most valuable day in the analytics build.
Deflection is the reduction in human contacts against a baseline, and it can only be measured against traffic you were already getting. Measure the four weeks before launch, then hold out a control group if your volume allows it. Without a control you will attribute a seasonal dip to the bot, and someone will eventually check.
Resolution quality is the one nobody instruments and the one that predicts whether the bot survives its first quarter. A thumbs rating gets responses from a self-selected and mostly annoyed minority. Sampled human review is better: a hundred conversations a week graded against a rubric of correct, partially correct, wrong, or should have escalated. It costs a couple of hours and it is the only number that tells you whether contained conversations were actually good.
Alongside those, the reporting we build shows escalation reason distribution, which tells you what to fix next; the unanswered question queue, which is your content backlog written by your customers; time to first token and full response at p50 and p95; cost per conversation and per contained conversation; and containment split by intent, because an average across "where is my order" and "explain my invoice" hides everything interesting.
One warning about targets. Containment above 70 percent across a general support inbox usually means either the bot is answering things it should not, or the inbox is dominated by one simple intent. Order tracking bots hit 80 percent legitimately. A bot handling billing disputes and technical troubleshooting will not, and setting that target guarantees someone games the definition.
Channels Are Not Interchangeable
The same assistant deployed to four channels is four different products. The retrieval and the tools are shared; almost nothing else is.
Web widget
The most forgiving channel and the one with the most front-end work. The widget has to survive whatever CSS your marketing site is running, which is why we mount it in a closed shadow root rather than trusting class name isolation. It needs to respect your content security policy, which frequently means self-hosting the script rather than pulling it from a vendor CDN, and that conversation with your security team should happen in week one rather than the day before launch.
The advantage is context. The widget knows what page the customer is on, what is in their basket, whether they are logged in, and how long they have been stuck on the pricing page. Passing that context into the prompt changes the quality of the first answer more than any model choice does. It also needs session continuity across a page reload, keyboard accessibility, a visible focus state and screen reader announcements for incoming messages, which is a WCAG 2.2 AA requirement people discover during a procurement review.
Different rules, and the rules are not yours. The 24 hour customer service window means you can reply freely for a day after the customer's last message and after that only with templates Meta has approved, which reshapes every follow-up flow. Template approval takes days and gets rejected for wording, so it goes into the plan early. You go through the Cloud API directly or a business solution provider such as Twilio, 360dialog or Gupshup, and each has different throughput tiers and different webhook semantics.
There is no rich UI. Interactive lists and reply buttons have hard item and character limits, so a flow designed for a web widget has to be rebuilt as short numbered choices. Identity is a phone number, which is a weak identifier: before showing anything account-specific you need a second factor, usually an OTP or a booking reference. And people treat WhatsApp as a persistent thread, so they reply to something from three weeks ago and expect you to remember. Your session model has to handle that.
In-app and authenticated assistants
The best channel to build for, because identity is already solved. You know who the user is, what plan they are on, what they did in the last ten minutes. The bot can go beyond answering into doing: resend the invoice, retry the failed sync, generate the export. That is also the risk, so every write action needs an explicit confirmation step, an idempotency key, and an audit record naming the user and the assistant.
The main design shift is that in-app users are usually mid-task, not browsing. Answers need to be shorter and more actionable than on a marketing site, and deep links into the right settings page beat instructions telling someone where to click.
Voice
A different discipline and worth saying so plainly. Speech recognition adds 300 to 700 milliseconds before your pipeline starts, synthesis adds more at the end, and callers will not tolerate the silences that a text chat absorbs without complaint. You need barge-in so the caller can interrupt, you need answers written for the ear rather than the eye with no lists and no URLs, and you need a confirmation pattern for anything the recogniser might have misheard. Accent coverage is a real constraint and needs testing with recordings of your actual customers rather than a demo. We build voice where the case is strong, and we say so when a call-back offer would serve the customer better.
Latency Budgets and What Slow Feels Like
Customers abandon chat over speed more often than over accuracy, and slowness is easier to fix. We set a budget at the start and hold every component to it.
For a text chat the working target is a first visible token inside 1 second and a complete answer inside 3 seconds at p50, with p95 under 6. Beyond about 8 seconds people retype or leave, and a typing indicator only buys you a couple of extra seconds of patience.
A typical breakdown on a grounded answer: input guardrail and PII scan 20 to 60 milliseconds, query rewriting for follow-up questions 150 to 400 if you use a model for it, vector plus keyword retrieval 30 to 120, reranking 80 to 250, then the generation call where time to first token dominates at 400 to 1200 depending on provider, model size and prompt length. Tool calls add a full round trip to your own systems, and a legacy order API that takes 2 seconds will destroy the budget on its own no matter what you do with the model.
What actually moves the number, in order of effect. Stream the response, because perceived latency is time to first token and nothing else. Skip the query rewrite on the first message of a conversation, where there is no history to resolve against. Cache retrieval for repeated questions, which on support corpora is a large share of traffic. Run the answer-verification pass only on the risk categories that need it. Pin your model endpoint to a region near your customers rather than near your development team, because the network hop is real and it is one of the few places where building in India and serving the US needs a deliberate decision. Fetch tool data in parallel with retrieval where the call does not depend on the retrieved content.
And decide in advance what happens when the model provider is slow or down, because it will be. A timeout at 8 seconds, a fallback to a second provider behind the same abstraction, and a degraded mode that shows help centre search plus a ticket form. A widget spinning forever is worse than a widget that admits it is broken.
Multilingual Chatbots Without the Quality Cliff
Turning on other languages is a checkbox in most platforms and a genuine engineering problem in practice. The failure is predictable: English answers stay good, the German ones become subtly wrong, and nobody on the team can read them well enough to notice for two months.
The core issue is retrieval, not generation. Modern models write decent French. They cannot retrieve a French answer from an English-only index unless the embedding space is shared across languages. Two workable routes. Use a multilingual embedding model such as bge-m3, Cohere embed-multilingual-v3 or multilingual-e5 so a French question matches an English passage directly, then answer in French with a note about the source language. Or translate the query into English, retrieve, and generate the answer in the original language. The first is cleaner and needs no extra hop; the second sometimes wins on corpora full of product names and technical terms where translation happens to be more predictable than cross-lingual matching. We test both against your content instead of guessing, because the answer genuinely varies by domain.
Then the things that bite afterwards. Language detection on a two-word message is unreliable, so honour an explicit user or account preference before you sniff. Code-switching is normal for a lot of customers and a bot that hard-locks to one language mid-conversation reads as broken. Formality is not decoration: German du and Sie, Japanese keigo, French tu and vous carry real meaning and a mistake there sounds rude rather than quaint, so formality goes in the system prompt per locale. Right-to-left languages need the UI tested rather than assumed. Dates, currency and number formats need locale-aware rendering, and a delivery date shown as 03/04 will be read two different ways on two sides of the Atlantic.
Most importantly: every supported language needs its own evaluation set, graded by someone who actually speaks it. Fifty questions per language reviewed by a native speaker before launch. Skipping that is how the German bot quietly gets worse than no bot at all.
PII, Retention and What Your DPA Needs to Say
Chat transcripts are one of the messiest data sources a company holds, because customers paste anything. Card numbers, passwords, medical detail, someone else's phone number. Assume all of it will arrive and design for it.
Redact before you store, not after
Detection and masking runs on the message before it is written to any log, sent to any analytics tool, or included in a prompt beyond the current turn. Microsoft Presidio handles the common entity types and can be extended with your own patterns for policy numbers, member IDs or booking references. Card numbers get dropped outright rather than masked, and the bot tells the customer never to type them, because a chat channel that touches PAN data drags your whole stack into PCI scope for no benefit.
Know where the text goes
A prompt sent to a hosted model leaves your infrastructure. Your privacy notice and your data processing agreement have to say so, naming the sub-processor. Standard contractual clauses cover the transfer where the provider is outside the UK or EEA. Zero-retention or no-training endpoints exist across the major providers and should be enabled explicitly rather than assumed. If your position is that customer text cannot leave your cloud account at all, that is a legitimate requirement and it means self-hosting an open model, so it needs to be on the table in week one rather than discovered during a security review.
Retention and erasure that actually work
Set a retention window per data category and enforce it with a job, not a policy document. Ninety days for full transcripts is a common landing point, with anonymised aggregates kept longer for reporting. Erasure under GDPR Article 17 has to reach every copy, and the one people forget is the vector index: if a resolved ticket containing a customer's details was embedded into your retrieval store, deleting the source row does not remove the chunk. We build deletion to cascade to embeddings and keep a record of it, because being unable to demonstrate erasure is its own problem.
Access, residency and audit
Role-based access to transcripts with a reason recorded on lookup. Region-pinned deployment where you need EU, UK or Australian residency, which our engagements handle by deploying into your cloud account in that region so the data never leaves it. Delivery-side controls covered in the offshore section below. Where HIPAA or a sector regulator is in play we work to the controls your compliance team specifies rather than claiming a certification we do not hold, and we say plainly which parts of the stack are in scope.
How We Evaluate a Bot Before It Talks to a Customer
This is the part that separates a chatbot project from a chatbot demo, and it is where most of the engineering discipline lives.
Build the golden set from real questions
Between 150 and 400 questions pulled from your actual tickets, chat logs and site search, weighted to match real volume rather than what the product team finds interesting. Each entry records the expected behaviour: the correct answer, the source document it should come from, whether it should call a tool, or whether the right outcome is a refusal and a handoff. Building this takes two to four days and it pays for itself several times over, because everything afterwards is measured against it.
Measure retrieval separately from generation
When an answer is wrong, you need to know whether the retriever failed to find the passage or the model failed to use it. Those have completely different fixes. Recall at 5 and 10 and mean reciprocal rank on the golden set tell you the first. If recall at 10 is 0.7, no prompt engineering will save you, and the work is chunking, hybrid search weights and reranking.
Grade the answers
Groundedness, meaning every claim traces to a retrieved passage. Relevance to the question asked. Completeness against the expected answer. Correct refusal on out-of-scope questions, which is scored as a success, not a failure. A model-based grader with a tight rubric handles the bulk cheaply, and a human spot-checks 15 to 20 percent because model graders have their own blind spots and are generous about fluent nonsense.
Run the adversarial set
Separate from the golden set: jailbreak attempts, indirect injection through poisoned documents, requests for other customers' data, questions designed to extract the system prompt, competitor comparisons, legal and medical questions, and abusive input. Scored pass or fail with no partial credit. This set only grows, because every incident after launch adds a case to it.
Regression testing on every change
The suite runs in CI on every prompt change, retrieval config change, content re-index and model version bump. Prompts are code and are reviewed like code. This is what makes a chatbot maintainable, because otherwise a one-word prompt tweak to fix one complaint silently breaks nine other behaviours and nobody finds out for a fortnight.
Shadow mode, then a canary
Before any customer sees it, the bot runs alongside your agents on live traffic and drafts answers nobody sends. Your team grades a sample for a week. That single week produces better information than a month of internal testing, because real customers phrase things in ways your team never will. Then 5 to 10 percent of traffic, watched daily, with a kill switch that reverts to the old experience in one click and does not require a deployment.
How the Engagement Runs, Week by Week
A first production chatbot on one channel typically runs six to eight weeks. Additional channels and authenticated tool integrations extend it. This is the shape rather than a promise, and the estimate is fixed after week one, not before it.
Week 1: scope and ticket analysis
We read your tickets and chat logs and produce the intent volume breakdown, the answerable list, the refusal list, and the tools the bot will need. You will usually learn something about your own support mix here. Output is a scope document and a fixed estimate against it.
Week 2: content audit and ingestion
Your knowledge sources get inventoried, cleaned and indexed. Expect to find contradictions between the help centre and the policy PDF; the bot cannot resolve those and someone on your side has to decide. This is the most common cause of a slipped week, and it is worth staffing.
Weeks 2 to 3: golden set and retrieval build
The evaluation set is written while retrieval is built, deliberately in that order so the target exists before the thing being measured. Retrieval is tuned until recall on the golden set clears the agreed bar. No generation work happens until it does.
Weeks 3 to 5: generation, tools and guardrails
Prompting, refusal behaviour, tool integrations against your APIs, PII redaction and the injection defences. Each tool ships with its own failure path tested by pulling the plug on a staging dependency and watching what the bot says.
Week 5: escalation and helpdesk wiring
Handoff into your helpdesk with the full payload, tested end to end with a real agent on a real queue. Agents are asked what is missing from the payload, and the answer changes the build. Out-of-hours behaviour agreed and implemented.
Week 6: shadow mode
Live traffic, drafted answers, nothing sent. Your team grades a sample daily. Content gaps found here are fixed here. This week is where most of the real quality arrives, and cutting it is the single worst false economy in a chatbot project.
Week 7: canary launch
5 to 10 percent of traffic, monitored daily against containment, escalation reasons and sampled quality. Kill switch tested before the first customer arrives. Thresholds retuned against real behaviour rather than the golden set.
Week 8 and onward: ramp and handover
Traffic increased in steps with a hold at each level. Runbook, eval suite, ingestion pipeline and dashboards handed to your team, plus a working session where your engineer makes a change and ships it with us watching rather than driving.
Four Situations We Get Called About
A direct-to-consumer retailer drowning in order status
Most of their contacts are variations on where is my parcel, concentrated in a spike after every promotion, and the team hires temporary agents twice a year to survive it. Instinct says point a bot at the FAQ. That fails, because the answer is not in any document. It is in the order record and the carrier tracking feed.
The build is mostly integration: an order lookup tool, a carrier API, and an authentication step that matches email plus order number or postcode without leaking whether an email exists in the system. The interesting part is what the bot does with a delayed parcel. It should not read out a tracking status the customer already checked. It should say the carrier scan is four days stale, apologise concretely, and offer the two things your policy actually permits, usually a replacement or a refund, then execute whichever they pick. Peak traffic means the latency budget gets tested properly with load, and the carrier API rate limit becomes the constraint rather than the model.
A B2B SaaS company with 900 pages of documentation
Support engineers spend their days linking people to docs that already answer the question. Good case for retrieval, with one complication that sinks naive builds: three supported product versions, and the docs for all three sit on the same site. A customer on v2 gets a v4 answer, follows it, and files a bug against your product.
The fix is metadata filtering at retrieval time, with version resolved from the account record where the session is authenticated and asked explicitly where it is not. Every answer cites the doc page and states which version it applies to. The second thing worth building here is the unanswered question queue, which becomes the documentation team's backlog written by real customers, and in our experience it is the deliverable the client ends up valuing most.
A financial services firm that cannot give advice
Regulated, so the constraint is not accuracy but scope. The bot may explain how a product works and may never recommend one, never project a return, never comment on suitability. The failure mode is a model that helpfully drifts from explanation into recommendation over three turns because the customer keeps pushing.
That needs a classifier on every outbound message, not just the inbound one, plus an audit log an auditor can read without a developer present. Full transcript retention with the retrieval sources attached to each answer. PII redaction before anything lands in analytics. Deployment inside the client's own cloud tenancy in their region. And a refusal script written by their compliance team rather than by us, so the wording is theirs to defend.
A clinic group taking bookings on WhatsApp
Patients message a phone number expecting to book, move or cancel an appointment. Health data means minimal collection: the bot handles scheduling and never discusses symptoms, and anything clinical routes to a person immediately.
The engineering is dominated by WhatsApp's rules. Reminders after the 24 hour window need approved templates, so the reminder copy goes through approval in week one. Identity is a phone number, which is not enough to expose an appointment history, so the flow verifies with a date of birth or booking reference before showing anything. Calendar writes go through an idempotency key, because a customer tapping twice on a flaky mobile connection must not create two appointments. And every conversation ends by confirming the outcome in plain text, because people screenshot that and it removes a whole class of dispute.
How Offshore Delivery From India Actually Works
We are in India and you are not, so the honest questions are about overlap, control and what happens when something breaks at an inconvenient hour. Here are the real answers.
The overlap window, stated plainly
A standard Indian working day is 09:30 to 18:30 IST, which is 04:00 to 13:00 UTC. Against a UK team that gives you four hours of live overlap in winter and five in summer, and it is genuinely comfortable. Against Australia it gives two to three hours at the end of your day, which improves to four if our team starts at 07:30 IST, and for New Zealand an early Indian start is the only thing that produces meaningful overlap at all.
Against US Eastern, a standard Indian day gives you zero. That is the truth and there is no way to phrase it into an advantage. To get overlap somebody shifts. A 13:00 to 22:00 IST shift produces about two and a half hours from 09:00 Eastern; pushing to 15:00 to 24:00 IST gives about four and a half hours, at the cost of an engineer finishing at midnight. That is sustainable for a rota of two or three people and corrosive as a permanent arrangement for one, and any team promising it indefinitely for one person is describing turnover they have not told you about. US Pacific is harder still. We would rather agree a two hour daily window plus disciplined async than pretend at more.
What we do not claim is 24/7 coverage as a free bonus. Round-the-clock support means three shifts, three sets of context, and a handover cost you pay in coordination. It is worth it for production on-call on a system that matters. It is not worth it for development work.
Why chatbot work suits this model better than most
Here is a genuine advantage rather than a spun one. The recurring post-launch task on a chatbot is reading yesterday's conversations, spotting the failures, and fixing content or thresholds. Your evening is our morning. Conversations from your US afternoon get reviewed while you sleep, and the fixes are waiting for your standup. Very little of that work needs synchronous discussion, which is not true of, say, greenfield UX design.
Working rhythm and how you keep control
A written daily update in your Slack before your morning: what shipped, what the eval numbers did, what is blocked and what decision we need from you. One live call in the overlap window, kept to twenty minutes unless there is something real. A weekly demo against the golden set so progress is a number and not an opinion.
Written-first is not a nicety when the day barely overlaps. Decisions go in the repository as short architecture notes with the option that was rejected and why, so nobody has to reconstruct a Slack thread at 2am. Every change lands as a pull request with the eval run attached, and you may require your own approval on the escalation rules and refusal copy, which many clients do and we recommend. Prompts sit in version control and are reviewed like any other code.
People, English and continuity
You interview the engineers who will do the work and you can decline anyone. The person you talk to daily is the person writing the code; we do not put an account manager between you and the engineer, because on a system where the failure modes are subtle the translation layer costs more than it saves.
English is assessed in a working conversation about a technical trade-off rather than a test score, because the thing that matters is whether someone can disagree with you clearly in writing at 11pm your time. India's contact centre and support industry also means it is possible to hire engineers who have actually watched a support queue, which turns out to matter on this work more than a machine learning credential does.
On continuity: we work so that more than one person knows anything running in production, so a resignation is not an outage. Notice and handover terms are set out in the agreement before work starts, giving structured time to hand over when someone leaves. If a person is not working out, tell us and we will address it directly rather than let it drift; the mechanics of a replacement are settled in the agreement you sign, not improvised afterward. Exit is written into the contract from the start: repository access is yours throughout, documentation is a deliverable and not a favour, and the last two weeks of any engagement are handover.
Security and access
Company-managed devices with disk encryption and screen lock, access through your SSO where you have it, least-privilege repository and cloud permissions, no production customer data on developer machines. Where transcripts contain regulated data, we work in your environment through your access controls rather than copying anything to ours. NDAs and IP assignment are agreed before the first commit, and prompts and evaluation sets are worth naming explicitly in that paperwork, because those are the assets people forget to list.
The hidden costs, said out loud
Ramp-up is real: the first two weeks are slower while the team learns your systems, and pretending otherwise just moves the disappointment. Content ownership is the big one, and it is yours: somebody on your side has to decide what your refund policy actually is when two documents disagree, and no vendor can do that for you. Post-launch review is ongoing work, not a project that ends. And a chatbot exposes every inconsistency in your documentation, which produces a content backlog you did not have before. That backlog is genuinely valuable and it is still work.
The Risks Nobody Puts on a Sales Page
Your content is worse than you think. More often than not, a chatbot project uncovers a help centre with contradictory articles, policies that were changed in practice but never in writing, and pages last reviewed three years ago. The bot surfaces this within days. Plan for a content sprint you did not budget for, and put someone with authority on it.
Model providers change underneath you. A version bump can shift behaviour on a set of edge cases without any change from you. Pin versions where the provider allows it, keep the eval suite running on a schedule and not just on commits, and treat a provider deprecation notice as a scheduled piece of work rather than an emergency.
Costs scale with conversations and with prompt length. The prompt is the meter. Long retrieved passages, long histories and a verification pass all multiply. We instrument cost per conversation from day one, cap history length, and cache aggressively, because the bill that surprises people is almost always retrieval context rather than output.
Agents can quietly sink it. If your support team believes the bot is there to replace them, handoffs get mishandled and internal feedback dries up. Involve them in shadow mode grading, show them the escalation reasons, and give them a one-click way to flag a bad answer. Their flags are the best quality signal you will get.
Legal review arrives late and can reset your timeline. The questions are predictable: where does the text go, who is the sub-processor, how long do you keep transcripts, what does the bot promise. Get them asked in week one. A privacy review discovered in week seven has moved more launch dates than any technical problem we have hit.
Success can look like failure for a month. Containment often dips after launch as the bot starts handling harder questions that used to bounce. Meanwhile the easy contacts it absorbed are gone from your queue, so average handling time on human tickets goes up because only the hard ones are left. Both are healthy. Agree that reading of the numbers before launch, or someone will use it as evidence the project failed.
Engagement Models
Fixed-scope build
Best when the use case is clear: one or two channels, a defined content set, a known list of tools. We scope in week one and fix the price against that document. You get the bot, the eval suite, the ingestion pipeline and the handover. Changes to scope are quoted separately rather than absorbed silently, which keeps the estimate honest in both directions.
Dedicated team
Right when the assistant is a product surface rather than a project: multiple channels, continuous content and tool expansion, your own roadmap. Two to five people working to your backlog and your ceremonies, in an agreed shift window. Billing and notice terms are agreed with you before anyone starts. Most clients who start with a fixed build and keep going end up here.
Support and improvement retainer
For a bot already live, ours or someone else's. A set number of engineering days a month covering conversation review, content gap closure, threshold tuning, eval maintenance and provider version changes. This is the model most first-time buyers underestimate, because a chatbot is not a thing you finish.
We also take on rescue work: an existing bot that hallucinates, escalates badly or cannot be measured. That starts with a two week audit producing an eval set and a written diagnosis, and often the honest recommendation is to keep the platform and fix retrieval rather than rebuild anything.
Where This Sits Next to Our Other Work
If you want engineers embedded in your own team rather than a delivered project, hire chatbot developers covers the staffing route, and the retrieval and evaluation practice described above is the same either way. Most of the pipeline work on these builds is Python, so teams extending an existing bot often add Python developers in India to their own roster instead.
Where the bot needs to read from an ERP, a CRM or an order system that has no usable API, that is enterprise integration work and it usually sets the timeline rather than the chatbot itself. If the question is broader than a chatbot, for example which parts of your support and operations are worth automating first, AI strategy consulting starts with the assessment instead of the build. And where the requirement runs past conversation into forecasting, classification or scoring, AI and machine learning services covers the modelling side.
Frequently Asked Questions
What does a chatbot development project actually deliver?
A working assistant on your chosen channels, the retrieval index behind it, the tool integrations that let it read order or account data, the escalation path into your helpdesk, an evaluation suite you can rerun after every change, and a dashboard showing containment, escalation reasons and unanswered questions. You also get the prompts, the eval set and the ingestion pipeline as source you own, not as configuration locked inside a vendor console.
Should we build on GPT, Claude, Gemini or an open model?
Pick on constraints, not on benchmarks. If your data cannot leave your infrastructure, an open model such as Llama or Qwen on your own GPUs is the only option and you accept the operations cost. If it can, a hosted model is faster to ship and cheaper below roughly a million conversations a year. We build behind a provider abstraction so switching is a config change, then run your own eval set against two or three candidates.
How long before the chatbot is live?
A single channel bot answering from existing documentation, with handoff to your helpdesk, is typically six to eight weeks from kickoff to real traffic. Add three to four weeks for each authenticated tool integration such as order lookup or booking. WhatsApp adds two to three weeks of Meta business verification and template approval that sits outside our control. Anyone promising two weeks is skipping the evaluation.
What containment rate is realistic in the first quarter?
For a support bot over decent documentation with two or three lookup tools, 35 to 55 percent of contacts fully resolved without a human is a defensible first quarter, climbing as you close content gaps. Anyone quoting 80 percent before reading your ticket mix is either counting abandoned chats as successes or serving a narrow use case such as order tracking, where high numbers are genuinely normal.
How do you stop the bot giving a wrong answer about pricing or policy?
Anything with a number in it comes from a tool call against a live system, never from the model reciting a document. Pricing, balances, delivery dates and entitlements are read through an API at answer time. On top of that we set a retrieval score floor below which the bot refuses and hands off, and we run an entailment check that compares the drafted answer against the retrieved passages before it is sent.
Can the chatbot run on WhatsApp as well as our website?
Yes, and it needs separate design work rather than a copied deployment. WhatsApp has a 24 hour customer service window, after which you may only send pre-approved template messages, so any follow up flow has to be built around that rule. Rich UI does not exist, so option lists replace buttons and long answers need splitting. Identity is a phone number, which changes how you authenticate someone before showing account data.
Who owns the code, the prompts and the conversation data?
You do, assigned in the contract before work starts. That covers the application code, the prompts, the evaluation set, the ingestion pipeline and every conversation log. We sign your NDA and a data processing agreement, and where you need EU or Australian data residency we deploy into your cloud account in that region so the transcripts never leave it. Nothing is trained on your data without a separate written instruction.
What happens after launch, and what does the ongoing work involve?
Somebody reads conversations every day for the first month, then weekly. The recurring work is closing content gaps the bot exposes, retuning escalation thresholds, adding tools for questions that need live data, and rerunning the eval suite when a model version changes underneath you. Budget a day or two a week of engineering after launch. A chatbot left alone for a quarter quietly gets worse as your product moves on.