那次串号，丢了一个客户
去年有个做代运营的团队跟我讲过一次事故。
他们手上的账号是按客户分组的，但设备是共用的——哪个客户有活，就临时分几台过去。有一次一个运营在赶两个客户的排期，把 A 客户的一个账号登到了 B 客户的设备上。
当时没造成什么损失，他们也没太在意。两周后 A 客户拿着登录记录来问：为什么我的号在这个城市登录过？他们答不上来。那个客户没有续约。
团队负责人后来说了一句话：效率低我还能解释，串号我解释不了。
做代运营的，平时最关心的确实是效率——一个运营能管几个客户、一套流程能跑多少账号。但真正的风险不在那里。
真正的风险是串号：A 客户的账号，被在 B 客户的设备上操作了；或者两个客户的账号，出现在同一个设备分组、同一条网络出口下面。
为什么这个更严重？因为效率低影响的是毛利，串号影响的是信任。而且它有几个特点：
- 不可逆。一次操作记录错了，你没法抹掉。
- 发现得晚。往往是客户先发现数据不对，你才知道。
- 后果不对称。A 客户可能什么都没察觉，B 客户已经打电话来问为什么自己的号半夜在别的城市登录。
所以隔离这件事，应该按「最坏情况会怎样」来设计，而不是按「这样做成本多少」来设计。
第一层：物理隔离，设备和网络按客户分开
这是底线层，不能省。
具体是两件事：
设备按客户划分。 每个客户的账号跑在自己那组设备上，不要为了省设备把多个客户的账号混编在一组里。混编的代价是：每次下发任务你都要额外做一次筛选，而每一次额外筛选都是一次出错机会。
网络出口按客户分开。 这一条比设备划分更容易被忽略。如果三个客户的账号都走同一条宽带，那么这三个客户在平台看来就是同一个来源——一个客户的操作出了问题，另外两个可能一起被牵连。而且从客户的角度，这件事是很难解释的。
出口不用做到一机一 IP，但至少要保证不同客户不共享同一条出口。独立 IP 的具体配法，站内有一篇专门讲：iOS 手机群控工具批量操作手机配置独立 IP 的三种方案。
有一个实操建议：给每个客户的设备分配一个能一眼认出的命名前缀。 客户 A 的设备叫 A-01、A-02，客户 B 的叫 B-01。这个习惯在设备到 30 台以上时会救你很多次——因为「这台是谁的」这个问题，在群里被问的频率比你想象的高。
第二层：云控租户，把「分给谁」变成系统规则
物理层靠人守，系统层靠规则守。云控平台本身提供了租户机制，正好对应代运营这个场景。
它的思路是：把「这台设备归谁」从你的记忆里拿出来，变成系统里的配置。
关键动作是给每个客户开一个租户，然后把这个租户的设备范围在那个范围里定死。任务下发时会带上租户标识，于是这位客户的任务只会在他的设备范围内执行。另外租户还可以从脚本库和任务库里复制现成的脚本和任务——同一个交付流程服务多个客户时，这一条能省下大量重复配置。
这里有一个必须踩对的点：给租户分配的时候，要把设备量和有效期都配全。这是实际部署里最常见的失败原因之一——如果只建了租户没配设备范围，或者配了范围但没设有效期，租户下发任务会直接失败，而报错信息不一定指向这个原因。
云控的权限管理里还有一个入口值得用起来：用户管理中可以针对账号配置云控设定。如果团队里有多个运营同时管不同客户，这一层能避免「谁都能看到所有客户」这种情况。
三层放在一起看，职责是这样分的：
| 层 | 防什么 | 靠什么 |
|---|---|---|
| 设备划分 | 操作串号 | 物理分组 + 命名前缀 |
| 网络出口 | 关联风险 | 按客户分线路 |
| 云控租户 | 任务下错、权限越界、结果混杂 | 租户 + 设备范围 + 有效期 |
客户数据的边界怎么划
隔离不只是「操作别串」，还有「记录别混」。
在开始接第一个客户之前，就应该定下来三件事：
- 操作记录存在哪。 截图、执行日志、运行结果，按客户分开存放，而且路径或命名能直接对应到客户。别等到出事的时候去翻。
- 谁能看到什么。 如果一个运营管两个客户，他当然要能看到这两个；但他不应该看到第三个客户的任何东西。
- 交付材料从哪出。 如果客户要月度报告，这份报告的原始数据应该是从对应客户的范围里取的，而不是靠人工从一堆混存的文件里挑。
这三件事在只有一两个客户的时候感觉不到，但客户数量上去之后，回头补的成本非常高——因为你要把历史记录重新分拣一遍，而那时候你连哪些记录属于谁都不一定说得清。
交付的时候交什么、不交什么
代运营的边界要提前说清楚，这既是保护自己，也是让客户放心。
建议交的： 结果和必要的记录。账号有没有在正常运营、内容发布情况、数据表现、异常处置记录。客户关心的核心是「我的号你有没有在认真管」。
建议不交的： 设备状态、账号的完整控制入口、内部的任务配置和分组方式。这些是你的交付能力，不是交付物。把设备池的规模、分组逻辑都给出去，等于把自己的成本结构也交出去了。
这件事最好写进合同或服务说明里，而不是靠默契。特别是账号归属要写清楚：账号是客户合法持有的，你只是代为运营。
三个最容易出事的地方
第一，新客户接入的时候图快。 直接把手上的账号塞进现有分组，想着「先跑起来再说」。这是串号最常见的起点。正确的做法是把接入当成一个固定流程走：建租户、配设备范围、设有效期、分网络。
第二，人员交接时只说了一半。 交出去的是「谁管哪几个账号」，没交「这些账号对应哪些设备」。接手的人按账号理解，操作时按设备执行，中间那一层就断了。
第三，加急任务绕过流程。 客户临时要发一批内容，为了快，直接手动指定设备跑。这一步最容易把设备归属的规则打破。可以允许加急，但加急不能豁免归属检查——把核对设备归属做成加急流程里的固定一步，比事后追责有用。
这三个错误的共同点是一样的：为了快，省掉了一步。而省掉的那一步，恰好就是隔离本身。
最后
回到开头那个团队。他们后来把设备按客户彻底分开，加了命名前缀，也把租户配上了。负责人说重新分设备花了两天，比丢一个客户便宜太多。
代运营做的是信任生意。客户把账号交给你，本质上是相信你不会让它们出乱子。隔离做到的，就是让这份信任有制度支撑，而不是靠某个人的细心。
两层隔离建议都做：物理层按客户分设备和网络，系统层用租户把归属变成规则。加起来不会多花很多时间，但它决定了你从管 3 个客户到管 15 个客户时，是平滑过渡还是频繁救火。
设备规模和分组怎么规划，可以接着看苹果群控带机量实测和从 5 台扩到 30 台该先补哪三件事。云控平台本身的能力，站内有几篇专门讲，可以从手机云控系统是什么开始。
最后提醒一句：请确保代运营的账号为客户合法持有，操作方式遵守平台规则。技术是中性的，边界在用法上。
关于 EasyClick：手机自动化 AI 智能体平台，覆盖安卓免 root、iOS 免越狱、鸿蒙 Next 三大生态，提供脚本开发、苹果群控、本地中控投屏与云控系统。→ 了解全部产品
想要真实跑起来？
本文介绍的方案均可在 EasyClick 手机自动化平台落地。官网提供完整文档、开发工具与群控云控产品，免费体验。