Claudeforce Gave Every User Their Own Salesforce. Who's Going to Teach Them?

Section 1: Why Salesforce Just Let Your Users Leave Salesforce

A few weeks ago I watched a video in which someone built a working CRM in an afternoon. No developers, no implementation partner, no twelve-month programme. They described what they wanted to Claude, and by the end of the video they had contacts, deals, a pipeline board and automated follow-up emails. It was rough around the edges, but it worked. What stayed with me was not the build. It was the comments underneath. From people clearly running sales teams, asking the same question in slightly different words: why are we still paying for Salesforce?

That is an uncomfortable question for anyone who works in this ecosystem, and the easy response is to dismiss it. A CRM built in an afternoon is not a platform that runs a global service operation, and a five-person sales team was never the heart of Salesforce's market. All true. But it misses what the question is really about. Those people are not asking whether Claude can replace Salesforce's database. They are asking why working in their CRM feels so much harder than talking to an assistant that simply understands what they want.

Salesforce's answer is the interesting part, because it did not fight the question. With Claudeforce, and the wider AIforce layer launched at Dreamforce, Salesforce has effectively said: you don't have to come to us any more, we will come to you. Your data, your permissions and your business logic stay where they are, but your people can reach them from Claude, from Slack, from wherever they already spend their day. And instead of navigating a screen someone else designed, they can describe the view they want and have it built for them.

I want to be fair to this, because there is something genuinely good here, and I have spent more than ten years watching the problem it addresses.

Every organisation I have worked with has some version of the same story. A salesperson who is excellent with customers and hopeless with the system. Not because they lack ability, but because the screens were designed by people who think in objects and fields, while the salesperson thinks in conversations and relationships. Page layouts with forty fields, half of them legacy. Required fields nobody can explain. Three clicks to log a call that took two minutes. Over time people learn to work around the system, and the organisation calls it an adoption problem. It is one. But a large part of it was always an interface problem that had been labelled as adoption.

If a seller can now ask which accounts need attention this week and get a clear answer in plain language, without hunting through list views, a real source of friction disappears. For leaders who have spent years chasing their teams for updates, that matters. Reducing the effort it takes to engage with the platform has always been one of the strongest levers for adoption, and Salesforce has just pulled that lever harder than most people expected.

Here is the part I don't think has been talked about enough. For twenty years, the Salesforce screen has been more than an interface. It has been the shared language of the organisation. When a sales manager said "update the opportunity", everyone in the team pictured the same page, the same stage field, the same next-step box. When an admin redesigned a layout, they were deciding what every user would see and, by extension, what every user would pay attention to. The layout was quietly doing governance work, process work and training work at the same time. It told people what mattered.

Claudeforce keeps the data shared but makes the experience personal. Ten people in the same team can now look at the same pipeline through ten different views, each shaped by what that person thought to ask for. The person who asks good questions gets a good view. The person who asks vague questions gets a confident-looking answer to a vague question, and nobody else can see the difference. I wrote about the permissions side of this after the Dreamforce keynote, so I won't repeat it here. The issue is wider than who is allowed to build what. It is about what happens to consistency when the one thing everyone used to share disappears.

One line from the keynote has stayed with me: the suggestion that a seller on their first day could be almost as productive as experienced colleagues by using Claudeforce. I understand why that lands well on a stage. But productive at what? A first-day seller can certainly produce more output. Account summaries, meeting briefs, follow-up emails, suggested next steps. What they cannot produce is the judgement that tells them which of those outputs is wrong. An experienced seller knows that the close date on a particular deal has slipped four times, that a particular customer says yes when they mean maybe, and that the revenue figure the system offers first is not the one the board looks at. A new starter does not know what they don't know, and a fluent assistant will not tell them.

That is the trade Salesforce has made, and I think it is a reasonable one, provided organisations understand what they are trading. Friction has been removed at the point of access, and the difficulty has moved somewhere else. It has not gone. It has moved from the screen to the person sitting in front of it.

For most of the platform's history, organisations could at least lean on the screen. You could build a sensible layout, train people on it, write a process document with screenshots and be reasonably confident that everyone was looking at the same thing. When every user can design the screen they work in, the one thing that was always the same for everyone is gone. And that changes what it means to teach someone Salesforce.

Section 2: Salesforce Training Just Got Harder, and Almost Nobody Is Planning for It

There is a moment I have seen in almost every Salesforce classroom I have ever run. I ask the group to click on the Opportunities tab, and twenty people click on the same tab. Then someone near the back puts their hand up and says, "Mine looks different." I walk over, and within thirty seconds I can see why. They are in a different app, or they have pinned a list view, or someone has given them a different page layout. It is a small moment, and it is easily fixed, because there is a standard to go back to. Everyone else's screen tells me what theirs should look like.

That moment is about to become the norm rather than the exception.

With Claudeforce, users can now reach Salesforce through Claude and build their own views simply by describing them. Shortly after Dreamforce, Salesforce Ben made an observation that I think is the most important sentence written about this so far: personal interfaces will make training users significantly harder, and standard operating procedures and training will have to deal with variables that have never existed before. I agree. But I want to go further, because I think most organisations will draw exactly the wrong conclusion from it.

Let's be honest about what a lot of end-user training has been. In many organisations, it has been navigation training. Where the button is. Which tab to open. The click path from the account to the opportunity to the quote. I have argued for years that demo is not training, and that showing people a path does not build capability. But navigation training did have one advantage. It was teachable at scale. You could write it once, record it, hand it to every new starter, and your support team always knew the answer to "where do I find this?"

Personal interfaces remove that map. You cannot write a click path for a screen that does not exist until the user describes it. Process documents built around screenshots quietly become out of date. A support person can no longer glance over someone's shoulder and know what they are looking at. And the question the help desk receives changes from "where is the button?" to "why did Claude give me this number?" That second question is far harder to answer. It requires understanding what the user asked, which data sits behind the answer, and whether the answer is actually right.

Here is the conclusion I worry organisations will reach. The tool is conversational. People just ask it things. So surely training matters less now? It is an attractive argument, especially for a leadership team looking for savings in the rollout budget. It is also exactly backwards. When the interface did the guiding, users could get by with a fairly shallow understanding, because the screen kept them on the path. When the user does the guiding, the quality of what comes back depends entirely on what they know. Training has not become less important. What it needs to teach has changed, from navigation to judgement.

So what does judgement look like in practice? It starts with knowing what to ask. There is a real difference between a seller who asks Claude to show their deals and one who asks which deals have had no customer contact in three weeks and a close date this quarter. The second question reflects an understanding of how the business manages risk. That understanding has to be taught.

It continues with knowing what the data means. Most mature Salesforce orgs contain several fields that look like revenue, several that look like status, and at least one that everyone stopped using years ago but nobody removed. A user who doesn't know which field the business actually trusts will get a precise answer to the wrong question. In the past, the page layout hid most of that from them. Now it is all one question away.

Then comes knowing how to check. People need habits of verification. Does this answer match what I know about the account? What is it based on? When the stakes are high, should I open the record and look for myself? And finally, knowing when not to trust the answer at all, and to pick up the phone to a colleague instead.

None of this can be taught with a demo. It needs scenario-based training using the organisation's own data, its own field names and its own messy history. One exercise I have found far more powerful than any walkthrough is to give a team a generated pipeline summary that contains one subtle error, and ask them to find it. The discussion that follows teaches more about working with an AI assistant than an hour of watching someone else use one. People learn that the output is a starting point, not a verdict.

This kind of training is slower to design, harder to deliver and impossible to record once and forget. It needs trainers who understand the business and the data, not just the platform. And it is arriving at a time when access to learning is already under pressure. PwC's latest global workforce survey, published at the end of September, found that while use of AI at work rose sharply over the past year, only half of workers said they could access the learning they need, down from almost six in ten a year earlier. The need is growing while the access is shrinking.

The cost of getting this wrong is not dramatic, and that is what makes it dangerous. People who don't trust their own judgement tend to go one of two ways. Some retreat and stop using the tool, which is the adoption problem we already know. Others use it without question, which is a new problem we haven't learned to see yet. Both quietly erode the return on the investment.

So if training has just become harder, and more important than it has ever been, there is a question nobody on the Dreamforce stage answered. Who is actually going to do it?

Section 3: The Salesforce Professional You Need Next Isn't the One You're Hiring For

One of the most-watched Salesforce videos on YouTube at the moment asks a simple question: is a Salesforce career still worth it? Read the comments and you can feel the anxiety. Admins wondering whether AI will do their job. Developers watching agents write code. People halfway through a certification, asking whether they have backed the wrong horse. I understand why that question resonates. But I think the wrong people are asking it.

The more urgent version of that question belongs to the business. If configuration is becoming cheaper every year, and if every user can now build their own view of Salesforce simply by describing it, then what exactly are you paying a Salesforce professional for? And when you next hire one, or bring in a partner to help with a rollout, what should you actually be looking for?

Most organisations still answer that question with a profile designed for a different era. Look at a typical job description or partner brief and you will find certifications, the clouds someone has worked with, the number of years spent building flows and objects. All of that made sense when the hard part of Salesforce was building it. But as the first two parts of this series argued, building is getting cheaper and teaching is getting harder. Claudeforce moves the difficulty away from the screen and onto the person using it, and it changes training from navigation to judgement. A hiring profile built around configuration will find you someone who can add more capability to a platform your people already struggle to use with confidence. That is not a talent problem. It is a briefing problem.

So here is what I would look for instead, based on more than ten years of watching which people make rollouts succeed and which make them look successful.

The first sign is that they ask about your people before they ask about your platform. In the first conversation, the professional you need wants to know how your teams actually work, where they get stuck and what they quietly avoid. They are curious about the sales manager who keeps his own tracker and the service team that logs everything at the end of the week. Someone who opens with what you want switched on is telling you where their attention will go.

The second is that they explain meaning rather than location. Ask them to talk you through your own pipeline, and listen to how they describe it. The person you need tells your users what a field means, why it exists and what the business does with it. That skill was always valuable. Now that the screen location is no longer fixed, it is the only explanation that still holds.

The third is that they design training for variety. They know that a single demo path falls apart the moment someone's interface looks different, so they build learning around realistic scenarios, the organisation's own data and deliberate mistakes. They teach people how to check an answer, not only how to get one.

The fourth is less obvious, and I think it will become one of the most important. They understand that skills are training material. In the Claudeforce world, a packaged skill is a reusable set of instructions that every user who runs it will follow. Whoever designs that skill decides what a good pipeline review looks like, which fields count and what gets ignored. Most organisations will treat that as technical work and hand it to whoever is building. It is enablement work. The person writing your skills is effectively writing your training, whether anyone has called it that or not.

The fifth is that they measure behaviour and confidence, not attendance. Sessions delivered and completion rates tell you that training happened. They tell you nothing about whether people use the platform well three months later. The professional you need will want to know how you will tell the difference, and will be uncomfortable if you can't.

And the sixth is that they are willing to tell you to wait. Sometimes the most valuable thing an adviser can say is that the foundations aren't ready, that the data needs work, or that your teams need to be confident with what they already have before you give them something more powerful. Someone who never says that is selling you speed, not success.

The warning signs are just as easy to spot once you know where to look. Be cautious of anyone who leads with a demo, who promises the whole team trained in an afternoon, who reports success in the number of sessions delivered, or who talks about features for an hour without asking a single question about how your people work. I have seen each of those patterns many times, and they rarely end in the outcome the business was promised.

There is one more possibility I would ask every leader to consider before they start recruiting. The person you need may already work for you. In almost every organisation I have walked into, there is someone who has quietly become the unofficial help desk. Often it is an admin, sometimes a team lead or an operations analyst, occasionally a seller who simply understands the system better than anyone else. People go to them because they explain things in a way that makes sense. Most organisations treat that person as a builder, or don't formally recognise the role at all. Developing them into the person who leads your onboarding is often faster, cheaper and more effective than bringing someone in from outside, because they already understand your data, your history and your people.

Salesforce has spent the last few years making the platform easier to reach than ever before. Claudeforce is the clearest example yet. But reaching the platform was never the hardest part. So when you look at the people around your next rollout, it is worth asking honestly: do you have someone whose job is to make your team better at using Salesforce, or only people whose job is to make Salesforce do more?

==============================================================

Every new Salesforce capability gets a launch. Very few get a plan for the people who have to use it. If Claudeforce is coming to your organisation, the Salesforce Enablement Blueprint gives you a structured training system to prepare for it: needs analysis, training design, delivery support and aftercare, built around how your teams actually work. find more information here