Transport management software, module by module

A transportation management system is judged on one question: can an order that arrives on Monday be planned, driven, proved and invoiced without anyone re-typing it. Shyftbase answers it with eight modules on one data model rather than one application with everything switched on. What follows is the map — how the work divides, which module to start with, and where this platform stops.

How the platform is put together

Every land-based freight operation runs the same sequence, whatever it calls itself. An order arrives. Someone decides which facility and which vehicle it moves on. A driver executes it. Somebody proves it happened. Then it is charged to a client and paid out to whoever moved it. Run that across four or five systems and one shipment ends up with three identities: an order row, a stop on a dispatch board, and an invoice line that reconciles to neither.

Shyftbase is cloud software organised as modules against that sequence. Orders enter through one intake surface, whichever of the five published channels they arrive on — an EDI document, an API call, a bulk file, a person at a keyboard, or a client's own portal. Mid-mile planning consolidates movements between your own facilities. Last-mile delivery runs the leg with a customer at the end of it. Route optimization sequences the stops inside either one. Multi-hub network management holds the stores, suppliers, hubs, links and routing tables the planners work against. Warehouse management is where freight is received, counted and picked. Automated billing turns a completed service into an invoice and carrier settlement turns it into a payout. Shyftbase AI reads the images and documents the rest of the system produces.

Modules are chosen rather than bought as a bundle, and which ones run is one of the questions a quote turns on. No price for any of them is published.

Which module answers which problem

The list above is the architecture. The table below is the buying decision, written from the symptom rather than the feature — most operations arrive knowing what hurts, not what it is called.

Two rules settle most of the sequencing argument. Fix the record before the reporting: a planning module changes what a vehicle does tomorrow, a billing module changes what a client is charged for what already happened, and no routing project rescues a disputed invoice. And take modules on both sides of a handoff: a planner bolted onto the same four systems leaves the re-keying exactly where it was.

Who buys it, and what changes by industry

The legacy site sold this platform three ways at once — by job title, by industry and by supply-chain stage — and ran a page for each. Those pages are consolidated here, because the platform did not differ between them. What differed was the entry point.

By job title. An operations manager is buying tomorrow's plan: which vehicle, which sequence, which window. A logistics director is buying the layer over it — dashboards configured to the metrics that director chose, and network status across hubs and providers, both of which live in multi-hub network management. A finance or accounting manager is buying the invoice and the payout, which are automated billing and carrier and provider payouts. An owner is buying the coverage claim itself: first mile, mid mile, last mile and the returns leg on one system instead of four contracts. Four different first modules, one platform underneath.

By industry. Two verticals were sold as programmes and are worth naming, because the requirement genuinely differs. Health care buys the stock record: levels in real time, product categorisation, each item's location across multiple sites, scan events from the driver app that record where and when, and client-facing views of inventory instead of a spreadsheet — all of which is the warehouse and inventory module. Robotics buys the two ends rather than the middle: sourcing across multiple countries for materials like metals, electronics and composites, and delivery with installation support at the end customer, which is one appointment rather than two in the planner.

By stage. Sourcing, manufacturing, storage, planning, delivery and returns were six pages describing the one sequence at the top of this page. Manufacturing is the boundary case: this moves material around a plant, it does not run the plant.

One claim from that material does not survive the move. Recall management was named for health care with no lot, batch or expiry field published behind it and no workflow of any kind, so it is not restated — which makes it the first question a health-care buyer should ask rather than the last.

Choosing a logistics platform, including this one

There is no honest way to write a comparison from inside a product. What can be written is the short list of questions that separate a platform from a set of applications sold together. Put them to this one as readily as to anyone else's.

• Does one shipment record survive the whole lifecycle? Ask, live in the demo, for a rate table to be changed and an already-invoiced shipment re-rated. One system does it in place; a suite exports, edits and re-imports, and that gap is the reconciliation work you inherit.
• What will the planner refuse to break? Vehicle capacity, a delivery window, a driver's legal day, a dock appointment — ask which of those is hard and which is a preference the solver trades away when the day gets tight.
• Where does "real time" come from? A driver-app scan, a telematics feed, a carrier's status message and a dispatcher typing are four sources with four failure modes. A platform that will not name the source is describing an estimate of an estimate.
• What do the people who are not your employees get? Carriers, installers, clients and suppliers are most of the parties on a delivery and none are on your payroll. A login, a shared link or a phone call to your office decides whether they use the system at all.
• What does the vendor say it does not do? A platform with no stated boundary has not been deployed often enough to find one.

What behaves the same way across every module

Four capabilities cut across the modules rather than belonging to any one of them, and each used to have a page of its own here.

Access is granular and audited. Permissions are set at user, role and group level, and access to features, data and functions is controlled down to individual fields. Carriers, clients, drivers and agents get their own permission sets rather than a shared login, with data segregated between them, and permission changes are logged with who made them, when, and what changed.

Onboarding and documents are one flow. New drivers, clients and carriers onboard through the same process, and contracts, documents and the required steps sit in one place rather than in an inbox. Proof of delivery is managed there too, which is where delivery disputes are won or lost.

Field work is mobile. There is a driver app and a separate scanner app covering barcode scanning, digital signatures, order approval and field data capture, with push notifications on a shipment status change, a new order or an urgent alert.

Feedback is part of the delivery. Surveys can be triggered by delivery completion or a service milestone, the tracking link a customer already holds is converted into a survey link, and results from star ratings to net promoter score compile into the same analytics.

Returns run on the delivery system, not beside it

There is no separate returns product here, and that is the design rather than an omission. Shyftbase carries a dedicated reverse logistics capability integrated with the forward environment, and the same modules do the work in the other direction.

A return pickup is linked to the original delivery it came from. Scheduling is automated against the customer's request, service availability and route optimization, and timed against the delivery routes already planned — a backhaul movement in everything but name, which is why returns belong to the routing engine rather than to a bolt-on. Pickup status is tracked in real time, item condition is documented, stakeholders are updated automatically and chain-of-custody records are kept for the movement. Billing links to returns automatically, and returned products can be consolidated through the network management module for a customer-to-destination reverse flow.

Two further behaviours are published: a return authorization workflow, and a recommendation of what to do with the returned item that is described as machine-generated rather than typed by a clerk. Neither appears in any module's capability list, the AI module included, so both are demo questions rather than settled facts.

What is genuinely not described, and is therefore not asserted here: how a return authorization is numbered, whether a return label is produced, which outcomes a recommendation chooses between — restock, refurbish, resale, recycle, scrap, return to vendor — and what triggers a refund or a credit note. What reverse logistics covers is in the glossary.

Limits, and what is not published

This is a coordination layer for land-based freight. It is not an ERP, not a general ledger and not a manufacturing execution system: it hands completed, rated transactions to the systems that own the books, and supports manufacturing by moving materials around it rather than running it. The ERP, accounting and WMS connectors are named on their own page.

Four things a buyer will ask for are not published anywhere in the source material, and are stated as gaps rather than filled in:

• Integration mechanics. The connected systems are named. Which objects sync, in which direction, at what cadence, and by connector, application interface, EDI or file exchange is documented for none of them. Make it the first demo question.
• Security posture. No certification, audit report, hosting region or retention period is published, and the only named controls anywhere are the SSL/TLS encryption and OAuth on the integrations page. A security paragraph with nothing filed behind it is worth exactly what it costs to write, on this site as on any other: ask who audited what, and when.
• Deployment time. Weeks rather than months for most mid-market operations — a shape, not a quoted figure. The two numbers in the older material disagreed with each other, so neither is restated; ask for a plan sized against your own system count instead of a number.
• Outcomes. No module page carries a measured customer result, because none exists that could be sourced, dated and attributed. Each argues from mechanism instead — the honest position, and a weaker one than a real number.

Availability is the one figure published: 99.99% measured uptime. The word to hold any vendor to is measured rather than promised — no service-level document, credit term or third-party attestation sits behind it, here or on most platforms you will compare it against.