A phased concept for a client-facing freight portal backed by an internal operations platform, informed by how modern forwarders structure the shipment lifecycle from quote to delivery.
What sits behind the platform
The platform revolves around a central customer account where a client manages the entire shipment lifecycle. It brings freight forwarding, customs, logistics and supply-chain data into one place, including PO-level and SKU-level visibility.
In practical terms this is much closer to a customer logistics portal, or a lightweight TMS, than a simple booking engine. Everything a client needs hangs off the shipment record rather than living in scattered emails and spreadsheets.
Quote and booking workflow
A booking can be initiated through the customer interface or programmatically through a Booking API. That API supports creating a booking request, listing bookings, retrieving individual booking details, associating metadata with bookings, and working with booking line items subject to additional permissions. The booking endpoint effectively replicates the booking-request functionality available in the user interface.
The front-end booking wizard would collect the following, step by step:
An inbound workflow lets the customer select an international or domestic origin and enter either a supplier location or a port. If a supplier location is entered, pickup can form part of the service.
The clever part
For complex international freight, the right model is not simply "enter details, calculate price, pay, done." A stronger approach is a hybrid flow.
Standard lane, known carrier tariff and standard cargo can be priced instantly.
Unusual dimensions, dangerous goods or difficult destinations route into a manual quote workflow.
Negotiated rates are displayed after login.
Public indicative pricing, or a quote request, until an account is established.
Customer dashboard
Active shipments, upcoming departures, delayed shipments, customs holds and recent documents.
A guided, multi-step booking wizard for new bookings.
All bookings, each with a clear status.
Map and timeline view with major milestones and predicted arrival.
Invoices, packing lists, bills of lading, air waybills, customs documents, certificates and PODs.
Communication attached to the actual shipment, not random email chains.
Shipment status flow:
The document backend
Documents should be treated as structured objects attached to a shipment, not as miscellaneous uploads. A Documents API would support listing documents, retrieving document details, creating documents and downloading document contents. The client logs in and sees every document against the relevant shipment, while the operations team has the same information internally, with additional controls and notes.
Architecture
Rather than cloning a full enterprise platform, the recommendation is two views over the same shipment data: a clean customer portal and a controlled operations portal.
API and integration layer
Integration is where large platforms are most advanced, connecting logistics data to external systems such as ERPs through APIs and EDI. We would not attempt every integration in version one. Instead we design the architecture so capability can be layered in over time.
Our view for ThinkPrime
We would not try to build a full clone. That becomes a very large software project. We would build a genuinely useful ThinkPrime Client Portal with a deliberately limited first release, connected to the ThinkPrime website we have been developing.
Guided freight wizard.
Current and previous freight bookings.
Milestone timeline, with a map where tracking data is available.
All files organised by shipment.
Communication attached to each booking.
Saved addresses, suppliers, contacts and frequent routes.
If a customer regularly ships the same cargo from Shanghai to Sydney, they should not complete the whole form every time. They select a previous booking and adjust only what changed.
That makes the platform genuinely useful, rather than an expensive-looking customer login.