Salesforce Agentforce readiness is the extent to which an organisation has the data, processes, decision rules, integrations, governance and operating discipline required for AI agents to produce reliable commercial value. A Salesforce environment can be technically capable of running Agentforce while the wider business remains commercially unready. Before implementation, leadership must confirm that the use case is precise, the CRM data can be trusted, the workflow is defined, human escalation is clear and the outcome can be measured.
The Agentforce question is not simply whether Salesforce can deploy AI agents. It is whether the organisation asking those agents to sell, serve, recommend, update or act has built a commercial system worth automating.
What is Salesforce Agentforce readiness?
Salesforce Agentforce readiness is a business’s ability to deploy AI agents into real commercial workflows without exposing unreliable data, undefined processes or weak governance. It is not a simple yes-or-no technical check. Readiness has to be evaluated across the CRM, the wider commercial process, the organisation’s decision model and the systems connected to Salesforce.
Salesforce’s own implementation guidance places strong emphasis on data preparation, use-case definition, grounding, context, governance and testing. That is necessary. It is not sufficient. An agent can have permission to access a record, retrieve an approved knowledge article and execute a Salesforce Flow, yet still produce a commercially poor outcome because the underlying process was never designed properly.
Consider a lead-qualification agent. The technical build may work exactly as configured. But what happens if the company has no agreed ideal customer profile, sales and marketing use different qualification criteria, lifecycle stages are inconsistent, the CRM does not distinguish curiosity from buying intent, and regional teams apply different thresholds? The agent does not repair those disagreements. It applies them faster, or attempts to reason around them.
Technically functional AI can still be commercially useless. Agentforce readiness must therefore be judged by the quality of the commercial system it is entering, not by whether the agent can be switched on.
Why the KeyBanc downgrade matters beyond Salesforce’s share price.
In July 2026, KeyBanc downgraded Salesforce from Overweight to Sector Weight after customer, partner and CIO feedback raised two concerns: many organisations still lack the data foundation needed for useful AI deployment, while Agentforce had not yet demonstrated the product maturity or adoption momentum some buyers and investors expected.
That does not prove Agentforce is failing. Salesforce reported approximately $1.2 billion in Agentforce annual recurring revenue in Q1 FY27, up 205% year on year, alongside 3.8 billion Agentic Work Units across Agentforce and Slack. The commercially important point is the gap between buying AI capability and being capable of using it well.
A board should therefore ask more than what Agentforce can do and what it will cost. It should define the commercial constraint, verify whether the underlying data and process can support the use case, set the agent’s authority and escalation boundaries, and agree how commercial impact will be measured. That may redirect budget towards CRM remediation, data governance, process design, integration or a narrower controlled pilot before a wider rollout.
The four layers of Agentforce readiness.
Agentforce readiness has four connected layers. A project can pass a technical review and still fail commercially because the CRM, workflow or operating model is not ready.
Technical readiness.
Architecture, permissions, integrations, environments, security, grounding, testing, monitoring and auditability must allow the agent to operate safely inside a defined system boundary.
CRM readiness.
Objects, fields, relationships, lifecycle stages, ownership, activity capture, pipeline hygiene and reporting must be accurate and consistent enough for the selected use case. Data volume is not the test. Dependability is.
Commercial readiness.
ICP, qualification, pricing, sales progression, service policy, handoffs, retention logic and operating metrics must provide coherent rules for the workflow being supported. AI cannot stabilise commercial logic leadership has never agreed.
Organisational readiness.
Decision rights, accountability, adoption, training, exception ownership and management rhythm must define how people and agents work together, particularly when confidence is low or the agent is wrong.
The four layers describe where readiness must exist across the organisation. The six dimensions below explain how that readiness should be assessed.
The Agentforce Commercial Readiness Framework.
The framework below assesses six dimensions that must be strong enough for Agentforce to create measurable value. It is intentionally commercial. It does not replace a Salesforce architecture review, security assessment or detailed implementation plan. It identifies whether the business foundations justify that technical work.
Use-case clarity.
Direct test: can leadership define one commercial problem, one bounded job for the agent, the data and actions required, the escalation condition and one measurable outcome? “Use AI in sales” is not a use case. A useful contract specifies scope, exclusions, baseline, target metric, owner and failure response.
Warning signs.
The business case is based on general productivity.
The project contains several departments and workflows before one has been proven.
The team cannot identify what will stop, change or improve after deployment.
Success is defined as number of conversations, prompts or generated outputs.
Customer-data readiness.
Direct test: is the use-case data accurate, current, connected, governed and understandable? Readiness is use-case-specific. Inventory the Salesforce records, fields, documents, events and relationships the agent will use, then set quality thresholds, owners, permitted sources and refresh rules.
Warning signs.
Duplicate accounts and contacts are common.
Required fields are populated inconsistently.
Pipeline stages cannot be trusted.
Knowledge content has no owner, review date or approval status.
Critical context sits in inboxes, spreadsheets or employee memory.
Process maturity.
Direct test: is the workflow already defined, stable, owned and followed? A mature process has a trigger, ordered steps, entry and exit conditions, roles, service levels, handoffs, exceptions and evidence of completion. If the process is unclear, automation scales the ambiguity.
Warning signs.
Different teams use different versions of the process.
Experienced employees rely on judgement that has never been codified.
Handoffs are informal and not measured.
The CRM workflow does not match the buyer or customer journey.
Exceptions are more common than the standard path.
Decision and escalation logic.
Direct test: does the organisation know what the agent may observe, summarise, recommend, draft, update, execute or escalate? Define an authority matrix with confidence thresholds, approval points, exception routes, audit requirements and a named owner for failure handling.
Warning signs.
There is no written distinction between advice and autonomous action.
Human approval is added vaguely rather than at defined risk points.
No one owns false positives, incorrect updates or failed handoffs.
Escalation rules depend on subjective judgement that has not been translated into policy.
Cross-domain connectivity.
Direct test: can the agent access the commercial context needed for the decision? Website, marketing, telephony, product, finance, fulfilment, service and customer-success data may all matter. Map the minimum reliable data and workflow dependencies rather than using an agent to conceal broken handoffs.
Warning signs.
Marketing, sales and service use different lifecycle definitions.
Customer status differs across systems.
Website enquiries enter manual queues before Salesforce.
Pricing or contract data is not available where the agent acts.
Post-sale information does not flow back into account or opportunity context.
Measurement and governance.
Direct test: can the organisation monitor commercial impact, agent quality, adoption and risk against a pre-deployment baseline? Define business KPIs, operational measures, review cadence, incident ownership, change control, pause conditions and human-takeover thresholds before the pilot.
Warning signs.
There is no baseline for the current process.
The project tracks usage but not business outcome.
No owner is accountable for agent quality after go-live.
Testing is treated as a one-off phase rather than continuous control.
There is no agreed threshold for rollback or human takeover.
Score one point for every statement that can be supported with evidence. A confident opinion is not evidence. Use configuration records, data-quality reports, process documentation, dashboards, ownership assignments, test results or observed behaviour.
1. We have selected one precise use case with a named business owner.
2. The use case has a measured baseline and a defined commercial outcome.
3. The users, customers, triggers, actions and exclusions are documented.
4. The required CRM objects, fields, documents and event data are inventoried.
5. Data quality has been profiled for the proposed use case, not assumed.
6. Duplicate, stale, incomplete and conflicting records have remediation rules.
7. Unstructured sources have owners, approval status and review dates.
8. The current workflow is mapped and reflects actual operating behaviour.
9. Entry criteria, exit criteria, handoffs, service levels and exceptions are defined.
10. The CRM lifecycle and pipeline stages match the commercial process.
11. We have defined what the agent may observe, recommend, draft, update and execute.
12. Human approval points and escalation paths are explicit.
13. High-risk actions have a least-privilege access model and audit trail.
14. The minimum required integrations are stable and monitored.
15. Marketing, sales, service and operations use consistent customer and lifecycle definitions.
16. A controlled test environment and realistic scenario set are available.
17. Business KPIs, agent-quality metrics and risk thresholds are agreed.
18. An owner is accountable for monitoring, incidents, change control and improvement.
19. Users understand how the agent changes their role and have been involved in design.
20. Leadership has agreed the conditions for pilot expansion, pause or termination.
0 to 10: Red.
Do not proceed to broad implementation. The programme is likely to automate unreliable data or an undefined process. Run a readiness diagnostic and remediate the highest-risk gaps.
11 to 15: Amber.
A controlled pilot may be justified if scope is narrow, human approval is strong and the missing controls are addressed before expansion.
16 to 20: Green.
The organisation has a credible foundation for a pilot. Technical validation, security review and use-case-specific testing are still required before production.
The score is a decision aid, not certification. A single critical failure, such as ungoverned sensitive data or undefined authority for a high-impact action, can override a high total score.
When not to implement Agentforce yet.
Delay the implementation when any of the following conditions apply:
The business cannot name the constraint. “We need AI” is not an implementation brief.
The CRM cannot be trusted. If users routinely keep the real pipeline outside Salesforce, the agent will work from a partial version of the business.
The process changes by person. Agentic automation should not become a substitute for management agreeing how work should be done.
The use case depends on unresolved policy. Pricing discretion, service exceptions and qualification rules must be clarified before they become machine actions.
No baseline exists. Without current performance data, the programme cannot prove value or identify regression.
The proposed first use case is too consequential. Start with a task where failure is visible, reversible and contained.
Human escalation is undefined. An agent should not discover the organisation’s decision rights during a live customer interaction.
Leadership expects the tool to create adoption by itself. Product enablement cannot replace role design, operating rhythm and accountability.
Delaying does not mean rejecting Agentforce. It means sequencing the investment so the organisation does not pay to automate structural weakness.
Suitable and unsuitable first Agentforce use cases.
Stronger first use cases.
Internal knowledge retrieval with citations: help employees find approved information while keeping the final decision with the user.
Case or enquiry triage: classify, summarise and route requests using defined categories, with monitoring for incorrect routing.
Account and opportunity preparation: assemble CRM context, activity history and open actions before a meeting.
Drafting with human approval: prepare customer responses, follow-up notes or internal summaries based on approved sources.
Data-quality identification: flag missing fields, likely duplicates, stale records or inconsistent status for review.
Next-best-action recommendations: suggest a defined action while preserving human ownership during early deployment.
Weaker first use cases.
Autonomous discounting or pricing exceptions: high commercial impact and often dependent on uncodified judgement.
Automatic lead rejection: dangerous when ICP, intent signals and qualification logic are disputed or incomplete.
Policy interpretation from an unmanaged knowledge base: unreliable content creates confident but incorrect customer outcomes.
Multi-system execution without traceability: failures become difficult to isolate, reverse and govern.
Retention or churn intervention without reliable lifecycle data: the agent may act too late, target the wrong account or miss the real cause.
Executive forecasting from poor pipeline hygiene: adding AI commentary to unreliable opportunity data creates false confidence.
The correct sequence from diagnosis to scale.
Step 1: Diagnose commercial and CRM readiness.
Assess the wider commercial system before selecting a platform configuration. Identify where revenue, service quality or operational time is being lost, then determine whether Agentforce is relevant to that constraint.
Step 2: Select one bounded use case.
Choose a use case with sufficient volume to matter, sufficient structure to automate and sufficiently contained risk to learn safely. Define what is outside scope.
Step 3: Remediate the minimum viable foundation.
Clean the data required for the use case, standardise the workflow, align lifecycle definitions, fix the critical integrations and assign ownership. Do not attempt to solve the entire enterprise before a pilot.
Step 4: Define authority, controls and failure handling.
Set permissions, guardrails, approval points, escalation rules, logging, monitoring and rollback criteria. Decide how exceptions will be reviewed and how learning will be incorporated.
Step 5: Build and test against realistic scenarios.
Use representative data and include difficult cases, missing context, conflicting information, policy exceptions and adversarial prompts. Test both the expected path and the failure path.
Step 6: Pilot with measurable business outcomes.
Run the agent in a controlled area. Compare performance with the baseline. Track quality, escalation, time, conversion or resolution outcomes, not just activity.
Step 7: Scale only after the operating model works.
Expand when performance is stable, ownership is clear, users trust the process, failure handling is proven and the commercial outcome justifies the next investment. Scale should be earned by evidence.
How to measure whether Agentforce is creating commercial value.
No single KPI is sufficient. Use a layered measurement model.
Commercial outcomes.
Qualified-to-opportunity conversion
Pipeline progression
Sales-cycle time
Cost per resolution
Retention or expansion influenced
Revenue influenced by the workflow
Operational outcomes.
Time saved per task
Resolution time
Handoff delay
Queue reduction
Manual steps removed
Employee adoption and override rate
Agent quality and risk.
Task success rate
Grounded-answer accuracy
Escalation precision
Incorrect action rate
Human correction rate
Incidents and rollback events
Conversation volume, generated messages or tasks attempted can describe activity. They do not prove value. The primary business case should connect agent performance to an outcome the leadership team already cares about.
Why Agentforce readiness depends on all ten CTI domains.
The Commercial Transformation Index, or CTI, assesses how the systems behind growth work individually and together. Agentforce readiness is therefore not a CRM-only question. Each domain changes the quality of the data, rules or outcomes the agent can use.
ICP.
Defines which customers should be prioritised, qualified and served.
Positioning.
Provides approved value propositions, claims and differentiated language.
Pricing.
Controls packaging, discounting, approvals and commercial risk.
Marketing.
Supplies source, intent, engagement and lifecycle context.
Website.
Shapes the first structured data capture and commercial handoff.
CRM.
Provides records, ownership, pipeline logic, activity history and reporting.
Sales framework.
Defines qualification, progression, stakeholder mapping and next-action rules.
Operations.
Controls fulfilment, service, exceptions and downstream accountability.
Retention.
Adds onboarding, health, renewal, expansion and recurring-revenue context.
Automation.
Determines whether agent actions connect cleanly into existing workflows and controls.
Where the root problem is unclear, diagnose commercial maturity before committing to Agentforce scope. The first investment may be a domain remediation roadmap rather than an AI deployment.
Should your business implement Agentforce now, later or not at all?
Implement now when a bounded use case has reliable data, a mature workflow, clear authority, a measurable baseline and accountable ownership.
Implement later when the use case is valid but CRM data, process, integration or governance gaps need focused remediation. This is the most common commercially sensible answer.
Do not implement the proposed use case when the problem is not valuable enough, the workflow should be simplified rather than automated, the risk cannot be controlled, or the expected benefit does not justify ongoing ownership and monitoring.
The objective is not to prove that Agentforce belongs in every commercial process. It is to identify where agentic capability can improve the journey from first click to recurring revenue without creating a more expensive version of the existing problem.
What is your CTI Score?
Before commissioning an Agentforce proof of concept, assess the commercial system it will enter. b10 uses CTI to identify where CRM, data, process, handoffs, automation and the wider commercial operating model are ready, weak or disconnected. The output is a prioritised roadmap showing what to fix first and what should not yet be automated.
What is a Salesforce Agentforce readiness assessment?
A Salesforce Agentforce readiness assessment evaluates whether the data, CRM structure, processes, integrations, governance and organisation are capable of supporting a defined AI-agent use case. A strong assessment also tests whether the use case is commercially valuable and measurable.
How do I know if my business is ready for Agentforce?
Your business is more likely to be ready when it can define one precise use case, trust the required data, document the workflow, set clear agent authority, measure a baseline and assign ongoing ownership. Use the 20-point checklist above and treat any critical governance failure as a stop condition.
What data does Agentforce need?
Agentforce needs the structured and unstructured data required for the specific job it will perform. That may include CRM records, activity history, cases, knowledge content, product information, policies or connected system data. Quality and context matter more than raw volume.
Does Agentforce require Data 360?
Salesforce positions Data 360 as a context and governance layer for grounding Agentforce in business data, but the required architecture depends on the use case, product configuration and data sources. Confirm the current technical requirements with Salesforce or a qualified implementation specialist rather than assume one standard design.
Why do Agentforce proofs of concept stall?
Proofs of concept often stall when the use case is vague, the data is unreliable, the workflow is not owned, users are not involved, testing does not reflect real exceptions or success is measured through activity rather than business outcomes.
How should CRM data be prepared for Agentforce?
Start with a use-case-specific data inventory. Profile completeness, accuracy, freshness, duplication, consistency and ownership. Resolve the records and fields that materially affect the agent’s task, then test grounding and actions against realistic scenarios.
What is the best first Agentforce use case?
The best first use case is valuable, frequent, bounded, measurable and reversible. Internal knowledge retrieval, triage, summarisation, preparation and drafting with human approval are usually easier to control than autonomous pricing, rejection or multi-system execution.
How should Agentforce ROI be measured?
Measure Agentforce ROI against a pre-deployment baseline and include commercial outcomes, operational efficiency, agent quality and ongoing cost. Time saved alone is insufficient unless the organisation can explain how that time changes capacity, service, conversion or revenue.
Can Agentforce fix poor CRM discipline?
No. Agentforce can identify, summarise or act on CRM data, but it cannot resolve unclear ownership, disputed lifecycle stages, inconsistent qualification or poor management discipline by itself. Those are commercial operating-model problems.
Is Agentforce implementation an IT project?
Agentforce requires technical delivery, but it should be governed as a cross-functional commercial transformation programme. Technology, sales, service, operations, data, risk and executive leadership may all own part of the outcome.
