把重复的那一半交出去，人留在判断、例外和责任上

这张表划走的是「动作」，不是人。一个岗位从来不是由一件事组成的——拆开看，能交出去的只是其中重复发生的那几个动作，投诉、例外、判断、对外承诺一件都没少，而且恰恰是最占人的那几件。所以从这张表推到「该减几个人」，中间那一步是断的。真正会变的是每个人时间的构成：原来大半天花在搬运和等待上，之后大半天花在判断和处理例外上。要不要因此动编制，取决于你的业务量往哪走，不是这套系统能替你回答的问题——我们见到的多数情况，是同样的人接住了更多的量。我们也不建议把「减 N 个人」写进项目目标：这类目标没法公开讲，而不能公开讲的目标落地时一定被消极对待，没有人会认真配合一件用来替代自己的事。反过来做效果好得多——把工具交到员工手里，让他先拿去处理自己手上最烦的那部分。

抵触的根源通常不是怕麻烦，是怕两件事：它会不会替我做主，会不会被拿来考核我。这两件事靠承诺没用，得靠交付方式解决——我们的做法是把它交到员工自己手里，而不是装在他头顶上。交付里包含面向业务人员的培训，教的不是「这个系统怎么点」，是怎么把自己手上那些重复的活儿交给它：批量改文案、整理表格、起草回复、对齐术语与翻译——这些他每天都在做，学会当天就能省出时间。模板、话术、参数也都做成他自己能改的，按自己的习惯调，不必等开发排期；先改出效果的那个人会主动去教别人，这比任何推行力度都管用。上线顺序上还有一条固定做法：先上的一定是替他省时间的那部分，监控与统计放在后面；入口放在他本来就在用的沟通工具里，不要求任何人再登一个新后台。另外，右栏那些「留给人的」要在上线前就讲明白——人知道自己那一半没被动，态度会完全不同。一个人一旦发现这是他自己的工具、能让手上的活儿变轻，就不需要被说服了：他会开始主动要你加功能。

这九类是目前做法最定型、边界最讲得清的，不是我们能做的全部。判断依据从来不是岗位名称，是这件事的形状：有没有一个明确的触发、一段能讲清楚的处理规则、一个明确的出口。制造、批发、外贸、工程、诊所、律所、教育机构，我们都按同一套判据看。对不上任何一条线的，可以从单个模块起步，先做一件具体的事。

不需要，而且先招人往往会把顺序搞反。真正需要的是一个懂业务、说得清流程、并且有权改流程的人——他要能回答「这一步为什么这么做」和「例外该谁批」。技术那一侧由我们交付，交接时培训你现有的技术人员接手；平台那一层是我们自研的，但源码与文档一并交给你，底座是标准技术栈，换一个工程师也能接着改。