客户推送记录核查：发送失败、错误信息与重新发送｜云上订货系统
云上订货 · 更新于 2026-10-08
推送记录用于回查一条通知的后台处理结果。先辨认任务、客户与渠道，再判断待发送或失败是否适合重发，最后核客户实际收到的内容。记录标成功、弹窗提示重新发送成功、客户手机收到消息是不同证据；不能只把失败行变成成功就认定问题解决。
从任务与客户定位同一条记录
在 PC 管理端进入营销管理的推送管理，查看推送记录。列表显示任务 ID、客户 ID、推送类型、发送状态、发送时间与错误信息。先在推送任务中核任务名称、通知内容及渠道，再按编号对照记录，避免把同名任务或同名门店混在一起。任务详情主要显示任务内容和计数，不能保证其下面就有记录表；需要单条原因时到独立的推送记录列表查。
列表按记录建立时间倒序展示，重发后发送时间更新，不保证这一行因此排到最上方。翻页时保留原任务与客户编号，不以“第一行看起来相同”作为定位依据。一位客户可能关联多个账号，APP 设备、站内账号和客户门店也不是同一个计数口径；相同客户编号出现多行时，先核渠道和通知来源，不直接认定都是重复发送。处理某一行时还要保留能区分该行的标识或脱敏截图。
当前查询条件承接任务编号，但页面没有明确的失败状态筛选框或发送日期筛选框；按任务编号和列表实际字段定位记录。进入时若没有带入任务条件，应逐页按列表实际字段对照；若无法辨认原行，先交接定位信息。任务成功数、营销活动记录及优惠券使用订单均不能替代该原行的渠道、状态、发送时间和错误信息；本次是否发出及客户收到，须分别核原记录与实际接收结果。
图1：任务确认通知内容，记录确认客户与渠道；重发后仍定位原行，不按列表第一行猜对象。
先解释状态，再决定是否需要重发
记录状态为待发送、成功、失败三种。待发送表示这行还没有按当前流程记成成功，不等于系统一定会自动补发；失败应结合错误信息处理；成功也不能直接解释成送达或已读。页面未展示独立的已送达状态、阅读统计或重试次数，不要求客户从这些不存在的列核验。即使底层记录包含阅读、点击相关信息，也不能据此承诺当前页面已有可用统计。
APP 在异步推送提交后就可能建立成功记录，后续设备接收仍要独立核。短信调用没有抛出异常，也可能把本行记成功，并不代表这里收到了手机送达回执。站内消息建立记录后可能标成功，客户侧是否存在相应可见入口，还需要实际检查。微信模板服务尚未接入，会留下待发送及“微信模板消息服务暂未接入”等提示；这不是修改客户资料就能解决的号码错误，也不能写成已经发到微信。不要把它作为可用渠道试发或反复重发。
客户没有对应渠道资料、已退订或被当天频次规则过滤时，可能根本不产生失败行。因此“列表没有失败”不能证明任务全部到达，“没有找到记录”也不等于客户自己删了通知。先确认任务是否执行、候选客户是否在本次范围，以及实际渠道条件。若原任务属于立即发送，但在不执行时段创建而仍待发送，还要回查原任务，不以重发某行代替核对任务执行情况。
在发起重试前，记录原状态、原发送时间与脱敏错误提示，说明客户为什么仍需要这条通知。例如补货内容已过期，或客户已经下单，就不应继续催同一条消息。客户反馈未收到时，先核其查看的是哪台设备、哪个账号和哪个时间段；已经收到但不需要再次通知的对象，保留接收结果即可，避免把清空失败列表当作工作目标。
图2：记录成功不是送达回执；微信未接入、缺资料与被过滤分别处理，不能都靠重新发送。
按原渠道判断单条重新发送的条件
列表只有待发送或失败行可能显示重新发送。先核原任务仍存在、通知内容正确、客户仍需要接收，再处理这一行；没有按钮时不新建多份相同任务绕过状态。当前单条重发取关联任务的文案，不能承诺在记录列表直接修改标题或内容。若原任务或记录查不到，保留编号交负责人核查，不从相近名字选择另一份通知碰碰运气。
短信重发使用原记录保存的手机号。后来修改客户档案的联系号码，不保证改变这一行的重发对象；“已改新号码”不能作为直接点重发的充分条件。先由负责人确认原号码是否仍正确、客户是否仍愿意接收，并核实际短信服务条件。这里不会完整重走首次发送的人群、退订与频次过滤，不能依赖按钮替代这些人工检查。遇到记录无手机号提示时，先停在原行交接，不连续点击试探。
APP 重发会重新检查原客户当前可发送的账号与设备，并经过退订和当天频次判断。当前没有可用设备、被过滤或查询不到可发对象时，可能没有新增发送，但请求仍正常返回；页面提示重新发送成功不能单独证明新通知产生。此时原记录可能保留原发送状态，必须再刷新原行并核目标设备。不要为了看到成功提示反复按按钮；先核设备资料、客户接收条件和实际通知。
站内重发可能仅更新原记录状态，不能由此承诺客户收到了另一条新消息。微信类型不支持这个重发入口，未接入提示应作为功能边界交接。不同渠道的动作不能互相套用：短信旧号码、APP 当前设备、站内原状态各有不同承接对象。重发也不等于重新创建任务，更不保证撤回此前已收到的通知或自动修正原任务累计成功数。
图3：短信核原记录号码，APP 核当前设备，站内核原状态，微信不支持重发；不同渠道分别留证。
重发后刷新原行，时间与旧错误分别判断
操作一次后记录提示与时间，重新查询或刷新当前列表，再找到同一条原记录。页面提示不代替刷新，列表没有立即变化时，也不马上重复操作；先核原任务和原行是否仍一致。发送时间可能在记录状态更新时写为当前时间，即使 APP 没有可发对象且保留原状态也可能更新。因此这个时间适合与本次处理动作对照，不足以证明客户手机在同一时刻收到消息。
旧错误文字不保证在正常重发后自动清除。如果本行已变成功，仍留有先前错误，应把重发前后的状态、时间和错误一起交接，不把旧文字直接认定为本次再次失败。反过来，错误没有变化也不能证明已经解决。一般异常可能更新失败与错误；关联任务不存在、记录无手机号或不支持渠道等业务提示，还可能直接返回错误，并不保证给原行写入一条新的失败原因。必须保存当时提示，不能只等列表补齐证据。
单条重发主要更新原记录，没有可供本篇操作的重试次数列，也不保证新增一行。因此别用列表行数判断重发次数，或用原任务累计成功数是否增加判断这次修复。需要保留多次处理经过时，在交接中另记每次操作时间、操作者、原行与结果。仍待发送或失败的行先核具体条件，已成功但客户仍未收到的行进入接收核验，不把两种情况混成一次整批补发。
图4：刷新同一条记录比较三项变化；时间更新、旧错误保留、任务计数不变都不能独立证明到达。
用客户实际接收结果完成交接
请客户确认实际收到的标题或短信内容、接收时间和查看账号。APP 还要核点击后是否到正确企业的页面，不能只看通知出现；当前推送可能落到购物车，不能根据任务填写的链接就承诺一定打开某优惠活动。短信要确认真实手机上的内容，站内要确认客户自己的可见入口。没有这些结果时，只能写已核后台记录、客户接收待补，不能把一条样本成功扩展成所有客户都收到。
重要业务通知还要单独核下一步。例如提醒补货后，看客户是否需要继续选品；通知优惠活动后，核领取资格、领取结果与订单实际使用。通知成功、领券成功和订单抵扣成功是三个结果，优惠券及订单记录只核各自领取和抵扣业务，不能替代本次消息的实际接收结果。客户已收到而没有点击，也不应自动补发；是否需要再次联系由本次通知目的和客户反馈决定。
交接至少说明原任务、客户编号、渠道、原行定位、重发前后状态时间、当时脱敏错误和客户实际结果。保留哪些客户已确认收到、哪些缺渠道资料、哪些属于未接入或仍无法定位，并明确后续负责人。不要在截图或记录中公开完整手机号、设备标识和客户原始敏感信息。对仍无接收证据的对象保留待核，先处理不受影响的记录，不反复新建同内容任务向所有客户重发。
图5：后台原行、客户接收、点击落点与业务结果逐层确认；未核范围和处理责任继续保留。