Building Claude-Powered Support Bots for SaaS

Key facts, with sources

• Anthropic's published API pricing lists Claude Sonnet 4.6 at $3 per million input tokens and $15 per million output tokens, with Claude Haiku 4.5 at $1 and $5 for lighter workloads. (Claude Platform Docs)
• The Claude API offers a 50 percent discount on both input and output tokens via the Batch API and up to 90 percent savings on repeated input through prompt caching. (Claude Platform Docs)
• Current Claude Opus and Sonnet models support a 1 million token context window at flat per-token rates with no long-context surcharge. (CloudZero)
• Anthropic raised a $30 billion Series G at a $380 billion post-money valuation in 2026. (Anthropic)
• Anthropic said it hit a $30 billion revenue run rate after roughly 80x growth in about two years, driven primarily by enterprise and developer API consumption. (VentureBeat)

The architecture that actually deflects tickets

Every support bot I build has four layers. Retrieval finds the handful of documentation sections relevant to the user's question — this is where most answer quality is won or lost, and it deserves as much engineering as the model call. The generation layer sends those excerpts plus the question to Claude under a strict system prompt. The policy layer decides what the bot may answer at all: billing disputes, refunds, security reports, and legal questions route straight to humans no matter how confident the model sounds. The escalation layer creates a ticket with full conversation context when the bot bows out.

Founders often want to skip retrieval and stuff the entire help center into the prompt. Long context makes that technically possible for small doc sets, but retrieval still wins on cost at scale and — more importantly — it gives you an auditable record of exactly what the bot saw when it answered.

A system prompt that draws hard boundaries

The system prompt is a policy document, not a personality sketch. Mine always contain four elements: the grounding rule (answer only from the provided excerpts), the honesty rule (if the excerpts do not contain the answer, say so and offer escalation), the forbidden-topics list with an explicit escalation instruction, and format constraints so answers stay short and scannable. Claude follows this style of instruction well, which is precisely why it is worth writing carefully.

One pattern I insist on: the prompt never claims capabilities the bot lacks. If it cannot issue refunds, it should say a human will handle that — not perform a refund it has no tool for. Support users forgive I will connect you with the team far more readily than a confident answer that turns out to be theater.

import anthropic

MODEL = "claude-..."  # use the latest Claude model id
client = anthropic.Anthropic()

SYSTEM = """You are the support assistant for a B2B SaaS product.

Rules:
- Answer ONLY from the documentation excerpts provided in each message.
- If the excerpts do not contain the answer, say so plainly and offer to
  connect the customer with the support team.
- Never discuss refunds, pricing exceptions, security incidents, or legal
  terms. For those, respond that a human specialist will follow up.
- Keep answers under 150 words. Use numbered steps for instructions."""

def answer(question: str, excerpts: str) -> str:
    response = client.messages.create(
        model=MODEL,
        max_tokens=1024,
        system=SYSTEM,
        messages=[{
            "role": "user",
            "content": f"Documentation excerpts:\n{excerpts}\n\nCustomer question: {question}",
        }],
    )
    return response.content[0].text

Streaming and caching for a responsive, affordable bot

Perceived latency drives satisfaction more than actual latency. A streamed answer that starts rendering quickly feels faster than a slightly quicker answer that arrives all at once, so I stream every customer-facing response and pipe tokens to the client as they arrive.

On cost: the system prompt is identical on every request, which makes it an ideal prompt-caching candidate. I mark the stable prefix with a cache breakpoint and keep anything volatile — the retrieved excerpts, the question — after it. For a busy support widget this cuts input cost substantially, because the longest stable part of every request is billed at cache-read rates after the first hit. The discipline is keeping that prefix byte-stable: no timestamps, no user IDs, no per-request noise in the system prompt.

with client.messages.stream(
    model=MODEL,
    max_tokens=1024,
    system=[{
        "type": "text",
        "text": SYSTEM,  # byte-stable across requests
        "cache_control": {"type": "ephemeral"},
    }],
    messages=conversation,
) as stream:
    for text in stream.text_stream:
        push_to_client(text)  # websocket / SSE to the widget
    final = stream.get_final_message()

log_usage(final.usage)  # track cache hits and spend per conversation

Escalation is a feature, not a failure

The handoff to humans is where support bots earn or lose trust, so I design it explicitly. Triggers that force escalation in my builds: the model says the documentation does not cover the question, the customer asks for a human, the same intent appears twice without resolution, sentiment turns hostile, or the topic hits the forbidden list. On escalation the bot creates a ticket carrying the full transcript and the retrieved excerpts, so the agent never asks the customer to repeat themselves.

I measure deflection honestly: a conversation counts as deflected only if the customer did not open a ticket within a reasonable window afterward and did not immediately rephrase the same question. Vanity metrics like answered rate hide the bots that confidently answer the wrong thing.

Evaluate before every prompt or model change

Support bots regress quietly. A prompt tweak that fixes one complaint can loosen a boundary somewhere else, and a model version change shifts tone and refusal behavior in ways no diff will show you. My guard is a replay suite: a few hundred real anonymized conversations with graded expected behaviors — correct answers, correct refusals, correct escalations. Every prompt edit and every model upgrade runs the suite before deploy.

I also log every production answer with its retrieved excerpts and review a sample weekly. The failures you find are rarely model failures; they are retrieval misses and documentation gaps. A support bot is ultimately a very demanding reader of your docs — many clients find the biggest win of the project is being forced to fix the documentation itself.

When to hire senior help

Senior help matters most when you go beyond simple completions into agentic systems on the Claude API, where tool design, caching architecture, and eval harnesses decide reliability and cost. A few days of experienced review typically cuts token bills materially and prevents expensive rewrites later. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships AI — Claude API Development projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Skipping prompt caching in agent loops that resend the same system prompt and tool definitions every turn, paying full input price for tokens that could cost 90 percent less
• ✕Running latency-insensitive workloads like evals, backfills, and bulk classification through the live API instead of the Batch API's 50 percent discount
• ✕Migrating model versions by swapping the ID string without checking for removed parameters like temperature or thinking budgets, which now return 400 errors on newer Claude models
• ✕Treating refusal and max-token stop reasons as generic errors instead of branching on stop_reason, which surfaces as silent empty responses in production

Frequently asked questions

Sources

• Claude Platform Docs
• CloudZero
• Anthropic
• VentureBeat