AI Chatbot for Business: Custom vs Off-the-Shelf and When Each Makes Sense

An AI chatbot for business is a conversational system that uses natural language processing to understand what a customer or prospect is asking and respond with relevant information, actions, or routing decisions. Unlike rule-based chatbots that follow scripted decision trees, AI chatbots interpret meaning from unstructured text, handle questions they were not explicitly programmed for, and improve their responses as they process more conversations.

Platforms like Intercom, Drift, Zendesk, and HubSpot all offer chatbot builders. They work well for standard use cases: answering FAQ questions, collecting lead information through forms, and routing conversations to the right support team. They stop working when the chatbot needs to pull data from internal systems, apply business-specific logic to qualify leads, handle multi-step workflows that span departments, or operate across channels (web, WhatsApp, SMS, voice) with a unified conversation history.

What does an AI chatbot for business actually do?

Production AI chatbots handle five categories of work: answering questions, qualifying leads, booking actions, resolving support issues, and routing conversations. The difference between a production chatbot and a demo is that a production system connects to the company's real data and takes real actions.

Question answering goes beyond FAQ matching. A production chatbot trained on a company's knowledge base, product documentation, pricing structures, and policy documents can answer questions that span multiple sources. A customer asking "can I upgrade my plan and keep my current billing date?" requires the chatbot to understand the pricing model, the billing rules, and the upgrade path. A rule-based system cannot answer this unless someone anticipated and scripted that exact question.

Lead qualification means the chatbot asks diagnostic questions, evaluates the responses against the company's qualification criteria, and scores the lead before passing it to sales. The qualification logic is specific to the business. A SaaS company might qualify on company size, current tools, and budget timeline. A construction company might qualify on project type, location, and scope. The chatbot applies the same criteria a human sales rep would, but does it at 2 AM on a Saturday when the prospect is browsing the website.

Booking actions include scheduling meetings, creating support tickets, initiating returns, processing cancellations, and updating account information. Each action requires the chatbot to connect to a backend system (calendar API, ticketing system, CRM, order management) and execute a real transaction. The chatbot is not just collecting information. It is completing the task.

Support resolution handles the issues that do not need a human. Password resets, order status lookups, shipping updates, invoice requests, and account changes are all resolvable by a chatbot that has access to the right systems. In contact center operations where we have built AI systems, these routine inquiries typically account for 40-60% of total ticket volume. Resolving them automatically frees the human team to handle complex issues that actually require judgment.

Conversation routing uses intent classification to determine which team, agent, or department should handle a conversation the chatbot cannot resolve. The AI reads the conversation, classifies the intent, assesses urgency, and routes accordingly. A billing complaint routes to the billing team. A technical issue routes to support. A prospect asking about enterprise pricing routes to the sales team with the qualification context attached.

How do platform chatbots compare to custom-built chatbots?

Where do platform chatbots stop working?

Platform chatbots are designed for companies whose customer interactions follow predictable patterns. They stop working in five situations.

Complex product catalogs break platform chatbots. A company with 10,000 SKUs, configurable products, or industry-specific pricing rules cannot answer product questions from a FAQ database. The chatbot needs to query the product database in real time, apply the customer's pricing tier, check inventory, and present options that match the specific request. Platform chatbots do not connect to product databases at this depth.

Multi-step workflows that span systems break platform chatbots. A customer requesting a return that involves checking order status in the OMS, initiating a return in the warehouse system, issuing a credit in the billing system, and sending a confirmation email requires the chatbot to orchestrate actions across four systems. Platform chatbots handle single-system actions, not multi-system workflows.

Industry-specific compliance requirements break platform chatbots. Healthcare chatbots handling patient inquiries need HIPAA-compliant infrastructure. Financial services chatbots need audit trails and data handling that meet regulatory requirements. Platform chatbots offer general compliance certifications but not the specific data handling, logging, and retention requirements that regulated industries demand.

Omnichannel with unified context breaks platform chatbots. A customer who starts on WhatsApp, continues on the website, and calls in expects the conversation to be continuous. Platform chatbots treat each channel as a separate interaction. Custom chatbots maintain a single conversation thread across all channels, with full context available to both the AI and any human agent who takes over.

High conversation volume with per-interaction pricing breaks platform chatbots economically. A company handling 50,000 conversations per month at $0.50-2.00 per AI resolution pays $25,000-100,000 per month for platform chatbot AI features. A custom chatbot with the same volume costs $1,500-5,000 per month in LLM API usage and hosting after the initial build investment.

What does a custom AI chatbot include?

A production custom chatbot has six components: the conversation engine, the knowledge layer, the action layer, the routing logic, the analytics system, and the admin interface.

The conversation engine handles natural language understanding and response generation. In 2026, most custom chatbots use LLM APIs (OpenAI, Anthropic, or open-source models) as the language backbone, with system prompts and guardrails that keep the chatbot on-topic and accurate. The engine maintains conversation state, handles multi-turn interactions, and knows when to ask clarifying questions versus when to act.

The knowledge layer connects the chatbot to the company's information. This is typically implemented as a RAG (retrieval-augmented generation) system: the chatbot retrieves relevant documents, product data, or policy information from a vector database before generating a response. The knowledge layer is what makes the chatbot accurate about the company's specific products, pricing, and policies instead of generating plausible but incorrect answers.

The action layer connects the chatbot to backend systems. Each action the chatbot can take (book a meeting, create a ticket, look up an order, process a return) is a defined function with input validation, error handling, and confirmation logic. The chatbot does not guess at actions. It confirms with the user before executing anything irreversible.

The routing logic determines when to escalate to a human. This is the most important component for customer experience. The chatbot needs to recognize when it cannot resolve an issue (novel complaints, emotionally charged interactions, requests outside its scope) and route to the right human agent with full conversation context. Poor routing means frustrated customers repeating themselves. Good routing means the agent reads the chatbot's summary and picks up where it left off.

The analytics system tracks resolution rates, escalation rates, customer satisfaction scores, and conversation topics. It identifies where the chatbot fails (which questions it cannot answer, which actions fail, which conversations get escalated) so the team can improve it. Without analytics, the chatbot stays static. With analytics, it gets better every month.

The admin interface lets non-technical team members update the chatbot's knowledge base, adjust routing rules, review flagged conversations, and monitor performance without touching code. This is critical for long-term success. A chatbot that requires a developer for every knowledge update falls behind quickly.

How much does a custom AI chatbot cost?

A focused chatbot that handles one channel (web), connects to one knowledge source, and performs basic actions (FAQ answering, lead capture, meeting booking) costs $30,000-60,000 to build. A multi-channel chatbot with deep system integrations, custom qualification logic, omnichannel conversation history, and an admin interface costs $80,000-150,000.

Operating costs include LLM API usage ($0.01-0.10 per conversation depending on length and model), hosting ($200-800/month), and monitoring. For a company handling 10,000 conversations per month, the LLM cost is $100-1,000 per month. At 50,000 conversations, it is $500-5,000 per month. These costs are predictable and scale linearly with volume.

The cost comparison favors custom at scale. A platform chatbot for a 20-person support team costs $200-500 per seat per month ($4,000-10,000/month) for AI features. A custom chatbot costs $1,500-5,000 per month after the initial build, regardless of team size. Companies processing more than 15,000 conversations per month typically break even within 12-18 months.

When should a company build a custom chatbot instead of using a platform?

Use a platform chatbot when: the company handles fewer than 5,000 conversations per month, the product catalog is simple, the support workflow is standard (FAQ plus ticket creation plus meeting booking), one channel (web) is sufficient, and the team needs the chatbot live within days rather than weeks.

Build custom when: the chatbot needs to execute multi-step workflows across backend systems; the company operates in a regulated industry with specific compliance requirements; the product catalog, pricing, or business logic is too complex for a FAQ-based approach; multiple channels need unified conversation context; conversation volume makes per-interaction pricing prohibitive; or the chatbot is a core part of the customer experience and needs to reflect the company's specific brand, tone, and service standards.

Many companies start with a platform chatbot and migrate to custom when they outgrow it. The migration typically happens when the platform's per-interaction pricing exceeds the cost of ownership for a custom system, or when the business needs actions and integrations the platform cannot support. The RAG knowledge layer and the action integrations are the two components that justify the custom build. If the chatbot only needs to answer questions from a help center, a platform is sufficient. If it needs to know the customer, check their order, apply their discount, and process a return, custom is the path.