mPorts
简体中文

Part of mPorts OMS

What needs attention, why, and what to do next.

What needs attention right now? Problems in mPorts OMS brings the orders that are late, stuck, failed or waiting on something to the top, gives each one a reason, and is the place where your team works them and records what was done. Inside the product these are called exceptions.

Talk to mPorts Back to mPorts OMS

Most orders are fine. The job is almost entirely about the ones that are not, and the cost of a bad system is that finding them takes longer than fixing them.

An exception is only useful if it names a cause. “Order 4471 is late” is a symptom; “Order 4471 is late because the allocated location is short two lines” is something a person can act on in one step rather than four.

Shipments that stopped moving, with the reason

A real example: labels were created and then nothing happened. Each row has been idle for more than seventy days, and the product says so in plain words rather than leaving it to be discovered.

The mPorts OMS shipment tracking screen, listing shipments with a status of Label Created, a days-idle count and the note “Not picked up yet”.
Shipments with a label created and no carrier scan, with the days idle on each. Tracking numbers are redacted: a carrier tracking number is public on the carrier’s own site. Customer-sensitive information has been redacted from product screenshots.

One exception, worked end to end

Worked example

An order cannot be fulfilled from the location that was chosen for it.

  1. Signal

    Fulfillment recovery flags the order: the assigned warehouse cannot execute the plan.

  2. What mPorts shows

    The blocker, named in plain terms, so the person picking it up does not start from a blank screen.

  3. Investigation

    The other locations that hold the stock, what each would cost to ship, and whether the promised date still holds.

  4. Recommendation

    The fix that matches this blocker. Each blocker mPorts can raise has a known next step.

  5. Approval

    The operator confirms the step that changes the order. A step that writes never runs on its own.

  6. Action

    The order is replanned and resubmitted through the same steps a person would use.

  7. Record

    The exception, the decision and the outcome stay on the order, in the order they happened.

  • Detection

    Problems raised by the system at every step, rather than noticed by a person.

  • Cause, not symptom

    Each problem carries its reason, so the next step is obvious.

  • Workbench

    One place to work them, instead of several screens per case.

  • Recorded resolution

    What was done is part of the order's record.

Questions buyers ask

Does the AI fix problems automatically?

AI can explain what went wrong and suggest what to do, and it acts through the same steps a person uses, with approval wherever your rules require it. What runs without a person watching depends on the rules you set — it is something you configure, not a default.

What counts as an exception?

Anything that means an order will not do what was promised: inventory shortfalls, missed SLAs, shipment problems, fulfillment failures.

Related reading

Operate every channel from one place.

Talk to mPorts Back to mPorts OMS