代运营，交付的是过程，不是承诺

01  /  交付定位

先约定交付物，再谈效果

代运营这门生意里，最容易在三个月后崩掉的一环是交付物的定义。客户以为买的是结果——销量、访客、排名；服务方以为卖的是执行——每天按计划发布、按规则写文案、按节奏排版。两边的预期从来没有对齐过，等到第一份月报出来，才发现谈的不是一件事。

可交付、可验证、可复算的东西只有一类：过程记录。具体是四样。第一，发布记录——每条商品的 item_id、标题、描述、价格、发布时间、走的是哪条通道。第二，计划与实际的差额——这一周计划发多少、实际发多少、缺的几条因为什么缺。第三，内容变更记录——哪条商品在什么时候改过标题、价格或图片，改之前是什么。第四，异常记录——哪一天因为什么暂停过，暂停多久，恢复后怎么处理受影响的槽位。

这四样都能被第三方核对，也都能在客户质疑时拿出来。反过来，"这个月流量涨了多少"这类结果指标受平台分发、类目竞争、季节、价格等多重因素影响，服务方能控制的只有其中一小部分。把不可控的部分写进承诺，等于给自己设了一个无法兑现的条件；把可控的部分写清楚，才是能长期做下去的约定。

右栏这五条不是推脱，是诚实。平台侧的分发机制不公开也会变化，任何声称能控制它的说法都不可验证。左栏这五条则是实打实可以做到的，而且它们恰好是客户最该关心的：内容是否合规、节奏是否稳定、数据是否可查。

把交付物定下来之后，报价才有了依据。按条计价、按账号计价、按类目线计价，三种方式对应的工作量不同，但都能从台账里算出来——这个月实际发了多少条、改了多少次、处理了多少次异常，数字都在。没有台账的代运营只能按月收一个打包价，然后靠感觉解释为什么这个月做得少。

还有一个常被忽略的交付物：口径文档。客户换对接人、团队换执行人，口径不在文档里就要重新讲一遍，而每次重讲都会走形一点。文档不需要长，三页就够：标题怎么写、描述分几段、图片至少拍哪几张、售后只能承诺到什么程度。这份文档是代运营能规模化的前提。

02  /  客户隔离

三条隔离线：账号、环境、台账

代运营同时服务几个客户时，最危险的不是量不够，是串。串的方式有三种：把 A 客户的货发到 B 客户的账号上、A 客户的流程改动影响了 B 客户的执行、两个客户的台账混在一张表里分不开。三种串法里，第一种是事故，第二种是隐患，第三种是慢性病——它不会立刻出事，但会让你在半年后完全失去判断能力。

第一条线是账号隔离。一个账号只对应一个客户、一份发布计划、一套类目配额。不要出现"这批货哪个号有空就发哪个号"，理由不是规则，是数据：同一批货分散在两个客户的号上，哪个号表现好、哪批货该补，事后都算不出来。计划按账号切分，客户之间不挪用配额。

第二条线是环境隔离。设备可以服务多个客户，但同一时刻只跑一个；一台设备对应一个 adb 端口，用端口锁排队，拿不到就等，不要两个进程抢同一个端口——抢的结果是互相踢掉，表现为随机失败，而随机失败最容易被误判成流程 bug。驱动必须跑在 Windows 侧，不要绕到 WSL 里，跨层的 TCP 不通会让命令一直超时。界面读取在桌面屏可能失败，先试压缩模式再退回普通读取。

第三条线是台账隔离，也是最容易被省的一条。省它的理由通常是"先跑起来再说"，但台账的价值恰恰在过去时：三个月后客户问"我那批滞销的后来怎么处理的"，只有台账能回答。台账要有客户标识，两条通道写同一本、同一套字段，单一口径。字段至少包含客户、账号、item_id、标题、描述、价格、时间戳、通道来源。

三条线里，环境隔离的技术细节最多，也最容易在扩张时被破坏。一台设备上跑两个客户，图省事；一个端口两个进程抢，图快。这两件事在单客户时看不出问题，在多客户时会以"为什么今天总是失败"的形式出现，而排查成本极高，因为失败是随机的。多设备的并发与分工细节见多设备并行管理。

隔离做到位之后，还有一个好处：能交接。代运营最怕的是执行的人离职，所有口径在他脑子里。三条线都清楚的时候，换一个人接手只需要读三样东西——口径文档、台账、流程文件。这三样都在，交接是半天的事；都不在，交接是一个月的事，而且会掉数据。

03  /  排期与归属

多客户排期：槽位归属是算出来的

多客户并行时，排期不是把每个客户的计划摞在一起，而是先算总量、再分槽位、最后核对归属。三步的顺序不能反，反了就会出现某天某个账号要发六条、而规则上限是两条的情况，到那时只能临时砍，砍掉的还得挨个解释。

先算总量。系统的节奏规则是全局每日 5 到 10 条、单条服务线每日不超过 2 条、每条服务线每周不超过 12 条，发布窗口 09:00 到 21:59，两条之间至少间隔 30 分钟并带抖动。这里的"服务线"不是客户，是类目线。三个客户各两条类目线，就是六条服务线，理论上一天能排十二条，但全局上限是十条，所以必须轮换：今天 A 的两条线和 B 的一条线，明天 B 的另一条线和 C 的两条线。

再分槽位。槽位不是平均分，是按客户的优先级和类目结构分。判断优先级用三条：这个客户本周有没有新品到货、有没有滞销需要靠新流量带、有没有正在跑的促销节点。三条里占两条的优先排前面的时间点。这件事每周做一次，做成一张表，执行的人照着表走，不再临时判断。

最后核对归属。同一份发布计划里，一条商品归哪条通道是算出来的，不是标记出来的——同一函数对象负责计算，所以手机通道和网页版通道同时开着也不会把一条商品发两遍。这件事在多客户场景里尤其重要：如果归属靠人工标记，两个人同时排计划，一定会有一条被标两次，然后发两遍，而重复发布对账号是最直接的伤害。

多客户排期还有一个隐性成本：切换。同一个执行的人，上午跑 A 客户、下午跑 B 客户，中间要换设备、换账号、换素材目录、换口径。切换一次大约损失十几分钟，而且切换后的头两条最容易出错，因为还在上一个客户的语境里。可行的做法是把同一客户的槽位尽量放在连续的时间段里，一天最多切两次。

排完的表要能被核对。核对方式很简单：拿台账按日期导出，和计划表逐条比。差异只有三种——少发的、多发重发的、时间挪了的。三种差异各自的原因要能写出来，写不出来就说明排期表和执行之间有一层没人管。这一层在代运营里是事故高发区，因为它既不属于客户，也不属于执行人。

关于节奏本身的设计，包括间隔怎么加抖动、窗口怎么定、周内怎么摊平，见定时发布与节奏控制。这里只强调一条原则：多客户的排期要能一眼看出冲突——两个客户抢同一个时间点、同一个账号被排了两次、某个类目超过配额，这三种冲突如果看不出来，表就没有意义。

04  /  交付报表

报表给四栏，多一栏都是噪音

代运营的报表有两种读者：客户和内部。两种读者的需要完全不同，混在一张表里，结果是客户看不懂、内部也没法用。分开做，客户那份只放四栏，内部那份按需展开。

客户那份的四栏是：计划与实际的条数、每条的状态、内容变更、异常说明。四栏都能被客户自己核对，不需要专业知识。

四栏之外的东西，比如流量曲线、行业对比、投放建议，可以作为附加页，但不要混进这四栏。原因很实际：四栏是可核对的，附加页是不可核对的，混在一起会让客户分不清哪些是事实、哪些是判断。一旦分不清，任何一条不利的数据都会被当成借口。

内部那份要更细：按客户、账号、类目、周四个维度都能切。切出来看三件事——每个客户的发布量是否在配额内、每个账号的缺口是否集中在同一类原因、每个类目的问询结构是否在变化。这三件事构成下一周排期的输入。台账的字段口径见发布数据台账，两条通道写同一本、同一套字段，是这份报表能自动出来的前提。

报表的时间节奏也要定下来。周报周一上午出，月报次月三号前出，异常当天口头或书面告知。周报看执行，月报看结构，异常看响应。三条里最容易被拖的是异常告知——出了事想先自己处理好再说，结果客户从别处知道了，性质就变了。规则应该是：暂停的那一刻告知，处理完再补原因。

还有一个细节：报表用固定的模板，栏目名不要每期换。代运营换过几任对接人的情况下，模板稳定比内容漂亮重要得多，因为客户会拿着三个月前的报表和这个月的对比。栏目名一换，对比就断了，而对比恰恰是报表最大的价值。

最后一条：报表里不要写结论性的判断，比如"这个类目潜力很大"。判断可以当面讲，写进报表就变成了承诺。报表的定位是记录，判断的定位是沟通，两者混在一起，下一次客户就会拿你的判断来要求结果。

05  /  权限与留痕

权限切三层，每层都留记录

代运营团队一过三个人，权限就必须切。不切的后果不是安全问题，是责任问题：出了事不知道该看谁的记录，因为谁都能改任何东西，改完也没有痕迹。切法按动作分三层，不是按职位分。

三层之外还有一层只读：台账。台账应该对所有执行的人可读，但只有一个人可写。可读是为了让执行的人自己核对，可写只给一个人是为了保证口径一致——两条通道写同一本台账、同一套字段，这件事一旦有多个人维护，字段就会慢慢分叉。

留痕的具体做法不复杂：每次变更写一行记录，包含时间、人、对象、改前、改后、原因。这六项缺一项，三个月后就无法复原当时为什么这么改。很多团队只记"改了什么"，不记"为什么改"，结果半年后看到一堆改动记录，完全不知道哪一次是因为客户要求、哪一次是因为出了问题。

流程层的变更还要加一道验证。改完 YAML 流程，先在测试账号或测试数据上跑一遍，确认能走通再上生产。这里的教训来自一次真实事故：自检曾经污染了生产发布记录，根因是路径解析早于环境变量生效，程序以为在写测试文件，实际写的是生产文件。现在的做法是三条——写生产数据之前留备份文件、自检进程带标记时写生产直接抛错、整轮自检前后对生产文件做哈希比对。这三条不是洁癖，是把"测试影响生产"这类事故从可能变成不可能。

权限切完之后，还要定期看一眼谁有什么权限。人员变动之后权限不会自动收回，这是最常见的漏洞：离职的人还留着价格修改权，新来的人还只有只读。做法很简单，每月一次，把权限表和人员名单对一遍，多的删掉，少的补上。这件事五分钟，但漏一次可能就是一次说不清的改价。

06  /  失败关闭

宁可空一个槽位，不发一条要撤回的

代运营最容易在两种情况下把事故放大：一是不确定的时候继续发，二是出问题之后自动重试。两种做法都源于同一个心理——今天有量要完成。但代运营的账要按季度算，今天少发三条的代价，远小于今天多发三条错内容的代价。

系统的做法是失败时保持关闭。发布前到点复检：用当下的基线重跑一遍合规闸门，不通过就不发。这条规则挡住的是一类特定事故——计划是早上排的，晚上才发，中间价格改了、库存没了、或者同类商品在平台上突然多了一批。复检的成本很低，挡住的却是最容易发生的那类错误。

另一道闸是平台健康闸。它判断的不是这条商品，而是平台侧当前的状态：接口是否正常返回、页面是否正常加载、提交之后是否拿到回执。任何一项异常就暂停发布。为什么这道闸重要，理由很具体：发布失败有两种，一种是有明确报错的，重试即可；另一种是提交发出去了但拿不到回执，你不知道这条到底发出去没有。这时继续往下发，可能出现同一条发两遍，或者一批条目全部卡在未知状态，台账一片空白而平台侧多了一堆记录。

暂停之后不自动重试，是这套做法里最需要坚持的一条。自动重试在异常期间会反复提交同一个动作，第一次是意外，第十次就是行为模式。人工介入的代价是慢半小时，自动重试的代价可能是把一次小故障放大成一次集中提交，而集中提交在账号层面的后果最难处理。

两道闸的顺序也要定：先健康闸，后合规闸。理由是健康闸判的是"现在能不能发"，合规闸判的是"这条能不能发"。如果平台状态异常，无论商品多合规，发出去的结果都不可控；反过来商品不合规时平台正常，拦下来改就是了。顺序弄反，会出现闸门全过、设备空着、于是发出去的情况，而那时平台恰好不正常，回执也没拿到，账上就多了一条状态不明的记录。

这两道闸的能力边界也要跟客户说清：它们只能判断技术层面的状态，判断不了平台对账号的整体态度。账号层面的信号，比如问询突然消失、浏览突然归零，不在这两道闸的覆盖范围里，这类信号需要人看，看到之后该做的是整体降速，而不是继续按计划发。把技术闸当成账号健康的全部，是另一种形式的误判。相关内容见防封控与账号安全。

07  /  准入判断

接新客户前，先问四个问题

代运营的口碑不是靠接得多，是靠接得住。接不住的客户，做三个月双方都难受：你交付不出他要的，他付钱付得没底。所以接之前要有一道准入判断，四个问题，答不上来就先别接。

四个问题里，最容易问漏的是第二个。账号历史不清，等于接手一个未知状态，而代运营的交付是"过程可核对"，前提就是有一个干净的起点。基线留档这件事，花半小时，能省掉后面几个月的解释。

接得住的客户还有一个特征：有明确的对接人。对接人要能拍板三件事——价格能不能改、售后做到哪一步、新品什么时候上。对接人不清的客户，每个决定都要开会，节奏必然拖，而拖的后果在发布上是可量化的：计划四十条实际二十五条，缺口原因是"等确认"。

反过来，什么样的客户应该劝退，也要能说出口。货源一次性、账号状态不明、要求承诺销量、没有对接人，四条里占两条以上，做下去的成功率很低。劝退不丢客户，含糊接下来做砸了才丢。而且这类判断本身是专业度的一部分，愿意说"现在不适合"的服务方，在长期看反而更容易被推荐。

接进来之后的前两周要设一个观察期。观察期内不加量，只按最低节奏跑，看三件事：内容能不能过闸门、设备与环境是否稳定、客户的响应是否及时。三件事都顺，第三周开始加量；有一件不顺，先解决再谈量。这个观察期的成本很低，但它决定了后面三个月是顺着走还是不断救火。

08  /  分工与清单

三个人的团队，按这个顺序分工

代运营团队规模化的顺序，不是先加客户，是先拆角色。一个人做三个客户时，所有事都在一个人身上，做得动但扩不了；三个人做十个客户时，如果角色没拆，沟通成本会吃掉全部效率。拆角色的顺序按动作的耦合度来，耦合最松的先拆。

三个角色里，内容与合规这一层最难替，因为它需要判断力：什么样的标题算重复、哪张图不能用、这条描述漏了哪一段。选品与库存这一层最需要客户信息，通常由对接客户的人兼。发布与台账这一层最需要纪律，适合由最细心的人做，而不是由最懂业务的人做。

角色拆开之后，接口要定清楚。三个接口：清单交给内容、内容交给发布、台账回到选品。三个接口各有一份文件，不要靠口头传。口头传的结果是每次都要重讲，而重讲一次就走形一点，一个月后内容和最初的判断已经对不上。

• 一号一客户账号、发布计划、类目配额都按客户切开，互不挪用
• 环境不抢一机一端口加锁，驱动在 Windows 侧，同一时刻只跑一个客户
• 台账单一口径两条通道写同一本，字段含客户、账号、item_id、标题、价格、时间戳
• 归属靠算槽位归属由同一函数算出，不靠人工标记
• 排期一人做多客户排期只由一个人排，执行的人按表走
• 报表四栏计划与实际、每条状态、内容变更、异常说明
• 权限三层内容、价格售后、流程环境，各层留变更记录
• 流程改动先验证YAML 改动在测试数据上跑通再上生产
• 写生产先备份写生产数据前留备份，自检进程带标记时写生产直接报错
• 失败关闭到点复检不通过就不发，空槽位不算失败
• 异常当天告知暂停那一刻告知客户，处理完补原因
• 准入四问货源、账号历史、售后归属、期望是否落在可控项

清单里最容易被跳过的是"写生产先备份"和"流程改动先验证"，因为它们不产生当天的量。但这两条恰好是唯一能把一类事故变成不可能的措施——不是降低概率，是让它无法发生。代运营的口碑就是靠这类措施撑住的：客户不会因为你多发了三条而记住你，会因为你没有把他的数据搞乱而继续签。

最后说清边界。这套体系能保证的是过程可核对、内容可控制、异常可追溯；保证不了的是平台的分发结果。把这个边界在一开始讲明白，后面的合作才不会被一个不可控的变量拖垮。给客户看的判断标准，可以对照常见问题里关于预期与口径的部分。