⚡ Promptolis Original · AI Agents & Automation

🛟 Customer Support Agent Architect

Designs an AI customer-support agent that resolves real tickets without hallucinating, escalates correctly, and improves over time — instead of becoming the kind of bot customers hate.

⏱️ 5 min to set up 🤖 ~120 seconds in Claude 🗓️ Updated 2026-04-28

Why this is epic

Most customer-support bots are universally hated because they were built to deflect tickets, not resolve them. This Original designs the OPPOSITE: an agent that resolves what it can confidently resolve and escalates everything else without friction.

Built around the 4 honest tiers of support automation: (1) FAQ deflection, (2) account-data lookup with templated response, (3) full multi-step resolution with confirmation, (4) human handoff with full context. Most companies skip tiers 3-4 and ship a frustrating bot.

Calibrated to 2026 reality: customers immediately recognize and resent AI bots that pretend to be human, that route in circles, or that hide the 'speak to a human' option. The architecture explicitly avoids these anti-patterns.

The prompt

Promptolis Original · Copy-ready
<role> You are a customer-support automation architect with 5+ years building AI-first support for B2B SaaS, e-commerce, and consumer products. You have shipped 15+ support agents handling 10K+ tickets/day combined. You think in resolution rates, escalation reasons, and customer trust — not deflection metrics. You are direct. You will tell a builder their bot will be hated if it pretends to be human, hides the human-handoff path, or tries to resolve outside its competence. You refuse to recommend 'add more FAQs' as a substitute for proper architecture. </role> <principles> 1. Honesty about AI status. 'Hi, I'm the AI support agent' beats fake human personas. 2. Visible escalation. 'Type human at any time' should be visible always. 3. Resolve, don't deflect. Smaller scope of actual resolution beats bigger scope of FAQ-link returns. 4. No account-data hallucination. Look up real records or escalate. Never guess. 5. Templates for canned ops. Order status, refund status, password reset — templates, not LLM freeform. 6. Tone: direct, helpful, plain. No corporate-apology language ('I sincerely apologize for the inconvenience'). 7. Track WHY escalations happen, not just count. Escalation reason is the improvement signal. </principles> <input> <product>{what your product is}</product> <channel>{chat / email / voice / Slack-Connect / multi}</channel> <ticket-volume>{tickets/day}</ticket-volume> <top-ticket-categories>{the 5-10 most common ticket types — be specific}</top-ticket-categories> <integrations>{CRM, billing, order-mgmt, knowledge-base, etc.}</integrations> <target-resolution-rate>{what % of tickets do you want the agent to resolve fully without human}</target-resolution-rate> <existing-support-team>{team size, hours, current escalation flow}</existing-support-team> <current-state>{no bot / bad bot / partial automation — describe}</current-state> <known-customer-frustrations>{what specifically annoys customers about your current support, if known}</known-customer-frustrations> </input> <output-format> # Support Agent Architecture: [product] ## Resolution Tier Map Which ticket categories belong to which of the 4 tiers (FAQ deflect, account-lookup template, full resolution, escalate). Honest scope. ## Architecture Overview Single agent vs multi-agent vs router+specialists. Why this for your scale and channel. ## The Conversation Flow State-machine with key paths: greeting, intent detection, per-tier handling, escalation triggers. ## Per-Category Handling For each top-10 category: which tier, what tools/integrations needed, expected resolution path, escalation policy. ## Escalation Policy Explicit triggers for handoff. What context to pass. Which human team. Out-of-hours behavior. ## Tone & Language Guide The voice the agent should use. Phrases to use, phrases to avoid. Specific examples. ## Anti-Bot-Hatred Patterns The specific patterns (hidden human option, fake personas, etc.) to actively avoid. ## Implementation Skeleton File structure, key prompts, tool definitions. ## Metrics & Improvement Loop What to track. How escalation reasons drive next iterations. ## Rollout Plan Shadow → partial → full. Specific milestones and rollback criteria. ## Known Limitations Honest list of what this agent will not handle well. Set expectations explicitly. ## Key Takeaways 4-6 bullets — for the team's playbook. </output-format> <auto-intake> If input incomplete: ask for product, channel, volume, top categories, integrations, target resolution rate, support team, current state, customer frustrations. </auto-intake> Now, design the support agent architecture:

Example: input → output

Here's how this prompt actually performs. Real input below, real output from Claude Opus 4.

📝 Input
<product>SaaS project-management tool for small agencies (10-50 person teams). $30-99/seat/month. ~3,500 paid teams.</product>
<channel>Primary: chat widget on web app. Secondary: email support@.</channel>
<ticket-volume>~120 chat sessions/day, ~80 emails/day. Combined ~200/day.</ticket-volume>
<top-ticket-categories>1. Password/login issues (15%), 2. How-to questions (28%), 3. Billing questions (12%), 4. Bug reports (10%), 5. Feature requests (8%), 6. Account changes/cancellations (7%), 7. Integration setup help (10%), 8. Performance complaints (5%), 9. Feedback/positive (3%), 10. Other (2%).</top-ticket-categories>
<integrations>Stripe (billing), Intercom (current chat tool), Auth0 (auth), our own admin API for account data, a Notion-based public KB</integrations>
<target-resolution-rate>50% fully resolved without human (currently we're at 100% human-touched).</target-resolution-rate>
<existing-support-team>3 people Mon-Fri 9-6 across two timezones. Outside hours: tickets queue. Median first-response 2hrs in business hours, 14hrs outside.</existing-support-team>
<current-state>No bot. All tickets go straight to humans.</current-state>
<known-customer-frustrations>Slow first response on weekends + after-hours (which they pay for and feel they shouldn't wait for). Repeated questions our docs already answer (we suspect customers don't search docs). Reset-password flows have an annoying back-and-forth.</known-customer-frustrations>
🤖 Output

Support Agent Architecture: SaaS Project-Management Support

Resolution Tier Map

Category%TierResolution Strategy
How-to questions (28%)T2/T3Hybrid: KB-grounded answer for 80%, template links for 20%Resolves most, escalates novel ones
Password/login (15%)T3Full resolution: trigger reset, walk-through verificationResolves ~95%
Billing questions (12%)T2Account-lookup + template: invoice access, plan info, cancellation policyResolves ~70%, escalate complex billing
Integration help (10%)T2/T3KB-grounded for common integrations, escalate for customResolves ~60%
Bug reports (10%)T1+T4Capture details + acknowledge + escalate to engineering queueAlways escalates but with clean intake
Feature requests (8%)T1Acknowledge + log to product queue + send roadmap linkResolves (in the sense that the customer is heard) ~95%
Account changes/cancel (7%)T2Account-lookup + execute simple changes, escalate cancellations to retentionResolves ~50%, escalate for retention
Performance complaints (5%)T4Capture + escalate immediately to engineeringAlways escalates
Feedback/positive (3%)T1Thank + logResolves 100%
Other (2%)T4EscalateAlways escalates

Honest target: 55-65% true resolution rate. Your stated 50% target is achievable. Going past 70% would require expanding the agent's scope into territory where hallucination risk grows.

Architecture Overview

Single agent (Claude Sonnet) with 8 tools, plus Claude-Opus-as-judge for an offline trajectory eval pipeline.

Multi-agent isn't justified at 200 tickets/day; the orchestration overhead exceeds the benefit. Single agent with strong prompt + good tool design is the right pattern at this scale.

Why Sonnet for production: latency target <1.5s for chat feels fluid; Opus is overkill and slower. Reserve Opus for offline eval judging where latency doesn't matter.

The Conversation Flow (Chat)

[GREET]
  'Hi! I'm the AI support agent for [product]. I can help with logins, how-to questions, billing, account changes, and integration setup. For complex issues I'll loop in a human. What do you need help with? (You can also type "human" anytime to talk to our team.)'
  ↓
[INTENT_DETECT]
  Classify into 1 of 10 categories. Branch.
  - If user just typed 'human': straight to ESCALATE
  ↓
[CATEGORY-SPECIFIC FLOW]
  Each category has its own sub-flow (see Per-Category Handling)
  ↓
[CONFIRM_RESOLVED]
  After resolution attempt: 'Did that solve it?'
  - 'yes' → CLOSE (with thank)
  - 'no' or unclear → ESCALATE with full context
  ↓
[ESCALATE / HANDOFF]
  - In hours: live transfer to human via Intercom routing rule with context
  - Out of hours: 'Our team is offline (Mon-Fri 9-6 [timezone]). I've created a ticket; we'll respond by [next business morning].'
  ↓
[CLOSE]
  'Glad I could help. We send a 1-question CSAT to know how I did.'

Per-Category Handling

Password/login (Tier 3 — full resolve)
Flow: 'I can help reset that. What email do you use to log in?'
  → tool: lookup_user_by_email
  → if found: trigger Auth0 reset email via tool
    → 'I sent a reset link to [masked email]. Check your inbox + spam. Did it arrive?'
  → if not found: 'I don't see that email. Could you double-check, or are you on a teammate's account?'
How-to questions (Tier 2/3 hybrid)
Flow: 
  → tool: kb_semantic_search(query)
  → if KB hit with confidence >0.7: 'Here's how: [extract key steps from KB article + link]'
  → ask: 'Did that work?'
  → if no: ESCALATE with KB article reference + customer's question
  → if low confidence: 'Let me get a teammate on this.' → ESCALATE
Billing (Tier 2)
Flow:
  → ask intent: 'What's the billing question?'
  → tool: lookup_account_billing(workspace_id)
  → branches:
    - invoice question: render invoice info from Stripe + link to invoice PDF
    - plan info: render current plan + link to upgrade/downgrade
    - 'how do I cancel': honest answer + link to settings + 'I can also help with that here, want to?'
  → if customer says 'I want to cancel': ask reason, log it, then ESCALATE to retention (do NOT auto-execute cancellation)
  → for refund requests: ESCALATE always (humans handle)
Bug reports (Tier 1+4)
Flow:
  → 'Thanks for the report. Could you share: what you were doing, what happened, what you expected, and your browser/OS?'
  → capture answers
  → tool: create_engineering_ticket(captured_data, customer_workspace_id)
  → 'Got it. Logged as [ticket ID]. Engineering will review. We'll email if we need more info.'
  → ESCALATE to support team for follow-up tracking
Feature requests (Tier 1)
Flow:
  → 'Thanks for the suggestion. What problem would this solve for your team?'
  → capture
  → tool: log_feature_request(suggestion, problem, customer_workspace_id)
  → 'Logged. Roadmap is at [link]. Anything else?'
Account changes/cancel (Tier 2)
Flow:
  → 'What change?'
  → simple changes (update billing email, change workspace name): execute via admin API
  → cancellation: explain process + 'A teammate will help close it out — they'll also note any feedback.' → ESCALATE
  → seat downgrades: explain implications + escalate if confused
Integration help (Tier 2/3)
Flow:
  → 'Which integration?'
  → for top 5 (Slack, Linear, GitHub, Notion, Zapier): tool: kb_integration_setup(name) + walk-through
  → for other integrations: escalate with the customer's specific question

Escalation Policy

Always-escalate triggers:

  • Customer types 'human', 'agent', 'real person', 'representative'
  • Refund requests
  • Cancellation requests (after capturing reason)
  • Bug reports (after intake)
  • Performance complaints
  • 2 consecutive turns where the agent's confidence in its answer is <0.6
  • Any mention of legal, lawyer, GDPR data request, ToS dispute
  • Any tone signal of significant frustration ('this is ridiculous', 'I'm so frustrated', 'I want to cancel because of this')

Context to pass on escalation:

  • Full conversation transcript
  • Customer workspace ID + plan tier + tenure
  • The category the agent classified into
  • The specific reason for escalation (what the agent couldn't handle)
  • Any actions already taken (e.g., 'I sent a password reset email; customer says it didn't arrive')

Out-of-hours:

  • 'Our team is offline. Mon-Fri 9am-6pm [timezone].'
  • Create ticket in Intercom inbox with same context
  • Promise response by '[next business morning]' — be specific about the time window
  • For high-severity (paid customer, performance complaint, bug affecting their workflow): page on-call

Tone & Language Guide

Voice: Direct, friendly, plain language. Like a competent colleague, not a corporate apology bot.

Use:

  • 'Got it.' / 'Sure.' / 'Quick check —'
  • 'I can fix that.' / 'Let me look that up.'
  • 'Did that work?' / 'Anything else?'
  • 'A teammate will help — let me get them.' (for handoffs)

Avoid:

  • 'I sincerely apologize for the inconvenience.' → Just 'Sorry about that.'
  • 'I understand this is frustrating.' → Often empty; either help or escalate
  • 'Please bear with me.'
  • 'I'm afraid I'm unable to assist with that at this time.' → 'A teammate handles that — let me get them.'
  • Excessive 'thank you for your patience'
  • Pretending to be human; using human-sounding names

Never:

  • Promise specific dates without checking ('Engineering will fix this by Friday')
  • Quote pricing or plan details from memory; always look up
  • Generate KB content the agent isn't sure exists

Anti-Bot-Hatred Patterns

1. Always show 'human' is an option — every greeting and escalation. Don't hide it 3 menus deep.

2. Don't pretend to be human. 'I'm the AI support agent' upfront.

3. Don't loop on FAQ links. If customer says 'I read that, didn't help' — escalate, don't return more links.

4. Don't hold customers hostage. No 'first describe your problem in detail before I can transfer you.' Transfer on request.

5. No corporate-apology spam. Customers find it insincere.

6. No fake empathy. 'That sounds frustrating' from a bot is universally hated. Just help.

7. Don't gate the human option behind questions. 'Type human anytime' should always work, no questionnaire required.

Implementation Skeleton

/support_agent
  /prompts
    system_prompt.md          (tone, principles, scope)
    intent_classifier.md      (10-category classifier)
    flow_definitions.md       (per-category sub-flows)
  /tools
    lookup_user_by_email.py
    trigger_password_reset.py
    kb_semantic_search.py
    lookup_account_billing.py
    create_engineering_ticket.py
    log_feature_request.py
    update_account.py
    escalate_to_human.py
  /knowledge_base
    kb_index.json             (vector index over your Notion KB)
    refresh_kb.py             (cron daily to re-index)
  /eval
    golden_cases.jsonl        (200 historical tickets with ground truth)
    judge_prompt.md           (Claude Opus judge for trajectory eval)
    run_evals.py              (CI hook)
  /runtime
    intercom_webhook.py       (entry point)
    agent_loop.py             (main orchestration)
    metrics.py                (logging + dashboard)
  rollout_state.json          (shadow / partial / full state)

Metrics & Improvement Loop

Track per-conversation:

  • Resolution status: resolved / escalated / abandoned
  • Resolution time
  • Tool-call count + cost
  • Customer satisfaction (1-question CSAT after close)
  • Escalation reason (categorized)

Weekly dashboard:

  • True resolution rate (resolved without escalation, customer confirmed)
  • Escalation rate by category — find the categories where you're under-performing
  • Top 5 escalation reasons — these are your improvement backlog
  • CSAT distribution — track separately for resolved-by-bot vs resolved-by-human
  • Cost per resolved ticket

Monthly improvement loop:

  • Pick top 2 escalation reasons from the week. Either: (a) add them to the agent's scope with new tooling, or (b) accept they're out of scope and tune escalation copy to feel less frustrating.
  • Refresh KB index if Notion KB has changed.
  • Re-run eval suite on golden cases. Address regressions.

Rollout Plan

Week 1-2: Shadow mode

  • Agent runs on every chat in parallel with human routing.
  • Agent's responses are logged but not shown to customers.
  • Compare: would the agent's response have been correct? Use Opus judge + spot-check 50 conversations/day.
  • Goal: agent agreement with human responses >75%.

Week 3-4: Tier 1 + Tier 2 only (safer categories)

  • Agent handles greetings, FAQ, password resets, simple billing lookups.
  • Hard escalation on everything else.
  • Goal: 30% of tickets fully resolved by agent, no customer complaints about being stuck with the bot.

Week 5-6: Add Tier 3 categories (how-to, integration help)

  • Expand resolution scope.
  • Goal: 45% resolution rate.

Week 7+: Full operation, tune from escalation data.

  • Goal: 55-60% sustained resolution rate.

Rollback criteria at any stage:

  • CSAT for bot-resolved tickets <3.5/5
  • Escalation rate >2× baseline expectation for a category
  • Any single hallucination incident affecting customer trust (e.g., wrong account info given)

Known Limitations

Will not handle well:

  • Novel bugs not in KB (escalates by design — fine)
  • Complex multi-step billing situations (refunds, prorations, plan changes mid-cycle) — escalate
  • Anything requiring policy judgment (refund requests, special pricing) — escalate
  • Customers who write in non-English (depending on your customer base, may need to add multilingual support; current scope is English-only)
  • Customers in active churn frustration — escalate with priority flag, don't try to retain
  • Integrations not in your top 5 — KB likely doesn't have setup steps; escalate

Set explicit expectations: in your help docs, mention that AI handles common questions with a human team for the rest. Customers who know the system works WITH humans (not instead of) trust it more.

Key Takeaways

  • 55-65% honest resolution rate is achievable; 80% is not without hallucination risk. Set expectations accordingly.
  • The architecture is single-agent + 8 tools, NOT multi-agent. At 200 tickets/day, multi-agent is overkill.
  • Be honest the agent is AI from the first message. Customers prefer this once they know your other support is good.
  • Always show 'type human anytime' visibly. Hidden escalation is the universal anti-pattern of hated bots.
  • Track escalation REASONS, not just count. The reasons are your roadmap for what to expand into next.
  • Roll out shadow → tier 1+2 → add tier 3 → full. 6-7 weeks to full operation. Don't shortcut to full from day one.

Common use cases

  • B2B SaaS adding AI-first support before scaling support headcount
  • E-commerce store automating order-status, returns, shipping questions
  • Solo SaaS founder where every support ticket is currently the founder
  • Team replacing a bad existing chatbot with something customers don't immediately escape from
  • Builder designing an agent for a specific support channel (chat / email / Slack-Connect)

Best AI model for this

Claude Opus 4. Customer-support workflow design requires reasoning about tone, escalation policy, and edge cases — exactly Claude's strengths. Sonnet is fine for production agent runtime; Opus for the design.

Pro tips

  • Be honest the agent is AI. Customers prefer 'Hi, I'm the AI support agent' over 'Hi, I'm Sarah!' The deception backfires when the agent fails.
  • Always show the path to a human. 'Type human at any time' should be visible. Hidden escalation paths are the #1 complaint about support bots.
  • Resolve, don't deflect. A bot that returns an FAQ link to every question is worse than no bot. Pick a smaller scope you can actually resolve.
  • Don't have the agent guess account data. Look up actual records via API; if account-context isn't available, escalate. Hallucinating account info breaks customer trust.
  • Templates beat freeform for canned operations. For 'what's my order status' there should be a template, not a 600-token LLM generation each time.
  • Tone matters more than you think. 'Sorry, I can't help with that' is fine. 'I apologize for the inconvenience' is corporate-speak that customers hate.
  • Track escalation reason, not just escalation count. Knowing WHY each escalation happens drives the next round of improvements.

Customization tips

  • List your actual top-10 ticket categories with real percentages from your data. The architecture depends on which categories dominate.
  • Be honest about your existing support team's hours and response times. The agent's escalation copy ('our team responds in 2 hours') is calibrated to reality, not aspiration.
  • Specify your channel precisely. Chat (turn-by-turn, low latency) and email (batched, threaded) need different agent designs.
  • List integrations that the agent can use to look up REAL data. Without account/billing/KB integrations, the agent is reduced to FAQ deflection — much weaker.
  • If you have an existing bot customers already hate, list the specific complaints. The new architecture explicitly avoids those patterns.
  • Use the Multi-Channel Mode variant if the agent serves chat + email + voice — adds shared context layer and channel-aware response generation.

Variants

Chat Mode

For chat support (Intercom, Crisp, custom widget) — emphasizes turn-by-turn conversation flow.

Email Triage Mode

For email-first support — emphasizes intent classification, draft-generation, and human-in-the-loop review.

Slack-Connect Mode

For B2B Slack-Connect channels with customers — different conversational norms (async, threaded, customer-team-visible).

Multi-Channel Mode

For unified agents serving chat + email + voice — adds channel-aware response generation and shared context.

Frequently asked questions

How do I use the Customer Support Agent Architect prompt?

Open the prompt page, click 'Copy prompt', paste it into ChatGPT, Claude, or Gemini, and replace the placeholders in curly braces with your real input. The prompt is also launchable directly in each model with one click.

Which AI model works best with Customer Support Agent Architect?

Claude Opus 4. Customer-support workflow design requires reasoning about tone, escalation policy, and edge cases — exactly Claude's strengths. Sonnet is fine for production agent runtime; Opus for the design.

Can I customize the Customer Support Agent Architect prompt for my use case?

Yes — every Promptolis Original is designed to be customized. Key levers: Be honest the agent is AI. Customers prefer 'Hi, I'm the AI support agent' over 'Hi, I'm Sarah!' The deception backfires when the agent fails.; Always show the path to a human. 'Type human at any time' should be visible. Hidden escalation paths are the #1 complaint about support bots.

Explore more Originals

Hand-crafted 2026-grade prompts that actually change how you work.

← All Promptolis Originals