高风险事件响应与升级
当支付暂停、平台限制、安全投诉、隐私请求、claim 投诉、GMC 暂停或拒付爆发时，用 severity、owner、证据包和暂停规则处理。 这篇可以单独读，也可以作为利润、商品数据、广告、隐私、支付和客服之间的风险治理 handoff。
先说清楚：这篇可以单独读
如果你现在只遇到一个具体问题，比如支付审核、GMC 暂停、EU 资料不齐、cookie banner 不确定、拒付上升或促销上线前心里没底，可以直接从本课开始。
TrekCup 会作为本课案例。我们不把合规写成法律百科，而是把风险拆成 owner、证据、停止条件和下一步动作，让运营团队知道今天应该补什么、暂停什么、谁负责。
本课产出：高风险事件升级树
当支付暂停、平台限制、安全投诉、隐私请求、claim 投诉、GMC 暂停或拒付爆发时，用 severity、owner、证据包和暂停规则处理。
本课目标是交付一份incident escalation runbook。这份资产必须能回答四个问题：当前风险是什么，证据在哪里，谁负责，什么时候可以继续或必须暂停。
- 第一步：列出影响上线或扩量的风险节点。
- 第二步：为每个节点绑定公开来源、内部证据和 owner。
- 第三步：把继续、小流量测试、补证据、暂停或升级写成规则。
incident escalation runbook：incident severity
下面这张表是本课的可交付资产。使用时不要只填状态，要写清来源、证据、owner、截止时间和 stop/go 规则。
| 风险节点 | 证据或来源 | 经营判断 |
|---|---|---|
| P0 | 安全风险、监管通知、支付完全暂停 | 暂停销售并升级创始人/法务/支付方 |
| P1 | GMC 暂停、拒付上升、产品 claim 投诉 | 冻结 campaign 并整理证据包 |
| P2 | 隐私请求积压、页面政策缺口、单 SKU 异常 | 限时修复并复盘 owner |
| P3 | 低风险政策或文案缺口 | 进入下次季度治理 |
公开来源参考：
- https://help.shopify.com/en/manual/payments/chargebacks/chargeback-reasons
- https://help.shopify.com/en/manual/fulfillment/managing-orders/protecting-orders/fraud-analysis
- https://www.shopify.com/legal/aup
- https://www.paypal.com/us/legalhub/paypal/acceptableuse-full?locale.x=en_US
- https://ec.europa.eu/safety-gate/
- https://webgate.ec.europa.eu/safety/consumers/consumers_safety_gate/obligationsForBusinesses/documents/GPSR-Presentation-website.pdf
- https://support.google.com/merchants/answer/6150127
这些来源用于确认平台、监管、支付、隐私、税费或广告政策边界；非官方调研信号只转成 source-neutral 的操作判断，不在前台显名。
先分级，再处理
TrekCup 遇到支付暂停时，最差的做法是全团队同时找资料。runbook 先分 P0/P1/P2/P3，再规定谁暂停销售、谁整理订单证据、谁联系支付方、谁写客户话术。
落地时，把这个判断写进incident escalation runbook。每个高风险动作都要能追溯到一个证据包、一个 owner 和一个明确的 stop/go 规则，而不是在上线当天靠感觉决定。
证据包比解释更重要
平台、支付方、客户和监管视角不同，但都需要证据。订单、tracking、产品页、政策页、沟通记录、供应商资料、标签、税费设置和 consent log 要能快速汇总。
落地时，把这个判断写进incident escalation runbook。每个高风险动作都要能追溯到一个证据包、一个 owner 和一个明确的 stop/go 规则，而不是在上线当天靠感觉决定。
暂停规则要提前写
高风险事件里最难的是是否继续卖。runbook 要提前写清：哪些 SKU 暂停、哪些市场暂停、哪些广告暂停、哪些订单 hold、何时恢复。
落地时，把这个判断写进incident escalation runbook。每个高风险动作都要能追溯到一个证据包、一个 owner 和一个明确的 stop/go 规则，而不是在上线当天靠感觉决定。
TrekCup 操作演练
TrekCup 模拟一次 P1：GMC 暂停加拒付上升。30 分钟内要完成 severity、暂停范围、证据包目录、外部沟通 owner、客户话术和恢复条件。
执行检查
- 每个风险节点都有 owner，不用模糊的团队一起看代替责任人。
- 每个公开 claim 都有官方或机构来源，不用社媒截图当正文证据。
- 每个 blocker 都有暂停范围、恢复条件和复盘时间。
- 结果要写回下一次 launch gate、利润复盘或季度治理 roadmap。
incident escalation runbook的证据链检查
incident escalation runbook最容易失败的地方，是只收集资料但不形成判断。更稳的做法是把证据分成四层：公开规则、内部事实、客户承诺和经营动作。公开规则回答平台或监管边界，内部事实回答店铺现在做到了什么，客户承诺回答页面和 checkout 说了什么，经营动作回答团队准备继续、暂停还是升级。
如果四层证据冲突，先暂停高风险动作。例如页面承诺免费退货，但客服 SOP 写的是买家承担退货；广告承诺快速发货，但 EU 包裹没有清楚税费责任；系统里有 cookie banner，但第三方脚本在同意前已经触发。这些冲突都要先进入incident severity，再决定是否上线。
最小记录方式是一张 8 列表：风险节点、公开来源、内部证据、客户触点、owner、当前状态、下一步动作、恢复条件。字段少一点没关系，关键是每次上线、扩市场、换支付、加像素或改 claim 时都用同一张表。
当团队暂时拿不到完整证据时，可以标记为临时通过，但必须限制流量、限制市场或限制 SKU，并写清补证据的截止时间。合规治理的价值不在于一次性完美，而在于让每次增长动作都带着更清晰的风险边界。
incident escalation runbook的验收标准
第一条验收标准是可复查。任何人打开incident escalation runbook，都能看到公开来源、内部截图或系统记录、客户触点和最后决策。不要只写已确认或没问题，这种状态无法被下一位同事复查。
第二条验收标准是可执行。表里每个 blocker 都要能变成动作：补政策页、改产品页、暂停广告、hold 订单、调整 checkout 文案、补标签资料、联系支付方或安排外部确认。不能执行的判断，需要继续拆小。
第三条验收标准是可恢复。暂停不是终点，暂停后要写恢复条件。例如补齐 business info 后重新提交 GMC，补齐产品安全资料后打开 EU 市场，拒付比例回到警戒线以下后恢复自动 capture。没有恢复条件，团队会在保守和冒险之间来回摇摆。
第四条验收标准是能回写到其他系列。incident escalation runbook的结论要能进入利润复盘、商品数据、广告结构、邮件发送、CRO 页面和客服 SOP。这样合规不是额外会议，而是每个增长动作前的一道运营控制点。
第五条验收标准是能解释给非合规同事。广告同事要知道为什么某个国家不能放量，客服同事要知道客户问到税费或退款时该怎么回答，运营同事要知道哪些订单需要 hold，创始人要知道哪些风险会影响现金和账号。
第六条验收标准是能留下版本记录。每次修改incident escalation runbook，都要记录改动时间、改动原因、影响页面或流程、验证结果和下次复查日期。三个月后回看时，团队能知道某个 gate 为什么变严、某个市场为什么暂停、某个 claim 为什么被改写。
最后，验收时要检查这份资产是否真的改变了下一步动作。如果填完incident escalation runbook之后，预算、页面、客服话术、商品资料、支付设置和事件记录都没有任何变化，说明它还只是文档。真正可用的风控资产，会让团队更快决定哪里可以继续，哪里必须先停。
交给季度治理前要带上的事件记录
本课接收前面所有 gate 的失败结果，并把它们转成事件响应、暂停和恢复规则。
如果你是从利润、广告、CRO、邮件、商品数据或运营系列跳到这里，记住边界：前面的系列负责创造增长动作，本系列负责判断这些动作能否安全进入市场、能否继续扩量、是否需要暂停或升级。