先给结论:把“让账户重新跑起来”当作一次修复,把“让账户在变化中继续跑得稳”当作长期维护,两者按不同依据计价。一次修复的价值看它消除了哪个具体故障、多久恢复;长期维护的价值看它在一段时间内替业务吸收了多少变化、减少了多少临时决策。分不开时,最容易出现的后果是:修复做完,维护费照付,但没人说得清这笔钱在防什么。
拿你正在看的一份账户报告或对账单当对象,逐项问三个问题:这件事有没有明确的“坏了”状态?做完之后业务是否立刻恢复到一个可用的基线?如果答案都是“是”,它偏修复。反过来,如果这件事没有坏掉,只是需要在预算、出价、关键词或落地页变化时持续调整,它偏维护。
常见的误判是把“账户跑得不好”直接归为修复。跑得不好可能只是没达到目标,而不是坏了。两者计价逻辑不同:修复按事件计,维护按周期计。先分类,再谈钱,否则后面的报价永远对不上口径。
修复的价值来自它消除了什么。可以按下面几步把它变成可执行的处理方案:
假设一个场景:某账户因为落地页改版,表单提交按钮在移动端被遮挡。修复动作是把按钮恢复到可点位置并验证提交流程。做完后,你下一步应该做的不是立刻加预算,而是观察一段时间内转化动作是否稳定出现。如果稳定,说明修复有效;如果仍不稳定,说明故障判断有误,需要回到第1步重新界定。这个动作的结果直接决定后续是继续排查还是转入维护。
维护不是修复的延长线。它的价值在于业务前提会变:预算会调、竞品会动、平台规则会更新、产品会换卖点。维护费买的是“有人持续接住这些变化”。
把维护拆成可计价的三个维度:
维护通常按周期计费,比如按月或按季度。定价前先明确一个假设:这段时间内业务前提会变化多少次。变化越多,维护费越应该覆盖对应的人力预留。如果变化很少,按周期付高额维护费就不划算,可以考虑降低响应时限或改为按次处理。
很多报价把修复和维护打包,导致你无法判断钱花在哪。可以用一个简单动作拆开:把过去一段时间的实际工作列出来,逐条标记为“修复”或“维护”。
标记完成后,你会看到两类证据:一类是某个具体故障被消除,另一类是某些变化被持续吸收。如果清单里几乎全是修复,说明当前阶段的问题集中在故障,维护费占比应该低;如果几乎全是维护,说明账户结构本身没有明显故障,钱主要花在应对变化上。
这个动作的结果会直接影响下一步:如果发现维护费在为一个没有故障、也没有变化的账户付费,就应该重新谈维护范围,或者把它降级为按次处理。反过来,如果发现修复反复出现,说明根因没解决,继续按次修只是重复付费,应该把其中一类问题转为维护项。
前提变化是分开计算价值的触发点。以下几种变化前后,应采取不同决策:
注意不要把“请求量下降”或“抓取量归零”单独当作处理正确的证据。这些现象还有别的解释:可能是季节性波动,可能是统计口径变了,也可能是数据本身延迟。要结合修复标准是否达成、维护范围内是否出现新变化来判断。
最后提醒一句:免费不等于没有成本。免费修复可能占用你或对方的时间,免费维护可能附带额度或迁移限制。把这些隐性成本写进对比口径,修复和维护的价值才能真正分开算。