Add Slack broadcast learnings to handbook

contents/handbook/marketing/slack-messaging.md

@@ -19,29 +19,49 @@ Broadcasts go to every shared customer and partner channel, so they're best rese
 - [Maintenance and incident comms](/handbook/marketing/incident-comms) where customers should be aware of disruption.
 - Invitations to betas, events, or programs aimed at existing customers.
 
-Because every customer sees the same message, keep broadcasts infrequent and high-signal. If a message is only relevant to a subset of accounts, it's usually better to let the account owner share it directly.
+Because every customer sees the same message, keep broadcasts infrequent and high-signal. As a rough guide, **no more than one broadcast every couple of weeks** as it's easy to tip over into spamming people. If a message is only relevant to a subset of accounts, it's usually better to let the account owner share it directly.
 
 ## Check with Sales before sending
 
 Broadcasts reach live customer and partner channels, and Sales or the TAMs may know of sensitive accounts that should be excluded from a particular comm. Always give them a chance to flag any before you send:
 
 1. Share a brief update in <PrivateLink url='https://posthog.slack.com/archives/C090RCG671C'>#group-cs-sales-support</PrivateLink> describing the comm you're about to send and who it will reach.
 2. Allow at least **24 hours** for salespeople and TAMs to respond with any accounts that should be excluded or any other concerns.
-3. If no feedback is received within that window, go ahead and send your comm – you don't need to wait for explicit sign-off or be blocked.
+3. **Ping more than once.** A single message is easy to miss. Follow up a couple of times, and give a final heads-up with the scheduled send time (e.g. "this is going out at X") so people have a last chance to flag anything.
+4. If no feedback is received within that window, go ahead and send - you don't need to wait for explicit sign-off or be blocked.
 
 This step is required, but it keeps PMMs unblocked while giving the people closest to our customers a simple way to catch anything sensitive.
 
+### Excluding channels before you send
+
+Beyond accounts that sales or CS flags, scan the audience yourself for channels that shouldn't receive the message:
+
+- **Drop legacy and archived channels.** Pylon's audience often includes old or inactive channels. They're usually obvious from the name – exclude them so the message only lands in live channels.
+- **Check for recent negative sentiment.** It's worth quickly asking an LLM to scan the `#posthog-*` channels and surface any negative sentiment from the last two weeks. This usually turns up a handful worth excluding.
+- **Consider excluding people already using the feature.** If the broadcast is nudging people towards something, exclude accounts that already use it – or word the message so it still works for them (e.g. framing it as "in case you missed these features" rather than assuming they haven't seen them).
+
 ## How to send a broadcast in Pylon
 
 1. Log into the [Pylon admin](https://app.usepylon.com/) using SSO with your PostHog email address.
 2. Find the broadcasts feature in the Pylon UI and create a new broadcast.
 3. Select the audience – typically all customer and/or partner Slack channels. Double-check the audience before sending, as the message goes to live customer channels.
 4. Write your message. Keep it short, friendly, and link out to the [changelog](/changelog), blog post, or docs for the full detail.
-5. Preview, then send.
+5. **Send the message as yourself, not as PostHog.** Pylon lets you choose the sender - sending from a real person feels more personal and gets a better response than a faceless company message.
+6. Preview, then send.
 
 ## Before you send
 
 - **Write copy that follows our [style guide](/handbook/content/posthog-style-guide).** These messages land in customer-facing channels, so they should read like a helpful heads-up from a teammate, not a press release.
+- **A light, self-aware tone works well.** Leaning into the fact that it's an automated broadcast (rather than pretending otherwise) tends to land well and pre-empts any "stop spamming us" reactions.
 - **Link, don't dump.** Point people to the canonical source (changelog, blog, docs) rather than pasting long updates into Slack.
 - **Coordinate with related comms.** A broadcast usually accompanies an email and/or in-app announcement. Make sure timing and messaging are consistent across channels.
 - **Remember the audience is live customers.** Once sent, a broadcast cannot be unsent from people's Slack, so review carefully.
+
+## After you send
+
+Broadcasts generate replies, and how they reach you isn't always obvious:
+
+- **Replies land in a thread in your private Slackbot**, which isn't shareable with the rest of the team. If a customer replies *outside* the thread in their channel, you won't see it at all unless you're already a member of that channel.
+- **Expect a lot of questions.** Use judgement on what to answer yourself versus what to hand off:
+  - Simple, generic questions (e.g. "where can I read more?") are fine to answer directly.
+  - Account-specific questions (e.g. "how would *we* use this?") are usually better routed to the account's TAM or CSM, who have the context to answer well.