苹果群控，是指用一台电脑集中管理并批量操控多台 iPhone 的技术方案，免越狱、免签名、免硬件，靠外部输入注入驱动设备。
这篇要回答的是：苹果群控客户问今天的为什么没发，怎么答。
一个做代运营的工作室负责人说过一句话，我印象挺深。
他说他最怕的不是出事；出事了他知道怎么处理；他怕的是客户来一句：「你们上周是不是漏了两天？」
因为这个问题他自己也答不上来，得先花半小时去翻记录。
那一刻的区别很关键：如果是「今天没发」，你打开后台就知道；如果是「上周是不是漏了两天」，你要把上周每一天的每一条都过一遍才能确认。客户在等，你在翻。
这篇文章讲的就是怎么让这类问题不再需要翻记录。
让客户能看到的东西，变成一张每天必看的表
大部分团队每天看的是设备状态——在线多少台、任务成功多少条。这些是对的，但和客户感知的东西不是一回事。
客户能感知的只有两样：内容有没有按时出现，和消息有没有回。
所以要做的是把这两样单独列出来：
- 今天计划发几条、实际发了几条、分别在哪几个账号上
- 今天有多少条客户消息进来、回了多少条、还剩多少条没回
这两行加起来，就是客户眼中的「今天你们干了什么」。
为什么要单独列？ 因为设备状态正常不等于客户那边正常。可能出现的情况是：所有设备在线、任务显示成功，但某个账号的内容因为平台审核没通过，实际没显示出来。这时候你的设备报表是全绿的，而客户的感受是「今天没发」。
这张表不需要复杂，一天两行。它的价值在于：客户问起的时候，你手上有东西可看，而不是先去翻。 省下的就是那半小时。
说明白，只需要三句话
回答这类问题的时候，最容易犯的错是讲过程。
「昨晚定时任务在凌晨一点四十失败了，我们排查发现是设备掉线导致……」
这段话每一句都是真的。但客户听完的结论通常是「所以你们的设备不稳定」或者更糟的「所以你们没有及时发现」。
有效的说法只有三句：
- 发生了什么：今天这条没发出去（或者说：这周有两天没发）
- 现在什么状态：已经补上了 / 今天会并入下一批 / 那两天的内容已经重新排了
- 之后怎么避免：我们在任务失败的时候会收到提醒，下次会比你先发现
三句话里没有一句需要提设备、脚本、网络；客户关心的是他的生意有没有受影响，不是你的技术细节。说客户听得懂的。
两句不能说的话：
- 不要承诺「以后不会再发生」。 承诺做不到的事，下次出事你就没有余地了。说「会更早发现」比说「不会再发生」可靠。
- 不要解释为什么「设备会掉线是正常的」。 在客户听来，这等于承认你的基础设施不稳定。技术上的正常和客户认知里的正常是两回事。
把翻记录变成打开就有
这是三件里最省事的，也是最容易被拖着的。
现在的问题是：每周/每月的交付材料，要么靠人工从一堆记录里挑，要么靠回忆写。这两种做法都有一个共同后果：出问题的时候你没法快速自证。
要做的很朴素：每天收工前花五分钟，把当天那两行表存下来。 一天五行字，一个月就是一份完整的交付记录。
它的作用有两层：
- 被问的时候能立刻答。客户问「上周是不是漏了两天」，你打开表格就能说「是周二和周四，分别是这两个原因，已经补了」。
- 你也能自己发现趋势。连续三周的表格放在一起看，你会看到「周三总是容易出问题」这种规律，这是日报里看不到的。
交付边界，提前说清楚比靠默契强
代运营的交付边界最好提前说清楚。
建议交的： 结果和必要的记录。发了什么、什么时候发的、数据怎么样、异常怎么处理的；客户要的是「我的号你有没有在认真管」。
建议不交的： 设备状态、内部的任务配置、账号的完整控制入口；这些是你的交付能力，不是交付物。把设备规模、分组逻辑都给出去，等于把成本结构也交出去了。
这件事写进服务说明比靠默契好。尤其是**「产出记录」和「设备日志」要区分开**：前者是交付物，后者是内部材料。客户要的是前者，你给前者就够；客户要后者，说明他对结果不满意，那就该谈结果，而不是给他看日志。
回到那位负责人的问题。
他后来做了两件事：每天收工前存一行当天的产出记录；把「客户能看到的东西」单独列成一张表；执行了两个月之后，他说客户的问题变了。从「你们是不是漏了」变成「这个月的数据怎么比上个月好」。
这个变化挺关键的； 前者是在质疑你的执行，后者是在和你讨论生意。而触发这个转变的，不是你的技术变好了，是你能把「做了什么、结果如何」随时说清楚。
代运营做的是信任生意。而信任这件事，很大一部分建立在「你随时能给出答案」上。