如何写出成员真的会读的社区公告

大多数公告只换来十一个赞和零个提问，而运营者把这读成了认可。那不是认可。那是一屋子人读完之后、对读到的东西无事可做时发出的声音。

发公告是运营者最常用、也最少被审视的工具。下面是那些成员真的会照做的公告，和那些被一划而过的公告之间的区别。

那道测试题：你是在告知，还是在要求？

动笔之前先想清楚你在做的是哪一件事，因为这是两种完全不同的帖子。

告知型公告改变的是成员知道什么。要求型公告改变的是成员必须做什么—打开某个开关、迁到别处去、在几个选项里选一个、在某个日子出现。后一种能换来注意力，因为无视它是有代价的。前一种要和成员这一天里的所有事情抢注意力，而且通常抢不过—这没关系，只要你一开始就明白这一点。

麻烦从这里开始：你写的是告知型，期待的却是要求型的反应。这就是那种收获十一个赞的公告，然后一个月后你发现，半个社区根本没听说过这回事。

其实大部分事都不该发公告

一有事就想发公告的冲动，规模一大就失灵。什么都发的运营者，等于教会了整个社区：公告是谁也不会留意的背景板。等真正要紧的那一条来了，它撞上的正是这个习惯。

经验法则是：该公告的是那些对人有约束的事，而不是那些让你自己高兴的事。规则变更、价格变更、关停，以及任何带着他们必须赶上的日期的事。除此之外几乎所有东西，都更适合做成一条恰好写得不错的普通帖子。

第一句话就是整条公告

假定没有人会读到第一句之后—因为大多数人确实不会—然后照这个假定来写。

这意味着第一句要扛住变化和日期，它后面的所有内容都只写给想看细节的少数人。“从下月一号起，周一的例会改到 UTC 时间 16:00”，这是一条公告。“关于如何让我们的例会对这个不断壮大的全球社区里的每个人都更好用，我们最近想了很多……”，这是一条公告的暖场表演，而有些人永远走不到正片。

第一句话要最后写。先把整篇写完，找出成员会转述给另一位成员的那一句，把它挪到最上面。如果找不出这样一句，说明你手里还没有一条公告。

写他们会怎样，而不是你做了什么

运营者从里面写公告，描述的是工作。成员从外面读公告，找的是后果。

“我们已经把资源库迁移到了新的结构上”，这是工作。“你收藏的链接现在在‘资源’里—什么都没有被删掉”，这是后果，也是唯一有人需要的那部分。你花掉的力气是看不见的，而且就该这样；一个必须自己把你的公告翻译成后果的成员，多半根本懒得翻译。

只要一件事可能被读成损失，就说明什么被保住了。每一条变更公告背后都藏着一个没人问出口的问题—“我是不是丢了什么”—而不回答它的公告，会在回复里换来同一个问题重复一整周。

发在哪里，决定了谁会读到

位置比文笔管用，而这也正是大多数公告悄无声息地消失的地方。

一条帖子，发在成员真的会看的空间里，署一个人的名字。不要用没人会看第二眼的横幅，不要用页脚的小字，也不要用一个成员从来不去的独立公告区。有截止日期就置顶，日期过了就取消置顶；一条五个月前的置顶帖，是在教大家“置顶的东西都是过期的”，而代价要由下一条来付。

署自己的名字，比听起来要紧得多。以品牌名义发出的公告读起来像政策；同样的字由一个人说出来，读起来像有人在告诉你一件事，而只有后者才会换来值得一读的回复。

只发一次，然后有计划地重复

一条公告只会被读一次，读它的是那些恰好在它落地时在场的人，这群人比你的成员总数小得多。

所以重复不是唠叨，而是算术—尤其当你的成员分布在不止一个时区时，单独一条帖子只能够到当时醒着的那些人。在写第一条之前就规划好两三次不同时段的触达，并且让每一次都比上一次更短，而不是把它重写一遍。

不管用的是那种焦虑的补发—同一条公告再发一遍，顶上加一句“怕你错过！”。它读起来像底气不足，而且会教会大家：你的第一条本来就是可选的。

软件能做什么，不能做什么

值得弄清楚工具到底在哪一环帮得上忙，因为它摆在你面前的那个选择，正是这整篇文章在谈的事。

Mateflow 把帖子和「广播」当成两样东西。帖子活在一个空间里，可以被回复。一条广播最多走三个渠道—「社区内」、「邮件」和「推送」—编辑器给每个渠道各留一份内容：邮件是主题加正文，社区内是一段简短的消息，推送是一行字加一个链接。这种分开正是有用的地方，因为这三者是在完全不同的注意力状态下被读到的。社区内消息还要选一个类型：「公告」、「更新」、「警示」或「提醒」，而老实地选就是这件事的全部功夫所在—如果什么都是「警示」，那就什么都不是。

发送对象是大多数人会漏掉的那个设置。你可以发给全部成员，只发给邮箱已验证的成员，或者只发给最近若干天内有过活动的成员，还能再按空间或访问组进一步收窄。最后这一项才是要紧的：它让你把话说给真正还在这里的人，而不是说给一份把所有已经离开的人都算在内的名单。两个诚实的限制—一条广播的状态可能回来是「部分成功」，也就是发出去了一部分、另一部分没发出去；另外，邮件渠道并非每个套餐都包含。

不舒服的地方在于，它会告诉你结果如何。社区内报告发送数和已读数；推送报告发送、送达和点击；邮件在这三项之外再加打开和退信—而「已发送」不等于真的送达，这本身就是一门小小的功课。大多数运营者从不去看，而这正是那种十一个赞的公告能作为习惯活下来的唯一原因。

永远不该发的三种公告

有三类情况，公告本身就是错误，无论写得多好。

不要公告一种你希望出现的行为。“这里是一个大家互相帮助的地方”，这是一篇关于某条规范的帖子，而不是这条规范的一次实例，而规范是靠你看得见地做出来的，从来不是靠被描述出来的。写成公告，读起来像是在指责大家没有这么做。

不要公告一次清退。公开发帖说某人被移出，等于邀请一场公投，还顺手给了他一群听众；一次、直白、私下处理掉。例外是成员显然会注意到并开始猜测的时候，即便那样也只需一句话，而不是一份卷宗。

不要公告一次重启。让社区复活不是从一条帖子开始的；它从一小群人和一个值得回来的理由开始。向所有已经离开的人公告重启，是把一个安静的社区变成一个公开失败的社区的办法。

另外三件不要做的事

不要公告一件你还没决定完的事。“我们在考虑改到周四”，这会招来一场你不想要、也没法干净收场的辩论。先决定，再公告，然后真心去听—或者干脆先问，并把它称作一个问题，但不要把其中一样打扮成另一样。

不要把日期埋起来。任何带截止日期的事，都把截止日期放进第一句。出现在第四段的日期，就是一个会被它所适用的那些人错过的日期。

不要公告了，然后让它不了了之。你公告过又悄悄放下的事，会比你从来没公告过的事被记得更久，而且它是从一个你看不见的账户里取款。如果它死了，就说它死了。

唯一一条必须写好的公告

有且只有一条公告，在它面前手艺不是可选项，而它恰好是最后一条。

关停一个社区，是上面每一条规则都要收紧的那种情况：一条帖子，发在主空间，署你自己的名字；日期和后果放在第一行；他们的钱和他们的数据会怎样，要说出来而不是暗示；管理员要先私下告知。它也是人们最想把话说软的一条，而把它说软，正是把一场体面的告别变成一场公开抱怨的原因。

如果你能把那条公告写好，别的你都能写—它是同一种能力在压力下的样子，这也是一个相当合理的理由：先拿小事练手。

归结起来

公告不是一种把事情告诉大家的方式。它是在申请成员注意力的一小块，而无论你有没有换回任何东西，这一块都已经花掉了。

所以，把它花在那些对人有约束的事上，把变化和日期放进第一句，写后果而不是写工作，并且刻意挑选渠道和受众，而不是把什么都发给所有人。然后去看看到底有多少人真的读了—这个数字通常令人清醒，也是治那种“发了本不必发的公告”的毛病最快的一剂药。