AI for internal comms: the announcement is easy, the tone edit is the job

What is a model good for in internal comms, and what is it not?

Most internal comms is logistics. A migration date, a process change, a deprecation, a new approval step. Those messages have a fixed shape, get written twenty times a year, and are exactly where a model earns its place: give it the facts and the audience, get a complete draft in under a minute, and spend your time on the parts that carry judgment.

The remaining messages are the ones that change how people feel about their work, and a model writes those in a register borrowed from a thousand press releases. It opens with enthusiasm it has no basis for, describes decisions in the passive voice, and offers empathy unattached to any action. None of that is a prompt failure you can fix with better instructions. It is what the average of published corporate writing sounds like, and the average is what you asked for.

The six-part shape for any change announcement

1. What changed, including the part people will not like. First sentence. No preamble, no context paragraph in front of it.
2. When it takes effect. A date, not "in the coming weeks".
3. Who is affected, and who is not. Naming the people who can stop reading is a kindness and halves your reply volume.
4. What the reader must do, and by when. If the answer is nothing, say nothing, explicitly.
5. What is not changing. Only the reassurances that are actually true. One false one poisons the rest.
6. Where to push back, and who answers. A named person and a channel, not "reach out with any questions".

Part 6 is the one that gets cut for length and the one that determines whether the message lands as information or as an edict. A change announcement with no route for disagreement produces the disagreement anyway, in DMs you never see.

Before and after, on a deprecation notice

The model's draft, given the facts and asked for an announcement:

Hi team! We're excited to share that we'll be sunsetting the legacy reporting dashboard as part of our ongoing efforts to streamline the analytics experience. This change will allow us to focus our resources on the tools that deliver the most value. We understand that change can be challenging and we appreciate your patience during this transition. Please don't hesitate to reach out with any questions!

Two exclamation marks, one piece of enthusiasm about removing something people use, one apology-shaped sentence attached to no action, and no date. The edit:

The legacy reporting dashboard shuts down on 14 October. If you use it, you lose three reports that have no equivalent in the new analytics view: weekly cohort retention, the account health export, and the custom funnel builder. I made this call because keeping both running costs us roughly a day of engineering a week, and the new view covers the other eleven reports. Support, finance and the exec team are unaffected and can stop reading here. If one of those three reports is load-bearing for your work, tell me in the analytics channel before 30 September and I will keep it running while we rebuild it. Everything else in the new view stays where it is.

Nothing in the second version is softer. It is more specific about the loss, which is why it reads as respectful: it names the three reports rather than hoping nobody notices, and it attaches the empathy to a deadline and a person rather than to a sentiment.

The prompt, and the second prompt that matters more

The first prompt is unremarkable and works:

Draft an internal Slack announcement. Facts: the legacy reporting dashboard shuts down 14 October; three reports have no replacement (weekly cohort retention, account health export, custom funnel builder); reason is one engineer-day a week of maintenance; support, finance and exec are unaffected. Neutral register, no enthusiasm, bad news in the first sentence, name me as the decision owner, end with a named channel and a date for pushing back.

The second prompt is where the message actually gets tested:

Now write the three replies this message will get in the channel, in the voice of the people most affected, including the most annoyed plausible one.

A model is good at this. It will produce the finance analyst asking about the account health export, the support lead who did not realise they were unaffected, and someone asking why this was not raised in planning. Edit the message until those three replies are already answered, then send. This costs five minutes and removes most of the thread.

The five edits a model will not make on its own

• Delete every instance of "excited", "thrilled" and "pleased to share" when the news removes something from someone.
• Move the loss into sentence one, then check that nothing in front of it survived.
• Convert every passive decision into a named one. "It was decided" becomes "I decided" or "Ana decided", which is uncomfortable to write and is the whole point.
• Cut any empathy sentence not attached to an action. "We understand this is disruptive" earns its place only when the next clause says what you are doing about it.
• Add the escalation route, with a name, a channel and a date.

Those five take about ten minutes on a draft that took one minute to generate, which is the real ratio of this work. The generation was never the expensive part.

What does this approach get wrong?

It gets wrong the messages where the content is loss rather than logistics. A team being restructured, a project everyone cared about being cancelled, a colleague leaving. You can run the same structure and the same edits, and the result still reads as drafted, because people who are upset read for evidence that a human thought about them specifically. The cheapest honest version is short, in your own words, without a model in the loop, and followed by conversations rather than a thread.

The second limit is structural rather than tonal. No editing pass fixes an announcement for a decision nobody owns. If you cannot write sentence three as "I decided" or "Ana decided", the message will read evasively no matter how carefully it is worded, and what you actually need is to go back and get the decision owned before you announce it.

How this fits the rest of the job

Announcements are downstream of decisions, so the better lever is usually upstream. Claude Code meeting notes to decisions covers producing a record with a named owner, which is what makes sentence three of any announcement writable. For the recurring, purely logistical end of the work, AI release notes for product managers covers the format that repeats every sprint, and ChatGPT for product managers covers setting up the reusable prompts so you are not rewriting the instructions each time.

On the Builders Camp side, the craft sits in Product Storytelling, a 1 week bootcamp with 2 live sessions and 7 microlessons covering narrative structure, stakeholder persuasion and the written formats this page is about. The system around it, turning repeated writing into a workflow you run rather than rebuild, is what 10x Productivity with AI covers, in 1 week with 2 live sessions and 8 microlessons. If the comms you are writing are organisational rather than product-level, the Product Leadership Track bundles both alongside the operating-cadence material, and the Product Leadership Track runs across 11 weeks.

See the Product Storytelling bootcamp

One thing worth measuring: keep the last five announcements you sent and count the replies that asked a question the message should have answered. That number, not the time it took to write, is the one that tells you whether the editing pass is working.