# Using Teammately for Customer Support AI Generated: 2026-09-13T04:42:43.534Z Source build: local Canonical docs: https://teammately.ai/docs --- 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. --- id: playbooks.enterprise-assistant-review title: Running Expert Contributions for an Enterprise Assistant summary: Collect expert judgment for assistants that must follow product, domain, and policy expectations. kind: recipe product_area: playbooks status: stable updated: 2026-08-23 canonical: /docs/playbooks/running-expert-contributions-enterprise-assistant --- # Running Expert Contributions for an Enterprise Assistant Use this playbook when an enterprise assistant needs domain experts to judge outputs before the team turns that judgment into standards and benchmarks. ## Contribution boundary Use this when a named specialist must resolve a bounded correctness question that prepared Cases and source context cannot answer automatically. Do not use a Contribution as a general request to “review the assistant.” ## Request and complete the work 1. Name the decision the expert owns and select the smallest set of Cases that exposes it. 2. Prepare the Project Agent Brief, source material, Case context, questions, and allowed response form before sending the request. 3. In the Benchmark's **Expert Contributions** workspace, choose the recipient, Tasks, materials, and any Checkpoints required to confirm progress or handoff. 4. Pilot the Contribution with one specialist and verify that the recipient can enter the executable Task and has enough context to answer. 5. Preserve expert responses, rationale, unresolved questions, and Checkpoint state as Contribution provenance. 6. Inspect **Contributed Artifacts** and reconcile candidate Policies, Rubrics, Cases, or coverage observations into their owning project surfaces. 7. Apply the owning approval and version controls. Contribution completion does not automatically approve a Policy, Rubric, reference response, or Dataset membership change. ## Contribution is complete when The required Tasks and Checkpoints have reached their terminal states, the expert's attributable answer is preserved, and every contributed artifact is either reconciled, rejected through its owning workflow, or left explicitly unresolved. {% example-demo title="Procurement assistant review" %} A procurement specialist receives five Cases that differ by spend authority, vendor category, and contract status. The Contribution asks one bounded question: who must approve each purchase, and what source controls that answer? The specialist completes the Tasks, explains two exceptions, and confirms the proposed boundary at a Checkpoint. Contributed Policies and Rubrics retain that provenance but become governed only after the accountable owner approves them in Correctness Governance. {% /example-demo %} ## Evidence to collect - Cases, candidate outputs, Project Agent Brief, source context, and constraints shown to reviewers. - Checkpoint or interview records that capture reviewer rationale. - Attributable expert answers, rationale, unresolved concerns, and Checkpoint state. - Contributed artifacts and their reconciliation into Cases, Policies, Rubrics, or coverage observations. - Benchmark coverage and run results produced after standards are approved. ## Related docs {% related-card-grid title="Related docs" %} - [Request an Expert Contribution](/docs/expert-contributions/request-contribution) - [Complete an Expert Contribution](/docs/expert-contributions/complete-contribution) - [Inspect Contributed Artifacts](/docs/expert-contributions/contributed-artifacts) - [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) {% /related-card-grid %} ## Source confidence Doctrine-backed: the approved product model treats expert work as attributable contribution rather than automatic approval. Linked code-backed pages define request composition, executable Tasks, Checkpoints, lifecycle, and contributed-artifact reconciliation. --- id: object-model.applicability-logic title: Applicability logic summary: Explain when a policy or rubric should be used for a case, output, or coverage segment. kind: reference product_area: object_model status: stable updated: 2026-08-23 canonical: /docs/object-model/applicability-logic --- # Applicability logic ## Definition Applicability logic is the boundary that decides whether a policy or rubric should be considered for a specific case, output, or coverage segment. It prevents a good standard from being applied to the wrong behavior. Use this reference when a benchmark result is hard to explain because a standard seems relevant in some cases but not others. The question is not only whether the policy is correct; it is whether the policy was eligible to judge that output. ## Fields, states, or lifecycle rules - Applicability sits between the case/output and the policy/rubric that may judge it. - Weak applicability makes benchmark failures noisy: a candidate can fail a good rubric on a case where the rule should not have applied. - Strong applicability names the behavior condition, source context, or case segment that brings the standard into scope. - Applicability changes can make old benchmark evidence stale because the same output may be judged by a different standard boundary. - This page explains the public object relationship, not a public rule language, API schema, or export contract. ## Related objects Applicability logic should be read with [Policies](/docs/object-model/policies), [Rubrics](/docs/object-model/rubrics), [Cases](/docs/object-model/cases), and [Coverage Dimensions](/docs/object-model/coverage-dimensions). Use the Correctness Governance workflow to write the boundary and troubleshooting when the observed Case set is wrong. {% example-demo title="Applicability logic boundary" %} Raw case: A user asks whether a product works with equipment they already own. Policy: Compatibility claims require explicit source support. Applicability logic: The policy applies only when the answer recommends, validates, or compares a product for a concrete use context. Benchmark interpretation: If the case only asks for a product description, the compatibility rubric should not judge it. If the answer claims the product will work with the user's equipment, the rule is in scope. {% /example-demo %} ## Source confidence Code-backed: Policy and Rubric types and their detail routes expose applicability fields and the links among governed standards, Cases, and evaluation checks. This page describes those product relationships; it does not define a portable rule language. ## Related task pages {% related-card-grid title="Related task pages" %} - [Work with Policies and Rubrics](/docs/correctness-governance/policies-and-rubrics) - [Fix weak applicability logic](/docs/troubleshooting/weak-applicability-logic) - [Resolve conflicting correctness evidence](/docs/governance/conflict-resolution) - [Product quickstart](/docs/quickstart) - [Task index](/docs/operating-manual/task-index) {% /related-card-grid %} --- id: coverage.case-segmentation title: Case Segmentation summary: Segment cases into meaningful behavior groups so benchmark coverage is explainable. kind: concept product_area: coverage_engineering status: stable updated: 2026-08-23 canonical: /docs/coverage-engineering/case-segmentation --- # Case Segmentation ## Definition Case segmentation is the act of reading a Case population by meaningful behavior slices instead of only as a total count. In Teammately, reusable Dimensions and ontology values provide governed segmentation axes; Project Topics and Case Construction Patterns provide additional intent; Benchmark Dataset Representation shows how selected Cases occupy those axes. A segment is an analytical grouping, not a new Case object or a hidden approval state. ## Why it matters Aggregate benchmark results can hide concentrated success and consequential absence. A candidate may score well overall while failing every Case with missing evidence, a particular jurisdiction, or a high-impact exception. Segmentation makes those differences inspectable and gives Coverage Stories a concrete population to address. ## Where it appears in the product Define reusable axes in **Coverage Facets → Dimensions & Ontology**. Classify Cases against those values through supported Case and coverage workflows. Use **Benchmark Datasets → Representation** to inspect the current selected population. Use Coverage Management when a sparse or absent intersection needs a Story, Case Foundry work, or an Expert Contribution. ## Artifacts it affects Keep three identities separate: the reusable Dimension, the ontology value assigned to a Case, and the Benchmark Dataset membership being analyzed. Changing a value can alter current Representation without modifying an older Snapshot. Adding a Case can change counts without changing the segmentation model. A filter is a view over evidence, not a new evidence object. ## Operational check Choose axes that describe material behavior, context, risk, or source conditions. Check distinct Case counts as well as assignments, inspect unclassified and conflicting values, and avoid interpreting overlapping segments as additive totals. When reporting a result by segment, name the Benchmark Version whose Case assignments support the analysis. {% example-demo title="Finding a hidden source-authority gap" %} The dataset contains many high-impact Cases and many Cases with superseded sources, but Representation shows almost no Cases where both conditions occur together. The team creates a Coverage Story for that intersection. Case Foundry prepares candidates, reviewers confirm their realism, and a later Snapshot records the expanded segment. The Dimension definitions remain reusable across other Benchmarks. {% /example-demo %} ## Related workflows {% related-card-grid title="Related workflows" %} - [Dimensions and ontology](/docs/coverage-engineering/dimensions-ontology) - [Coverage dimensions](/docs/object-model/coverage-dimensions) - [Coverage Gaps](/docs/coverage-engineering/coverage-gaps) - [Product quickstart](/docs/quickstart) - [Task index](/docs/operating-manual/task-index) {% /related-card-grid %} ## Source confidence Code-backed: the Representation explorer and Dimension classification types establish facet-based Case grouping, assigned and missing values, and benchmark-scoped distribution views. Coverage significance and gap priority remain accountable human judgments.