Four Systems, One Word: Untangling a Rollout Before It Confused Everyone

The Setup

A single word — "connected" — carried four different systems, and got one of them wrong.

With the core email-capture feature finally working end to end (see the companion case study on that root-cause fix), the project shifted from "does this work" to "let's roll it out." That shift surfaced a different kind of problem — not a technical bug, but a communication one, and it started with a single word doing too much work.

Leadership had told a stakeholder that a related integration was "connected." It wasn't. That mistake landed on leadership's credibility in a conversation I wasn't part of, and the fallout showed up as a terse follow-up: stop and show me how this actually works before you touch anything else.

The Untangling

Four genuinely separate systems had been getting called the same thing.

Digging into the actual ask revealed the real problem: four different systems had been getting referred to interchangeably, when they were four genuinely separate things. Each could plausibly be called "the email thing is connected," and each meant something different technically. The stakeholder had been told the wrong one of the four was live.

• The native email-capture feature — syncs automatically in the background once a user accepts a one-time consent prompt. No visible interface.
• A separate productivity add-on license — extra features layered on top of capture, gated by its own limited license pool.
• The actual desktop mail client add-in — a visible panel a user has to install, either themselves or pushed centrally by an IT admin. This was the one leadership actually meant.
• A third-party sales engagement tool's own plugin — a completely different vendor's extension that happened to also touch email, with its own separate activity log that looked superficially similar to the others in Salesforce.

The Structural Fix

Explain how it works. Then what needs to happen. Then implement, test personally, and train.

Rather than re-explaining piecemeal, leadership asked for a specific structure going forward: explain how something works, then what needs to be done, then implement, then test personally, then train the team. That ordering — test yourself before you tell anyone else to do it — became the actual standard for the rest of the rollout.

In Practice

Five things had to happen before a single rep got a message.

• Diagnosed which of the two remaining license bottlenecks was real — one had genuinely maxed-out seats; a second turned out to already be resolved, avoiding an unnecessary reshuffle of someone else's access
• Coordinated with the external IT contact to push the correct add-in centrally, rather than each user self-installing inconsistently
• Tested personally before training anyone — added my own account to the configuration, accepted the same consent prompt a rep would see, and confirmed a real, external customer email landed correctly on the right account record, not a synthetic test
• Removed my own test account cleanly afterward, since the point was verification, not permanent access
• Drafted individual, not broadcast, messages to each rep per leadership's specific instruction — explaining what the feature does and doesn't capture (explicitly excluding internal-to-internal email), with a single clear action

The Takeaway

The easier-looking phase was the one with more ways to quietly go wrong.

The technical fix from the first phase of this project was the harder problem to solve. This phase was arguably the easier one to get wrong — not because the systems were complicated, but because plain language ("connected," "the outlook thing," "email tracking") kept collapsing four distinct systems into one, and every collapse created a chance for someone to confidently say something untrue without realizing it.

The Result

Zero reported issues in the first wave — because nothing shipped that hadn't been personally verified.

A rollout that could easily have repeated the earlier "looks fixed, isn't" pattern instead shipped with individually tested, individually delivered instructions, a corrected understanding of which systems were actually live, and zero reported issues in the first wave of rep sign-ups.

What Was Built

• Four-system disambiguation — native EAC capture, productivity add-on license, desktop mail client add-in, and third-party sales engagement plugin identified as distinct
• License bottleneck diagnosis — one pool genuinely maxed out, a second already resolved and left alone
• Centralized add-in push coordinated with external IT, replacing inconsistent self-install
• Personal verification pass — own account added, consent accepted, live external customer email confirmed on the correct record, then access removed
• Individual, not broadcast, rep instructions — scoped to what is and isn't captured, one clear action each
• Stack: Salesforce · Einstein Activity Capture · Outlook Integration · Outreach · Microsoft 365