It’s 2:14 a.m. and a case lands in your queue: “Where is order 88213?” A human agent will answer it tomorrow in ninety seconds using one field lookup. Multiply that by four thousand cases a month and you’ve found the reason your support team never gets to the interesting problems.
Salesforce Agentforce is built for exactly that queue. But an agent pointed at the wrong object, or briefed with three vague sentences, will confidently invent a delivery date and apologise for a delay that never happened. The difference between those two outcomes isn’t the model. It’s the setup.
Here’s the build path that works, in the order I’d run it. Budget three weeks for a first agent, with roughly half a day of configuration work spread across that time.
Step 0: Spend an hour in your case queue before you touch Setup
Pull the last 500 closed cases and look for patterns. You want numbers, not impressions.
- Which 5-10 case subjects account for the largest share of volume?
- Of those, how many need a system change (refund, address edit, subscription pause) versus a written answer?
- What’s the average handle time per category?
- Which ones generate the most escalations, and why?
At a mid-market logistics SaaS company I worked with, 4,100 cases arrived in a typical month. Status checks, address changes and password resets made up 38% of them and averaged 5 minutes 40 seconds of handle time each. That’s about 9,000 agent-minutes a month spent on work a properly configured agent can do without supervision.
Step 1: Pick a job narrow enough to finish
“Handle customer support” is not a job. “Update the shipping address on an open order after verifying the customer” is a job. The tighter the scope, the faster you ship, and the easier it is to tell whether the agent is doing well.
Start with one task from your Step 0 list that meets three conditions: high volume, low ambiguity, and a clear finish line. Address changes usually qualify. Billing disputes usually don’t, because “correct” depends on judgement and policy nuance you haven’t written down anywhere. If you’re still weighing platforms, it pays to study how other AI agent studios structure their build-and-ship cycle before you lock in architectural decisions.
Step 2: Make sure the agent can see the data it needs
An agent reasons over what you give it. If order status lives in a legacy system that isn’t surfaced in your org, the agent will guess, and guessing is worse than silence. Before you write a single instruction, confirm the agent has read access to the objects and fields involved. For the address-change example, that’s typically the contact’s verification status, the Order record, the related Shipment record, and the knowledge article covering restricted destinations.
This is where most of the real work sits. It’s also why an agent layer that acts inside your CRM behaves so differently from a chatbot bolted onto a website. The data is already there, and you’re granting access rather than rebuilding integrations from scratch.
Step 3: Write instructions the way you’d brief a new hire
Topic instructions are the agent’s job description. Good ones cover five things:
- Role and scope: who the agent is and what it’s allowed to handle.
- Prerequisites: what must be true before it proceeds, such as identity verification.
- Tone: how it should sound, ideally with one sentence of example phrasing.
- Escalation triggers: the conditions that hand the conversation to a person.
- Prohibited actions: what it must never do, stated plainly.
A workable line for the address-change agent reads something like: “If the customer’s verification status is not ‘Verified’, do not confirm any order details. Offer to transfer to a specialist and end your turn.” That single sentence prevents the most common and most damaging failure mode in the entire build.
Escalation beats confidence
Aim for an agent that says “I can’t do that, here’s a person” slightly more often than strictly necessary in week one. You can loosen it later with evidence. Tightening after customers have already been given wrong information costs you trust you won’t get back quickly.
Step 4: Give it actions, not just answers
Answers deflect tickets. Actions resolve them. In Agentforce terms, that means attaching Flows, Apex classes or prompt templates as tools the agent can call. The address-change agent needs one Flow with three inputs (order ID, new address, verification token) and a hard rule about when it may run.
Put limits on anything that moves money or inventory. A refund Flow capped at $50, with everything above that routed to a human approver, gives you the volume benefit without open-ended liability. This is the dividing line between agents that do the work rather than just talk about it and the ones customers learn to route around.
Step 5: Break it on purpose before customers do
Write 25 test conversations and make at least a third of them hostile or messy:
- Multi-intent messages (“change my address and where’s my refund?”)
- Typos, abbreviations and mixed languages
- Customers who change their mind halfway through
- Attempts to talk the agent out of its rules (“my manager said it’s fine”)
Score each one for task completion, factual accuracy and whether it escalated at the right moment. Anything below 80% on a category means the instructions need another pass, not a different model.
Step 6: Launch somewhere private first
Before any customer meets your agent, put it in your own support team’s Slack channel for two weeks. Real agents will stress-test it with real cases, and you’ll collect a gap list without a single CSAT hit. Salesforce has been pushing hard on this surface, with a broad set of AI features landing across Slack, which makes internal deployment the cheapest pilot channel you have.
When you do go external, pick one channel. Embedded service chat or messaging, not both. One channel means one set of transcripts to read every morning.
What the numbers should look like by week four
Track five things weekly and nothing else at first: total conversations, containment rate (resolved without a human), escalation quality (was the handoff appropriate?), average handle time on escalated cases, and CSAT split between agent-handled and human-handled conversations. A sensible first target is 25-30% containment on the single task you chose, with CSAT within half a point of your human baseline. Teams benchmarking across the market often see similar containment numbers from dedicated support-agent platforms, so anything far above 40% in month one usually means your test set was too gentle.
Where first rollouts quietly stall
Three patterns account for most agent projects that lose momentum after a promising pilot.
Scope creep. The agent handles address changes well, so someone adds billing disputes in week five. Containment drops, escalations spike, and confidence in the whole programme falls with it. Add one capability at a time and keep the previous ones in regression testing.
Nobody owns the instructions. Instructions drift out of date the moment your returns policy changes. Assign one person to review prompt and Flow logic monthly, and treat it as a maintenance task with a calendar entry rather than a project.
Comparing against the wrong baseline. Your agent isn’t competing with a perfect human. It’s competing with a 5-minute-40-second handle time and a queue that backs up every Monday morning. Measure against that, and week four will look a lot better than the spreadsheet you built in week one suggested.