---
id: playbooks.customer-support-ai
title: Using Teammately for Customer Support AI
summary: Govern assistant behavior where correctness depends on policy, escalation, tone, and account context.
kind: recipe
product_area: playbooks
status: stable
updated: 2026-08-23
canonical: /docs/playbooks/customer-support-ai
---

# Using Teammately for Customer Support AI

Use this playbook when support behavior must respect customer policy, escalation rules, account context, and tone without reducing correctness to satisfaction scores.

## Start with one support decision

Choose one decision family—refund eligibility, service credit, account change, plan entitlement, or escalation. Do not begin with “support quality” as a single standard; the required context and accountable owner differ across those decisions.

## Build the support boundary

1. Configure the **Project Input Schema** for the account, channel, transcript, entitlement facts, and source material the assistant actually receives.
2. Import ordinary and failed interactions under **Assets → Cases**, preserving prior turns when they affect the answer.
3. Define Coverage Facets for intent, customer state, available account evidence, policy exception, escalation need, and interaction mode.
4. Request Contributions from the support or operations owners who can decide allowed commitments and escalation boundaries.
5. Approve separate Policies and Rubrics for eligibility, commitments, escalation, and communication requirements; do not combine them into one “helpful response” check.
6. In Coverage Management, add boundary Cases for missing account context, frustrated customers, conflicting sources, and exception requests.
7. Evaluate saved Harness Versions and inspect the applicable Rubric failures by Case and coverage slice.

## Hold or proceed

- Hold when the Case omits account facts that the real assistant would receive.
- Route an unclear exception to an Expert Contribution instead of encoding a guessed rule.
- Treat an unsupported promise as a correctness failure even if tone is acceptable.
- Proceed to candidate improvement only after the governing Policy and Dataset boundary are stable.

{% example-demo title="Refund exception handling" %}
A customer requests a refund outside the standard window after a service outage. The Case contains the outage fact but not the account evidence required to approve an exception. Support owners establish that the assistant may explain the standard rule and escalate, but may not promise approval. Evaluation shows the candidate passes routine refunds and fails only when an outage is mentioned, giving the Harness owner a specific commitment boundary to fix.
{% /example-demo %}

## Evidence to collect

- Conversation-shaped Case input and the account or policy material actually available.
- Attributable Contribution decisions about commitments, escalation, exceptions, and required language.
- Separately governed Policies and Rubrics for each decision boundary.
- Dataset representation across routine, ambiguous, exception, missing-context, and high-impact Cases.
- Case-level response and Rubric evidence tied to exact Harness and Benchmark Versions.

## Related docs

{% related-card-grid title="Related docs" %}
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
- [Review prepared Cases](/docs/coverage-management/case-review)
- [Compare Harness Versions](/docs/benchmark-evaluations/compare)
- [Read run results](/docs/benchmark-evaluations/inspect-results)
- [Run a benchmark](/docs/benchmark-evaluations/run-evaluation)
- [Importing cases](/docs/operating-manual/import-and-prepare-cases)
- [Agent Setup](/docs/agent-setup)
{% /related-card-grid %}

## Source confidence

Doctrine-backed: the approved product model establishes the flow from support evidence to expert-owned standards, designed coverage, and versioned evaluation. Linked pages define the active Case, Contribution, governance, and Benchmark surfaces.