This is the third in a series on the state of enablement and where it could go next, my takeaways from Learning Technologies 2026 and Docebo Inspire 2026.
At the end of my last post, I said the next wave of AI in enablement isn’t about content, it’s about connecting field behavior to enablement signals. This post is about that next wave.
The first wave made content faster: quicker course creation, AI assessments, instant retrieval. That work is real and the efficiency gains are already visible. But the teams that pull ahead next are building something different: a system that connects sales leaders’ priorities to rep behavior in the field, measures whether the work is actually happening, and pushes the right intervention to the right person at the right moment.
What this adds up to is a behavioral operating system for enablement. I’ll use Behavior OS as shorthand, but the label matters less than the architecture behind it.
Why enablement is stuck
Most enablement teams are still predicated on one question: how do we produce more content, faster? Not for lack of will.
The shift from sales to revenue enablement promised to tie the function to outcomes, but the funding model, the inherited tools, and the way success is measured all still reward content production and completion over outcome ownership. The promise stayed aspirational; the day-to-day stayed the same. Enablement even spends itself competing with organic enablement, the Slack threads and SME 1:1s and recorded calls reps actually learn from, when it should be building on them.
With AI able to absorb the content-production and knowledge distribution workloads, enablement finally has the bandwidth for the bigger job: answering the question sales leaders actually care about. Are our reps doing the work that drives outcomes?
That is a system question, not a content question, and no single system in the GTM stack answers it today. However, plenty of tools that emit those signals are already in place.
And that’s the shift. Not more content, faster, but a system that makes the work visible against the revenue outcome:
- where the behaviors need to be
- where they are today, and whether they’re improving or decaying
- what’s actually closing the gap
Ask most teams how the field is tracking against a competitive priority and the answer is “we’ll build a training series, give us a few months.” Ask a team running this architecture and the answer is “here’s the gap, here’s who’s closing it, and here’s what we’re doing about it this week.”
The architecture
This sounds aspirational, so let’s get tactical.
Below is the Behavior OS diagram that walks through a target-state architecture. Every layer maps to a system category that has real vendors today, but the connective tissue between them, the interpretation and routing in the middle, exists as point solutions rather than coherent infrastructure.
The next part in this series will walk through the technology layer in more detail: what’s available, what’s missing, and what an enablement team can stand up itself before the market consolidates.
To keep this vision concrete, I’ll thread one example through every layer. A sales leader at a data infrastructure company walks into a planning session and says: “We need to win more head-to-head migration deals against our biggest competitor. They’re winning by being faster on POCs and we need to flip that.”
That’s a real priority, but in most enablement orgs it becomes a launch deck, a Rise course or webinar series, and a competitive battlecard. We can do better!
1. Align
This is where the conversation with enablement should start, and where the role of enablement changes the most.
Today most enablement teams operate as reactive content creators. Roadmaps, customer events, GTM strategy, quotas, and forecasting all spell out what field success should look like, but by the time those goals reach enablement they have been flattened into topics measured by completion and consumption.
If this sounds familiar, it’s because it’s built into the design of the system itself.
The goals exist, and their answers live in the data that sales tools already generate.
- CRMs hold pipeline.
- Sales planning tools hold quota.
- Conversation intelligence holds deal motion.
- Meeting outcomes hold buying-committee engagement.
But what does enablement own? Learning data, collateral, and sometimes tools that loosely string together content engagement with a pipeline view. It’s not very compelling or impactful.
Yet the enablement and productivity challenge remains: how do we answer the question, “are we winning more head-to-head against our biggest competitor, and if not, what do we change?” Instead the enablement output stays abstract: “X reps completed the migration training.” But did they do what we asked, and did it work?
Without a system to close that loop, nobody knows, and the usual attempt to close it turns conversation intelligence into another learning object, burying the real signal under the same pass/fail model. The shift in this layer isn’t simply a tool or a new way to view information, it’s redefining the role itself.
Enablement needs to move out of reactive content creation and into data analysis, outcome mapping, and system design. Instead, the job is to partner with sales leaders to translate strategy into a behaviorally specific catalog with measurable outcomes. This gives enablement real opportunity at the start, the middle, and the end of the entire cycle.
Furthermore, the output of that partnership isn’t a course, it’s a set of behaviors, the signals that verify them, and the proof points the field will generate.
Going back to the migration priority: “Win more head-to-head migration deals against our biggest competitor.” This is the strategy, and the opportunity is to align on its three behavior changes:
- Can the seller position the migration advantage in a head-to-head competitive conversation and earn the next technical meeting?
- Can the seller scope and run a focused POC that proves workload value on a compressed timeline?
- Can the seller engage technical decision-makers across multiple teams in the buying committee?
These aren’t abstract skills, they are observable behaviors with field signals that verify them.
But behaviors only matter if the organization agrees on what counts as proof. That agreement is the proof contract: for each behavior, the signals that confirm it happened, the criteria that separate doing it from doing it well, and the false positives that don’t count. If the goal is to improve competitive migration positioning, what signals would demonstrate that the behavior actually happened? Was the positioning detected in the call? Did the customer engage with it? Did it earn the next technical meeting? The behavior catalog plus its proof contracts is the real output of the Align layer.
The same shift applies to technical roles: not “knows Python” or “knows SQL,” but can the SE run the live demo and field the follow-up in front of this customer, and is that still true after the product pivots. Skills have to be behavioral, and they have to stay alive.
The outcome isn’t “can you pitch Feature X?” It’s “can you move deals in stage Y to the next stage faster?” The first is a learning question, the second is a business question. We have to flip the script to build the catalog from the second.
2. Prepare, then apply
Now we move into developing a rep against those behaviors — this has two phases: a controlled Prepare phase off the field, and an on-the-job Apply phase with real customers.
The five-stage pattern
The pattern is recognizable in sports training, and since we’re rolling into summer, I’ll use baseball as my analogy.
Think about becoming a better hitter in baseball. You don’t start by stepping into the box. First you watch games. You study the mechanics. You see how pitchers attack the strike zone, how good hitters adjust between at-bats. That’s Learn.
Then you take swings in the cage, off a tee, in a batting practice round. You’re not in the game yet, and nobody’s keeping your stats. You’re building muscle in a safe place where you can fail and adjust. That’s Practice.
Then you face live pitching in a scored tryout, with a coach deciding whether you’ve earned a roster spot. You clear the bar or you don’t. That’s Prove.
Then the season starts and you take a real at-bat with the game on the line. You did it for real, once. That’s Do.
Then you do it again across a full season, the league adjusts to you, and you adjust back. That’s Maintain, the hardest part, and the part that actually wins seasons.
A concrete example: Sarah
The same shape applies to a real rep on a real deal. Take Sarah, an AE on the data infrastructure team, working the competitive migration priority from earlier.
Before her first competitive call, Sarah doesn’t sit through a course. She pulls a brief built for this specific account and this specific competitor, drawn from what’s already known about the deal. Knowledge arrives as a just-in-time artifact, not a curriculum. She’s learned the migration positioning.
She rehearses the migration pitch against an AI roleplay that pushes back like a skeptical platform architect, gets a read on where she’s weak, and tightens it before she’s ever in front of the customer. It’s low-stakes by design, and the score is a mirror, not a gate. She’s practiced it in roleplays, with her manager, and against simulated objections.
Then she clears the certification: a scored demonstration against a defined quality bar, graded, pass or fail. She clears it in March, and the badge goes on the wall. She’s proven it by clearing the certification. It tells you Sarah cleared the bar under controlled conditions on the day she was tested. That is real and worth having, but it is not the same as doing the job.
That distinction is the entire reason enablement gets dismissed by sales leadership. The badge says “Sarah can position our migration story competitively” in March. By June, her deals show no competitive positioning, POCs stuck in scoping, no advancement. Nobody flags it. The badge is still on the wall. The space between Prove and what happens next is the gap the whole architecture exists to close.
The first time Sarah runs that positioning with an actual customer, on an actual deal, not in a roleplay and not for a grade, that’s Do. It is where the controlled phase ends and the field begins, and it is the first thing most enablement programs cannot see. Certification is visible. The first real rep is not, unless something is watching the field.
Then she does it again across her pipeline, and when the messaging changes or the competitor shifts, she relearns, reproves, and runs the new version instead of the stale one. That’s Maintain, the hardest stage to operationalize and the one almost nobody runs today, which is why it sits at the strategic frontier. It is also where revenue is won or lost, because a behavior that was proven once and then quietly decayed looks, on a dashboard of completions, exactly like one that is thriving.
Prove is the capstone. Do and Maintain are the proof that never stops. “Sarah passed the exam” is Prove. “Sarah is doing it, it’s working, and she’s still doing it” is Do and Maintain, and that second sentence is the one sales leaders actually care about. It is also the one the next layer has to be able to see.
Prove is the capstone. Do and Maintain are the proof that never stops.
Proof becomes continuous only when behaviors map to identifiable signal hypotheses, which is exactly what the next layer makes possible.
3. Signals
Most of the signals that prove behaviors are happening are already being captured. The CRM logs the deal. Conversation intelligence transcribes the call. The certification system records the pass. The learning platform tracks what content the rep pulled. The data is everywhere. What’s been missing isn’t the data. It’s the deliberate mapping between specific behaviors and the signal patterns that prove them, and that’s what the proof contracts from the Align layer finally make possible.
What’s been missing isn’t the data. It’s the deliberate mapping between specific behaviors and the signal patterns that prove them.
Signals are where the Apply phase becomes visible. Most importantly, they’re where Do and Maintain stop being invisible. They’re how the field becomes a real-time picture instead of a quarterly retrospective. They’re also the foundation everything else in this architecture sits on.
At scale, none of this is human-doable. A sales leader managing a few dozen reps can track behavior patterns in their head. One managing hundreds or thousands cannot. Turning the signal stream into a coherent picture of what the field is actually doing requires a central intelligence layer. That layer is the next major piece of the architecture, and I’ll get into how it actually works in the next post (Part 4).
The signals themselves aren’t new. What changes is which ones matter, how they combine across phases, and what they’re being read for. The proof contracts from Align tell the engine which patterns to look for and which to ignore, and once that filter exists, the signals stop being a flood of disconnected metrics and start being legible evidence of specific behaviors.
Controlled phase signals
The controlled signals come out of learning environments where the conditions are designed, the content is curated, and the test is graded. This is where enablement has historically built its program: the training engine. The LMS, the practice platform, the certification system. The advantage is that everything here is measurable by design.
- Prepare/Learn signals: from the LMS and knowledge tools (content engagement, completions, assessments, certifications)
- Prepare/Practice signals: from AI coaching platforms (roleplay scores, simulation results, scenario performance, practice frequency)
- Prepare/Prove signals: from certification and accreditation systems (who cleared the graded bar, when, and against which standard)
Reps prepare, practice, and prove. Whether any of that connects to outcomes in the field is a different question, and one the training engine can’t answer. Those signals live somewhere else.
On-the-job signals
The on-the-job signals come from Apply, out of the GTM stack. These are systems that were built for sales operations and customer engagement, not for enablement. But the data they capture is exactly what enablement needs to see whether behaviors are happening.
Take Gong (and other conversational intelligence tools) as the concrete example. Organizations have used it for years, but its early trackers were basic: keyword spotting, talk-time ratios, sentiment heuristics. Useful, but limited. AI changed Gong’s capabilities, and therefore changed what the broader ecosystem can do.
Going wall-to-wall with conversation intelligence now gives an organization visibility into every aspect of the customer relationship. Not just whether the rep mentioned the competitor, but which competitors are showing up, which features are being asked about, which objections are emerging, which positioning lands and which doesn’t, and why customers pick one product over another.
Beyond conversation intelligence, the on-the-job signals come from CRM (MEDDPICC, activities, stages, outcomes), meeting outcomes, follow-up cadence, and technical validation. These are all Do and Maintain signals.
Knowing where the behaviors are taking hold and where they’re decaying, day by day, hour by hour, call by call, is exactly the visibility that decides whether the field stays aligned to the strategy or drifts.
The problem is they don’t talk to each other. And without Align in front of them, they aren’t an end-to-end system. They’re a series of data points living in separate silos.
Your LMS doesn’t know whether a rep used the framework you trained them on in last week’s call. Conversation intelligence knows the call happened. The CRM knows the deal moved. None of them know whether that behavior is the one Align said matters.
Nobody on the enablement team, or likely across the sales org, can look at a single screen and answer “is this AE doing what we asked them to do, and is it working?”
But individually, the signals are now precise enough to ground concrete answers.
Take the first migration behavior, positioning the advantage and earning the next technical meeting:
| Behavior | 👍 Yes | 👎 No | ⚠️ Yes, but no |
|---|---|---|---|
| Positioning the advantage | Conversation intelligence detects competitive positioning; technical meeting scheduled. | Positioning isn’t showing up in calls; sellers defaulting to feature talk. | Positioning is happening, but customer isn’t engaging; message isn’t landing. |
| POC scoping | Scoping doc in CRM; milestones land on schedule. | POCs stall in scoping. | POC ran but produced no business-value evidence. |
| Multi-threading | Contacts live across data engineering, platform, security, and finance. | Deal still single-threaded as it scales. | Many stakeholders listed, none with real influence on the decision. |
The feedback is live and behavior-specific, per-rep, per-call, refreshing constantly, not a quarterly checkbox next to “migration enablement complete.”
And each signal can generate a response
- Yes: the behavior is confirmed and the rep is good for the pulse check
- No: This goes to the manager for intervention
- Yes-but-no: Call review and message refinement needed
Every stage is emitting signal as a byproduct of work, at a depth that would have required dedicated headcount five years ago. What does not exist is the engine that brings them together. Nothing takes the behavior definitions from Align, fuses them with the signals every tool already produces, decides which behavior is present and whether it’s working, and routes the right response. That gap is not a capture problem and it is not a tooling shortage. It is a missing engine, and it is the entire reason this needs to be an operating system rather than another dashboard.
The Intelligence Layer, and where Part 4 picks up
That engine has a name in this architecture: the Intelligence Layer. Surfacing signals is the easy half. Interpreting them across every phase and routing the right intervention to the right person at the right moment is the half nobody has built. Doing it without flooding every manager’s inbox with alerts they can’t act on is what makes it hard. It’s where most enablement orgs hit a wall, because there is no product to buy that does it.
Reading the signals at a point in time tells you whether a behavior is present and effective, missing, or present but ineffective. That answers “is it happening right now?” The Intelligence Layer adds the two states no single tool can produce, improving and decaying, which answer “where is this behavior trending over time?” Those trend states are what give the system memory.
The Intelligence Layer doesn’t exist as a vendor category yet. Pieces of it do. Conversation intelligence interprets calls, CRM tracks motion, learning platforms track completion. But no platform sits in the middle and owns the connective tissue between the priorities defined upstream and the behaviors playing out downstream. Every team that wants this today has to assemble it themselves. That’s the strategic frontier.
Part 4 is about how you build it. Given the signals already exist and you can name the states, how do you unify and act on them without drowning every manager in alerts? Which vendors play where, what’s mature, what’s missing, and what an enablement team can stand up themselves before the market consolidates.
A dashboard tells you where you are. An operating system knows where every behavior has been and where it’s going next.
This is part three of a series on what I took away from Learning Technologies 2026 and Docebo Inspire. Part four picks up with how to build the signals engine before someone else owns the category.