An Agentforce case deflection architecture should not begin with a benchmark. It should begin with a boundary: which requests may the agent resolve, which Actions may it execute, and when must a person take over?
Salesforce describes Agentforce as a platform with several pricing and deployment options. That product description does not establish a universal containment rate or prove that one architecture will work in every Service Cloud org. The evidence has to come from the approved use case, the current org, and a controlled measurement plan. See Salesforce’s current Agentforce overview for product-level information, then validate tenant-specific capabilities in your own documentation and contract.
1. Define an eligible case before measuring deflection
“Cases avoided” can hide several different outcomes:
- the customer solved the issue;
- the customer abandoned the interaction;
- the agent redirected the customer to a static page;
- the issue resurfaced through another channel;
- the conversation escalated without enough context.
A defensible metric starts with named intents and an eligibility rule. Exclude requests that require legal judgment, unsupported identity checks, unavailable system Actions, or policy exceptions. Record repeat contact and escalation separately from successful resolution.
The target should be local to that scope. A password-reset flow, an order-status query, and a disputed invoice do not share the same risk or data requirements.
2. Map the minimum authoritative context
For each eligible intent, write down the facts required to resolve it:
- Identity: what level of authentication is required?
- Entitlement: what product, contract, or service level applies?
- Current state: which system is authoritative for order, billing, shipment, or case status?
- Policy: which rule permits or blocks the requested outcome?
- Action: what operation can the agent execute, and what confirmation is required?
Do not add Data 360 by default. It becomes relevant when the use case needs governed identity reconciliation, cross-system context, segmentation, or activation that the existing architecture cannot provide safely. A narrow CRM-only use case may not need it.
3. Separate knowledge from executable resolution
A knowledge article can explain a policy. It cannot prove that a refund is allowed, change a shipping address, or confirm that an integration completed.
Every Action should therefore have:
- an explicit input schema;
- permission and identity checks;
- idempotency or duplicate-execution protection where applicable;
- a defined success response;
- a defined failure response;
- logging that supports operational investigation;
- a human fallback.
Free-form Instructions should not replace deterministic controls for price, eligibility, consent, regulatory checks, or destructive operations.
4. Test the boundary, not only the happy path
A useful test set includes:
- clear eligible requests;
- ambiguous wording;
- missing or contradictory context;
- expired sessions and permission failures;
- unavailable downstream systems;
- attempts to cross the Topic boundary;
- repeat contact after an apparent resolution;
- multilingual and channel-specific variations where those channels are in scope.
Use a versioned set of cases and record expected outcomes. Product test tooling can help execute scenarios, but the organisation still owns the assertions, risk classification, and release decision.
5. Design the human handoff
Escalation is not evidence of failure when it is the safe, intended outcome. A useful handoff includes:
- authenticated customer identity or a clear identity gap;
- the customer’s stated intent;
- the facts the agent verified;
- the Actions attempted and their results;
- the reason for escalation;
- the next recommended queue or owner.
If the human must repeat discovery from zero, the architecture has not completed the handoff.
6. Measure outcomes without invented precision
Build a local scorecard rather than importing a headline percentage:
| Measure | What it should distinguish |
|---|---|
| Eligible volume | Requests inside the approved resolution boundary |
| Resolved without human | Confirmed outcome, not simple conversation closure |
| Escalated as designed | Safe handoffs triggered by named conditions |
| Unexpected escalation | Missing data, broken Action, weak instruction, or unknown intent |
| Repeat contact | Same issue returning within the chosen observation window |
| Action failure | Technical or permission failure by Action and system |
| Customer outcome | Confirmation, correction, abandonment, or unresolved state |
Define the denominator and observation period before release. Change targets only when the scope or evidence changes.
Production-readiness decision
A release is defensible when the sponsor can answer five questions:
- Which intents are eligible?
- Which systems and fields are authoritative?
- Which Actions are permitted and reversible?
- Which conditions force escalation?
- Which local metrics will decide expansion, redesign, or stop?
The aim is not the highest possible deflection number. It is a bounded service outcome that can be explained, tested, monitored, and stopped safely.
