大多数审批流程都以同样的方式失败。没人反对这个想法。然后审核人缺席两天，三条帖子错过了发布时段，有人开始问能不能自己直接发。
所以这篇文章讲的不是怎么打开审批，而是怎么把审批运转起来：谁审核什么，一次审核该花多长时间，以及在审批晚于计划时间才到的那个周四早晨会发生什么。如果你只想看这个功能能做什么，请看审批工作流页面。这里默认你已经决定要用。
先划清一个界限。审批针对的是团队里占有席位的人。如果审核人是没有账号的客户，请改用审阅链接，详见如何让客户对社交媒体帖子给出反馈。
完整示例：三个人，一个客户
以一家使用 Pro 套餐（含 3 个席位）的小型代理公司为例。
- Maya 是所有者，负责账单。
- Dev 是审批者。他熟悉客户的品牌规范和法律上的敏感点。
- Sam 是 Contributor。他撰写并排期客户的大部分帖子。
周二下午，Sam 写了一条宣布客户春季促销的帖子，排期在周四 9:00。因为他是 Contributor，按钮上显示的是 Submit for Approval，而不是 Schedule。帖子会带着周四的时间保存，但会显示 Awaiting approval 标记，在有人批准之前不会发出。
Dev 收到通知。周三早上，他打开帖子，发现促销是周日结束，而不是周六。他驳回帖子并写下理由：“促销到周日 23:59 结束，不是周六。”帖子带着 Rejected 标记回到草稿，Sam 打开时，会在编辑器顶部看到 Dev 的备注。
Sam 改好日期，再次排期。这算作重新提交，所以帖子又回到待审批状态，Dev 再次收到通知。周四 9:20，也就是计划时间过去 20 分钟后，Dev 才处理到它。这就是那个尴尬的情形。由于时间已经过去超过 15 分钟，Dev 需要选择：Approve and publish now 或 Approve and pick a new time。Dev 知道促销邮件已在 9:00 发出，于是选择立即发布。
如果他在 9:10 打开，也就是 15 分钟的宽限期内，批准后会直接发布，不会再问任何问题。
这个故事里有三点值得照搬：驳回附带了理由，审核人是一个有名有姓的人而不是“谁看到谁来”，延迟审批的规则事先就已知晓。
决定谁审核什么
问题不是“谁资历最深”，而是“这条帖子发错了，谁会最难堪”。
| 如果风险在于… | 审核人应该是… | 原因 |
|---|---|---|
| 品牌语气和风格 | 内容团队的审批者 | 几秒钟就能判断，自己的帖子可以直接发布 |
| 法律、价格或受监管的表述 | 管理员或所有者 | 对这些说法负责的人 |
| 面向客户的准确性 | 客户负责人，担任审批者 | 最接近客户的真实情况 |
| 新来的撰稿人 | 团队里最有经验的人，担任审批者 | 审核同时也是培训 |
审批者可以直接发布，所以担任这个角色的人不用等任何人。只有 Contributor 需要经过这道关卡，Viewer 则完全无法创建帖子。完整的角色列表见邀请团队成员并设置角色。
至少指定两个可以批准的人。只有一个审核人，一天病假就会变成内容冻结。
先定时限，再搭流程
选一个数字，并大声说出来。对计划好的内容，“一个工作日内”就够了。
然后倒推。如果一次审核可能要一天，那么任何内容都不应该在发布时段前不到一天时提交。一个简单的约定：前一天下班前提交。更晚的算是请人帮忙，所有人都应该清楚这一点。
当审核仍然晚了，15 分钟规则是你的安全网，而不是计划。过了这个点，就要有人在延迟发布和重新排期之间做选择，而这不该是审核人在 9:20、客户还在等的时候做的判断。
写出能闭环的驳回理由
驳回备注是作者在关键时刻收到的唯一反馈。它最多可写 2,000 个字符，而且是可选的，所以很容易留空。别留空。
- 不好：“不行。”
- 更好：“对这个账号来说太像推销了。先讲客户故事，把折扣放到最后一行。”
- 最好： 更好的版本，再加上怎样改才能通过，让下一次提交成为最后一次。
驳回也不是判决。帖子回到草稿，作者修改并重新排期，然后再次进入审核。把它当作一轮，而不是拒绝。
常见错误
什么都设关卡。 如果每条即时回复和每次转发都要等审批，审核人就会开始不看就批。把关卡留给计划好的、面向客户的或受监管的内容，让审批者直接发布时效性强的内容。
只有一个审批者，没有备份。 前面提过，这是流程被悄悄放弃的最常见原因。
批准后编辑却没意识到。 如果 Contributor 修改了已批准的帖子并再次排期，它需要重新审批。这是有意为之。提前告诉大家，否则他们会以为工具坏了。
忘了自动化。 由没有发布权限的人创建或编辑的重复排期和 RSS 订阅源，会被设为需要审批，即使他们试图关闭也一样。有发布权限的人可以再把它关掉。如果你想知道为什么某个订阅源的帖子在等待，先从这里查起。
用审批流程对待客户。 没有席位的客户不能成为审批者，为了让他们审批而给一个席位，会占掉你 3 个或 10 个席位中的一个。
以为通知对所有人都一样。 审批提醒遵循每个人自己的通知设置：应用内、邮件或手机。把邮件静音的审批者可能永远看不到请求。请他检查一次。
智能体与集成
如果脚本或 AI 助手通过 API 为你创建帖子，即使账号持有者本来可以直接发布，也可以在创建时把 requestApproval 设为 true。这样它会像 Contributor 的帖子一样等待，由人来决定。这是让自动化替你准备一周内容、又不让它不经检查就发布的最简单办法。
设置检查清单
- 数一数你的席位。Free 有 1 个，Pro 有 3 个，Business 有 10 个，待处理的邀请也计入上限。
- 邀请成员，并给每个人能完成工作的最低角色。写稿的用 Contributor，审核的用审批者。
- 至少指定两个可以批准的人。
- 约定一个处理时限和一个提交截止时间。
- 决定哪些内容可以跳过关卡，并告诉审批者可以直接发布这些内容。
- 试跑一轮：提交一条帖子，附理由驳回，重新提交，再批准。
- 确认每位审批者都真的收到了通知。
Pro 和 Business 的价格见定价页面。无论帖子发往哪个平台，审批流程的运作方式都一样。
接下来
先从一个客户或一组频道开始，运行两周，看看帖子卡在哪里。在扩大关卡范围之前，先缩短时限或增加第二位审批者。准备好之后，免费开始，升级到 Pro 后再邀请队友。