mPorts

AI 电商运营操作系统

在一个地方,把整个商业运营跑起来。

每多接一个零售商、一个电商平台、一个仓库、一套系统,订单、库存与履约就更难管一分。mPorts 把它们收到一起——并由 AI 帮您的团队看清哪些需要处理、弄明白发生了什么,并把事情做完。

在您客户已经下单的渠道上运营

零售商、电商平台,以及它们背后的系统。每一个都有自己的规则、自己的文件格式,以及自己对“一笔订单”的理解。

  • Walmart Marketplace
  • Wayfair
  • Target Plus
  • GigaCloud
  • Mirakl
  • The Home Depot
  • Lowe's
  • Macy's
  • BJ's Wholesale Club
  • QVC
  • Houzz
  • Shopify
  • LingXing
  • Eccang
  • YQN
  • Mainfreight
  • SLM Fulfillment
  • EasyPost
  • ViteDirect
  • TrackingMore

此处列出渠道名称,用于说明 mPorts 在哪些渠道上运行。这不代表所列公司与 mPorts 之间存在合作、背书或认证关系;名称仅用于标识该渠道。

渠道变多,不该意味着人工变多。

这些系统本身都没有问题,各自也都在完成自己的工作。成本产生在它们之间的缝隙里——产生在每天有人手工核对、让两个系统对上口径的那些环节。

  • ERP
  • 电商平台
  • 订单管理
  • 仓储
  • 第三方物流
  • 承运商
  • 表格

横向滑动可以看到完整链路。每两个系统之间的空隙,都是有人在手工衔接。

一个互联的商业运营
  • 同一笔订单要在第二个系统里重新录入一遍,因为两边并不共享同一条记录。
  • 两个系统的库存对不上,而最先发现的往往是客户。
  • 要回答“这单为什么延迟发货”,需要打开四个界面外加一张表格。
  • 决策依据的数字,没有人能追溯到它的来源。
  • 每增加一个销售渠道就要增加一个人,因为这些工作无法规模化。
  • AI 试点在演示里跑得很好,却始终没有进入真实的业务流程。

系统有很多,答案应该只有一个。

订单从四面八方进来,发货却发生在别处。mPorts OMS 在中间保留一份共同的记录——您承诺了什么、现在进行到哪一步、花了多少钱——让一个问题只有一个答案,而不是四个界面。

需求从哪里来

mPorts OMS

一份共同的记录

  • 订单
  • 库存
  • 履约
  • 发货
  • 异常

工作在哪里发生

订单

所有订单,都在一个地方。

不必再为了搞清楚“现在到底怎么样了”,去挨个打开零售商后台、仓库系统和表格。

mPorts OMS 把所有已连接渠道的订单收进来,并一路跟到履约与发货。"这单到哪了"只需要看一个界面,而不是四个。

  • 看见需要处理的订单——延迟、卡住、失败的会排到最前面
  • 弄清发生了什么——从零售商到仓库再到发货,完整可追
  • 更快地解决问题——看清订单卡在哪一步,以及下一步要做什么

随时知道每一笔订单进行到哪一步

mPorts OMS 会告诉您每一笔订单现在在哪、被什么卡住、下一步需要处理什么。下面这个视图使用与实际产品相同的导航和订单阶段,其中的客户数据已被移除。

订单 / 订单指挥塔

订单指挥塔

纵览每一笔订单在零售商、OMS、仓库、承运商与回传确认之间所处的位置。

  1. 已导入
  2. 已路由
  3. 已提交仓库
  4. 仓库已接收
  5. 已发货
  6. 已有跟踪号
  7. 零售商已确认

七个阶段。订单一旦卡住,一定卡在某个有名称的阶段上——这正是“这单为什么延迟”能够被回答的原因。

此视图依据 mPorts OMS 实际界面还原,客户数据已移除。

库存

有货就卖,没货不卖。

超卖要付两次代价:一次是向客户取消订单,另一次是渠道给您的考核评分。

订单不断进来的同时,mPorts OMS 让各个零售商、电商平台与仓库之间的可售库存保持一致。

  • 一个库存视图——各仓库位有多少可售,一目了然
  • 分渠道控制——每个渠道能卖多少,由您来定
  • 避免超卖——订单进来时,可售数量同步保持一致

履约

每一单,都从正确的地方发出。

这一单该从哪个仓库发?答案取决于库存、距离、成本,以及您对客户作出的承诺——而当第一个方案行不通时,答案还会再变一次。

mPorts OMS 决定订单从哪里履约;方案出问题时它会告诉您,而不是等到变成客户投诉才被发现。

  • 为这一单挑选合适的发货地点
  • 履约失败时知道失败了,并知道原因
  • 在变成客户问题之前重新安排

发货

让每一笔发货、每一个渠道都保持同步。

货出了仓库并不算结束。要等零售商拿到跟踪号、客户能查到物流,这笔发货才算完成。

mPorts OMS 负责创建发货、处理面单,并把跟踪号回传给需要它的那个渠道。

  • 创建发货与承运商面单
  • 跟踪号回传给对应的零售商或电商平台
  • 缺失与延迟的跟踪号会被主动提示,而不是等人发现

EDI

按零售商要求的方式与他们对接。

大型零售商不会问您愿不愿意用 EDI。采购订单、回执、发货通知与发票会按他们规定的格式发过来,也必须按同样的格式回过去。

mPorts 通过 EDI 与零售商对接;而这些单据所影响的订单、库存与履约,就在您处理其他事情的同一个地方管理——不需要您的团队再单独登录另一套系统。

  • 采购订单进来,回执发回去
  • 发货通知与发票,按零售商要求的格式
  • 由此产生的订单,与其他所有渠道一起运营
  • 我们不会声称的:EDI 是免费的,或每种格式对每个零售商都已上线

连接

继续用您已经在用的系统。

您的 ERP、您的仓储系统、您的第三方物流、您的承运商。mPorts 把零售商与电商平台连到企业已经在运行的这些系统上,而不是要求您先把它们换掉。

每个系统只接一次,并在一个地方维护,而不是每个应用各建各的连接。新增系统只需接一次,系统出问题时也只需在一个地方排查。

  • 电商平台与销售渠道
  • 仓储与第三方物流系统
  • 承运商与物流跟踪服务
  • 应用程序接口

不用去找问题,直接问。

要弄清一件事为什么出错,通常得打开好几个系统,再把答案拼起来。另一种方式是:用您跟同事说话的语气,把问题问一次。

运营人员向 mPorts AI 询问某个零售商的订单为何延迟,以及 AI 给出的回答 示例

我们在 Lowe’s 的订单今天为什么延迟?

有 37 笔订单需要处理。

  • 24 在等仓库回执
  • 8 存在库存冲突
  • 5 已发货,但跟踪号还没回传

建议的处理动作

  • 重新提交给仓库
  • 核查库存冲突
  • 重新回传跟踪号

按您的规则需要审批的地方,未经人审批,任何操作都不会被执行。

这是对“问题是什么样、答案是什么样”的示意。其中的数字是虚构的——本网站不会公布真实的订单数量,因为那属于客户的经营数据。

它在运营里工作,而不是在旁边

它用的就是您团队在用的那份订单、库存、履约与发货信息——直接读取,而不是从界面上去猜。

  1. 01

    观察

    看清已连接的渠道与系统中正在发生什么。

  2. 02

    调查

    顺着问题涉及的订单与系统一路回溯。

  3. 03

    建议

    说明下一步该做什么,并给出依据。

  4. 04

    审批

    按您的规则该由人决定的地方,由人决定。

  5. 05

    执行

    通过与人完全相同的流程,完成已批准的工作。

  6. 06

    留痕

    记录做了什么,以及变更前后分别是什么样。

大多数 AI 只能从外面看您的商业系统。

大多数 AI 助手的工作方式,是去看别的软件,再去猜正在发生什么。mPorts 的 AI 直接在 OMS 内部工作,而订单、库存与履约的信息本来就存在那里。它用您团队看的同一份信息来解释问题;而真要动手改什么,仍然要走您原本的规则与审批。

从外面工作

对于身处系统之外的工具,这是唯一可行的路径:看软件显示了什么,推断它意味着什么,然后基于这个理解去行动。

AI 助手

推断正在发生什么

商业系统

  1. 去看其他软件
  2. 推断界面上的内容是什么意思
  3. 基于这份理解采取行动

从里面工作

mPorts OMS 本身就存着订单、库存与履约信息,因为业务本来就在它里面流转。AI 直接读取这些信息;而它要做的任何变更,都走与人完全相同的步骤与审批。

商业系统

  • 订单
  • 库存
  • 履约
  • 发货
  • 已作出的承诺

mPorts OMS 中的 AI

  1. 基于已经记录下来的信息解释问题
  2. 给出处理建议,并说明它看了哪些信息
  3. 按您的规则,需要审批的地方等人审批
  4. 通过日常流程完成变更

其他软件

这里说明的是 AI 从哪里获取信息、变更以什么方式发生,而不是在声称这套 AI 比别的更准确或更能独立行事。运营信息由 mPorts OMS 保存,AI 基于它工作,实际变更由日常流程完成。

AI 在这里被允许做什么

AI 给出的运营建议,只要您的规则要求审批,就必须先经人审核批准,才会被真正执行。

每一项重要变更都会被写下来:谁或什么发起的、影响了哪条记录、做了什么、变更前后分别是什么样。AI 发起的工作在您事先设定的规则下运行,并保留完整的执行记录。

这些是运营原则与产品能力,不是一个独立售卖的产品。本网站也不会把它们包装成一个产品卖给您。

客户最先问的问题

我们不需要替换您的核心系统

mPorts 的设计前提,是与企业现有系统并行运行、与它们对接,而不是要求先把它们换掉。

某个具体系统能否接入,取决于对应的连接是否已经做出来。这是一个有明确答案的问题,我们更愿意在一开始就把它讲清楚,而不是暗示一种我们尚未实现的兼容性。

  • 您的记录系统继续运行,也继续作为业务记录的依据
  • mPorts OMS 与它们对接,而不是替换它们
  • 您的团队,以及协助他们的 AI,都在这层连接之上工作

第二个产品

触达更多企业买家。

mPorts Distribution 是面向制造企业、品牌方、分销商与企业采购方的 B2B 商业与分销平台。

企业买家在这里发现商品、发起询价、下单,并处理售后事宜。它与 mPorts OMS 是两个独立的产品,也分别采购——多数企业都是先上其中一个。

  • 为企业买家设计的商品目录与选品体验
  • 询报价与采购流程,而不只是一个购物车
  • 下单与订单历史记录
  • 售后的履约进度与退货处理

让系统真正落地的服务

软件很少单独失败,它往往失败在与企业真实流程、数据和决策衔接的那一环。以下服务正是覆盖这一段路程。

  • 落地实施

    AI Forward Deployed Engineering

    驻场式工程服务,把 AI 从试点推进到您真实系统中的实际业务流程。

    AI Forward Deployed Engineering
  • AI 可见度

    Generative Engine Optimization

    让企业经过核实的知识变得准确、结构化、可被引用,从而使 AI 系统能够正确理解并呈现您的企业。

    Generative Engine Optimization
  • 业务变革

    AI Commerce Transformation

    围绕可衡量的商业运营目标,对齐业务流程、数据、系统与 AI。

    AI Commerce Transformation
  • 基础建设

    Integration & Data Engineering

    连接运营系统并统一业务信息口径,使数据能够被稳定、一致地使用。

    Integration & Data Engineering

适合哪些企业

四个常见的起点。问题的形态往往相似,但最痛的位置各不相同。

  • 供应商与制造企业

    您负责生产,需要一条触达海外企业买家的通路,以及订单进来之后能够支撑服务的运营能力。

    供应商与制造企业
  • 品牌与卖家

    您在多个渠道销售,每新增一个渠道就增加一层协调工作,而这些工作无法靠加人来解决。

    品牌与卖家
  • 第三方物流与履约

    您为其他企业提供履约服务,因此两套运营必须对得上:请求了什么、发出了什么、现在到哪了。

    第三方物流与履约
  • 零售商

    您依赖供应商与第三方物流,需要他们的信息以可直接采取行动的形式到达。

    零售商

我们不会对您说的话

您在本网站上不会看到对接数量、成本下降百分比、系统可用率或客户 logo 墙。并不是因为这些不重要,而是因为对于其中任何一项,我们目前都还没有愿意为之负责的证据。

这里的每一句事实陈述,都对应一条有明确来源、有复核日期的受管控依据。当我们能够拿出数字时,我们会公布数字。在那之前,不写才是诚实的答案。

客户常问的问题

mPorts 会替换我们的 ERP 吗?
不会。mPorts 的设计前提是与企业现有系统并行运行、与它们对接,而不是要求先替换掉它们。您使用的具体 ERP 能否接入,取决于对应的连接是否已经做出来——直接问我们,我们会如实回答。
mPorts Distribution 与 mPorts OMS 有什么区别?
Distribution 是企业买家找到并采购您产品的地方。OMS 是您的团队处理“之后发生的事”的地方——覆盖所有渠道的订单、库存、履约与发货,包括那些与 Distribution 无关的渠道。
必须整套一起上吗?
不必。各层次可以拆开使用。哪几层适合您,取决于目前工作最吃力的环节在哪里——这也是最值得先聊清楚的一件事。
AI 运营具体做什么?
它遵循固定路径:您提出问题,它检查已连接的系统、弄清当前状况、给出处理建议,在您的规则要求处等人批准,再由负责这项变更的系统执行,并记录结果。它不会自行替您经营业务。

让商业运营变得更容易。

告诉我们目前最吃力的环节在哪里。如果 mPorts 不是合适的答案,我们会直接告诉您。