Short answer: a custom assistant that answers from your own content typically takes 12 to 24 person-weeks to build properly, and 26 to 34 if it also looks up customer accounts and takes actions. At $50 an hour that is roughly $24,000 to $68,000; at $150 an hour, three times as much. Model usage usually costs cents per conversation. Before building, check whether an off-the-shelf product already does the job, because for standard support on standard channels it often does.
About these numbers. Effort ranges are planning estimates for an experienced team, not survey data and not a BBR price list. The $50 and $150 hourly figures are reference points for lower-cost and higher-cost regions; rates by team type are discussed in our guide to MVP development cost. All per-token and per-resolution prices in this article are illustrative placeholders. Take current prices from the vendor’s pricing page and use the same formulas.
What kind of chatbot this guide covers
“AI chatbot” covers several different products. This guide is about two of them:
- A customer-support assistant on your website, in your app or in a messaging channel, answering from help content and handing over to your team when it should
- An internal knowledge assistant that lets staff ask questions of policies, procedures, product documentation and past work
Both are retrieval systems with a conversation on top: they search your content and have a hosted language model write an answer from what was found. Why that design is normally preferred to training a model on your content is explained in RAG vs fine-tuning. Costs for other kinds of AI feature, such as summarising, extraction and agents, are in our broader guide to the cost of adding AI to a product.
The build blocks
Cost is effort multiplied by rate. The table lists the blocks a production assistant is assembled from, with effort in person-weeks. Pick the ones you need and add them up.
| Block | Effort (person-weeks) | What is in it | What moves it |
|---|---|---|---|
| Prototype and feasibility | 2–4, usually a separate first stage | A sample of your content, a basic pipeline, 30–50 test questions, a quality report | Whether real questions and content are available on day one |
| Content ingestion | 2–5 | Connectors to where content lives, parsing, cleaning, chunking, scheduled re-sync, removal of deleted content | Number of sources; PDFs, scans and tables; how often content changes |
| Retrieval and answer quality | 1–3 | Keyword plus vector search, reranking, citations, “I do not know” behaviour | How similar documents are to each other; how precise answers must be |
| Permission-aware retrieval | 1–3 | Filtering search results by what the asking user may see | Internal assistants nearly always need it; public support bots usually do not |
| Conversation interface | 2–4 | Web widget or in-app chat, streaming replies, history, source links, feedback buttons, mobile layout, accessibility | Less if it sits inside an existing screen; more for a branded embeddable widget |
| Additional channel (Slack, Teams, WhatsApp, email) | 1–2 each | Channel API, formatting, identity mapping, rate limits | The channel’s approval process and message rules |
| Handoff to humans | 1–2.5 | Triggers for escalation, transcript and summary passed to the agent, business-hours logic, a fallback such as creating a ticket | Live chat takeover is harder than ticket creation |
| Guardrails | 1–2 | Scope limits, abuse and prompt-injection handling, topics that must go to a person, rate limits, an off switch | Public-facing and regulated subjects sit at the top of the range |
| Evaluation set and test runner | 1–3 | 100–300 real questions with accepted answers, automated scoring, a report on every change | Availability of a domain expert on your side |
| Analytics and conversation review | 1–2 | Resolution and escalation rates, unanswered questions, feedback, a review screen for your team | How much reporting your support lead needs |
| Helpdesk integration | 1–2 | Create and update tickets, sync conversation history, read help-centre articles | Quality of the helpdesk’s API |
| Each lookup or action in another system (CRM, orders, billing) | 0.5–2 | Authentication, the call itself, error handling, tests | Read-only lookups are cheap; actions that change data need approval steps and more testing |
| Customer identity verification | 1–2 | Tying the chat session to a logged-in user, or verifying by email code, before showing account data | Whether the chat runs inside an authenticated app |
| Agent loop and approvals | 2–4 | Multi-step tool use, step and spend limits, human approval for consequential actions | Needed only when the assistant acts, not just answers |
| Usage metering and limits | 0.5–1.5 | Per-user and per-tenant quotas, cost dashboard, spend alerts | Essential if the assistant is a feature of a multi-tenant product |
| Additional languages | 0.5–1.5 | Test questions per language, retrieval checks across languages, interface strings | Whether content exists in each language or only in one |
| Testing, deployment, project management | Add 20–30% to the total | ||
Two blocks deserve a closer look because they are the ones missing from low quotes.
Handoff to humans
An assistant with no way out turns a customer with a problem into a customer with a problem and a grievance. A proper handoff decides when to escalate (the customer asks, confidence is low, the topic is on a list that always goes to a person, the same question has been asked twice), and what the agent receives: the transcript, a short summary, the customer’s identity and the sources already shown. Outside business hours it should create a ticket and say when to expect a reply.
Evaluation set
This is a set of real questions with answers your team accepts as correct, run automatically whenever the content pipeline, prompt or model changes. It is how you know the assistant is ready for customers, how you find out that a cheaper model is good enough, and how you survive the model vendor retiring the version you launched on. The method is described in our LLM integration guide. It needs days of time from someone on your side who knows the right answers, so plan for that person’s availability.
Three worked examples
Each example lists blocks and effort, adds 25% for testing, deployment and management, and converts at two reference rates using a 40-hour week: $2,000 per person-week at $50 an hour, $6,000 at $150 an hour. The prototype stage is listed separately.
A. Internal knowledge assistant for a 40-person company
Staff ask questions about policies, procedures and product documentation held in a shared drive and a wiki. Answers link to the source. HR documents are visible only to managers. Web interface only.
| Block | Person-weeks |
|---|---|
| Content ingestion (two sources) | 3 |
| Retrieval and answer quality | 2 |
| Permission-aware retrieval (simple group rule) | 1 |
| Conversation interface (plain web chat) | 2 |
| Guardrails | 1 |
| Evaluation set and runner | 1.5 |
| Analytics and review | 1 |
| Metering and limits | 0.5 |
| Subtotal | 12 |
| Testing, deployment, management (+25%) | 3 |
| Total | 15 |
About $30,000 at $50 an hour; about $90,000 at $150 an hour. Before commissioning this, check whether the AI search built into your existing workspace suite covers the need. For a company of this size it frequently does.
B. Customer-support assistant with helpdesk handoff
A widget on the website and in the web app answers from the help centre and product documentation, shows sources, and creates a helpdesk ticket with a summary when it cannot help or the customer asks for a person. Public content only, one language.
| Block | Person-weeks |
|---|---|
| Content ingestion | 3 |
| Retrieval and answer quality | 2 |
| Conversation interface (embeddable widget) | 3 |
| Handoff to humans | 1.5 |
| Guardrails (public-facing) | 1.5 |
| Evaluation set and runner | 2 |
| Analytics and review | 1 |
| Helpdesk integration | 1.5 |
| Metering and limits | 0.5 |
| Subtotal | 16 |
| Testing, deployment, management (+25%) | 4 |
| Total | 20 |
About $40,000 at $50 an hour; about $120,000 at $150 an hour.
C. Support assistant that looks up accounts and takes actions
Everything in example B, plus: the assistant recognises the logged-in customer, can look up order and subscription status, and can prepare a refund request that a support agent approves with one click.
| Block | Person-weeks |
|---|---|
| Everything in example B | 16 |
| Customer identity verification | 1.5 |
| Order lookup (read-only) | 1 |
| Subscription status lookup (read-only) | 1 |
| Refund request with agent approval (write action) | 2 |
| Agent loop, limits and approval flow | 2.5 |
| Subtotal | 24 |
| Testing, deployment, management (+25%) | 6 |
| Total | 30 |
About $60,000 at $50 an hour; about $180,000 at $150 an hour. The step from B to C is where an assistant stops being a search interface and becomes software that acts on customer accounts, with the security review that implies. Many teams sensibly launch B, study what customers actually ask for, and add only the two or three actions that would have resolved the most conversations. Connecting to those systems is ordinary API integration work, and its cost depends mostly on the quality of the APIs involved.
Running costs
Model usage: the per-conversation formula
Hosted models bill per token, with input and output priced separately. In a conversation, each turn sends the system prompt, the retrieved passages, the conversation so far and the new question. So:
Cost per conversation = (total input tokens across all turns × input price) + (total output tokens × output price)
Monthly model cost = cost per conversation × conversations per month
A worked illustration. Assume a four-turn conversation. Every turn sends a 600-token system prompt, 2,500 tokens of retrieved passages and a 50-token question, which is 3,150 tokens before any history. Each answer is 350 tokens, so each completed turn adds about 400 tokens of history to the next one.
| Turn | Fixed input | History | Input tokens | Output tokens |
|---|---|---|---|---|
| 1 | 3,150 | 0 | 3,150 | 350 |
| 2 | 3,150 | 400 | 3,550 | 350 |
| 3 | 3,150 | 800 | 3,950 | 350 |
| 4 | 3,150 | 1,200 | 4,350 | 350 |
| Total | 15,000 | 1,400 |
Now apply two placeholder price points. These are not any vendor’s prices.
| Placeholder “mid” model $1.00 input / $4.00 output per million tokens | Placeholder “premium” model $5.00 input / $20.00 output per million tokens | |
|---|---|---|
| Input: 15,000 tokens | $0.0150 | $0.0750 |
| Output: 1,400 tokens | $0.0056 | $0.0280 |
| Per conversation | $0.0206 | $0.1030 |
| 3,000 conversations per month | about $62 | about $309 |
| 30,000 conversations per month | about $618 | about $3,090 |
Three observations. Input dominates, because retrieved passages are sent again on every turn, so better retrieval that sends fewer passages lowers the bill directly. The model tier changes the cost fivefold in this illustration, and only an evaluation set can tell you whether the cheaper tier is good enough. And even the expensive column is small next to the cost of a person handling the same conversations. Work out your own cost per human-handled ticket (support payroll divided by tickets handled) and compare it with your own version of this table.
Everything else you pay for each month
| Item | Planning note |
|---|---|
| Hosting for the pipeline, API and database | Similar to a small web application: tens to low hundreds of dollars a month at modest volume |
| Embeddings and vector storage | Small. Indexing is a one-off cost repeated only for changed content; storage is free if you use the vector support in a PostgreSQL database you already run |
| Document parsing or OCR services | Metered per page; matters only for large scanned archives |
| Messaging channel fees | Some channels, such as business messaging on WhatsApp, charge per conversation or per message |
| Helpdesk seats and API access | Check that your helpdesk plan includes the API access the integration needs |
| Monitoring and logging | Free tiers to low hundreds of dollars a month, or logs kept in your own database |
| Content upkeep | Someone on your team owns the knowledge base and reviews unanswered questions weekly. This is staff time, and it is the single largest influence on answer quality after launch |
| Engineering upkeep | Reviewing failures, extending the evaluation set, adjusting retrieval, migrating when a model version is retired. A common planning figure is 15–25% of the build cost per year, more if you keep adding capabilities |
Buy or build
There are three kinds of packaged product to consider before commissioning custom work: the AI assistant built into your helpdesk or live-chat platform, standalone chatbot platforms that ingest your content and give you a widget, and the AI search built into workspace and document suites for internal use. Their pricing is usually per seat, per conversation or per resolved conversation.
| Off-the-shelf | Custom build | |
|---|---|---|
| Time to first answers | Days | A prototype in 2–4 weeks; production in a few months |
| Up-front cost | Low | The figures in the examples above |
| Running cost | Scales with seats or resolutions; can become the larger figure at volume | Model usage in cents per conversation, plus upkeep |
| Content sources | The vendor’s supported connectors | Anything you can reach, including your own database |
| Permission rules | Usually public content, or the suite’s own sharing model | Your rules, enforced at retrieval |
| Actions in your systems | Limited to the vendor’s integrations and configuration options | Whatever your APIs allow, with your approval steps |
| Placement | The vendor’s widget and supported channels | Anywhere, including deep inside your own product |
| Control over prompts, model and evaluation | Limited | Full |
| Data handling | The vendor’s terms and sub-processors | Your choice of model provider, region and retention |
| If it is a feature you sell to your own customers | Rarely suitable | Necessary |
Decision rules
- Buy if your content lives in a standard help centre, your channels are standard, and the job is answering questions and passing conversations to agents.
- Buy first, then decide if you do not yet know what customers will ask. A packaged tool for three months gives you real questions, which are the raw material for a custom evaluation set later.
- Build if the assistant is part of your own product, must respect per-user or per-tenant permissions, needs to act in systems the packaged tools do not reach, or has data-handling constraints a vendor cannot meet.
- Build if volume makes usage-based fees larger than the cost of ownership, as in the comparison below.
- Combine where the platform allows it: a packaged front end and helpdesk integration, with custom actions exposed to it through your own API.
An illustrative break-even
Suppose a packaged assistant charges a placeholder fee of $0.80 per resolved conversation, and the custom alternative is example B built at $50 an hour ($40,000), with upkeep at 20% of the build per year ($8,000), hosting at $100 a month, and model usage at the “mid” placeholder rate of about $0.021 per conversation.
| 500 resolutions a month | 5,000 resolutions a month | |
|---|---|---|
| Packaged, per year | $4,800 | $48,000 |
| Custom, model usage and hosting per year | about $1,330 | about $2,460 |
| Custom, year one (build + upkeep + running) | about $49,330 | about $50,460 |
| Custom, each later year (upkeep + running) | about $9,330 | about $10,460 |
At 500 resolutions a month the packaged product is cheaper in every year, and the custom build is justified only by capabilities the package lacks. At 5,000 a month the custom build costs about the same in the first year and far less afterwards. Your break-even depends on the vendor’s real fee, your real rate and your real volume, so redo the table with those. Note also that a “resolution” is defined by the vendor, and that a $150 rate triples the build and upkeep lines ($120,000 and $24,000 a year), which pushes the break-even at 5,000 resolutions a month from about one year to more than five.
What pushes the cost up, and what brings it down
| Raises cost | Lowers cost |
|---|---|
| Content scattered across many systems, in scans and slide decks | One well-maintained help centre or wiki as the source |
| Contradictory or outdated documents | A content owner who cleans up before the build |
| Complex visibility rules between departments or customers | Public content only, or one simple rule |
| Actions that change data or move money | Read-only at launch; actions added later from evidence |
| Several channels and languages at launch | One channel, one language first |
| A custom widget with heavy branding | A chat panel inside your existing interface |
| Live takeover by agents inside the same chat | Ticket creation with transcript and summary |
| No real questions available for testing | An export of past tickets or search queries on day one |
How to get a quote you can compare
- Describe the users and the channel. Customers or staff; website, app, Slack or another channel.
- List the content sources, with rough sizes and formats, and say who keeps each one up to date.
- State the visibility rules, even if the answer is “everything is public”.
- List the systems the assistant should read from or act in, and whether each has a documented API.
- Give volumes: conversations or tickets per month today.
- Export 100 real questions from tickets, chat logs or site search. Nothing improves an estimate more.
- Ask for a prototype stage with a fixed price and a written quality report, and make the production build conditional on its result.
- Ask each vendor to mark the build blocks in this guide as included or excluded, and to estimate the cost per conversation with the model they propose.
The wider process, including when a chatbot is the wrong answer to the problem, is covered in how to build an AI product. BBR builds assistants of this kind on hosted models, with retrieval, guardrails and evaluation as standard parts of the work, and does not train foundation models. The scope and stages are described on our AI development page.