Give Your Salesforce Team Claude First, Because Every Other Rollout Waits on Them

The usual plan for an AI rollout starts with the people closest to revenue, which in a Salesforce company means sales. I agree that sales should be the first business team to use Claudeforce. But there's a team I'd give it to before them, and it's the one that will be asked to make the sales and service rollouts work: your Salesforce administrators and developers.

Every Claudeforce rollout needs customization for your environment.

The ready-made skills in the Claude plugin will get a sales team started, but they're generic. Within a few weeks, the sales team will want skills built around how your company works, like a renewal review or a plan for a national account. Service will need agents set up with the right fields, the right rules about what they may change, and a clean handoff to a person. Somebody has to connect Claude to the systems Salesforce doesn't hold. All of that is work for your Salesforce team.

That team already has a backlog other departments are waiting on, and the requests in it have been waiting because something more urgent kept arriving. If Claudeforce work goes to the end of that queue, the rollout waits behind everything already in it. If it goes to the front, everyone else waits longer. Neither is a good outcome, and both are avoidable if the team gets faster before the requests arrive.

Claude makes the build work faster, and the review work stays where it is.

There are two tools I'd put in their hands. The first is Agentforce Vibes, Salesforce's own coding tool, which is built into Setup and uses Claude by default. A developer describes the change in plain English, it reads the organization's existing configuration and code, proposes a plan, and then writes the change for a person to review. As far as I know from Salesforce's documentation, it doesn't deploy anything unless someone asks it to. The second is Claude Code, Anthropic's coding tool, which developers can connect to the Salesforce command-line tools they already use.

What shouldn't change is how work reaches production. The code that Claude writes gets reviewed, tested in a sandbox and released the same way as code a person writes. I'd be clear with the team about this from the start, because faster building creates pressure to skip the slow steps, and a skipped review means mistakes reach production faster too.

There's a link to the first post in this series here as well. Your administrators have the widest access in the company, so Claude working on their behalf can see and change more than it can for anyone else. Doing this work in a sandbox, which is where it belongs anyway, keeps that access away from live customer data.

Watch the age of the oldest item in the backlog, not the size of the backlog.

The obvious measure is how many items are in the backlog. The trouble is that the count can drop because the team clears a batch of easy requests while the hard ones the business is waiting on stay where they are.

The age of the oldest item is harder to improve by accident. If that request was opened two quarters ago and the oldest item a few months from now was opened last month, the team is getting through the work other departments have been waiting on. That's the change that makes the sales and service rollouts possible, so it's the number I'd report to the executive who owns the program.

Start them the week the program starts, before the sales pilot.

My recommendation is to give your Salesforce team access as soon as the program has an owner, and before the first sales team gets the plugin. By the time sales asks for its first custom skill, the team building it has had a few weeks with the tools and has started clearing the queue in front of it.

The last post in this series is about the numbers to ask for at the end of each stage, so you know when one step is finished and the next can start.