一张图最后写着结束，读者却不知道是请求已经登记，还是资料已经交到对方手中。结束符号能够标记路径终点，但不能独自解释业务结果。本文用虚构的资料请求受理说明如何给终点补充含义，不描述任何真实系统的状态机制，也不把图画完等同于任务已经执行。
先限定这张图处理哪一段
如果图只描述从收到请求到登记完整信息，终点可以表示受理环节结束，但不能直接声称交付完成。若本图覆盖完整交付，则需要核对后续整理、确认和发送等实际动作。开始范围与结束范围应相互对应，不在标题里写全流程，正文却只画最容易描述的一段。
用结果短句代替泛泛结束
可以在终点前或终点说明中写清本路径实际得到什么，例如请求已登记，待确认用途。具体名称由业务方确认，不是随意增加一套状态标签。不要用已处理概括所有结果，因为它可能包含成功、拒绝或仍需补充等完全不同情况。相同图形不代表相同业务含义。
未完成事项需要明确去向
虚构案例中，收到资料请求但用途不清，可以结束当前登记动作，同时记录由谁继续确认。也可以按实际业务选择保持待补充，不应由绘图者自行决定。关键是让读者知道哪些已经发生、哪些还未完成，不把暂时无法继续的路径统一标为成功。后续责任不能随着箭头停止而消失。
不同出口分别检查结果
正常受理、请求撤回、信息不足等路径，可能在不同位置终止。逐条写出各自的结果和必要记录。若多个出口合并为同一终点，先确认是否真的不需要保留区别。不能为了让图简洁，就把已登记与已交付合并，造成后续人员误以为无需再行动。
用后续接手人的问题验收
请另一位同事只看终点及相关材料，说明现在能确定什么、还缺什么、下一步谁负责。如果他说不清，回到图的范围和输出补充说明。不要只问图有没有闭合，也不要只检查最后一个框是否对齐。可执行的结束应该减少状态猜测，而不是给图形增加一个看起来完整的尾巴。
规则变化后重看所有终点
英飞官方流程图资料介绍了起止节点和明确结果的表达，可用于整理此类任务。实际受理范围扩大或后续交接改变后，原先终点的解释也可能需要调整。本文配图均为方法示意，不是产品界面。建议每张图都回答结束了哪段工作，再决定它是否真的代表整件事已经办完。