Skip to content

Logistics · Web

Reista

A client portal for a haulier: consignment status, route and paperwork for every delivery, with no call to the dispatch desk. The portal was the smaller half of the job — before it, no system held a status at all: it lived in drivers’ messages and in a dispatcher’s memory.

Role
Product design, frontend, backend
Timeline
4 months
Stack
Next.js · TypeScript · PostgreSQL

What changed

−70%
calls to the dispatch desk: around 700 a week before, around 210 after. The second figure is the fourth month after opening; in the first weeks there were more calls than before the portal existed.
518 → 28
calls a week about status and paperwork. The other subjects — changes to an order and genuine exceptions — stood at around 180 a week before, and stand there still.
18% → 4%
of consignments in transit whose latest event is more than a day old. The first figure is the fourth week after events went live, the second three months later. The gap was closed not by technology but by the gap becoming visible from outside.
same day
is when the signed delivery note appears in the portal. It used to take a day or two: the customer emailed, and accounts went looking for the scan.

What did not change is the transit time. The portal made no truck faster: cargo takes exactly as long as it always did, and no fewer dates are missed. What changed is when a missed date becomes known: the customer gets an email at the moment the dispatch desk learns of the delay, rather than two days later and from their own consignee.

Before

Only the dispatch desk knew where the cargo was. A client called, a dispatcher opened the consignment record and read out what was on the screen — and the screen held the order, the run and the planned date. Where the cargo actually was, the screen did not know: the dispatcher filled that in from the driver’s messages and from the morning round of calls to subcontractors.

  • No program held a status. The operations system knew a consignment had been accepted and later invoiced; everything in between lived in drivers’ messages, in the morning round of calls and in the head of whoever ran that lane. While that person was on holiday, the lane answered its customers worse.
  • Around 700 calls a week to six dispatchers. Three quarters of them asked where the cargo was or for a copy of the paperwork: questions only a dispatcher could answer, and only while at their desk.
  • A customer heard about a delay last, usually from their own consignee waiting for the truck. The dispatch desk knew by mid-morning but had nothing to warn anyone with: no list of who a given delay concerned existed.

What we built

  • A portal where each consignment shows its latest event with time, place and source, and beside it the whole route: what is confirmed and what is still a plan.

  • Notifications in the portal and by email: out for delivery, delivered and any move in the planned date by default, the rest switched on by choice.

  • Shipping documents download from the same place, with no request to the dispatch desk: a copy of the signed delivery note appears on the day of handover.

Outcome

Dispatchers stopped reading the screen out loud: calls dropped by 70%, and the ones left are about exceptions and changes to an order — the places where a person is needed rather than a screen. But it was not the portal on its own: first the haulier got events, then those events became visible from outside, and only then did people start recording them on time.

The client

A regional groupage haulier: four depots, its own trucks and subcontracted ones, around 2,100 consignments a month, 540 customer companies. An average consignment travels for four days and passes through two depots. Six people work the dispatch desk, each covering their own lanes.

A consignment is not a truck. It is a few pallets inside somebody else’s truck: one trunk run carries consignments for ten to fifteen companies, and each drops off at its own depot. So the question a customer asks — where is my cargo — is not the question of where the truck is: a consignment has a history of its own, and it overlaps with the run’s history along a single leg.

The brief

What the client asked for
Build a client portal: the customer signs in and sees where their cargo is. It was scoped at a couple of months — the data exists, it only has to be shown.
What the brief turned into
The data did not exist. The consignment record had a status field with eleven values; three were used in practice, and two of the three only after delivery. Between pickup and handover the database said nothing. That made the portal the second and smaller half of the work. The first half was giving the haulier a record of where the cargo is, and someone to keep it. The portal is not the shop window here, it is the reason: while only a dispatcher sees a status, it can go unrecorded; once the customer sees it, it cannot.

Why the obvious route was closed

The portal itself is the thin part. The hard part sat upstream, in where the events come from: they have to be captured off people busy with something else, and off trucks half of which belong to somebody else.

The haulier’s operations system
An off-the-shelf transport package on the vendor’s support contract: orders, runs, tariffs, invoices. Nobody was going to let us rewrite it, and there was little point — the one thing we would have added is a status, and a status was exactly what it did not have. The split settled itself: it stays the source of what a consignment is and which order it belongs to, while everything that happens to that consignment lives with us. It exposes a read-only mirror of its database, and not one row of ours goes back into it.
Subcontracted trucks
In peak season 47% of runs go on subcontractors’ trucks. Their drivers are not employees: you cannot put an app on their phone or make them press a button. Anything leaning on a driver’s action covers half the volume — and a portal that knows about half the consignments is worse than none, because a customer sees one empty record and goes back to the phone.
Telematics
The trackers are on the company’s own trucks. Subcontractors either have none or will not share the feed. A dot on the map for one consignment and blank space for the one next to it is not a partial feature, it is a promise kept every other time.
Work on the depot floor
A depot hand has both hands full, and in season he will not fill in a form — and season is exactly when the data matters most. An event has to be captured by a movement he already makes: one second, no keyboard. Otherwise it is not captured at all, and you find that out a month after launch.
What must not go outside
The internal consignment record holds the subcontractor’s rate, the driver’s phone number, the plate and the make-up of the run — and the run is groupage: ten to fifteen other companies’ consignments ride alongside. That record cannot be opened to a customer whole, or nearly whole.

How the work ran

  1. 01

    Where a status comes from

    3 weeks

    Two weeks sitting beside the dispatch desk, listening to calls and tagging each one by subject — that is where the 700 a week and the three quarters about status and paperwork came from. In parallel we worked out what the operations system actually holds. The output was not a portal mock-up: it was a list of events and an answer to who can confirm each one without stopping their own work. The list started at twelve events and ended at six — anything with nobody to confirm it was struck out.

  2. 02

    Events

    6 weeks

    A database of our own: consignment, run, event, and the event’s source. Reads from the operations system, writes only to ourselves. A depot screen and scanners at four sites, and handover marked from the driver’s phone. Half the stage went on a pilot at one depot: fields came off the form one at a time until only a scan and a single button were left, and the screen itself moved from a desk to a post by the loading door — a depot hand does not walk away from the pallet to record something.

  3. 03

    The portal

    4 weeks

    The consignment list, the record with its route, the documents, users, subscriptions. Inside a customer company people got separate logins instead of one shared account: the logistics manager, the accountant and the director come for different things and subscribe to different things. The default subscription is out for delivery, delivered, and any move in the planned date — the call log showed people were not calling at random but the day before the date they expected. The other four events can be switched on, and rarely are.

  4. 04

    Opening in waves

    3 weeks

    First 40 companies accounting for 55% of consignments, then everyone else two weeks later. In the first days the calls went up rather than down, and that was the point: a customer could see that nothing had been recorded on their consignment since Thursday, and called about exactly that. The stage turned out to be less about launching than about closing those gaps: two depots got a second scanner, and the morning round of calls to subcontractors started landing in the database instead of a notebook.

Technical decisions

The stack answers to a portal read far more often than it is changed: Next.js renders on the server, so a link out of an email opens on a status rather than a spinner; PostgreSQL stores the events and polices the queries so nobody else’s consignment can fall into a result set; TypeScript keeps one event vocabulary across server and screen — there are six of them, and a seventh cannot appear without going through the interface.

  • A status field replaced by events

    The status field described the invoice, not the cargo, so we did not try to fix it. In its place are records of things that happened: type, time, place, who marked it. Six types: picked up, received at depot, loaded onto a run, arrived at destination depot, out for delivery, delivered. A status is stored nowhere — it is the latest event. The consequence matters more than the model: a stale status stopped being a hidden data defect and became a visible line — the last event was Wednesday at 14:20, and that is all anyone knows.

  • One movement per event

    The label was already on the pallet: a depot hand sorted cargo by lane from it, but the code on it was for the eye and nobody ever scanned it. Four depots got a scanner and a screen where a scan is followed by one of two buttons, received or loaded. Handover is marked by the driver from a phone, as a photograph of the signed delivery note. One action yields both the event and the first copy of the document, and that copy reaches the customer long before the paper original gets to their accounts department.

  • The map shows the route, not the truck

    The company’s own trucks carry trackers and the subcontracted ones do not, so there is no live dot in the portal for anybody. The map draws the consignment’s way through the depots: what has been passed, when, and on what evidence; what is left, and by which planned date. That route is equally honest for a company run and a hired one, and it never has to be explained to a customer who saw a moving dot yesterday and does not see one today.

  • A projection goes out, not the record

    The portal does not read the internal consignment record: it reads a separate table carrying only the fields a customer is allowed to see. The cut by company is not in the screen code but in the database itself — a PostgreSQL row-level policy applies to every query, including the ones somebody writes a year from now. Forgetting a condition in one query is easy; getting around a rule the database applies is not.

  • The portal does not finish the dispatcher’s sentences

    A status is never inferred forward. If the last event is arrival at the destination depot on Tuesday, that is what the portal says, rather than that the cargo is in transit: the planned date sits alongside, labelled as a plan. Every event shows its source — scanned at a depot, marked by the driver, or entered by a dispatcher on a subcontractor’s word. A spoken-word mark and a scanned one look deliberately different: on a consignment carried by a subcontractor, handover is almost always on somebody’s word, and the customer should know what they are trusting.

What stayed outside the scope

Some of the work was kept out of the portal by decision, and some of it does not come down to code.

  • Booking a consignment. The portal only shows: an order still arrives by email or phone and is entered by a dispatcher. Taking an order means checking dimensions, lane and tariff — writing inward rather than showing outward. That is a separate job, and a heavier one than this.

  • Events from subcontractors. A dispatcher marks them on the carrier’s word, off the morning round of calls. For carriers to mark them themselves they need a portal of their own, and that is a different product and a different conversation about who owes whom what.

  • The small shippers. Of 540 companies, 62% sign in over the course of a month, and they account for 89% of consignments. For a company that ships once a quarter a phone call is cheaper than a login, and nobody intends to re-educate them.

  • Original documents. The paper set travels as it always did: a copy in the portal does not stand in for the original in the customer’s accounts. Electronic document exchange is something the haulier is setting up separately, and not in this project.

In progress: a planned date calculated from the first year of actual transit times rather than from the tariff norm, and pickup at the shipper — the one event of the six still recorded after the fact, once the cargo is already at a depot.

More projects

All projects

Contact

Send a description of the task

A reply with the scope, the timeline and a budget estimate comes within 24 hours.

Get an estimate

The first call is 30 minutes, with no commitment on your side.