发送资料后迟迟看不到确认，有人会在流程图里直接画超时后重新发送。但超时只能说明这次等待没有取得明确结果，不足以证明对方没有收到。若原操作已经完成，重做可能造成重复。本文用虚构的资料发送场景，讨论业务流程怎样表达结果未知，不介绍任何产品接口或承诺技术层面的防重复能力。
先拆开三种不同状态
收到明确成功结果，可以进入后续处理；收到明确失败结果，再按失败原因决定修正还是停止；没有取得结果，则进入待核对。不要把后两者合并为红色失败框。绘图前先写每种状态依据什么判断，例如接收记录、回执或人工确认，并把仅凭操作者感觉的情况排除在已成功之外。
未知状态先走查询路径
在示例中，资料发送等待超时后，先核对接收记录，而不是立即返回发送节点。若查到对应资料已经被接收，就记录已完成并继续；若确认没有接收，再判断是否允许重试；若仍不能确认，就保留待核对，并指定负责人和下一次检查条件。查询需要什么标识，也应在图旁说明清楚。
写明哪些情况才允许重做
重试不是一个默认出口。先确认接收方如何识别同一份资料，业务上是否允许重复，以及重做前应保留什么记录。没有可靠防重复措施时，应由负责人员核实后再决定。图中可以写确认未接收且允许重试，而不是笼统写失败就再来一次。技术实现应由相应人员验证，图上的文字本身不能消除重复风险。
待核对也需要明确去向
不能查到结果时，不要让箭头永远绕回查询。可以按团队实际约定等待后再查，或交给指定角色联系接收方；次数和时限应来自真实规则，不能为了图完整随意填一个数字。若需要停止自动处理，结束的是这一轮处理，不代表原发送已失败，更不能把待核对写成已取消。
用两种相反情况检查图
先假设对方已经收到，只是确认迟到，沿图检查会不会重复发送。再假设对方确实没收到，检查是否存在核实后补发的路径。若两种情况都被同一条立即重试覆盖，就说明状态区分还不够。补充一条长期无法核实的情况，确认它会落到有负责人的待处理项，而不是消失在图外。
建议把超时节点理解成提醒我们确认结果的信号，而不是业务失败的裁决。流程图应让操作者知道现在确认了什么、还不知道什么，以及凭什么开展下一步。先查询、保留未知、谨慎重做，通常比一条看似简洁的返回箭头更忠实于实际工作。