The situation
A B2B software company with a small support team handling a steady case volume, a large share of which were variations on the same handful of questions — password and access issues, billing date queries, and “where is my invoice.” Leadership wanted an Agentforce deployment. The support lead was skeptical, having watched a chatbot project fail two years earlier.
What we checked first
Before designing anything we pulled a sample of several hundred recent cases and categorized them by hand. Roughly half were genuinely repetitive and rule-bound. The other half needed account context an agent could get wrong in expensive ways.
We also read the knowledge base the agent would have been grounded on. A meaningful portion of the articles were stale — referencing a UI that had changed, or a policy that no longer applied. An agent grounded on that content would have confidently told customers the wrong thing, which is precisely how the earlier chatbot had lost the team’s trust.
So the first phase of the engagement wasn’t an agent at all. It was a knowledge audit.
What we built
Once the knowledge base was current, we scoped the agent narrowly and deliberately:
- Three topics only — access and login, billing dates, invoice retrieval — chosen because each had clear rules and no judgment calls
- Read-heavy actions. The agent could look up an account’s billing schedule and surface an invoice. It could not change anything, and it could not close a case.
- An escalation path that fired early. Two failed attempts to resolve, or any sentiment signal suggesting frustration, handed off to a human with the full conversation attached.
- Evaluation against real history. We ran the agent against the categorized historical cases and reviewed every response with the support lead before it went anywhere near a customer.
Outcome
The agent went live on the three scoped topics after a staged rollout that started with internal users. Deflection on those specific case types was meaningful and, more importantly, the support lead trusted it — because she had personally reviewed where it got things wrong during testing and knew exactly what it was and wasn’t allowed to do.
The team has since expanded it to a fourth topic. The pattern held: audit the knowledge first, scope narrowly, test against real cases, then expand.