海外营运出状况时，最难的不一定是立刻修好问题，而是值班者不知道该通知谁、谁有权暂停流程、谁能向客户说明。跨时区团队、供应商与不同沟通管道，让只有姓名和电话的名单往往不足以接班。事故联系卡要标出第一窗口、失联时的下一站、批准人和对外通知责任；权责表则把可先做的保护动作与必须批准的承诺分开。无论遇到出货延误、付款中断或共享平台无法登录，先区分已确认情况和待查问题，再按顺序通知、决策、记录。以下做法是供企业依班表、风险和内部授权填写的操作框架，实际内容应由负责营运的人员逐项确认。
事故第一联系人是谁？
事故第一联系人应是当班负责协调的人，而非通信录里职称最高者。卡片要同时写角色、姓名、所在地时区、可用时段、主要联系方式和另一个备援方式；只写一个手机号码，遇到漫游、停机或夜间便无法接手。卡片要放在值班者找得到的受控位置，并确认新接手人有权限打开。接通后，联系人先确认「收到」，再问发生时间、影响市场、受影响系统或订单、目前已知事实、已采取的动作，以及下一次回报时间。把观察到的结果与推测分开，例如「付款页持续转圈」是观察，「银行拒绝交易」仍待确认。这样交班者不会把猜测当成原因，也不会先向客户承诺恢复时间。
建卡时可用任务而非个人英雄：营运值班人收集现况，技术或供应商窗口查服务状态，负责人决定是否停单；第一联系人负责把人接上，不必自己解决每一层问题。字段旁标示数据最后确认日，避免新同事拿到旧版本。卡片不放密码、一次性验证码、完整付款数据或客户证件；需要进系统时，由有权限的人走公司核准的访问方式。若事故涉及人身安全、资安或跨境数据，先照公司既定通报进程保全现况，避免在群组转传敏感截屏。
例如，假设台湾团队发现新加坡订单无法出货，值班人先在卡片所列频道通知「海外营运值班」并提供受影响批量、发现时间及已暂停的步骤；窗口回复收到后，指派物流窗口查仓库状态，再把需要主管拍板的项目标出。这让每个人知道现在由谁接球，而不是同时私讯多位主管、各自听到不同版本。
无法联系时找哪位备援？
首位联系人没回时，接手路径要明确写在同一张卡上：由谁在什么条件下转找谁，通过哪个替代管道，并在什么位置留下已尝试联系的时间。触发条件由公司按事故级别和时区订定，例如内部可设置「主要窗口在自订时限内未确认收到，就联系备援」；这是内部操作值，不是通用服务承诺。不要只写「找主管」，应列出姓名或职务、代班顺序、可联系时段、能作的决定，以及如何找到下一层批准人。若主窗口与备援同时休假、使用同一支电话或依赖同一个故障系统，名义上有两人，实际仍只有一条路。
备援应该有能力先接住信息、判断是否需升级，并知道哪些动作已事先授权；若不能批准对外承诺，也要能找到批准者。可设第二备援或当地合作窗口，但清楚标示他是公司内部责任人、外部供应商，还是专业顾问，避免接手人误以为对方代表公司决策。联系方式至少准备两种可行信道，并用非事故状态定期演练确认，不要在真的停机时才发现群组已失效。个人联系数据只供必要值班角色访问；更换职务后，立即交接或撤下旧人的事故权限。
假设主要窗口在欧洲深夜没有回复，接手人先按卡片上的时限改找备援，再将联系时间、回复状态和手上数据记入事故纪录。备援若只能协调、不能决定暂停新订单，就同时联系表上列明的营运批准人；若仍无法取得批准，采取卡片预先核准的暂时保护动作并继续升级。如此既不无限等待，也不把未授权的商业决定推给外部窗口。
哪些决定需要主管批准？
主管批准不是由事故发生后临场猜测，而是事前把可逆的保护动作、商业影响和外部承诺分层。公司可先列出「运行人可立即做」「主管须批准」「须再找专业人士确认」三类，并为每一类填入职务名称、替代批准人、可接受金额或影响范围，以及批准留下的纪录。以下只是示意，门槛要由企业依现金流、合约、客户承诺和风险自行设置，不是法定标准：
| 决策类型 | 建议先写明 |
|---|---|
| 暂停单一受影响流程 | 值班人可否先止损及何时回报 |
| 动用额外成本或补偿 | 金额上限、批准职务、记录位置 |
| 对外承诺恢复时间 | 谁核实状况、谁批准文本 |
| 涉及合约、数据或监管问题 | 先保全数据，再由适当专业人士判断 |
表格要能回答「没有人即时批准怎么办」。遇到多个市场同时受影响时，也先注明由哪位主管汇整信息，避免各地分别承诺不同做法。可预先授权短期、可撤回的保护措施，例如暂停有疑虑的批量，并规定由值班人通知主管；不可把「保护措施」扩张成删除数据、改客户纪录、承诺赔偿或永久停业。对成本与影响较大的决定，设置单一批准人及其代班者，不让多人各自口头同意后互相矛盾。若需要考虑法律、税务、银行或数据保护问题，先把事实整理给合资格的外部专业人士，不能以事故卡取代个案判断。
假设系统故障时可以先暂停新订单，值班人照预授权操作并记录时间；要退款或承诺补偿，则等指定主管核准。任何人若只能通报而无批准权，卡片就应明示，避免沉默被当成同意。
客户与供应商谁来通知？
通知名单要按受影响对象分开，指定一位主要对外窗口与一位备援，其他同事把查证结果交回窗口，避免客户收到不同版本。客户通知者通常由企业按既有客户关系安排；供应商通知者则应能说清服务、批量或交付要求。两类消息都先写四件事：已确认的状况、目前影响、对方需要采取的动作，以及下一次更新的时间或条件。仍未查明的原因要标成待确认；不要猜测故障责任、转传内部争论，或承诺确切恢复时间。若尚无新信息，也可依约定时间简短回报「仍在确认，下一次何时更新」，让收件人知道有人负责。
先用名单判断谁真的受影响：若只有一个物流批量延迟，就通知该批量相关客户及承运窗口，不必把未受影响市场一并惊动；若付款、登录或数据功能可能扩及多地，先由事故负责人确认范围，再决定是否扩大通知。供应商若需要订单编号或追踪信息，仅提供查问题所需的最少内容，经核准管道发送。客户个人数据、付款信息和尚未证实的个案细节，不应贴在开放群组或把所有收件者放在同一封信件副本。涉及法律权利、合约解释或可能受规管通报的情况，应交由合资格专业人士判断，不要让客服自行作法律结论。
假设海外仓库回报部分货件扫描延迟，通知窗口可说明目前核实到的批量、对交付的已知影响，以及下一次更新安排；未确认的原因不写成仓库失职。发送前由事故负责人核对名单和文本并留存副本；若信息有变，沿用同一窗口更正，清楚指出哪项内容更新，避免新版与旧版同时流传。
更新纪录放在哪里？
事故期间只保留一个正式纪录位置，例如公司已核准、具访问权限管理的工作平台；群组、电话和电邮可用来通知，但重要事实与决定应回写该纪录。卡片本身只指向存放位置和管理者，不要在多个私人通信群组各存一份含个人电话或客户数据的文件。若平台不可用，先以事前指定的脱机表格记下时间和决策，平台恢复后补回并注明补登时间，避免把不同时区的先后顺序弄乱。所有时间最好标出时区，写出状态改变，而不是只留「稍早」「刚刚」。
每则纪录可有事件编号、发现时间、回报者、影响范围、已核实事实、未确认事项、处理动作、决策人、批准时间、对外通知对象与下一个更新点。证据以权限受控的位置链接，保留原始消息或截屏时先屏蔽不必要的个人及付款数据。不要只截取片段而删掉上下文，也不要在事故结束后覆写原纪录；更正时添加一笔，说明何时由谁修正了什么。访问权限按值班需要设置，离职、换组或供应商合约结束后收回；保存期限按企业既定数据政策和个案要求处理。若由不同人轮班，指定交接字段与下次更新时间，避免纪录停在前一班。
例如假设台北时间十六时四十分发现海外订单状态不同步，纪录应分别列出发现时间、受影响订单范围、当班人做过的查核，以及主管何时批准暂停同步；若同一事件涉及另一时区，保留原时区或另注明换算方式。接手人打开纪录就能先看到最新状态、负责角色和下一步，不必翻阅整串聊天重建事故。
事故结束如何清除旧联系？
事故解除后，清理联系卡不是把旧人的名字直接删掉就结束；先确认事件纪录已补齐、未完成事项已有责任人、客户与供应商收到必要的结案或后续安排，再检查事故期间添加的临时联系方式和授权。把过时联系卡标为停用并保留版本日期或移转纪录，让团队知道哪一份现行有效；若旧版含私人电话或敏感数据，依公司访问与保存政策撤权、封存或安全删除，不要留在公开共用文件夹。事件纪录与联系数据用途不同，清理名单不代表抹除应保留的决策轨迹。
检查可放在事故结束交接及固定的内部盘点中，也应在人员、时区、供应商、通信工具或决策权变动时即时更新。逐项确认主要窗口、备援、批准人、对外通知者仍在任且可联系；用一次低风险演练测试电话与替代信道是否可达，记录谁确认及日期。若有人离职或责任转手，先指定新窗口并测通，再撤下旧人的工作权限，避免出现空窗。不要把事故卡散发成无法追踪的附件；固定一个受控来源，给需要的人链接并说明版本。
结案检讨聚焦于联系是否接通、升级是否到位、批准是否找得到、消息是否一致、纪录是否可读，并把改善项目指派给人和期限；不需把检讨变成责怪个人。若同一项联系信息再次失效，就调整备援或演练方式，并更新版号与确认人。下一个可立即采取的动作，是把目前的值班人、替代窗口、批准人和通知责任填入一页卡片，交接前逐一测试。若需延伸了解香港公司与海外营运议题，可浏览 Chan & Chung 首页。