Tracking one shipment is easy. Tracking ten thousand across six carriers isn't.

If your WMS works well, nobody's suggesting you replace it: a mature WMS does things — pick path optimisation, location management, radio frequency — that would be foolish to rewrite.

The point is that a WMS governs the warehouse, not the promise to the customer. It knows where an item sits and how to pick it most efficiently, but it doesn't know that this particular order should have shipped yesterday because the customer has a line down. It typically knows one warehouse while you have three. And it almost never knows about returns, carrier disputes or the customer portal.

Pwas sits above: it reads pick and ship events from the WMS, joins them to ERP orders and carrier statuses, and holds the level that today has no owner — the order status as the customer sees it. At sites with no WMS it can also cover basic operations: pick lists, terminal confirmations, outbound control.

Keeping up is a question of where carrier knowledge lives. In the traditional approach every carrier is hand-written code: when something changes, someone has to find that code, understand it and modify it — and meanwhile shipments to that carrier stop.

In Pwas a carrier is a declaration: which calls it exposes, which fields it wants, what it returns, what to do when it errors. Changing a field or adding a service is an edit to that declaration, not a rewrite. The same goes for rates and selection rules: they're readable conditions — weight > 30kg and zone = islands — that whoever manages transport can read, challenge and have changed without a development cycle.

One thing no technology removes: if a carrier changes its service, someone has to notice and update the declaration. The difference is that the work takes an afternoon instead of a week, and doesn't require touching anything else.

In most projects the customer portal is the most expensive part, because it's an additional application to design, build and keep in sync with the main system. It's also why so many distributors have been postponing it for years.

Here the arithmetic changes, because the portal isn't a second system: it's a different reading of the same model, filtered by permissions. When you declare that a customer can see only the orders they own and only certain fields, that rule holds everywhere — internal screens, portal, automated interfaces — because the system enforces it rather than each piece of software remembering to.

In practice, giving customers access stops being a project of its own and becomes a decision: which information do we want to show, and to whom. Which is the right question.

It doesn't help, or helps little, where better deterministic algorithms already exist: route optimisation and reorder calculation don't magically improve because you put a language model on them.

It helps a great deal in three places. On messy inbound documents: orders arriving by email in twenty formats, scanned loading lists, carrier confirmations as PDFs — read and turned into structured data, with human confirmation where the risk warrants it. On operational questions: "which orders promised for tomorrow haven't left the Bologna warehouse?" gets an immediate answer, with no report to build. On repetitive correspondence: a draft reply to a chaser, pre-filled with the shipment's real status, that a person checks and sends.

In every case the same non-negotiable rule holds: the agent has no free access to the system. Every action goes through a plan verified against the real permissions of the user who asked, with explicit limits and a complete trace. An agent doesn't issue a credit note because an email suggested it: it can propose one to whoever has the authority to approve it.