Change Communication Pipeline: A Persistent Claude Project for Reorg Messaging

What This Builds

A single, persistent Claude workspace that holds the facts, tone, and prior drafts of one specific change effort, so every new communication in that effort (manager talking points, an all-hands script, a manager FAQ) starts from the same shared understanding instead of you re-explaining the reorg from scratch in a new chat every time. Draft two lines up with draft one because they were built in the same place.

Nothing built here sends itself. Every draft still goes through your review and a named sign-off before it reaches anyone.

Prerequisites

• A specific change effort in progress or about to start (a restructuring, a leadership change, a team merger) with facts that are settled enough to write from
• A Claude account on a plan that supports Projects
• Total ongoing cost if you do not already have this: $20/month for Pro, which includes Projects
• Roughly an hour to set up the Project's instructions and starting knowledge before your first draft

The Concept

A Claude Project is a dedicated workspace, not just a chat. You load it once with the facts of the situation, the tone you want, and the language that has already been approved, and every conversation you start inside it remembers that context automatically. It works like a project binder that a new communication draft can be pulled from anytime, instead of you carrying every detail in your own head across five separate conversations over three weeks.

Build It Step by Step

Part 1: Create the Project and write its instructions

1. In Claude, create a new Project and give it a name tied to the specific change effort, not a generic one (so you are not tempted to reuse it for an unrelated situation later)
2. In the Project's custom instructions field, write something like: "You are helping draft internal communications for [describe the change in one sentence: a team restructuring, a leadership transition]. Tone: direct, calm, and specific. Avoid corporate euphemism. Every draft must state what is changing, when, and who to contact with questions. Do not speculate about facts not provided in this Project's knowledge. Refer to affected people by role, not by name, unless I explicitly provide a name for a specific draft."
3. Save the instructions

What you should see: A Project home screen with your instructions saved and ready to apply to every new conversation started inside it.

Part 2: Load the knowledge base with role-labeled facts

1. Write a single reference document with the settled facts of the change: what is changing, the timeline, the business reason, and the key messages leadership has approved
2. Use role labels instead of names ("the manager of the East region team" rather than a person's name) and leave out anything not yet finalized, like severance terms or exact headcounts, until those are locked
3. Upload this document to the Project's knowledge

What you should see: The document listed in the Project's knowledge panel, available to every conversation you start inside this Project.

Part 3: Draft each communication in its own conversation, inside the Project

Start a new conversation inside the Project for each piece:

• Manager talking points: "Draft talking points a manager can use to tell their team about this change. Include an opening line, three key points, and a way to handle the most likely pushback question."
• All-hands script: "Draft a three-minute script for the leader to read at an all-hands announcing this change, consistent with the manager talking points already in this Project."
• Manager FAQ: "Draft an FAQ covering the six questions managers are most likely to get after this announcement, consistent with the facts and tone already established."

Because every conversation pulls from the same Project knowledge and instructions, the facts and phrasing stay aligned without you pasting the same background into each one.

Part 4: Route every draft through a named review before it moves

Before any draft leaves your hands: send it to your designated reviewer (typically your HR director, your communications partner, or legal counsel for anything touching headcount or severance) and log their sign-off before the draft goes to a manager or leader. Do not skip this for time-sensitive drafts. A fast, wrong communication is worse than a slightly slower, correct one.

Real Example: Three-Week Restructuring Rollout

Setup: A Project called "East Region Restructure" holds the approved facts: two teams merging, a new senior manager layer, effective in three weeks.

Input: Over the three weeks, five separate communications get drafted inside the Project: initial manager talking points, an all-hands script, a manager FAQ, a follow-up email for affected employees, and a 30-day check-in message.

Output: All five stay consistent on the timeline, the business rationale, and even specific phrases ("this reflects our growth in the East region, not a performance decision") because they were drafted in the same context instead of five separate chats.

Time saved: Cuts the review cycle needed to catch contradictions between communications, since the drafts do not drift from each other in the first place.

What to Do When It Breaks

• A draft contradicts an earlier one → Check whether the knowledge document was updated after facts changed. Projects only stay consistent if you update the source document the moment a fact changes, not after the next draft is already written.
• Claude starts speculating about details you never provided → Tighten the Project instructions to explicitly say "do not speculate about facts not provided," and remind it in-conversation if it happens.
• The Project knowledge grows unwieldy after many drafts → Periodically consolidate into a single, current "facts as of [date]" document and remove superseded versions, so the Project always points to one source of truth.
• A name slips into a draft before an announcement is public → Review every draft for names and specific dates before it leaves your hands. Set your own habit of scanning the last line of the review checklist for anything that reads as pre-announcement detail.

Variations

• Simpler version: Skip the Project and paste the background facts into a single long chat instead, if the change effort is small and finishes in a day or two
• Extended version: Add a second knowledge document tracking "questions asked so far, and how we answered them" so the FAQ can grow accurately as real questions come in from managers

What to Do Next

• This week: Set up a Project for whatever change effort is currently active, even a small one, to build the habit
• This month: Build a lightweight template for the instructions field so starting the next Project takes minutes, not an hour
• Advanced: Keep a separate, reusable Project for your general communication voice and approved phrasing, so each new change-specific Project starts from a stronger baseline

Advanced guide for HR Business Partner professionals. Pre-announcement reorg details (who is affected, effective dates, severance terms) are highly sensitive. Keep employee names and specific compensation or severance figures out of the Project's stored knowledge, use role labels throughout, and add real names only in the secure system of record just before distribution, never inside the AI workspace itself.