AI chatbot development ranges from configuring a scripted flow in an afternoon to building an agent that takes actions in your systems over several months. The effort differs by roughly a hundredfold, and most of the cost sits in integrations and grounding rather than in the conversational layer itself.
A brief that says “we want an AI chatbot on our website” could describe a weekend of configuration or a six-month engineering project. Both are legitimate. The problem is that nobody establishes which one is meant before quoting, which is why chatbot projects overrun more reliably than almost any other category of software. This piece is about getting that decision right first.
About Wow Labz. Wow Labz is an AI-native custom software development company based in Bengaluru, India. Since 2011 it has shipped 400+ products across 15+ years, won 30+ awards, and touched 100M+ lives, for clients including Coca-Cola, AB InBev, HDFC, Emaar and UCSF. It holds a 5.0 rating across 23 verified Clutch reviews and is ISO 27001 certified.
Four different things people call a chatbot
Sorting your requirement into one of these four tiers is the single most useful thing you can do before talking to any supplier. The capability gap between them is enormous, and so is the cost.
Tier one: scripted flow
Buttons and decision trees, with no AI involved. It routes enquiries, qualifies leads, books slots and collects form data. It cannot answer anything you did not anticipate, and that limitation is frequently acceptable. If your goal is to get visitors to the right place or capture a lead, this is often the correct answer and it is available off the shelf for a low monthly fee. Configure it, do not build it.
Tier two: FAQ retrieval
Answers questions whose answers already exist in your help centre or documentation, using retrieval rather than scripted rules. This is where most briefs actually land once you interrogate them. It cannot see your live data and it cannot take an action. Days of work, and the real effort is cleaning up the content it will draw from rather than the bot itself.
Tier three: grounded assistant
Reads your live systems to answer questions specific to the person asking. Where is my order, what is my balance, when does my contract renew. This is where genuine integration work begins: authentication, access scoping, API reliability. It reads but does not write. Weeks rather than days, and the cost lives almost entirely in the integrations.
Tier four: acting agent
Issues refunds, changes bookings, updates records, escalates with context. At this point it is not really a chatbot any more, it is an agent with a chat interface, and it needs approval gates, audit trails, cost ceilings and an evaluation suite. Months, with governance accounting for most of the work.
If your requirement is tier four, the conversational surface is the least interesting part of what you are commissioning. Our guide to how to build an AI agent covers that build properly, and for support-specific deployments AI agents for customer support covers what to automate and what to escalate.
How to tell which tier you need
Four questions, in this order. The first no answer tells you where to stop.
- Do users ask questions you cannot list in advance? If yes, you are at tier two or above. If the answers are all knowable in advance and finite, tier one will do and will be more reliable.
- Does the answer depend on who is asking? If yes, you need tier three. “Where is my order” cannot be answered from a help centre, no matter how good the retrieval is.
- Does it need to change something in a system? If yes, you are at tier four, with everything that implies for governance. If it only needs to tell someone what to do, tier three is enough.
- Can you name the metric that will prove it worked? If not, that is not a reason to avoid building. It is a reason to start at tier two, measure, and expand. Tiers compose upward reasonably well when designed that way.
The most common mis-scope we see. A brief written for tier four, a budget approved for tier two, and an expectation set with stakeholders somewhere in between. The gap surfaces at the first demo, when the bot answers general questions well and cannot tell a customer where their order is.
Where the money actually goes
This is the part quotes tend to obscure, and it is worth understanding before you compare two of them.
On a tier three build, integrations typically dominate: authentication against each system, API reliability, rate limits, and defined behaviour when a system is down. Knowledge and grounding comes next, and most of that is cleaning up content rather than configuring retrieval. Guardrails and testing, conversation design, and analytics account for most of the remainder.
The conversational layer itself, which is to say prompting a model and wiring it to a chat interface, is a small share of the work. That is the inversion worth internalising. A quote that is mostly “chatbot development” with integration as a minor line item has the ratio backwards, and the overrun will arrive precisely where the estimate was thinnest.
The percentages are illustrative rather than a benchmark, drawn from typical engagements. The proportions shift by project. The ordering is remarkably stable.
The no-code route, honestly
For tiers one and two, no-code platforms are usually the right choice, and we say that as a company that builds custom software. They will get you a working, monitored, maintained chatbot faster and cheaper than any bespoke build, and the vendor carries the maintenance burden.
Three places they run out.
- Integration depth. Connecting to a system the platform does not natively support is where no-code projects stall. If your requirement is tier three, check the connector list before anything else.
- Evaluation and testing. Most platforms report deflection and containment. Few give you a proper evaluation set you can re-run before changes. That gap matters as soon as the bot is customer-facing.
- Compliance and data residency. Where the bot must operate inside a regulated process, or where conversation data cannot leave your perimeter, packaged tools frequently cannot be made compliant at any price.
A reasonable sequence: prototype on a no-code platform to learn what users actually ask, which is information you cannot get any other way, then decide whether the production system needs to be custom.
How a chatbot build actually runs
- Collect real questions first. Pull a few hundred real questions from your support inbox, chat logs or search queries. This costs a day and reshapes most briefs, because the distribution of what people actually ask is rarely what stakeholders expect.
- Fix the tier. Use the four questions above. Get it agreed in writing, because this is the decision everything else depends on.
- Sort out the grounding. For tier two, that means auditing and cleaning the content. For tier three, it means confirming which systems it will read and whether you can actually get authenticated access. Discovering an API limitation late is the most common cause of overrun.
- Design the failure behaviour. What it says when it does not know, when it must not answer, and when it hands to a human. Designing this last is the classic mistake; it is the behaviour users encounter most.
- Build the evaluation set. Fifty to a hundred real questions with expected answers, run before every change. Without this you cannot tell whether a prompt edit improved anything.
- Launch narrow. Publish to a segment, watch the transcripts daily for the first fortnight, and expect the first week of real conversations to surprise you.
What breaks in production
- Stale grounding. A bot that answers confidently from stale help content will tell customers about a policy that changed last quarter. Grounding needs a freshness process, not just a one-time index.
- No refusal behaviour. If the bot cannot say “I do not know, here is a human”, it will invent something. Refusal behaviour is a feature and it needs explicit design and testing.
- Escalation without context. Handing a frustrated user to an agent with no transcript makes the experience worse than having no bot. Escalation must carry context.
- Cost at scale. Per-conversation model costs look trivial in testing and become significant at volume, particularly if the bot retries or holds long context windows. Set ceilings.
- Nobody owns it. Nobody reads the transcripts after week two, so the bot quietly degrades as products change. Assign an owner before launch, not after.
Build, buy, or configure
| Route | Right for | Watch for |
|---|---|---|
| Configure a no-code tool | Tiers one and two, standard requirements | Connector coverage, and weak evaluation tooling |
| Platform plus integration work | Tier three where a platform covers most of it | Integration effort being under-quoted |
| Custom build | Tier four, regulated processes, or where the bot is part of your product | Ongoing ownership, which exceeds the build |
Most organisations asking for a chatbot should configure rather than build. The build case is real but narrower than the market implies: it holds when the bot must act, when integration depth defeats packaged connectors, or when compliance rules out third-party processing.
Questions to ask any supplier
- Which tier is this quote for? Any answer other than a tier is a warning sign. It means the requirement has not been pinned down.
- What share of the estimate is integration work? If it is a small percentage of the total on a tier three build, the estimate is wrong.
- What happens when it does not know? There should be a specific, designed answer. “It will hand over to a human” is not a design.
- How will we know if a change makes it worse? If there is no evaluation set, nobody can tell whether changes are improvements.
- Who maintains the grounding content? The answer should be a person and a cadence, not a support email address.
How Wow Labz approaches chatbot development
We start by reading your real questions, because the tier decision follows from the data rather than from the brief. If tiers one or two cover your requirement, we will tell you to configure a tool and we will name one. That conversation costs us a project and saves you considerably more.
Where custom work is warranted, usually at tier three or four, we scope the integrations explicitly and separately, so the estimate reflects where the effort actually sits. Our AI development services team designs the refusal behaviour, escalation and evaluation set as part of the build rather than as a later phase, because those are the parts users actually encounter.
Our agentic delivery platform, NeoCrew, compresses the build into days rather than weeks. On chatbot work that matters mainly because it leaves the timeline available for grounding and evaluation, which is what separates a bot people use from one they route around.
Not sure which tier your chatbot needs to be?
It is a one-week question, and getting it wrong is what causes chatbot projects to overrun. In a Discovery Sprint we review your real user questions, fix the tier, scope the integrations line by line, and give you a fixed estimate. Tell us what you want your chatbot to do and we will tell you honestly whether you need a build or a subscription.
Frequently asked questions
How much does AI chatbot development cost?
It depends entirely on which of four tiers you need. A scripted flow is a low monthly subscription. FAQ retrieval over your own content is days of work. A grounded assistant that reads live systems runs to weeks, with integration dominating the cost. An agent that takes actions runs to months, with governance accounting for most of the effort.
What is the difference between a chatbot and an AI agent?
A chatbot answers questions within a conversation. An AI agent reasons across multiple steps, retrieves from your systems, takes actions such as issuing a refund or updating a record, and decides when to escalate. The practical difference is that an agent can complete a task rather than only respond to a question.
Can I build an AI chatbot without coding?
Yes, and for many requirements you should. No-code platforms handle scripted flows and retrieval over your own content well, and the vendor carries maintenance. They run out at deep integrations with systems they do not support, at rigorous evaluation, and at compliance constraints such as data residency.
How long does it take to build an AI chatbot?
Hours for a scripted flow, days for FAQ retrieval, weeks for a grounded assistant that reads live systems, and months for an agent that takes actions. Timelines are usually set by data and integration access rather than by the conversational build itself.
What is the hardest part of AI chatbot development?
Integration and grounding, not conversation. On a typical grounded build, integrations and knowledge preparation together account for over half the effort, while prompting and wiring the model to a chat interface is a small share. Designing what the bot says when it does not know is also consistently underestimated.
Should we build a custom chatbot or use a platform?
Configure a platform unless you have a specific reason not to. Building is justified when the chatbot must take actions in your systems, when integration depth exceeds what packaged connectors cover, when the bot is part of the product you sell, or when compliance prevents conversation data being processed by a third party.
