Salesforce Service Cloud Consultant study materials
Salesforce Service Cloud Consultant study resources

70% Containment in Two Quarters

Salesforce Service Cloud Consultant · Put your knowledge to work in context.

All case studies

70% Containment in Two Quarters

Aster Benefits administers supplemental health policies. Its 180 agents handle 250,000 contacts a month; 62% are status checks (claim status, coverage, ID card) and 21% are address or dependent changes. The knowledge base holds 2,100 articles, 40% unvalidated, and some describe state-specific rules. Leadership wants an AI service agent to contain 70% of contacts within two quarters, including 'change my address' and 'what is my claim status', handing the rest to humans. Legal has two hard requirements: no protected health information may reach a model provider without an approved agreement, and every answer about coverage must carry the state-specific disclosure. Claims data lives in a Heroku Postgres instance replicated into Salesforce nightly; identity is verified through a partner OTP API.

1. Which intents belong in the first release, and what must be built for each?

Read the worked answer

Start where volume is high, data is structured, and the answer is verifiable. Volume alone is not the criterion - reversibility and regulatory exposure are.

Release 1 - include

  • Claim status (the largest single intent). Requires: successful OTP verification before any data retrieval; a read path to claim data; and an explicit decision about freshness. Nightly replication means the honest answer is 'as of yesterday', stated in the response - or you expose a near-real-time API for status. Do not let the model paper over the latency.
  • Coverage and ID card lookup. Same identity gate, read-only, low risk provided the answer cites the plan document version.
  • Address change. A write action, so it needs: verified identity, a Flow or API that validates the address, a confirmation step, an audit record of before and after, and a human fallback when validation fails or when the move crosses state lines and therefore changes coverage - that is a licensed-agent conversation.

Exclude from release 1: claim adjudication and appeals, medical-necessity questions, anything requiring advice, and any intent whose answer depends on state-specific rules that are not yet modelled as structured data. A generative model must not compose a coverage determination.

Gate for every included intent: documented data source, identity requirement, controlled template for the regulated sentence, and written legal sign-off on the exact wording.

2. Define the boundary between the AI agent and a human, including guardrails and handoff quality.

Read the worked answer

Design the handoff as a contract, not as a failure mode.

Deterministic escalation triggers

  • Identity verification fails, or the customer declines verification.
  • Intent is outside the enabled set, or retrieval confidence falls below the threshold you set from pre-launch testing.
  • The customer asks for a person, or sentiment turns negative after one clarification attempt.
  • The request implies a coverage change, complaint, appeal, or exception.
  • The enabled action fails twice (validation error, downstream API error).

Handoff payload: full transcript attached to the case, verification state (so the human does not re-ask the security questions), detected intent, retrieved sources, and what was already attempted. Route by intent to the correct queue with a priority, instead of dumping everything into a general queue.

Guardrails

  • No PHI to a model provider without the approved agreement. Confirm, for this specific configuration, which masking and retention controls are contractually enabled, and get it in writing - do not infer it from a product demo.
  • Deny by default on actions: the agent may perform only the specific writes you enabled, scoped to the authenticated customer.
  • Coverage answers carry the state disclosure by template, not by model choice; every session is logged for audit and QA.

Test the unhappy paths before go-live: an unverified user asking about someone else's claim, a customer moving state mid-conversation, and the OTP API being down. Those three tests reveal more than a hundred happy-path transcripts.

3. How would you measure progress toward 70% containment without gaming the number?

Read the worked answer

Containment is trivially inflatable, so define it defensibly and always pair it with resolution.

  • Containment = the session was handled end to end by the agent, with no human transfer, and no new contact from the same customer on the same topic within 7 days. Drop the follow-up window and you count frustrated people as successes.
  • Resolution = a weekly random human QA sample confirms the answer was correct and complete (set a threshold, e.g. 95% plus), with no complaint or appeal attached.
  • Handoff quality = transfer rate by intent, and repeat-contact rate after transfer. A bad handoff shows up here before it shows up in CSAT.
  • Business outcomes = cost per contact, CSAT for AI-handled versus human-handled contacts, and agent hours redeployed to complex work.
  • Keep a control. Hold out roughly 10% of eligible traffic to human handling so seasonal effects are separable from agent effects. Without it, every improvement is unattributable.

Phasing: ship claim status, run 3-4 weeks, fix retrieval and templates, then add coverage lookups, then the write action last. Each addition gets its own accuracy gate before it takes traffic.

Watch for the two failure modes a volume target creates: agents quietly working around the AI because it is slightly wrong, and the AI absorbing contacts that should have been flagged - complaints, vulnerable customers, anything with a regulatory edge. Then publish the number with its definition on the same page. A 55% containment figure that survives scrutiny is worth more than a 70% figure that later turns out to mean 'we did not transfer.'