Chatbots for business: when they pay off, when they don't, and what they really cost

Almost every conversation we have about chatbots for business starts the same way: someone has seen a flawless demo, thought "this will kill half our inbox", and arrives with the decision half made. The demo was indeed flawless. The catch is that a demo answers questions asked in a controlled setting, and your bot will be answering an annoyed customer at 22:40 on a Friday about an order the ERP has flagged as "exception".

That gap — between the demo and Friday at 22:40 — is what this guide is about. When a chatbot genuinely solves something, when it is a cosmetic layer over a broken process, which channel to pick, what it costs to build and to keep running, and what to look at to know whether it works. No promises about replacing your customer service team, because that doesn't happen.

What is a business chatbot today, and what isn't it?

A business chatbot is a conversational interface connected to your systems. That second half of the sentence is what separates useful from decorative. A bot that only knows what's on your public website is a search box with extra steps. A bot that checks order status in the ERP, sees the customer history in the CRM and can open a ticket is a different animal.

Three things get called by the same name in meetings, and it's worth separating them:

• Flow bot (decision tree). Menus, buttons, predefined answers. Cheap, predictable, dull. Works very well for closed transactions: booking an appointment, checking opening hours, collecting form data.
• Natural-language bot over your documentation. Understands the question and answers from your manuals, price lists and policies. Handles the informational query. This is where most of the real value — and most of the projects that succeed — sit today.
• Agent. On top of answering, it acts: changes an appointment, processes a return, updates an address. Now we're talking about permissions, traceability and a different design altogether — covered in AI agents in the enterprise.

What a chatbot isn't: a substitute for documentation you never wrote. If your return policy lives in the heads of two customer service people and in an email thread from 2023, the bot can't know it. And it won't invent it well.

A chatbot doesn't fix a bad process. It makes it faster, more visible and harder to defend.

When do chatbots for business make sense, and when don't they?

The useful criterion isn't sector or company size, it's the shape of your query volume. A chatbot pays off when there are many similar questions with an objective, checkable answer. It pays off badly when every case is different, when the answer depends on professional judgement, or when being wrong is expensive.

| Scenario | Chatbot? | Why | |---|---|---| | "Where's my order?" with tracking in a system | Yes | Objective, queryable answer, high volume | | Hours, pricing, coverage, standard terms | Yes | Stable, verifiable information | | Appointments, bookings, rescheduling | Yes | Bounded transaction with written confirmation | | First-line product support triage | Yes, with escalation | Covers 40-60% of tier 1; the rest goes to a person | | Complaints, cancellations, incidents involving money | Not initially | High cost of error and an emotional component | | Tax, legal or medical advice | No | Professional liability; useful internally, not customer-facing | | High-ticket consultative selling | No | The value is in the human conversation | | A company with 30 queries a month | No | Maintenance costs more than the saving |

That last row deserves a paragraph. A chatbot isn't free after launch: someone reviews conversations, corrects answers, updates content when a price changes. Below a certain volume — as a reference point, roughly 300-500 monthly queries of repeating types — the arithmetic doesn't work, and the honest move is to say so before starting.

There's a middle case that almost always gets overlooked: the internal bot. An assistant that answers your own team about procedures, customer terms, or how something is done in the ERP. Less glamorous, far lower risk (the end user can judge a dubious answer), and frequently more saving per euro invested than the public-facing bot.

Which channel: web, WhatsApp, or inside the product?

The channel choice shapes the project more than the model technology does.

Web. Easiest to launch and the least legally fraught. Anonymous by default: you don't know who's typing until they identify themselves. Good for pre-sales and information; limited for account operations.

WhatsApp Business. In Spain this is where the customer actually is, and that changes two things. First, the phone number identifies the person, which allows personalisation from the first message but turns every conversation into personal-data processing you need to have covered. Second, the official API uses a template and conversation-window model with a cost per business-initiated conversation; model it up front, because a mass campaign can turn a marginal cost into a surprising invoice.

Inside the product or customer portal. The best place if you sell software or run a private portal: the user is already authenticated, so the bot knows who they are, what they bought and what state it's in. That's where an assistant can move from answering to resolving without opening a security hole.

Email. Rarely discussed and very profitable: classifying inbound, extracting data, drafting replies a person reviews and sends. No chat interface, no risk of the customer seeing a bad answer, and on a channel that in many companies carries more volume than chat.

A common mistake is opening three channels at launch. Each has its own tone, formatting limits and way of handing over to a person. One channel done well teaches you more than three done halfway.

What does a business chatbot really cost?

This is where proposals get opaque. Broken down by line item, with order-of-magnitude ranges for a mid-sized company in Spain:

| Line item | Indicative range | Note | |---|---|---| | Scope definition and conversation design | €3,000-8,000 | Deciding what it answers, what it doesn't, how it escalates | | Content and knowledge base preparation | €2,000-10,000 | Usually the underestimated item | | Integrations (CRM, ERP, ticketing) | €4,000-20,000 | Depends on whether an API exists or must be built | | Deployment, testing and go-live | €3,000-8,000 | Includes adversarial testing, not just the happy path | | Model consumption | €50-600/month | Scales with volume and conversation length | | Platform / channel | €0-500/month | Per-conversation cost on messaging channels | | Maintenance and continuous improvement | €300-1,500/month | Conversation review and tuning |

Two warnings about that table. First: model consumption, which makes the most noise in meetings, is almost never the big line. The expensive parts are integrations and content. Second: a proposal with no maintenance line isn't cheaper — the cost simply arrives later, with no budget assigned to it.

To work out the return, the number that matters isn't "conversations handled", it's queries resolved without human intervention × minutes each one used to take. If your team averages 4 minutes on an order-status query and the bot resolves 400 a month, that's around 27 hours monthly. That's the floor of the calculation; the ceiling usually sits in out-of-hours response time, which saves no hours but prevents losses. Same approach we apply to any process in AI process automation.

How do you integrate it without building a Frankenstein?

A disconnected chatbot is a brochure that talks. Integration is the project, and doing it in this order avoids rework:

1. Identify the five most frequent queries using real inbox and phone data, not intuition. Export three months of tickets and count them. 2. Check where each answer comes from. If the data sits in a system without a decent API, that's the first thing to solve — or to rule out. 3. Decide what the bot may write and what it may only read. Most projects should start read-only. Writing to production systems is a separate decision, with its own audit log. 4. Design the escalation before the answers. How it hands over to a person, with what context, during which hours, and what the customer sees while waiting. A bad handover cancels out every other benefit. 5. Instrument from day one. Every conversation stored, tagged and reviewable. Without that there's no continuous improvement, only opinions.

The ugly part is almost always the same: systems that don't expose what you need, or expose it with latency that breaks the conversation. Worth examining closely before signing; in integrating AI into your tools we break down the specific questions to ask of each system.

Which metrics tell you the chatbot is working?

The ones shown in demos — conversation counts, unique users — say nothing. These five do:

• Resolution rate without a human. Conversations closed without escalation and without the customer asking the same thing again within 48 hours. This is the headline metric.
• Escalation rate and its reason. Escalating isn't failure; escalating without a classified reason is. Those reasons are next month's improvement backlog.
• Detected incorrect answers. From a hand-reviewed sample each week. If nobody reads conversations, you don't know your error rate, and you'll find it out through a complaint.
• Time to first useful answer. Not bot response time (always instant), but how long it takes the customer to get the information they came for.
• Contacts avoided on the expensive channel. If phone and inbox volumes don't drop, you haven't removed work: you've added a channel.

A realistic sample size for manual review: 30-50 conversations weekly for the first quarter, then 20 a month. It's tedious, and it's exactly what separates a bot that improves from one that quietly degrades as prices change.

Which risks must you close before going public?

Four, and none is optional once the bot talks to customers.

Hallucination with consequences. A bot that invents a contract term or a delivery date creates an expectation somebody will have to manage. Mitigate it by restricting answers to verifiable sources, requiring the bot to cite where the fact came from, and programming "I don't know, let me pass you to a person" as a legitimate answer rather than a failure.

Personal data. Everything a customer types into the chat is processing: lawful basis, notice to the user, retention period and a decision about where it's processed. If the model is a third party's, you need a processing agreement and clarity on whether the data is used for training. Before connecting customer history to anything, review what can be minimised or masked — the detail is in data anonymisation.

Transparency. The user has to know they're talking to an automated system. The EU AI Act requires it for systems that interact with people, and it also prevents half the anger. What applies to a smaller company is summarised in the EU AI Act for SMEs.

Abuse and prompt injection. Someone will try to make the bot say what it shouldn't, or reveal its instructions. Test for that before going live, with a set of hostile cases, not just the happy script.

Frequently asked questions

How long does a business chatbot take to reach production?

With a bounded scope — one channel, five query types, read-only integration — between 6 and 10 weeks from kickoff to public launch, and half that time goes into content and integrations, not the bot. Projects promising two weeks are usually counting deployment only.

Can a chatbot replace the customer service team?

No, and anyone promising it hasn't operated one. What it does is absorb the repetitive share and free up time for cases that need judgement. The team's mix of work changes: fewer status queries, more real incident resolution and review of what the bot is answering.

Is a chatbot platform better than custom development?

It depends on how many integrations you need. With one or two and informational queries, a platform is faster and cheaper. As soon as you have to orchestrate several systems, apply your own business rules or meet traceability requirements, custom ends up costing less than forcing the platform. The question that settles it is where the data behind the answer lives.

What happens if the chatbot gives a customer a wrong answer?

The company answers for it, not the model provider. That's why design matters: restrict the bot to verifiable sources, keep a record of every conversation so you can reconstruct what was said, and have a fast correction path. A bot with no auditable history is an operational risk, not just a technical one.

If you're weighing up a chatbot and the internal conversation has stalled at "which tool do we use", the step before is probably missing: which queries you actually get, where the answer lives, and which channel carries the volume. That's exactly what comes out of the audit, in enough detail to decide whether the project pays off or whether you should start somewhere else. And if you'd rather talk it through before moving anything, let's talk.