两套运营，一份状态
履约请求是一次交接，而交接正是两边最容易开始对不上的地方。他们的系统说一套，您的系统说另一套，差异最后以邮件的形式浮现，而不是以一条谁都能看到的差异记录。
有用的结果并不是再多一个门户，而是请求、发货与确认在两边是同一条记录，因此一个问题只有一个答案。
从请求到确认
每个阶段都是有名字的状态，而不是谁手工填进去的一个说明。一旦卡住，它一定卡在某个具体位置——这正是让"恢复"成为一套流程、而不是一次调查的原因。
请求来自
mPorts OMS
走同一条生命周期
- 请求
- 仓库路由
- 库存分配
- 拣货打包
- 面单
- 发货
- 确认
双方都能看到
履约团队在这里处理什么
-
履约请求
请求通过已连接的系统进来，而不是以表格和邮件附件的形式。
-
仓库路由
在拣货之前决定由哪个仓发出，而不是等问题出现之后。
-
库存状态
在库多少、已被占用多少，以及这对下一个请求意味着什么。
-
面单与发货
发货创建与承运商面单，属于同一条生命周期的一部分。
-
跟踪与确认
确认信息回传给发起请求的一方，而无需他们访问您的系统。
-
异常恢复
在已经出问题之后的履约恢复——这是常态，值得为它做设计。
哪些能连，以及哪些我们会先确认而不是想当然
mPorts OMS 可对接仓储与第三方物流系统，用于下发履约请求与交换库存，同时也对接电商平台、零售渠道与承运商。
您使用的具体 WMS 或承运商是否已经接入，取决于是否已有对应的集成。我们会如实告知，而不是想当然——尚不存在的集成是一个需要评估的范围问题，而不该是签约之后才发现的意外。
客户常问的问题
- 我们的客户需要 mPorts 账号才能看到他们的订单吗？
- 把请求与确认保存为同一条记录，意义就在于双方看到的是同一份状态。具体某个客户以什么方式查看，取决于他们如何接入——通过自己的系统，或者直接接入。
- mPorts 能连接我们现有的 WMS 吗？
- mPorts OMS 可对接仓储与第三方物流系统。您使用的具体服务商是否已接入，取决于对应的连接是否已经做出来——我们会先确认，而不是想当然。
- 这会取代我们的 WMS 吗？
- 不会。WMS 管的是仓库内部的作业，mPorts OMS 保存的是围绕它的那幅图——请求了什么、承诺了什么、实际发出了什么、成本是多少——并把两者连接起来。
- 发货出问题时会怎样？
- 恢复一笔失败的履约，是日常流程的一部分，而不是旁边另开一套；每一项重要变更都会被记录下来：谁做的、做了什么、变更前后分别是什么样。