Change Comms that Create Pull

Mandates create compliance; stories create pull

Nearly every AI rollout is announced the same way. A leader sends a message that the new tool is "now available," lists its capabilities, links to a training deck, and asks everyone to "explore how it can help your workflow." Three weeks later, licenses sit unused, the same forty percent of early adopters are doing all the experimenting, and the rest of the organization has quietly decided this is optional. The communication was not wrong. It was pushing capability at people who had no reason to change what already works, and capability is not a reason. A reason is watching someone at the next desk finish in twenty minutes what used to eat their whole afternoon.

Pull is the difference between people you have to chase and people who come asking for access. It is engineered, not lucky. It comes from making the value of the change concrete, personal, and visibly earned by a peer rather than promised by leadership. The unit of persuasion is not the feature list; it is the before-and-after story told with a real piece of work, from a real colleague, in language the audience already uses. Get that right and adoption stops being a campaign you run and becomes a current that carries new users in on its own. Get it wrong and no amount of reminder emails will move the number.

There is a practical reason pull outperforms mandate, and it is not soft. Adoption of a tool is a change in habit, and habits change when the perceived reward is immediate and the perceived risk is low. A capabilities announcement raises the risk (a new tool to learn, a chance to look slow in front of peers) without making the reward concrete, so the rational move for a busy person is to wait. A peer story inverts that math: it shows the reward is real and already claimed by someone ordinary, which lowers the felt risk of trying and raises the felt cost of staying behind. That is why the same rollout, told two ways, produces adoption curves that are not close.

Engineer pull with proof, not promises

Design change communication around five levers, each of which converts a passive announcement into an active reason to try. The through-line is proof: every message should let the reader see a specific person like them getting a specific result, so the natural next thought is "I want that." Sequence the levers so credibility builds before you ever ask for broad adoption.

Worked example. A 600-person services firm rolled out an AI drafting assistant. The launch email drove 9 percent of staff to activate in the first two weeks, and it stalled there. The team scrapped the "capabilities" approach and switched to pull. Each week they published one 150-word story: a named consultant, the specific task ("scoping memo for a mid-market client"), the honest before-and-after ("2 hours to 25 minutes, then 10 minutes of editing"), and one line on exactly how to start, with a Friday setup offer. They rotated the storytellers across teams so every function saw someone like them. By week four, activation had climbed from 9 to 34 percent, and roughly half the new sign-ups came from an unsolicited "can you set me up too" reply rather than a manager's nudge. The messages were shorter and less frequent than the original plan; they simply carried proof instead of promises.

Turn your rollout into a pull engine

• Recruit five credible early adopters across different functions and capture one honest before-and-after story from each, with real numbers and the rough edges left in, so the wins read as true rather than staged.
• Rewrite every announcement to lead with a peer outcome, not a capability; the subject line should name a person and a result, not the tool.
• Make the try path one reply and one deadline: "reply and I will set you up by Friday" beats "explore the portal" every time because it removes the friction of self-serving.
• Run an eight-week cadence of one fresh story per week, rotating storytellers across teams so every audience sees someone who looks like their own job succeeding.
• Publish adoption progress as social proof ("34 percent of the team is now drafting with it") so the fence-sitters feel the pull of a moving crowd rather than a top-down order.

Why well-meaning rollout comms fall flat

• Leading with capabilities instead of outcomes. Feature lists inform but do not motivate. Fix: open with a peer's concrete before-and-after and let the capability be the explanation, not the headline.
• Using vendor benchmarks as proof. People discount corporate and vendor claims. Fix: replace every external statistic with a named internal colleague's result on real work.
• Over-polishing the stories until they read like marketing. Perfect wins feel fake. Fix: keep the friction in ("it got the tone wrong twice, then nailed it") so the story stays credible.
• One big launch and then silence. Adoption is a habit, not an event. Fix: sustain a weekly drip for at least eight weeks so the change stays visible while habits form.
• Mandating use to force the number. Compliance is not adoption and it breeds quiet resistance. Fix: make trying easy and desirable, and let visible peer success do the persuading.

Ship these this week

• Five named before-and-after stories captured from real early adopters, with honest numbers.
• Every announcement rewritten to lead with a peer outcome in the subject line.
• A one-reply, one-deadline access path replacing "explore the portal."
• An eight-week story calendar with a different storyteller each week.
• A running adoption figure you can quote back to the organization as social proof.