mPorts OMS 的一部分
什么需要处理，为什么，接下来怎么做。
现在什么需要处理？mPorts OMS 的问题处理把延迟、卡住、失败或在等待什么的订单排到最前面，为每一笔给出原因，并且是您的团队处理它们、记录处理结果的地方。在产品内部，这些被称为异常。
大多数订单都没问题。运营的工作几乎全部围绕那些有问题的订单展开；而一套糟糕系统的代价是——找到它们比修好它们还费时间。
只有说明了原因，一个问题才有价值。“订单 4471 延迟了”是症状；“订单 4471 延迟，因为分配到的仓位缺两行货”才是一个人可以一步处理、而不是分四步排查的事情。
那些停下来的发货，会被挑出来并说明原因
一个真实的例子：面单已经创建，然后就没有然后了。每一行都已经闲置七十多天，而产品会直接把这件事说出来，而不是等人自己发现。
一个问题，从头到尾
一笔订单无法从为它选定的地点发出。
-
信号
履约恢复标记了这笔订单：被指派的仓库无法执行方案。
-
mPorts 显示什么
用直白的话说明卡点，接手的人不必从一张空白的界面开始。
-
追查
其他有库存的地点、各自的发货成本，以及承诺的日期是否还能守住。
-
建议
与这个卡点对应的处理方式。mPorts 能标出的每一种卡点，都有一个已知的下一步。
-
审批
会改动订单的那一步，由运营人员确认。写入的步骤永远不会自行运行。
-
执行
订单按日常流程重新规划并重新提交。
-
记录
问题、决策与结果按发生顺序留在这笔订单上。
-
发现问题
问题在每一步由系统提出，而不是靠人发现。
-
给原因，而不是症状
每个问题都带着原因，下一步因此是明确的。
-
工作台
在一个地方处理，而不是每一单都要开好几个界面。
-
处理留痕
做了什么，会成为这笔订单记录的一部分。
客户常问的问题
AI 会自动解决问题吗？
AI 可以解释问题出在哪并给出处理建议，并且通过与人相同的流程来执行，在您的规则要求处保留审批。哪些环节可以无人值守地运行，取决于您设定的规则——这是一项配置，而不是默认行为。
什么算异常？
任何意味着订单无法兑现承诺的情况：库存缺口、时效超期、发货问题、履约失败。