One build: your content sources ingested and chunked, retrieval tuned against a real question set out of your inbox, the web widget, one team channel, the escalation and refusal rules, the answer and escalation dashboard, full source as a repository with a Dockerfile, deployment, documentation, and a tuning window after handover. Extra source types or extra channels beyond the agreed scope are flat add-ons, quoted up front.

In four phases: scoping and content inventory ($2,000), ingestion and retrieval ($3,500), channels, guardrails and dashboard ($3,000), tuning and handover ($1,500). A phase is agreed before it starts and paid when you approve that phase’s deliverable, so you are never paying up front for work you have not seen.

Direct B2B, on your own contract and invoicing. Reach me on LinkedIn, tell me what content you have and what your queue keeps asking, and we sort the terms and the paperwork directly, including an NDA first if that is your policy. I do not run this one through a freelance platform.

One scoping call to go through what you have written and which questions matter. Then read access to each source, created by you: a help center export or crawl access, a documentation repository, a read-only API token for your ticketing system, a wiki export. A set of real questions out of your inbox, which is what retrieval gets tuned against. And someone who can tell me whether an answer is correct during the tuning window, usually an hour or two a week. For running it, your team ships the container through your normal pipeline, or you hand me a deploy target and I do it, your call.

Anything with readable text behind a credential you create: a help center with an export or crawlable pages, documentation in a repository or on a site, PDFs and manuals with a real text layer, past resolved tickets through your ticketing system’s API, wiki pages, structured FAQ files. What does not count: knowledge that only exists in someone’s head, a decision buried in a chat thread nobody wrote up, and screenshots or scanned pages with no text layer. OCR over scans is possible and gets quoted separately when the content is worth it.

Enough that the repetitive questions actually have answers written down somewhere. A ten-page help center is not a candidate: the bot would refuse most questions, correctly, and you would have paid for the privilege. What I look for during scoping is the overlap between your real question set and your material. If most of those questions already have an answer in your content, this works. If they do not, you have a documentation problem first, and I will tell you that instead of selling you a bot.

It is built so that the failure mode is refusal rather than invention. Answers are composed only from passages retrieved out of your content, every one carries its source link so the reader can check it in a click, and when nothing clears the confidence threshold it says it does not know and offers a person. An LLM can still misread a passage it retrieved correctly, which is exactly why the citation is mandatory and why the escalation path exists: a wrong answer is visible and checkable in one click, not a mystery. The tuning window is spent on precisely that, the questions it answered badly and whether the cause was retrieval, chunking or a gap in the documentation.

Not in this build. It reads your content and answers from it. Refunds, account changes, order edits and subscription changes need write access to your systems and a different standard of review, so they are quoted separately. If you want them later, the retrieval side does not change, they go on top of it.

The bot, the index, the widget backend and the dashboard all run on your own infrastructure. Your documentation and your ticket history are never uploaded to me or into a vendor’s index. The only thing that leaves your network is the model call you configure, and the model is your choice as long as it speaks an OpenAI-compatible or Anthropic-compatible API: that covers the big providers, the aggregators, and anything you run yourself behind an OpenAI-compatible endpoint, which is what vLLM, Ollama and similar servers expose. Self-host the model and nothing leaves at all. You pay your provider directly at their rates, and I take no cut of it.

The model is the only meaningful running cost, and a retrieval bot is cheap next to an agent: one retrieval and one short composed answer per question. The spend depends on which model you pick and how much traffic the widget takes, so I estimate it against your real question volume during scoping. Self-host the model and the token bill disappears; the rest is a container and a database on hardware you already run.

A tuning window against real traffic comes before handover, and the documentation covers re-ingesting content, changing thresholds and adding a source. After that, Content Care picks up the upkeep on a monthly retainer if you would rather not own it, at $600 a month with no minimum term. Always a choice, never a requirement.