“可能”和“可以操作”是完全不同的故事。在代理机构经营多个博客时，总会有一天达成以下结论。与其使用新工具，不如好好组合现有工具来解决问题。因此，有一种最常见的组合选择。
- WordPress多站点
- 使用Notion整理账户和规则
- 使用Excel管理博客列表和权限
这种组合一开始看起来相当合理。
选择这种方式的原因很明显
这种组合的最大优点是简单。
- 已经在使用的工具
- 几乎没有额外费用
- 给人“只要我们整理好就行”的信心
换句话说，即使推迟做出新决定，也会给人解决问题的感觉。
因此，许多团队都经历了这个阶段。
但这种方式有一个前提条件
要维持这种结构，必须始终满足一个前提条件。
“每个人都准确理解规则，始终遵守这些规则。”
在现实中，这几乎是不可能的条件。
- 人会变化
- 项目会增多
- 例外情况必然会发生
从这一刻开始，这种组合开始出现裂痕。
文件和规则增多，但稳定性并未增加
每当出现问题时，团队都会这样应对。
- 创建另一个Notion文档
- 添加一条规则
- 发布“一定要检查这个”通知
但有一个重要事实。
随着文件数量的增加，实际运营的稳定性反而会下降。
原因是：
- 不是每个人都会始终查看所有文件
- 规则是习惯而不是记忆
多站点的问题不在于“技术”
WordPress多站点本身并不是一个糟糕的选择。从技术上讲是强大的。
但从代理机构运营的角度来看，它无法回答以下问题。
- 是否可以完全分离每个客户？
- 是否可以仅授予作者所需的权限？
- 是否可以结构化地防止错误本身发生？
最终，多站点是一个需要人不断完善运营政策的结构。
这种结构真正的问题在于“依赖性”
在维持这种组合的过程中，团队逐渐对特定人员产生依赖。
- “这个问题○○最了解”
- “问问那位就行”
- “以前的设置只有那位知道”
这种状态并不稳定。只是还没有发生问题而已。
运营崩溃的时刻总是相似的
这种结构崩溃的时刻通常相似。
- 关键人员离开
- 博客数量超过临界点
- 多个项目同时发生
然后团队意识到。
“这不是因为我们做得不好，
而是最初的结构就不合适。”
因此，这个问题是“运营标准”的问题
这里的重要结论是。
- 不是因为现有工具不足
- 也不是因为实际操作人员不够仔细
而是因为将个人标准设计的工具
强行应用于代理机构运营。
在下一篇文章中，将讨论
从一开始就以不同方式设定标准，
也就是blog.haus是如何起步的。
下一篇预告
〈为什么blog.haus不是“博客工具”，而是“运营系统”〉