Build a Claude-Powered Onboarding Chatbot for SaaS

What is a Claude-powered onboarding chatbot and why build one

A Claude-powered onboarding chatbot is a conversational interface embedded in your SaaS app that replaces (or supplements) static tooltips, product tours, and setup checklists. Instead of a user clicking through a rigid tour, they describe what they're trying to do — "I want to connect my Stripe account" or "how do I invite my team?" — and Claude answers in context, walks them through the steps, and can even trigger actions in your app via tool use.

The reason this matters for SaaS specifically: activation is the single biggest lever for retention, and generic tours have a fixed script that can't adapt to what a user actually asks. Building one requires three things: a system prompt grounded in your product's onboarding flow, access to the user's current account state, and a way to call Claude's API reliably from your frontend or backend without managing provider keys, rate limits, and streaming infrastructure yourself. Below is the full build process.

Step 1: Define the onboarding scope, not the whole product

Don't build a chatbot that tries to answer every support question. Scope it tightly to the first-run experience: account setup, first key action (first project created, first integration connected, first invite sent), and the 3–5 things that correlate with a user becoming "activated" in your product.

Write this scope into a system prompt:

You are the onboarding assistant for [Product]. Your only job is to help
new users complete setup: connecting their data source, inviting a
teammate, and creating their first project. If asked about anything
outside onboarding, politely redirect to support@product.com.
Keep responses under 4 sentences unless walking through a multi-step task.

This keeps responses short, on-task, and prevents the bot from hallucinating features or giving generic advice unrelated to your product.

Step 2: Ground responses in the user's actual account state

A generic onboarding bot that doesn't know whether the user has already connected an integration is worse than no bot. Pass account state into the conversation as structured context on every turn:

{
  "account": {
    "plan": "trial",
    "integrations_connected": ["slack"],
    "team_members": 1,
    "projects_created": 0
  }
}

Inject this as a system or user-turn message so Claude's suggestions match reality — e.g., skip "connect Slack" if it's already connected, and nudge toward "create your first project" instead.

Step 3: Call the API with streaming for a responsive UI

Onboarding chatbots live inside your app UI, so latency matters more than in a support ticket flow. Stream the response token-by-token rather than waiting for the full reply.

const res = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-sonnet-4",
    max_tokens: 400,
    stream: true,
    system: onboardingSystemPrompt,
    messages: [
      { role: "user", content: "How do I invite my teammate?" }
    ]
  })
});

const reader = res.body.getReader();
// read chunks and append to the chat UI as they arrive

Full streaming setup, including handling the chunked response format, is covered in /docs/streaming. For a SaaS onboarding widget, streaming is what makes the bot feel like a live assistant rather than a slow form.

Step 4: Use tool calling to let the bot take action, not just explain

The highest-leverage version of an onboarding chatbot doesn't just describe steps — it performs them. Define tools that map to your app's onboarding actions and let Claude call them when the user confirms:

{
  "tools": [
    {
      "name": "invite_teammate",
      "description": "Send a team invitation to an email address",
      "input_schema": {
        "type": "object",
        "properties": {
          "email": { "type": "string" }
        },
        "required": ["email"]
      }
    },
    {
      "name": "create_first_project",
      "description": "Create a new project with a given name",
      "input_schema": {
        "type": "object",
        "properties": {
          "name": { "type": "string" }
        },
        "required": ["name"]
      }
    }
  ]
}

When Claude returns a tool_use block, your backend executes the actual API call against your own app (not Claude's) and sends the result back as a tool_result. This turns the chatbot from an FAQ into a functional onboarding agent. The full request/response shape for tool use is documented at /docs/tools.

Step 5: Keep a short, rolling conversation window

Onboarding conversations are short-lived by nature — most users finish setup in under 10 turns. Don't persist unlimited history; cap the context to the current session plus the account-state object. This keeps token usage predictable and responses fast, which matters when you're billed per request across hundreds or thousands of trial signups.

Step 6: Instrument activation, not just chat satisfaction

Log which onboarding steps the bot successfully helped complete (via tool calls) versus which it only explained. This tells you where users stall and where the bot's explanations aren't converting into action — a much better signal than generic chat ratings.

Where SubToAPI fits

Everything above assumes you have a stable, authenticated endpoint to call Claude from your app's backend or frontend proxy. SubToAPI turns your existing Claude access into that endpoint: you get an application API key (sub_live_...), standard /v1/messages requests, streaming, and tool use, without managing separate provider credentials or building your own retry and rate-limit handling. Request shapes match the examples above exactly — see /docs/quickstart to get a key running in a few minutes, or /docs/messages for the full request reference. Pricing starts at Solo for solo builders and scales to Team and Scale plans with per-seat pricing for teams shipping onboarding flows across multiple products — details at /pricing.

questions

Do I need a separate chatbot framework to build this, or just the API? Just the API. An onboarding chatbot is a system prompt, account-state context, and optionally tool definitions sent on each request — no separate framework is required to get a working version in production.

Should the onboarding bot have access to the full product, or just setup tasks? Scope it to setup and activation tasks only. Mixing in general support or feature questions dilutes the system prompt and makes responses less reliable for the thing that actually moves activation metrics.

How do I stop the bot from repeating steps the user already completed? Pass current account state (integrations connected, team size, projects created) into the conversation on every turn so Claude's suggestions reflect reality instead of a generic script.