AI support bot: capabilities, cost, and limits

The first useful version drafts answers from approved knowledge

A safe first release does not pretend to replace the support team. It retrieves the relevant product or policy source, prepares an answer, shows the evidence and escalates when the request needs account context or human authority.

This narrow route can already reduce repeated research. It also creates the evaluation data needed before the system is allowed to answer customers directly.

Start with one channel and a bounded set of questions. A bot that answers 30 approved topics reliably is more useful than a general assistant that sounds confident across the whole business.

What an AI support bot can do

The bot can search product documentation, compare options, summarize a policy, request missing details, classify intent and prepare a response. With controlled tools, it can also retrieve order or account context after authorization.

Each capability needs its own boundary. Reading an order status is different from changing an address. Explaining a refund policy is different from authorizing a refund. Keep read actions, recommendations and irreversible actions separate.

The knowledge base is a product, not a folder upload

The assistant needs approved sources with owners, versions and access rules. Contradictory FAQ pages, outdated PDFs and undocumented exceptions will produce inconsistent answers regardless of the model.

Split content by purpose and audience. Public product information, internal operating instructions and customer-specific data should not share the same access path. Record which source supported each answer so reviewers can correct content rather than guessing at prompts.

Add a routine for publishing changes and rerunning evaluation. A correct answer can become wrong when a policy, price or product changes.

A production bot needs more than chat

The visible conversation is only the front end. The working system also needs identity, retrieval, permissions, tool constraints, response validation, conversation state, escalation, logs, monitoring and a manual fallback.

Keep deterministic checks outside the model. Required identifiers, allowed tools, schema validation, rate limits and prohibited actions should be enforced by code. The model can interpret language and propose a response inside those boundaries.

Every failure should have an owner. If retrieval returns no source, an integration times out or the response fails validation, the conversation needs a safe message and a visible human route.

What determines implementation cost

Cost follows scope and risk: number of knowledge sources, content quality, channels, languages, account integrations, authorization, evaluation depth, expected volume and the consequence of a wrong answer.

Rollder's current starting bands are $0–300 for a workflow map, $1,500–3,000 for a bounded validation sprint and from $4,000 for a production system. These are service starting points, not universal market prices. A support bot with private account data, several channels and action permissions requires more work than a public product assistant.

Recurring cost includes hosting, model usage, retrieval storage, observability and ongoing knowledge maintenance. Estimate peak conversations, long messages, retries and evaluation runs rather than multiplying only the average prompt price.

• How many approved sources and content owners are involved?
• Does the bot answer publicly or use customer-specific data?
• Which actions can it request or execute?
• How many channels and languages must behave consistently?
• What evaluation and response-time requirement applies?
• Who operates failures and updates after launch?

Limits that should be visible to the customer

The bot should say when it lacks information or authority. A confident guess is not better customer experience than a clear handoff. Do not hide escalation behind repeated clarification loops.

Some requests should always reach a person: legal or medical claims, unusual refunds, account ownership disputes, security incidents, vulnerable customers and any case outside approved policy.

Conversation memory also needs limits. Define what is retained, for how long, where provider logs exist and how a person can request correction or deletion under the applicable policy.

Evaluate before allowing direct answers

Build an evaluation set from real, sanitized support questions. Include common requests, vague messages, conflicting policies, missing identity, prompt injection attempts, sensitive data and situations that require escalation.

Score source quality, factual correctness, policy version, completeness, prohibited claims and escalation separately. A fluent response with the wrong policy should fail.

Begin in agent-assist mode. Record corrections and unresolved topics, improve the knowledge route, then release only the categories that meet an agreed threshold.

A sensible release sequence

Phase one is internal search with citations. Phase two drafts responses for support agents. Phase three answers a narrow group of low-risk questions directly. Tool actions come later and require explicit authorization, audit logs and rollback behavior.

Keep a feature switch and manual fallback at every phase. Expanding scope should be a measured decision based on corrections, escalation quality and customer outcomes, not a reaction to a successful demo.

• Choose one channel and 20–40 approved topics.
• Assign an owner to every source and escalation queue.
• Test retrieval, answer generation and handoff separately.
• Measure correction rate and unresolved topics before direct release.
• Add account actions only after authorization and failure recovery are tested.