Before You Add Claudeforce, Open What You Already Bought

Last week I wrote about Claudeforce — Salesforce's new AI co-worker for sellers, and the 80% of the workforce nobody planned for when it shipped. I said it wasn't a case against AI. It was the training and adoption conversation nobody in the press release and interviews wanted to have.

A week later, that conversation has a much bigger stage to happen on.

Dreamforce opens this week, and Claudeforce will be one of the loudest things on the floor — screens full of it, sessions built around it, a keynote demo that will, in all likelihood, look completely effortless. An AI co-worker that drafts the email, qualifies the lead, updates the record, moves the deal forward, all while a presenter narrates it like it's the most natural thing in the world. Somewhere in the audience, a Salesforce leader will lean toward the colleague next to them and say some version of "we need this." By the time the applause dies down, half the room will already be mentally drafting the business case.

I want to spend a few minutes on why that reaction is so easy to have, and why it's almost beside the point. Not because Claudeforce won't work. It almost certainly will, for exactly the use cases it's demoed on. But "it works in the demo" and "it will work here, in this org, with this data, run by this team" are two very different claims, and the gap between them is where most technology investment quietly goes to die.

There's nothing dishonest about a Dreamforce keynote demo. Nobody is lying to you. But it's worth saying plainly what it actually is: a Salesforce org built for exactly one purpose, run by people who know it intimately, showing exactly the path that was rehearsed. The data is clean because someone made it clean. The fields are exactly the ones the demo needs, and none of the ones it doesn't. There is no legacy process quietly working around a validation rule from 2019. There is no user in the audience of that org wondering which of three near-identical automations actually fires first, or which of two "status" fields is the one that actually matters.

That's not a flaw in the demo. That's the demo working as designed. Every piece of enterprise software has always been sold this way, and it isn't a criticism of Salesforce, or of Claudeforce specifically, to say so. The job of a keynote is to show you the ceiling. It was never going to show you the floor, and it was never going to introduce you to the version of your own org that's been running for six years, through three reorganisations, two platform migrations, and at least one admin who left without writing anything down.

The problem isn't the demo. The problem is how easy it is, watching one, to quietly assume your organisation is closer to that ceiling than it actually is. A polished demo doesn't just showcase a capability — it resets, for a few minutes, everyone's sense of what "normal" looks like. Leadership walks out of that session calibrated to a org that doesn't exist, and every gap between that and the org they actually run starts to feel like a failure that needs fixing with something new, rather than a perfectly ordinary accumulation that needs finishing with something old.

This isn't the first time this has happened, and it's worth remembering that, because the pattern is much easier to see in hindsight than in the moment.

A few years ago, it was Einstein — Salesforce's original push into predictive and generative AI, announced with exactly this kind of ceremony, promising to score every lead and forecast every deal. Plenty of organisations bought in. Fewer finished the configuration work required to make any of it trustworthy, and a meaningful number quietly stopped looking at the Einstein features within a year, not because the technology failed, but because nobody had the bandwidth to keep feeding it well enough to trust its output. Before that, it was CPQ, promising to collapse quoting from days to minutes — genuinely capable, and still, in a large number of orgs, only partially rolled out, running alongside manual quoting habits that never fully went away. Before that, the original wave of Flow automation, which is still, in plenty of orgs today, only about half migrated from the process builder it was meant to replace years ago.

None of these were bad products. Every one of them could do, and still can do, exactly what was promised on stage. What happened afterward was the same story each time: the launch got the attention, the follow-through didn't, and twelve months later a new keynote arrived promising to solve problems that the last keynote's product could already have solved, had anyone gone back to finish setting it up properly.

Claudeforce doesn't need to fail for this pattern to repeat. It can be every bit as capable as advertised and still end up half-adopted in three years, sitting exactly where Einstein, CPQ, and Flow migration sit in a lot of organisations today — not abandoned, not broken, just never quite finished.

There's a reason this keeps happening, and it isn't that organisations are bad at buying software. It's that buying is a single event with a clear owner, a signature, and a date on a calendar — while adoption is a long, unglamorous, ongoing responsibility that belongs to nobody in particular the moment the launch excitement fades. A signature gets celebrated. The eighteen months of quiet follow-through after it almost never does, and things that never get celebrated have a way of never quite getting finished either.

So let’s talk about the floor, as best the data can describe it.

Across enterprise Salesforce estates, somewhere between fifteen and thirty-five percent of what's being paid for sits unused — licences assigned to people who barely log in, add-ons attached at the original deployment that nobody adopted, editions bought for capability that never got switched on. Industry-wide, the average licensed seat runs at something close to half its actual potential use. This isn't a Salesforce-specific failing; it's close to the norm across enterprise software generally. But Salesforce, because it's so often the most heavily customised system in the building, tends to sit on the higher end of that range rather than the lower one.

It's rarely one dramatic gap. It's usually a scattering of smaller ones: an approval process built for a policy that changed two reorganisations ago and never got updated. A duplicate management rule switched on at go-live and never revisited as the business grew into new regions with different data patterns. A forecasting feature demoed once to a sales leadership team that has since turned over almost entirely. A reporting dashboard built for a KPI the business stopped tracking last year, still refreshing quietly every morning for an audience that no longer opens it. None of these individually look like much. Together, they add up to an org that's paying, in full, for a version of Salesforce it's only using in part — and that gap tends to widen every year, quietly, without a single moment dramatic enough for anyone to notice and intervene.

Behind those licences are the people meant to be running them. A survey of more than a thousand Salesforce admins across seventy-two countries earlier this year found that technical debt — the quiet accumulation of quick fixes, half-finished automations, and fields nobody remembers the purpose of — is now the single biggest challenge admins report facing, ahead of everything else on their plate. Nearly a third describe it as high or very high. And in the same survey, despite reporting reasonable satisfaction with the role itself, six in ten admins said they're considering moving out of it within the next two years.

Sit those two facts next to the Dreamforce keynote for a moment. The org on stage has none of that debt. The org watching from the audience, in a meaningful number of cases, is being managed by someone who is already stretched thin holding together what's there, has already been trained once and never again, and is now about to be handed a new capability to configure, govern, and maintain — on top of a backlog that was already the thing keeping them up at night.

None of this is a scandal. Nobody set out to create it. It's simply what happens, gradually, in almost every organisation that's been running Salesforce for more than a couple of years, as people move roles, priorities shift, and the person who understood why a particular feature was configured a particular way is no longer in the building to explain it. It's exactly the gap that a keynote demo, by its very nature, can't show you — because showing it would defeat the purpose of the demo.

Here's the part worth sitting with, because it isn't new, and it won't end with this product cycle.

Every year, the newest capability gets the best-resourced introduction any feature will ever receive. It gets the keynote slot, the internal champion, the executive attention, the line in next year's roadmap deck. Whatever was announced with the same energy twelve months ago gets none of that anymore. It got its moment. The organisation moved on. And somewhere in the org, that capability is still sitting there, half-configured, briefly demoed to a handful of people who have since changed roles, quietly waiting for someone to come back and finish the job that excitement started and attention abandoned.

This is not a story about laziness, and it's not a story about any one team failing to do their job properly. It's a structural pattern, and it repeats because nothing in most organisations is designed to interrupt it. Budget cycles reward new commitments, not the unglamorous work of finishing old ones — a line item for a new platform is an easy story to tell a board; a line item for "finally training people properly on something we bought two years ago" rarely gets the same hearing, even though it's very often the cheaper and higher-return option. Internal comms gets built around launches, not follow-ups, because launches are exciting to write about and follow-through, by definition, isn't news. Leadership attention, like everyone else's, flows toward whatever's newest and loudest — which is a perfectly human instinct, and also precisely the instinct that leaves last year's investment quietly stranded while this year's gets the ceremony.

Claudeforce isn't the cause of that pattern. It's simply this year's most visible instance of it, arriving at the one week of the calendar when the pattern is hardest to see, because the entire industry is, for three days, pointed at the ceiling rather than the floor.

The honest question isn't whether Claudeforce is impressive. By every indication, it will be. The honest question is whether your organisation has actually finished adopting what it bought the last two or three times something looked this impressive — and whether anyone is going to ask that question before the next licence gets signed.

Most organisations have a renewal process. Very few have a review process — a standing habit of asking what's already been bought and how well it's actually being used, on a schedule, before the next purchase gets evaluated rather than after.

That's the structural fix underneath everything above, and it doesn't require a project, a consultant, or a quarter of runway. It requires a decision to look, on a regular cadence, at the gap between what's licensed and what's used, and to treat closing that gap as seriously as the organisation treats acquiring new capability in the first place. The reason so few organisations do this isn't that it's difficult. It's that nobody owns it. Adoption of what's already been bought tends to fall into the gap between the team that purchased it and the team that has to run it day to day, and gaps like that rarely get filled by accident. They get filled because someone decides, deliberately, that they will be.

That decision doesn't need to be dramatic, and it doesn't need to wait for a formal programme to justify it. It can be as simple as adding one recurring item to an existing quarterly meeting: what did we license in the last two years, and what fraction of it is anyone actually using well. The value of asking that question isn't just the answer it produces. It's that asking it at all starts to change the incentives around every future purchase, because a leadership team that knows it will be asked "did we finish the last one" tends to think differently about the next one.

If you're heading into Dreamforce week, or into the budget conversations that tend to follow it, here's where I'd start looking before signing anything new.

- Pull a usage report on your current licence before the renewal conversation, not during it. You can't meaningfully evaluate a new capability against a baseline you don't actually have in front of you.

- Ask who was trained on each major feature added in the last two years, and when. A capability with no named owner and no recent training is, functionally, a capability you don't have — you're just still paying for it.

- Run a short session with your admin or your Superusers before the next new pitch lands, not after. They almost always know exactly what's sitting unused. They're rarely the ones asked.

- Separate "we don't have this capability" from "we have this capability and never finished rolling it out." Budget conversations routinely treat these as the same problem. They aren't, and the fix for each is completely different.

- Before the enthusiasm from this week turns into a business case, make the business case answer one question first: what would it cost to properly finish what we already bought? If nobody can answer that, that's worth knowing before the next signature, not after.

Claudeforce will get its moment on the Dreamforce stage this week, and it will probably deserve it. It's a genuinely capable piece of technology, and none of this is an argument for ignoring it. What deserves equal attention, and almost never gets it, is everything already sitting in your org from the last time something looked exactly this good on a screen — because the organisations that get real value from what's new are, almost without exception, the ones that finished what they already had first.