The Training Deliverable is Broken. Here’s What We Do Instead.
Ask almost any Salesforce consulting partner how they handle training, and you'll hear some version of the same answer. Training is a deliverable. It gets scoped early, priced by the hour, and scheduled for a specific window near the end of the project, usually right before go-live. A trainer – often someone who didn’t build the configuration – drafts an agenda, blocks off a day or two, and walks your team through a fixed list of topics decided months earlier, back when almost nobody involved actually knew what the final solution would look like.
This is the industry-standard approach to Salesforce training. It is also, in our experience, fundamentally broken.
The Problem with Treating Training as an Event
A fixed-scope training deliverable has to be estimated in advance, which means somebody has to guess, months before the system is built, exactly how many hours of training a team will need and exactly which topics matter most. That estimate becomes a contract line item, and contract line items are notoriously resistant to change. If new priorities emerge during the build (and they always do) adding them means a change order. Everybody hates change orders. So more topics get crammed into the same fixed window instead, and the training event grows heavier and less focused the longer the project runs.
There's also a quieter assumption baked into the fixed-event model, that clients will use the weeks beforehand to prepare, working through Trailhead modules or other pre-reading so the training session itself can move faster. Some consultants call this out in their contracts as a request or even a requirement – ourselves among them. But in practice, that rarely happens, and it's not really anyone's fault. Salesforce development isn't your team's full-time job – that's precisely why they hired a consultant in the first place – and asking them to carve out real prep time on top of a session that's already going to pull them out of their day-to-day is asking a lot. When the big event finally arrives, teams often show up less prepared than the plan assumed.
Worse, treating training as a single event fundamentally misunderstands how people learn. Learning is not linear, and it does not compress well. Organic learning looks different for every person and every organization, and a training program that tries to squeeze that natural process into a single day (or even two or three, if you can afford the cost), and to cover a fixed list of topics, is fighting against how people actually absorb new systems. The result, even when the trainer does everything right, is often disappointing. Nobody walks away from a single all-day session as a confident expert in a new system. That was never realistic in the first place.
The Insight that Changed How We Work
At BrightHelm, over the course of all of our Salesforce engagements, we noticed something that most of the industry seemingly misses entirely: guided testing and training are, at their core, the same activity.
When we walk a user through a feature, showing them where to click, what to enter, and what to expect, that interaction is functionally identical whether the feature has already been signed off or not. If it has been accepted, we call it training. If it hasn't, we call it testing, or more specifically, guided testing, because most client users cannot perform effective user acceptance testing without some direct guidance. The mechanics are the same either way. The only real difference is timing, and whether the functionality in question has crossed the finish line yet.
Once we saw that clearly, treating testing and training as two separate, disconnected line items on a project plan stopped making sense. They aren't two activities, or two isolated events bolted onto a timeline. They're one continuous thread that should run through the entire engagement.
How We Train Differently
So we changed our model. Training and testing are no longer scoped as a fixed number of hours tied to a fixed list of topics decided in advance. Instead, we treat it as a Level of Effort deliverable, calculated as a percentage of the overall project, the same way we've always calculated Project Management overhead. The bigger the project, the bigger the training allocation. And critically, clients are only billed for time actually used. If a session isn't needed, it isn't charged.
Training itself is delivered through recurring office hours sessions, at a cadence appropriate to the project, starting from the very first week of the engagement – even before we've built anything at all. Early sessions cover foundational skills: how to navigate our client portal, how to read a status report, how to be an effective participant in a technical engagement. As the project progresses and functionality gets built, sessions shift naturally to cover what's actually being delivered, with topics tracked as we go. The longer the engagement runs, the more total training time a client receives, and testing simply becomes another topic covered in that same continuous rhythm, guided by the same team, in the same format.
Because this is an ongoing cadence instead of a single scheduled event, we can also be far more responsive. If something new becomes a priority mid-project, we simply cover it in an upcoming session. No change order required.
Just for the record – we still stan an organized, agenda-focused training event. Do you need one? You can have one! We’ll estimate the hours and deliver on budget. But that event can now stand on its own feet when contextualized in a continuous stream of just-in-time enablement across the whole platform and engagement.
Why This Matters More Than It Seems
There's a deeper reason this shift matters beyond convenience. A fixed-scope training deliverable quietly puts a consulting partner and a client on opposite sides of the table. The partner is incentivized to do as little as possible within the scoped hours, since every hour spent training is an hour not spent elsewhere. The client, meanwhile, is incentivized to extract as much as possible from that same fixed pool, since it's the only training they're getting. Neither party is doing anything wrong. The incentive structure itself is the problem.
Level of Effort pricing removes that tension entirely. When training is a percentage of the project rather than a capped deliverable, and unused time is never billed, both sides want exactly the same thing: whatever training will actually make the client's team successful, delivered at whatever pace and depth genuinely serves them.
That's not a minor operational tweak. It's a different relationship. We'd rather work with enthusiastic, informed partners who understand what's being done on their behalf and have real control over it, rather than clients who are simply “consulted at.” Learning is not linear, and neither is a successful Salesforce engagement. Everything about this approach comes from what years of hands-on experience have taught us actually works. We built our process around it because we believe it's simply a better way to help organizations get real value out of their Salesforce investment, starting sooner and lasting longer than a single training event ever could.
Ready to try a different way?
Reach out to us at https://brighthelmpartners.com and let’s start a conversation!
