业务通知没有送达：事件、接收对象与渠道结果排查｜云上订货系统
云上订货 · 更新于 2026-10-08
原订单或咨询已经发生，但预期员工没有看到通知，先分清缺的是消息记录、在线页面提醒还是手机提示。三种结果不能互相证明，业务保存成功也不表示提醒已到达。固定原企业、原业务编号、事件发生时间、预期接收员工和使用终端，再找最早出现的差异。本文围绕新订单、待财务审核、客户咨询及出库超时排查。请按当前企业实际配置及原事件记录回查，历史规则不能代替本次投递和外部服务结果。
先固定原事件、接收员工与缺失的具体结果
先由业务人员回读原编号，确认确实完成了预期动作，并记录原单状态、操作时间、企业身份及来源。客户在订货端下单、员工在管理端建立草稿和员工提交订单不是相同事件；财务待审核提醒也不能以财务审核已完成替代。描述“没通知”时具体说明消息列表查不到、页面没有弹出、手机没有提示还是消息已经看到但单据打不开。保留首次提示与脱敏原记录，不能为复现再次收款、审核或出库。
接收人必须落实到企业中的实际员工账号，不能只写姓名或岗位。由接收员工确认进入原企业的管理身份，核是否误进关联企业、客户订货身份或另一个同名账号。业务提交者、客户所属员工、企业创建人和指定接收人可能不是同一人；他人已经收到也不证明预期员工已收到。记录使用的PC页面或手机端、消息类型、查询条件与最后刷新时间，同一编号按各自账号检查，不靠群里转述代替原接收结果。
图1：原事件、实际接收对象、各渠道结果和业务处理逐层确认，一层成功不能代替后续结果。
有权人员先从PC系统设置的消息设置查看相应规则，再由原员工查管理端消息列表中的订单消息或客户咨询页签。当前列表按登录员工查询并分页，未读数与列表有分别刷新的过程，红点数量不是完整投递凭据。记录原编号和事件时间后查对应消息内容及关联对象，必要时检查后续页；不能只看首页十条就认定没有消息。没有对应记录时先核触发与接收范围，已有记录时继续核具体提醒渠道。
消息开关与接收名单分别保存，刷新后回读
消息设置分为新订单消息推送、订单财务审核消息推送、客户咨询通知及出库超时通知，四类指定接收人分别管理。新订单的“订单客户所属员工”与咨询的“客户所属员工”是各自开关，不把勾选其中一项当成另一类也已启用。财务审核的指定人员需要单独核对。出库超时还有订单审核人、客户所属员工、指定接收人及启用通知字段，先记录本次实际设置，不按相似名称猜接收集合。
新增或删除指定接收人时，核实际员工编号和属于哪一种通知，再点击保存并刷新相应页。移出接收人后的删除提示可能只对应当前页面，名单是否更新仍须保存后重新查询。保存时接收人按四类名单一起提交；某一类保存为空可能清除该类原名单，因此不能为了排查一人随意清空其他组。若选择对象提示不存在，应重新核原员工，而不是用另一个同名人员补位或批量扩大接收范围。
图2：四类名单分别核，开关与接收名单独立回读；页面删行提示和一次保存提示都不能证明全部设置已生效。
开关点击与保存名单存在各自请求，保存设置和保存接收名单也不是一个不可分的结果。刷新后分别确认开关值、所属员工选项、各组实际人员和默认咨询提示，不以其中一个成功返回替代另一个。遇到错误或原值未改变，保存准确提示、发生时间和失败的那一项，由有权人员沿对应请求处理。默认咨询提示只说明页面展示文字，不能证明咨询已经发给员工、员工已回复或手机已经收到。
事件类型与实际接收对象逐项配对
新订单先核原订单来源和提交动作。订货端创建与管理端提交是不同事件，实时新单提醒不能用管理端草稿生成成功来证明。订单确认后的财务提醒还判断最终是否待财务审核及是否自动流程，因此原单已经自动完成后没有同样提醒，不能直接归为消息故障。指定接收人和客户所属员工按该事件的规则组合，核原客户当时所属关系与实际人员，不把后来转交的员工当成历史事件必然接收人。
咨询先核原客户、原会话和实际选择的服务员工。设置里的指定人员和所属员工影响候选对象，但候选名单出现不证明已经发送，也不证明候选人员全部接收同一会话。保持原客户身份与会话编号，分别确认客户实际发出内容、员工端对应会话和回复记录；默认提示、已打开聊天窗口与实际回复不能合并验收。若无候选或对象不正确，先查该组配置和所属关系，不能转发真实客户内容给无关人员做测试。
图3：四种事件各用原状态和实际对象核对；超时通知还要检查通知时间、扫描条件与当前发送集合。
出库超时先回读原单仍处于待出库或部分出库范围、是否还有待出商品以及通知时间是否存在并已到达。财务审核后应回读按设置形成的通知时间，停止该单通知会清空时间；后开总开关不能据此承诺全部旧单自动补齐。定时通知还需核实际执行记录及符合条件的原单，不保证到点立即提醒所有订单。还需核该次通知的指定接收名单；即使勾选所属员工或审核人，也不能仅据此认定空名单会发送，通知时间顺延也不证明已送达。保存原单通知时间、接收名单和实际执行结果，交有权维护人员继续核查，不反复切开关或回退原单凑提醒。
消息记录在线提醒与手机结果分别检查
先查原员工可见的对应消息记录。消息记录需核接收员工、消息类型、关联单据和标题是否完整，以及对应服务是否接受；字段缺失或返回失败时继续核这一层。业务保存与消息服务接受是两项结果，批量业务尤其需逐项查通知反馈，不能从原单成功推定提醒必然成功。有权人员按同时间窗和脱敏原编号核提交及返回，保留准确错误；没有记录时不能先假定手机拦截，也不擅自重发整批客户通知。
在线页面提醒还依赖原企业、原员工对应的有效连接。原员工的在线连接不存在、已关闭或发送异常，不能用消息列表有一条记录来排除。原员工确认当前企业身份并正常刷新页面后，沿原事件时间核连接及消息展示；另一企业或另一员工页面弹出不作为验收。避免为了测试保持多个重复会话或绕过原身份直接请求发送，无法取得本次连接结果时明确留为待核。
图4：服务接受、在线页面展示和手机实际提示分别需要证据，排队执行及消息已读都不是全渠道到达证明。
手机结果再核实际接收员工使用的端、账号和企业，以及该次推送的设备登记和返回。新单手机推送还需核接收设备、提示音条件和实际反馈；已排队不代表手机展示，手机有提示也不表示原单已审核或出库。原员工在实际使用的手机检查通知权限、当前登录身份及对应消息，不用重装、切换到另一账号或重复真实业务代替定位。若另外使用短信等外部渠道，只沿本企业已经确认可用的具体功能查原发送记录和服务返回，不能把订单消息开关理解为所有渠道都自动发送。
按首个差异验收，保留原业务与未核结果
处理时只修正已有证据指向的条件，并记录批准的变化及回读结果。事件未成立先回查原流程，名单未保存先核名单请求，消息服务失败查本次返回，已有消息而页面或手机未展示则查对应终端；不要同时改接收人、总开关和在线连接后猜哪项有效。旧事件是否可补发需按当前实际功能确认，不能承诺开关打开即补全部历史提醒。原单已有审核、收款或发货结果时优先读取记录，不作废重建或重复动作换取通知。
图5：按首差异保留事件、名单、渠道和终端证据，消息已读与业务处理分别验收，未取得的投递结果明确待核。
最后由原接收员工在原企业确认对应消息及需要的终端结果，再回读原单或原会话的实际处理进度。消息已读仅表示该员工的消息标记变化，全部已读还可能清除当前类型的未读提示，不说明订单、资金或出库已经完成。交接记录包含脱敏企业员工标识、原编号、事件时间、预期接收集合、配置回读、消息服务及各端结果，并注明尚未核清的渠道、设备及运行结果。以原事件的实际接收和原业务结果为依据，不能用红点消失、排队成功或管理员看到消息代替。