How to Create AI-Powered Chatbots for Clients (That Don't Suck)

The Stack: Choosing Your Tools Without Overspending

Building a chatbot for a client isn’t a weekend project if you want it to actually work. You need three core components: a chatbot builder, a Large Language Model (LLM), and some ‘glue’ to connect to other systems. Forget the all-in-one platforms that promise the world; they’re usually inflexible and overpriced.

For the builder, your main contenders are Voiceflow and Botpress. They both offer visual, flow-based interfaces. I lean towards Voiceflow for client work because its collaboration features are better, and the UI is cleaner for explaining complex logic to non-technical stakeholders. Botpress is great, more open-source friendly, but can feel a bit more developer-centric. Honestly, you can’t go wrong with either for your first few projects. Voiceflow’s Pro plan is $185/month, which is steep for a solo operator. My take: their free tier is more than enough for your first 2-3 client builds. Start there.

Next, the brain. This is the LLM. You’ll be using an API from OpenAI or Anthropic. While GPT-4o from OpenAI is the most famous, I’ve found that Claude 3.5 Sonnet from Anthropic is often faster and significantly cheaper for most chatbot tasks. The latency is lower, which means the user isn’t staring at a ‘typing’ indicator for three seconds. For client-facing bots, that speed matters more than a tiny bump in reasoning capability.

Finally, the glue. Your bot will need to do things—book appointments, check order statuses, add leads to a CRM. This is where an automation platform like Make.com or Zapier comes in. You’ll use webhooks from your chatbot builder to trigger workflows in Make. This keeps your bot’s logic clean. The bot’s job is to understand intent, not to house complex business automation. A basic Make.com plan starts around $9/month, which is a no-brainer.

What Most Guides Get Wrong About Chatbot Prompts

Here’s the biggest mistake I see. People try to write one enormous, all-knowing system prompt. They stuff it with every possible instruction, every piece of company data, and every edge case. This is a recipe for disaster.

A single mega-prompt is slow, expensive (you pay for every token on every turn), and incredibly brittle. Changing one instruction can have weird, unpredictable effects on other parts of the bot’s behavior.

The correct approach is to use a multi-prompt architecture. Think of it like a manager and a team of specialists.

• The Router Prompt: This is a short, simple prompt with one job: determine the user’s intent. Is the user asking a question? Trying to book a meeting? Complaining? The router’s only output should be a single category, like `INTENT_BOOKING` or `INTENT_FAQ`.
• Specialist Prompts: Once the intent is known, the bot calls a different, highly-specific prompt that is an expert at that one task. The booking prompt only knows how to collect booking details. The FAQ prompt only knows how to answer questions from the knowledge base.

This separation makes the system exponentially more reliable. It’s easier to debug because you know exactly which prompt is failing. It’s cheaper because you’re not sending a 2,000-token context with every simple user query. And it’s more effective because each prompt is small, focused, and optimized for a single outcome.

Stop trying to build one brain. Build a team of them.

A Real-World Example: Building a Lead Qualification Bot

Let’s make this concrete. Imagine you’re building a bot for a local plumbing company. The goal is to qualify leads by checking if they are in the service area before booking a call.

Here’s how you’d structure it in Voiceflow, using the multi-prompt method:

1. Map the Flow: First, you map the conversation visually. It looks something like: Greeting -> Ask about the problem -> Ask for their address -> Check service area -> If yes, ask for contact info -> If no, politely decline.
2. The Router: A user says, “My sink is clogged and I live at 123 Main St.” The router prompt ignores the address for a moment and identifies the core intent: `INTENT_SERVICE_REQUEST`.
3. The Specialist – Address Extraction: The flow now calls a specialist prompt designed only to extract an address. This is a critical step. You don’t want a conversational model trying to parse addresses; you want a tool. The system prompt for this step would be something like this:

System: You are a highly accurate address parsing tool. Your only function is to extract a full street address, city, state, and ZIP code from the user's text. Respond ONLY with a JSON object in the format:{"address": "123 Main St", "city": "Anytown", "state": "CA", "zip_code": "90210"}. If you cannot find a complete address, return {"address": null}.

My favorite part of this setup is the visual flow builder in Voiceflow. You can see exactly where a conversation might fail, which is impossible when you’re just staring at a wall of code or a giant prompt. It turns an abstract problem into a concrete diagram.

4. The API Call: With the structured JSON data from the previous step, Voiceflow makes an API call to a simple service (maybe a Google Sheet or an internal API) to check if the `zip_code` is in the approved list.
5. The Final Steps: Based on the API response (true/false), the bot follows the ‘yes’ or ‘no’ path you designed. If yes, it might trigger a Make.com webhook to add the lead to the client’s CRM.

How Do You Handle Hallucinations and Bad Answers?

Your client will call you the second the bot says something weird. It’s going to happen. The goal isn’t to prevent 100% of errors—that’s impossible—but to build a system that fails gracefully and predictably.

First, force the LLM to give you structured output whenever possible. Like the JSON example above. If the bot is supposed to provide three options, don’t ask it to write a sentence with three options. Ask it to return a JSON array. Why? Because you can validate it. If the response isn’t parsable JSON, you know immediately that the LLM failed, and you can trigger a fallback response like, “Sorry, I had a problem with that request. Could you rephrase?” without the user ever seeing the garbled output.

Second, use a knowledge base for factual information. Don’t put your client’s entire service catalog or company history in the system prompt. Both Voiceflow and Botpress have built-in knowledge base features. You upload documents (PDFs, text files, website URLs), and the platform handles the retrieval-augmented generation (RAG) for you. This grounds the bot’s answers in reality. It answers based on the documents you provided, dramatically reducing the chance it will invent a service the client doesn’t offer.

Finally, create an explicit “I don’t know” path. One of the most important instructions in your prompt is telling the model what to do when it’s not confident. Something like, “If the answer is not in the provided context, you must respond with the exact phrase ‘I am sorry, but I cannot answer that question.'” This is infinitely better than a guess. A bot that confidently provides wrong information destroys trust instantly.

The Hidden Costs: API Calls, Maintenance, and Client Hand-offs

The sticker price of the tools is just the beginning. You need to price your services to account for the operational realities of running an AI agent for someone else.

API costs are the most obvious. A busy chatbot on a popular website can easily make tens of thousands of LLM calls a month. This can add up to hundreds of dollars in API fees from OpenAI or Anthropic. You must have budget alerts set up in your provider’s dashboard. You should also have a clause in your client contract that passes on API costs above a certain threshold. Don’t get stuck with a surprise $500 bill.

Then there’s maintenance. LLM models get updated, which can subtly change their behavior (this is called prompt drift). What worked perfectly in May might become less reliable in July. You need to be running periodic tests and plan for quarterly check-ins with your client to review performance and tweak prompts. This isn’t a one-and-done project; it’s a recurring service.

But the biggest headache is the client hand-off. My biggest gripe is with client education. I once had a client change a system prompt from “You are a helpful assistant for a law firm” to “Be a super fun and wacky dude!” for their chatbot. It started making jokes about legal precedent. It was a nightmare to fix. You have to build guardrails. Lock down the core system prompts and give clients access only to specific, safe areas like the knowledge base content. Don’t give them the keys to the engine room.

How to Debug When This Breaks

It broke. The bot is stuck in a loop, giving nonsense answers, or just not responding. Panicking is not a strategy. Here’s the operator playbook.

First, check the logs. Every decent chatbot platform has detailed conversation transcripts. Find the exact session that failed. Don’t rely on the client’s vague description of what happened. Look at the raw data. What was the last thing the user said? What was the bot’s last response?

Second, isolate the failing part of the flow. In a visual builder like Voiceflow, you can literally see the path the conversation took. You’ll see it hit a specific block—an API call, a logic condition, an LLM prompt—and fail. The error is almost always concentrated in one node. Re-run just that node with the exact same inputs from the log.

Third, test the prompt in a vacuum. If you suspect an LLM prompt is the issue, copy the full prompt (system message and user input) and paste it directly into the OpenAI or Anthropic developer playground. See what the model returns raw, with no other software involved. If it fails there, you know the problem is your prompt engineering. If it works perfectly in the playground, the problem is likely in your integration—a misconfigured API header, a timeout, or a data formatting error between the platform and the LLM.

This methodical process turns a black box mystery into a solvable engineering problem. It’s almost never the whole bot that’s broken; it’s always one specific component.

Building a production-grade chatbot is more about systematic engineering than it is about clever prompt writing. It involves choosing the right stack, architecting your prompts for reliability, and having a clear plan for when things go wrong. You can absolutely build this yourself by following the steps above.

We cover this in more depth elsewhere — deeper coverage of AI agent platforms.

If you’d rather skip the build and deploy a working version in an afternoon, we’ve packaged this entire workflow, prompts included, as a deployable AI automation blueprint at deepusecase.com/vault.