客户没收到邮件或短信，先查哪一环？用通知证据链决定等待、重发还是人工确认

预约时间已经改了，客户却说没收到提醒。此时直接点击“再发一次”，可能解决不了问题：第一次消息也许仍在排队，也许发往旧号码，也许已经到达但内容仍是旧时间。先把同一条业务事件和它的通知对应起来，才能判断应该等待、纠正对象、重新发送，还是人工确认。

排查的第一问不是“邮件还是短信更可靠”，而是这条通知要让谁知道什么、最晚什么时候知道、没收到会影响哪一步。普通资料更新和临近开始的预约变更，需要不同的补救节奏。

一条“发送成功”，可能只证明了其中一段

不同服务商的状态含义不完全相同。以 Twilio 短信文档为例，sent 与 delivered 是不同阶段；SendGrid 的 delivered 表示邮件到达接收服务器，不等于已经进入客户收件箱，更不等于客户已读。应按当前使用服务的文档解释状态，不能把不同渠道的“成功”合并成一个笼统绿勾。

用一个预约变更例子，把检查顺序走完

以下编号和时间均为虚构：预约 A-018 原定次日 10:00，今天 14:00 改为次日 15:00。客户在 14:10 表示没有收到短信。先确认预约记录确实是新时间，再找到对应变更版本的通知 N-204；不要拿上周的预约确认短信当作这次变更的证据。

若没有 N-204，就检查这类变更是否应触发通知、是否被暂停或漏掉；若通知存在但接收号码不是客户当前认可号码，应先核对对象，避免把信息继续发给错误的人。核对时使用脱敏显示，必要完整信息通过获准的私下渠道处理。

若 N-204 已有渠道消息编号，但没有最终回执，则记录为结果未确认，先查渠道记录及当前处理状态。不能因为网站请求超时，就认定渠道没收到并立即重复发送。若已明确未送达，按服务商原因进一步区分地址错误、渠道限制、临时故障等，再决定修正还是等待。

如果回执显示送达，仍应尊重客户“没看到”的反馈：核对消息时间、发送者标识和当前设备或邮箱分类，必要时安排人工确认。回执不是证明客户说错了的凭据。对于即将影响行程的变更，应按企业已有服务安排及时联系，并记录是否真正确认了新时间。

重发前检查三件事：仍然需要、对象正确、内容仍有效

首先确认业务尚未再次变化。若预约后来取消，重发“改为 15:00”的旧提醒会制造新的误解；待发送消息也应按业务版本检查是否已失效。仅把失败任务重新放回队列，并不能保证消息内容仍然正确。

其次判断第一次发送是否确定失败。结果未知时，需要查询或按渠道支持的重复识别能力处理；没有可靠依据就保留不确定状态并交接。一次业务事件、一个接收对象和一种通知意图应能关联到重试记录，避免把每次重发算成一项新业务。

最后约定重试的次数、间隔和停止条件。可恢复的暂时故障与无效地址不能采用相同动作；反复发送到错误号码没有价值。超过处理窗口或接近业务截止时间时，应转交明确负责人，而不是无限自动等待。具体阈值取决于通知时效与渠道规则，不应照搬一个通用数字。

人工补救也要留下可核对的结果

客服需要的不是全部技术日志，而是一张简洁交接单：业务编号及当前事实、通知编号、脱敏接收对象、已知渠道状态、尝试时间、尚未确认事项、下一步负责人。必须区分“已拨打无人接听”和“客户已确认”，不能都写成“已联系”。

修改联系方式后，确认本次通知是否应发往新对象，并保留必要变更依据。不要在公开工单粘贴完整客户地址、验证码或私密业务内容；排查证据够用即可。通知正文也只承载必要信息，敏感详情应通过正常授权入口查看。

交付验收应包含“未确认”和“过期消息”

使用授权的测试邮箱或号码，演练正常发送、明确拒绝、延迟、回执缺失、重复处理及业务再次变更。逐项检查通知能否关联到正确事件，页面是否准确表达状态，已失效内容是否停止继续发送，以及负责人能否发现长时间待处理项。

例如 A-018 只发生一次变更，却有两次发送尝试，统计仍应是一次变更、两次尝试，而不是两条新预约。再核对最终发送内容、接收对象和人工确认记录。验收目标是每一步都有依据，而不是所有测试都得到一个“成功”。

如果网站提醒经常漏收或重复，可私聊客服，提供通知用途、渠道和脱敏样例，沟通排查证据、状态展示及异常补救流程。

参考资料：Twilio：短信消息状态；SendGrid：邮件事件与送达回执。