A logistics customer no longer wants to pick up the phone to find out where their parcel is. They open an app, type a tracking number and expect a map, a status and a realistic ETA. If they don’t get that from you, they will find a carrier who gives it to them. That is why shipment tracking and a customer portal have stopped being a nice extra and become part of the service itself.
In our experience, the bottleneck is rarely the idea for features. The hard part is building a track and trace that can carry the traffic, plug into your TMS and telematics, and still make sense to a non-technical customer. Even without showing a specific rollout in this industry, we provide the people and skills who design and maintain such systems, in a team augmentation or dedicated team model.
What does a logistics customer actually expect today?
Expectations have shifted firmly toward self-service: the customer wants to handle things on their own, at any hour, without reaching an account manager. That translates into a few hard requirements for the software.
- Real-time visibility - where the shipment is and what has happened to it.
- A trustworthy ETA - not “by the end of the week” but a concrete time window.
- Proactive information - a notification before the customer starts to worry.
- A single point of access - one portal showing every order, not scattered links.
Meeting these expectations cuts call volume, because most “where is my shipment” questions get answered without a human.
How do you design a shipment tracking page (statuses, events, ETA)?
A track and trace page looks simple, yet it is event-driven underneath. Its core is the shipment event history (event log): received at the warehouse, loaded, transferred at the hub, out for delivery, delivered. Each event carries a timestamp, a location and its source, and from that we derive the current status and the projected ETA.
We design the data model so that a technical event (a raw scan, a telematics signal) stays separate from the status shown to the customer, which lets us add a source or rename statuses without rebuilding the screen. We compute the ETA from historical data and the vehicle’s current position rather than a fixed plan, because only then is it worth anything.
How do you build a customer portal and a partner portal (authentication, roles)?
A portal is where the customer logs in to the full picture of their orders, while a partner or carrier sees only their slice. Authentication and roles are the crux, because they decide who sees what.
- Authentication - email/password, corporate sign-in (SSO, OAuth) and optionally a second factor.
- Role model (RBAC) - shipper, consignee, freight forwarder, carrier, account administrator.
- Multi-tenancy - one portal serving many customer companies, with data kept apart.
- Data permissions - the customer sees their orders, the partner their tasks, nobody else’s.
The biggest trap here is not the look but cleanly isolating data between tenants, so we design the permission split from day one rather than bolting it on later.
How do you handle proof of delivery (POD: signature, photo, geolocation)?
Proof of Delivery closes a shipment’s lifecycle and often serves as evidence in disputes. These days it is rarely paper: the driver confirms delivery in a mobile app, and the system gathers a full set of proofs and pins them to the order.
That usually means a recipient’s signature on the screen, a photo of the parcel or the drop-off spot, and the geolocation and timestamp from delivery. We design this for offline work, because a driver on the road regularly loses signal: the app stores the POD locally and syncs it once the connection returns, so no proof is lost. The confirmation then appears in the customer portal as part of the shipment history.
How do you build notifications and exception alerts (events)?
Good track and trace doesn’t wait for the customer to check the status; it sends a signal when something matters. It helps to separate two kinds of message: routine progress notifications and exception alerts, meaning situations that need a reaction.
- Event notifications - received, out for delivery, “out today”, delivered.
- Exception alerts - delay, failed delivery, damage, stuck in customs.
- Channels - email, SMS, in-app push, and a webhook for system customers.
- Rules - who gets which alert and after what time an escalation fires.
We build these alerts on the same event stream that feeds the tracking page, so the customer and the operator always see the same thing.
How do you connect it to TMS and telematics?
A portal is only as good as the data flowing into it. That data rarely originates in the portal itself, so the real work is integrating with the TMS and with vehicle telematics. From the TMS we pull orders, routes and operational statuses; from telematics and the drivers’ mobile devices, GPS position and on-route events.
We tie these sources together with an integration layer, usually through APIs and webhooks, and through files (EDI, CSV) where a partner exchanges data in batches. Normalisation matters: different carriers and devices describe the same events differently, so we map them to a shared status vocabulary before they reach the customer. The portal then shows one consistent picture regardless of how many systems feed it.
Which skills do we provide for a project like this?
We shape the team around the specific scope, not “just in case”. A track and trace project spans an event-driven backend, a driver app and integrations, so it usually needs several roles.
- A backend developer building the event model, the APIs and the status and ETA logic.
- A frontend developer assembling the customer portal and the tracking page.
- A mobile developer owning the app with POD and offline work.
- An integration specialist wiring up the TMS, telematics and partner data exchange.
- A DevOps specialist standing up the cloud, CI/CD and monitoring for production traffic.
We fill these roles with specialists vetted before the start. Optionally we add an AI/Data layer (within the RITS Group, our AI/LLM/data teams develop the LLM and data competencies) for ETA prediction or spotting route anomalies, but we treat that as a skill set, not an off-the-shelf box.
How do we do it at RITS?
We work as a nearshore partner from Poland, with experience in industrial projects and in systems that join devices, cloud and apps. We don’t pretend to have a ready-made track and trace in a drawer; instead, we give you the people who will design and maintain that system alongside your team.
- We staff roles against the project’s spec and verify skills before anyone joins.
- We come in under a team augmentation or dedicated team model, depending on whether you already have a core team.
- We work in a close time zone, so code reviews and meetings run without a long ramp-up.
- We design track and trace end to end: from the event stream, through POD, to the integrations.
For a new product it is more often a custom software project; for developing an existing portal, team augmentation. We laid out the differences between these models in our article on IT engagement models.
Where to start with tracking and a portal?
Start from the single customer question that hits support most often (usually “where is my shipment and when will it arrive”). Answering it defines the minimal event model, the first track and trace screen and the integration to build first. You add the rest of the portal in layers once that foundation works.
Building shipment tracking or a logistics customer portal? Let’s talk - we’ll match a team and an architecture to your track and trace.