AI chatbot development turns a language model into a support and sales channel customers will actually use: a bot that answers from your own knowledge, looks up an order, books a slot and hands the conversation to a person when it should. A widget that improvises from the open internet creates more work than it removes. A chatbot wired into your systems shortens the wait and leaves your team with the conversations that need a human.
Contents
At CodeWiz we design and build customer-facing chatbots and tool-using agents for websites, shops and service businesses. We connect them to your knowledge base, CRM and order data, publish them on the web, WhatsApp and Viber, and add the guardrails, transcripts and evaluation that keep answers accurate and on-brand.
The work is for companies whose inbox never empties, shops that repeat the same shipping answers all day, and teams that want leads qualified or appointments booked without invented prices. Retrieval, context modelling and local model hosting belong to our AI/ML integration work. This article is about the conversation the customer has and the actions the agent is allowed to take.
AI Chatbot Development for Customer Support
A customer support chatbot handles the questions that dominate a helpdesk: where is my order, how do I return it, what are your hours, which plan includes this feature, how do I reset access. The business value is coverage outside office hours and a shorter queue, provided the bot is honest about what it does not know and can reach a person without making the customer start again.
We start from your real tickets, not from a generic script. The top intents become the scope; everything else is an explicit handover. Answers come from approved sources — help-centre articles, policy pages, product data — and the bot can show where an answer came from. Tone, languages and what the bot must never say (legal promises, medical or financial advice, discounts it cannot grant) are written down as policy before any prompt is tuned.
What you receive
- A conversation design: intents, example utterances, escalation rules and the wording for refusal and handover.
- A web widget that knows which page the visitor is on, so a question on a product page already carries that product.
- A connection to your helpdesk (email, Zendesk, Freshdesk, Help Scout or a custom queue) that forwards the full transcript, not a one-line summary.
- An evaluation set of real questions with the answers you consider correct, so later changes are measured.
We do not chase a higher containment rate by trapping people in the bot. A fast handover is a success. The same base can qualify a lead or book a slot and write it to the CRM, without inventing a quote.
LLM Agents with Tool Use
Answering from documents is only half of what customers ask. They want a status, a booking, a password-reset link or a ticket opened in their name. An LLM agent does that by calling tools: small, typed functions your backend exposes. The model chooses a tool and fills its arguments; your code performs the action and returns a result the model can explain in plain language.
The model never receives a database password or a broad admin token. Each tool is an allow-listed function with the minimum permission it needs, and the implementation checks identity. A signed-in customer can ask for their own order. They cannot fetch someone else’s by typing a different id, because the tool ignores any customer id the model invents and uses the session instead.
{
"name": "get_order_status",
"description": "Look up an order that belongs to the signed-in customer.",
"parameters": {
"type": "object",
"properties": {
"order_id": { "type": "string" }
},
"required": ["order_id"],
"additionalProperties": false
}
}Actions that move money or change an account — refunds, cancellations, address changes, discounts — require an explicit confirmation in the chat, and often a second check in your existing back office. Read-only tools can run immediately. We log every tool call with its arguments and result so a disputed conversation can be reconstructed. The same pattern works with any provider that supports structured tool calls; the OpenAI function calling guide describes the request shape most compatible APIs follow.
Tools we typically connect
- Orders, shipments and returns from your shop or ERP.
- Appointment availability and booking in your calendar or booking system.
- Account lookup for a signed-in user, and a ticket or callback when they are not.
- Product search, so the agent recommends what you actually sell, at the current price.
- Handover to a named queue, with priority when the customer is blocked.
Knowledge Base Integration for Accurate Answers
When the question is about policy, product detail or how something works, the agent should read your knowledge base rather than rely on model memory. That is retrieval-augmented generation. We have already written the engineering — chunking, hybrid search, permissions and evaluation — in our article on RAG, prompt engineering and large-scale automation. On a chatbot, the product requirements on top of that engineering are specific.
- Answers cite the article or policy they came from, and the widget can link the customer straight to it.
- If retrieval is weak, the bot says so and offers a person, instead of filling the gap with a plausible guess.
- Stale documents are worse than missing ones: publishing a new returns policy must retire the old passages the same day.
- Product questions go through search, not through a pasted catalogue. A fast product search is often the right tool behind “do you have this in blue?”
Customer chats contain personal data. Where that data cannot leave your network, the same agent can call a model you host yourself. The hosting choices are covered in our guide to local AI model hosting. The channel, the tools and the knowledge base stay the same; only the model endpoint changes.
Multichannel Bots for Web, WhatsApp and Viber
Customers will not move to the channel you prefer. Across Bosnia and Herzegovina, Serbia, Croatia and Montenegro a large share of service conversations already happen on Viber and WhatsApp, while the website still needs an answer at the moment of purchase. We build one conversation core — policies, tools, knowledge, handover — and a thin adapter per channel, so you do not maintain three bots that drift apart.
| Channel | Best for | Constraints to design for | What we deliver |
|---|---|---|---|
| Website widget | Help in context, on a product or checkout page | Anonymous visitors versus signed-in customers | Embeddable widget, page context, optional login |
| Customers who already message you there | Template messages outside the 24-hour window, opt-in | Cloud API bot, approved templates, handover | |
| Viber | Everyday chat in the region | Public account, keyboards and rich messages | Viber bot, menus, file and contact handoff |
| Helpdesk email | Teams that live in tickets | Slower, and customers often expect a person | Draft replies for agents, or auto-answers on narrow intents |
WhatsApp’s rules are part of the design, not an afterthought. Business-initiated messages outside an open session must use pre-approved templates, and people need a way to opt out. The WhatsApp Cloud API documentation spells out sessions and templates. Viber bots use a different message model — keyboards, carousels and files — described in the Viber REST Bot API. We map both onto the same internal events, so a handover on Viber looks like a handover on the site inside your helpdesk.
A web session, a phone number and an email are three identifiers for one customer. We link them only when the customer proves it, with a one-time code or a match to an order. Until then the agent sticks to public answers and a callback request.
Guardrails, Monitoring and Evaluation
A customer-facing agent is a public interface to your business. Guardrails are the limits that keep it there. We treat every user message as untrusted input. Instructions hidden in a pasted text do not grant new tools, change prices or reveal another customer’s data. The system prompt is not the security boundary. The tool permissions and the checks in your own code are.
What we put in place
- Scope limits: off-topic requests get a short refusal and a route back to support, not a general-purpose chat.
- Output checks: order ids, prices, stock and dates in a reply must come from a tool result, not from the model’s prose.
- Confirmation: anything that spends money or changes an account is repeated back and confirmed before it runs.
- Transcripts: each turn stores the user message, the retrieved passages, the tool calls and the reply, with personal data kept to what support needs.
- A review queue: low-confidence answers and unfamiliar phrasings are sampled for a person to mark right or wrong.
- Cost and latency budgets: a support reply that takes twenty seconds, or sends a huge prompt on every turn, will not survive real traffic.
A fixed question set runs before launch and after every prompt, tool or model change. Beside it we watch handover rate, repeat contacts and the topics the bot still fails. Quality is a release check, not a feeling after a demo.
Scripted Bots, Grounded Chatbots and Agents
Not every support flow needs an agent that picks its own tools. Choosing a simpler design, where it fits, is part of the job.
| Approach | Use it when | Where it breaks |
|---|---|---|
| Buttons and decision trees | The wording must be exact and the paths are few | Customers phrase things unexpectedly and abandon the tree |
| LLM grounded in your docs | Questions vary and policies change often | It cannot look up an order or take an action |
| Agent with tools | Customers need a status, a booking or a ticket | Needs permissions, tests and a human on money actions |
| Human with an AI draft | The topic is sensitive or the volume is low | No after-hours coverage unless someone is on shift |
Many projects ship a mix: buttons for the few questions that dominate volume, a grounded model for the long tail, and tools only where a lookup changes the answer.
Common Chatbot Mistakes We Fix
- Launching on the public site with no evaluation set and no handover, then judging the bot by the angriest screenshot.
- Pasting the entire FAQ into the prompt, so the help centre and the bot disagree a week later.
- Letting the model call a refund or delete tool because the description said it could.
- One bot per channel, each with its own prompt, so Viber promises what the website no longer does.
- Logging full transcripts, personal data included, into a tool with no retention rule.
- Measuring only containment, which rewards bots that refuse to escalate.
What Drives the Cost of AI Chatbot Development
We estimate after a short look at your tickets, channels and systems, not from a flat package. The same factors show up on almost every project:
- How many intents are in scope, and how clean the source articles are.
- Which tools must be built, and whether the systems behind them already have an API.
- How many channels launch together, and whether WhatsApp templates and opt-in already exist.
- Whether the model is a hosted API or runs on your own infrastructure.
- How strict the review process is: a bot that drafts for agents is less work than one that replies alone.
- A launch, versus an ongoing cycle of transcript review and new intents.
How We Work
- Discovery: we read a sample of real conversations, list the systems involved and agree what the bot may answer, what it may do and what must reach a person.
- Design: we write the intent map, the tool list with permissions, the channel plan and the evaluation questions.
- Build: we connect the knowledge base, implement the tools, adapt each channel and embed the widget or messaging webhook.
- Test: we run the evaluation set, try to push the bot off policy, and rehearse handover into your helpdesk.
- Launch: we open it to a limited audience first, with people reading transcripts daily.
- Support: we add the intents the traffic actually shows, retire stale answers and keep prompts, tools and channel apps up to date.
Why CodeWiz
- The bot and the systems around it: we build the websites, APIs and shops the agent has to talk to, so the integration is not a separate project.
- Open-source first: where a hosted model is the wrong fit, we can run open-weight models and leave you a path to move.
- Tailored scope: if buttons and a maintained help centre solve the problem, we will not sell you an agent platform.
- Fair pricing: premium development without premium prices, from Banja Luka, working remotely with clients locally and internationally.
- Business goals first: the measure is fewer repeated contacts and cleaner handovers, not a demo that chats about anything. More on the studio is on the about CodeWiz page.
Frequently Asked Questions
How much does a customer support chatbot cost?
It depends on the number of intents, the tools and channels, and whether a person still approves replies. A focused bot on the website, grounded in a tidy help centre, is a modest project. WhatsApp, Viber and several back-office tools make it a larger one. We quote after discovery, before any build starts.
How long does AI chatbot development take?
A single-channel support bot with a defined knowledge base is often ready in a few weeks, including an evaluation set and a handover path. Multichannel agents with new integrations take longer, mostly because the tools and the test conversations have to be right before customers see them.
Will the chatbot replace our support team?
No. It takes the repetitive, documented questions and the lookups a system can answer safely. Your team keeps the exceptions, the upset customers and the topics you do not want automated. The practical result is a shorter queue, not an empty one.
Can one bot run on the website, WhatsApp and Viber?
Yes. Policies, knowledge and tools are shared, and only the message format changes per channel. WhatsApp template rules and Viber keyboards stay in the adapter, so you do not rewrite the agent’s behaviour three times.
How do you stop the bot inventing answers?
It answers from retrieved documents and tool results, says so when those are missing, and cannot state a price or an order status that a tool did not return. We measure that on a fixed question set before launch and on sampled live transcripts afterwards.
Which languages can it speak?
The languages your approved answers cover. In the region that is usually Bosnian, Croatian, Serbian and English. The bot stays in the customer’s language and escalates when it is unsure.
Ready for a Chatbot That Does the Job?
Tell us which questions your team answers all day and which systems hold the truth, and we will propose a bot with a clear scope and a handover your customers can find. Contact us to talk it through, or see the wider set of development services.