What this prompt does
This prompt designs a customer support chatbot for [product_type] on [model_provider], grounded in a retrieval pipeline over [knowledge_source]. It specifies the full lifecycle: a RAG pipeline with chunking and retrieval, a greeting-to-resolution conversation flow, ticket creation in [ticket_system] when the bot cannot resolve an issue, and sentiment-based escalation to a human.
The structure works because it treats honest handoff as a first-class feature, not a fallback. By forcing the design to define when to escalate, how to summarise context for the human agent, and which [common_issues] get canned templates, it produces a bot that knows its limits. The safety guardrails step — no PII leakage, no unauthorized actions, stay on topic — is what keeps the bot from confidently inventing answers, which is worse than no bot at all.
Multi-turn context management is the other half of feeling competent. The bot remembers customer details and previous issues within a conversation, so users are not forced to repeat themselves, and the analytics layer (resolution rate, average turns, escalation rate, CSAT) gives you the numbers to tell whether it is genuinely helping. The A/B testing framework lets you compare response strategies on real traffic instead of guessing which phrasing resolves issues faster.
When to use it
- You are adding a support bot to
[product_type]and want RAG grounding instead of an ungrounded model that hallucinates. - You need clean human handoff with a context summary so agents are not starting cold.
- You want sentiment detection so frustrated users get escalated rather than stuck in a loop.
- You need ticket creation wired into
[ticket_system]for issues the bot cannot close. - You want analytics (resolution rate, escalation rate, CSAT) defined up front, not bolted on later.
Example output
Expect an end-to-end design: a RAG pipeline description with chunking and retrieval strategy, a conversation flow diagram from greeting to resolution or escalation, the [ticket_system] integration contract, sentiment-based handoff logic, and a deployment architecture diagram. It usually includes the guardrail rules and the analytics schema for resolution and CSAT tracking.
Pro tips
- Be specific in
[knowledge_source]. "Help docs, FAQ, and past resolved tickets" retrieves far better than a vague "our documentation." - Use a fast model for
[model_provider]on simple turns with a stronger fallback for complex ones, as the default suggests, to balance cost and quality. - List
[common_issues]concretely so the canned-response templates actually cover your real ticket volume. - Tune the sentiment-escalation threshold carefully; escalating too eagerly defeats the bot, too late frustrates users.
- Treat the PII and stay-on-topic guardrails as non-negotiable — a support bot leaking data or going off-script is a liability.
- Match
[ticket_system]to what your team already uses so handoff lands where agents work, not in a new silo. - Personalize the canned templates with customer context so they read as answers, not robotic boilerplate.
- Use the A/B framework to validate response strategy changes on real traffic before rolling them out to everyone.
