自动化运营
把每周重复的碎活交出去，把精力留给理解用户和做判断。
一个人做产品，最容易被偷走的是碎片精力。今天回五封差不多的邮件，明天整理三条差不多的反馈，后天再写一遍差不多的发布文案。单看都不大，积起来很消耗。
自动化的目的不是显得高效，而是把精力从重复动作里换出来，用在理解用户、改产品和做判断上。
如果一个自动化没有省下你的时间，它就是新增的维护负担。
先找重复出现的动作
连续两周记录你实际做了什么，把每周都出现的挑出来。常见的有：
- 用户提交表单后要手工转到表格或数据库
- 常见问题的重复回复
- 发布新版本后写更新说明
- 社交平台的发布文案初稿
- 每周数据汇总
- 反馈分类和打标签
- 用户访谈记录整理
- 付款后发交付说明或使用指引
不要凭印象猜。 真正吃时间的往往不是你以为的那件事。
判断标准：重复 + 可描述 + 可验证
三条同时满足，才值得自动化：
| 条件 | 含义 | 不满足会怎样 |
|---|---|---|
| 重复 | 不是一次性的 | 你花在搭建上的时间收不回来 |
| 可描述 | 你能说清这件事怎么做 | 做出来的结果时对时错 |
| 可验证 | 你能判断结果对不对 | 错了你也不知道 |
只满足一条就先别做。只满足"重复"是最常见的陷阱——事情很烦人，但你还说不清标准，这时候自动化只会把不确定性放大。
先写成 SOP，再交给工具
说不清怎么做的事，任何工具都很难稳定完成。先写一个小模板：
这件事叫：____
目标：____
输入是什么：____
按什么步骤做：____
输出长什么样：____
什么算合格：____写完你会发现两种情况：一种是步骤清楚了，可以交出去；另一种是写不下去,说明这件事本来就靠你临场判断，那就别自动化。
很多时候写 SOP 本身就已经省了一半时间，因为你不再每次重新想一遍。
不要一上来就追求全自动
第一阶段最好的形态是：
先自动完成大部分，你确认最后一步。
这比全自动更稳，也更容易发现问题。比如：
- 工具先把反馈归类，你确认真正的优先级
- 工具先写发布文案，你改成像你自己说话
- 工具先汇总一周数据，你判断哪些数值得看
最不该做成全自动的是直接发给用户的内容。
自动回复答错一次，用户会觉得根本没人看他的问题；自动发出的营销消息措辞不对，损失的是信任。对外的最后一步留给你自己。
值得先做的五件小事
- 反馈汇总到一个地方 ——邮件、表单、群聊，最后都进同一个文件或表格
- 反馈归纳 ——攒到十几二十条以上时，先让工具找出重复模式，你再定优先级
- 发布文案模板 ——把结构固定下来，每次不用从空白开始
- 常见问题回复草稿 ——见最小用户支持系统
- 周报草稿 ——根据本周数据、更新、反馈先生成一版，你补判断，见每周复盘
按这个顺序做的原因是：前两件降低信息丢失，后三件降低重复劳动。 信息丢了补不回来，劳动省不下来只是累。
自动化本身也有维护成本
每加一条自动流程，你就多了一处会坏的地方。控制方式：
- 数量上设上限。 早期五条以内，多了你自己都记不清哪条在跑什么
- 每条都要能看出它坏了。 静默失败比不做更危险
- 写下它在做什么、坏了怎么手工替代。 三个月后你会忘
- 定期确认还在用。 没人看的自动周报，停掉就行
一条你不知道是否还在正常工作的自动流程，等于一个隐藏的谎言——你以为事情被处理了，实际没有。
什么不该自动化
| 不要自动化 | 原因 |
|---|---|
| 用户访谈和一对一沟通 | 这是你理解产品的主要来源 |
| 优先级判断 | 需要你的上下文和取舍 |
| 定价和承诺 | 出错代价高，改回来更难 |
| 需求还在变的流程 | 流程一变，自动化就要重做 |
| 一个月才做一次的事 | 手工做比维护自动化便宜 |
最后一行值得强调：低频的事手工做没关系。 为了一年用四次的动作搭一套流程，是把工作从"做事"变成了"做工具"。
常见错误
凭印象选自动化对象。 做完发现省下的不是主要时间。
说不清标准就上手。 结果时对时错，还要花时间检查。
追求全自动。 对外内容出错的代价远大于省下的时间。
自动流程越堆越多。 维护成本超过节省的时间。
没有失败提示。 静默停了几周才发现。
自动化低频动作。 维护比手工做更贵。
把判断也交出去。 优先级和定价必须你自己定。
验收标准
- 记录过连续两周的实际动作，挑出了真正重复的
- 每条自动化都满足重复、可描述、可验证
- 每条都先写了 SOP
- 对外内容的最后一步由你确认
- 自动流程数量在你能记住的范围内
- 每条都能看出它是否还在正常工作
- 写下了坏掉时的手工替代方式
- 判断类工作没有被交出去
本章动作
记录本周你实际做过的运营动作，挑出重复、可描述、可验证的那一件，写成 SOP，只自动化到"生成草稿"这一步。