We’re six months into our new ABM platform rollout, and while our initial champion—let’s call him Mark—has been phenomenal in driving early adoption, we’ve hit a predictable but painful wall. Every strategic question, every complex workflow configuration, and every “why isn’t this syncing?” ticket ends up routed directly to him. His calendar is a nightmare, our project velocity has slowed, and frankly, it’s creating a single point of failure that makes me very nervous.
I believe we structured this incorrectly from the start. We followed a pretty standard playbook: identify a champion, have them lead training, and be the go-to expert. But we didn’t plan for the “what next?” when the tool moves from early adopters to the entire revenue team (40+ people now). Mark’s deep knowledge has ironically become a bottleneck.
Here’s our current state:
* **Knowledge Concentration:** All advanced troubleshooting, integration nuances, and best practices for lead scoring and attribution sit with Mark. Our official documentation only covers basic “how-to-click” steps.
* **Training Gap:** Initial training was platform-focused, not use-case-focused for different roles (SDRs vs. AEs vs. marketing ops). New hires get a diluted 30-minute overview that leaves them unequipped.
* **No Clear Escalation Path:** Support tickets go to vendor, but internal “how should we *use* this for our unique process?” questions clog Mark’s Slack.
* **Metrics Are Surface-Level:** We track logins and basic usage, but not the health of our internal knowledge distribution.
What I’m looking for are structured, tactical plays to systematically scale knowledge out. I’m thinking about:
* **Creating a “Train-the-Trainer” Framework:** How have you structured this with clear responsibilities and incentives? What materials did you provide to your secondary experts?
* **Documentation Beyond Basics:** What specific internal documents proved most valuable? (e.g., “Here’s how we handle account matching conflicts with our specific CRM hierarchy,” or “Our SLA for updating scoring models based on new content engagement”).
* **Building a Community of Practice:** Did you institute regular internal show-and-tells? How did you get people to attend and contribute without making it feel like extra work?
* **Early-Warning Metrics for Bottlenecks:** Beyond platform usage, what metrics did you track to spot knowledge bottlenecks *before* they stalled projects? (e.g., repeat questions in a channel, time-to-resolution for internal queries).
I’m particularly interested in the change management aspect of *decentralizing* expertise. How did you help your original champion transition from being the sole source of truth to a curator of knowledge, and did they resist?
—Jen
—Jen
You've nailed the core issue: the transition from champion-led to system-supported adoption. That training gap is critical. Your initial sessions likely created "button-pushers," not practitioners who understand the *why* behind workflows for their specific role.
To break the bottleneck, you need to decouple Mark's tacit knowledge from Mark himself. Start by instrumenting his support process. Capture every question he gets for two weeks, then categorize them. You'll likely find 20% of the question types cause 80% of the traffic. Those become the basis for your first real documentation layer: not clicksteps, but decision trees for common scenarios.
Could you build a simple intake form that forces users to classify their issue before reaching out? That data alone would map the knowledge gaps. Then, task a power user from each role (SDR, AE) with co-creating a use-case playbook with Mark, transferring the knowledge outward instead of him just providing answers.
Data > opinions
The trendy playbook never accounts for tribal knowledge becoming institutional debt. You made Mark the high priest of a mystery cult, not the architect of a repeatable process.
Your documentation gap is the real problem. Basic clicksteps are useless. You need runbooks written for the specific failures that happen. When lead scoring breaks, what do you actually check? That's what you document.
Stop trying to clone Mark. Force the team to log every question in a ticketing system for two weeks. The recurring patterns become your new documentation. Mark reviews it once, then it's gospel. If the answer isn't there, the ticket gets prioritized for him to solve and then document. Turns him from a help desk into a system builder.
Good luck getting anyone to actually read it, though.
-- old school