Agentforce Readiness Checklist: 25 Questions to Answer First

Most Agentforce projects that stall don't stall on the technology. They stall because something upstream of the agent — the data it reads, the knowledge it cites, the process it hands off to, the person who owns it — wasn't ready, and nobody checked before the budget was committed.

This is the checklist we work through before we quote an Agentforce engagement. It isn't a sales qualifier. It's genuinely the list of things that, in our experience across implementations, determine whether an agent ships and gets used or quietly gets switched off three months later. Some of these questions have uncomfortable answers. That's the point — it is much cheaper to find out now.

Work through it honestly. If you can answer most of these clearly, you're in good shape. If you can't answer several in the first two sections, fix those first; no amount of agent configuration will paper over them.

1. Business case — what is this agent actually for?

Question 1: Can you name the single use case in one sentence? Not "improve customer service." Something like "answer order-status questions from existing customers without a human touching them." Agents that are scoped to one job ship. Agents scoped to "handle support" do not.

Question 2: How many times a month does that job happen? If it's a handful, automation won't pay for itself. If it's thousands, you have a genuine case. Pull the actual number from your case or query volume rather than estimating — the estimate is almost always wrong in one direction or the other.

Question 3: What does it cost you today? Handle time multiplied by volume multiplied by loaded cost. You need this number to know whether the project is worth doing, and you need it again afterwards to know whether it worked.

Question 4: What happens if the agent gets it wrong? An agent that misroutes a support ticket is an inconvenience. An agent that misquotes a price, misstates a policy, or gives incorrect regulated advice is a different category of problem. Be clear which one you're building before you start.

Question 5: How will you measure success, and who agrees with that measure? Deflection rate, handle time, first-contact resolution, CSAT — pick the one or two that matter and get the person who owns that number to agree in advance. Retrofitting a success metric after launch never convinces anybody.

2. Data — can the agent find what it needs?

This is where most readiness assessments fail, and it's the section worth being most honest about. An AI agent is only as good as the data it can reach, and it will confidently answer from bad data exactly as readily as from good data.

Question 6: Is the data the agent needs actually in Salesforce? If order status lives in your ERP and nowhere else, the agent can't see it without an integration. That integration is part of the project, and it is often the larger part.

Question 7: Is it clean? Duplicates, half-filled records, free-text fields where picklists should be. An agent reading three versions of the same account will behave unpredictably, and you will struggle to explain why.

Question 8: Is it current? A nightly sync is fine for some use cases and useless for others. If a customer asks "has my order shipped," yesterday's data is a wrong answer delivered confidently.

Question 9: Do you have a single, trustworthy view of the customer? If the same person exists as three contacts across three objects, decide how the agent should resolve that before it has to.

Question 10: Who owns data quality, by name? Not "the team." A person. If nobody owns it, it degrades, and the agent degrades with it.

3. Knowledge — what will the agent actually say?

Question 11: Do you have written knowledge articles, or is the knowledge in people's heads? Agents ground their answers in documented knowledge. If your best answers live in your most experienced rep's memory, that's a content project before it's an AI project.

Question 12: Is that content accurate and current? Go and read ten of your articles at random. If a meaningful share are out of date, the agent will serve out-of-date answers at scale and much faster than a human ever could.

Question 13: Is it written in a way a machine can use? Clear headings, one topic per article, explicit answers rather than implied ones. Content written for a human who can infer context often confuses a retrieval system.

Question 14: What is deliberately out of scope? Write the list of topics the agent must never attempt — pricing exceptions, legal questions, anything regulated. This list is as important as the in-scope list.

Question 15: Who approves knowledge changes? Once an agent is live, editing an article changes what thousands of customers are told. That deserves a review step.

4. Security and permissions — what should it be allowed to see?

Question 16: Have you reviewed your sharing model recently? An agent inherits access. If your permissions are broader than they should be, the agent surfaces that immediately and at scale — which is how quiet data-access problems become loud ones.

Question 17: Is any of the data in scope personal, financial, or regulated? If so, what are the handling rules, and can you evidence that they're being followed?

Question 18: Do you need an audit trail of what the agent said? For most regulated contexts the answer is yes, and it's far easier to design in than to add later.

Question 19: What can the agent change, as opposed to read? An agent that reads is a lower-risk build than one that updates records, issues refunds, or triggers fulfilment. Be deliberate about which you're authorising.

5. Process and escalation — what happens at the edges?

Question 20: What is the handoff to a human, exactly? Which queue, with what context attached, within what time. A handoff that drops the conversation history is worse than no agent at all, because the customer has now explained themselves twice.

Question 21: How does the agent know it's out of its depth? Confidence thresholds, explicit topic boundaries, customer frustration signals. Decide the triggers before launch.

Question 22: Can a customer always reach a person? Not every use case requires it, but you should make that call consciously rather than discovering it in a complaint.

6. Testing and ownership — who runs this after launch?

Question 23: How will you test it before it meets a customer? Assemble a set of real historical questions — including the awkward ones — and check the answers against what a good human would have said. Testing against invented questions tells you very little.

Question 24: Who monitors it in week one, and in month six? Agents drift as products, policies and data change. Someone needs to read transcripts regularly. Name them.

Question 25: What is the rollback plan? If quality drops, who can switch it off, how quickly, and what happens to in-flight conversations? Knowing the answer makes everyone more willing to launch in the first place.

How to read your answers

If you answered sections 1 and 2 clearly, you're in a strong position — the rest is largely design work. If you struggled through section 2 on data, that's your project right now, and it's worth doing on its own merits whether or not you ever build an agent; clean, connected, trustworthy data improves everything else in the org at the same time.

If section 3 on knowledge is thin, that's usually a content and process problem rather than a Salesforce problem, and it's often quicker to fix than people expect once someone owns it.

And if you got through all twenty-five with clear answers, you're better prepared than most teams we speak to. The build itself is the straightforward part.

Where to start

You don't need to solve all twenty-five before doing anything. You need to know which ones you can't answer, because those are the risks in your project, and they're much cheaper to address now than after a build is underway.

If you'd like a second pair of eyes on your answers, our free Org Health Check covers the data, permissions, automation and adoption questions above directly against your org — we run Salesforce's own diagnostics and give you a prioritised view of what to fix first. No cost, no obligation, and you get a written summary either way.