Online Quote Request Portal for Transport Customers: What to Build

The word "portal" is used loosely in freight software, so start with what makes it a portal rather than a page: identity. Every person who signs in is attached to one customer account, and every screen they open is filtered by that identity. They see their own quotes, their own shipments, their own message threads — never another shipper's, and never yours.

That single property changes what the software can safely do. Because the system knows who is asking, it can show a real price instead of a promise to call back. It can pre-fill the origin the customer always ships from. It can let them accept a price without a countersignature. None of that is possible on an anonymous public form, where any answer would have to be either generic or manual.

Cargavo, a TMS for freight brokers and transport commissionaires, implements this with a claim on the signed-in account that carries the organisation and the customer identifier. The database rules deny by default and only release documents whose customer field matches that claim, so the isolation is enforced by the server rather than by the screen the user happens to be looking at.

Six screens make up the portal in practice: a price simulator, a quote request form for lanes no grid covers, a quote list, a quote detail with a booking action, a shipment list, and a message inbox. Everything else — grids, carriers, buy prices, other customers, analytics — belongs to the broker side and has no route in the portal at all.

If you are still deciding whether to automate quoting at all, start with the pillar guide on digital freight quoting; this guide assumes you have grids and are deciding what to expose.

Most brokers already have a "request a quote" form. It emails a summary to sales@ and, from that moment, the request is an email like any other: unnumbered, unsorted, invisible to the rest of the team, and impossible to count at the end of the month. The customer has no way to check what they asked for or what you answered.

The difference is not the input fields — a good form and a good portal ask for the same shipment data. The difference is what exists afterwards.

There is a second, quieter difference. A form invites free text, so it collects requests that cannot be priced: "3 pallets to Spain, urgent". A portal validates the shipment before it will produce anything, which forces the fields that make a quote possible — postcodes, unit count, dimensions, weight, stackability, options. Our guide on the information needed to quote freight lists the minimum set, and the comparison in email quote requests versus an online tool goes further on the handover cost of each incomplete request.

Cargavo, a TMS for freight brokers, keeps both doors open — an instant price when a grid covers the lane, a structured request when none does — but both produce the same kind of record.

Portals fail in two directions. Too thin, and the customer still emails you for everything. Too wide, and you have leaked your cost base. The scope below is the practical middle: everything the shipper needs to transact, nothing that describes how you buy.

Two design decisions inside that table do most of the work. The first is that the simulator and the request form share a field set, so a customer who fails to get a price can carry their inputs straight into a manual request instead of retyping them. The second is that messaging is threaded on a quote or a shipment rather than being a general inbox: when a shipper writes "can we push the collection to Thursday", the reference is already attached, and nobody has to ask which job.

Note what is absent. No grid list, no carrier tariff, no buy price, no margin, no other customer, no analytics. Cargavo, a TMS for freight brokers, has no portal route for any of those objects — they are not hidden behind a permission toggle that an administrator could switch on by accident.

For the broker-side counterpart of these screens, see the customer portal resources and the guide on choosing a TMS as a small brokerage.

"White label" is used to mean everything from a logo upload to a fully separate application. It is worth being precise about what a broker actually needs, because the expensive version buys very little.

What matters to a shipper is that the document they file looks like it came from their transport supplier. That means three things: the sender name on the quote email, the company name on the screen where they accept the price, and a reference format they can quote back to you on the phone. Colour and theme are pleasant; the name and the reference are the ones that appear in their accounts payable file.

In Cargavo, a TMS for freight brokers, an owner or administrator sets three branding fields on the organisation: the displayed company name, one primary colour as a hex value, and the portal theme — light or dark. The customer's interface language follows their own choice among English, French, Spanish and German, and amounts are shown in the currency the quote was priced in: EUR, USD, GBP, CHF, CAD, MAD or PLN.

Be honest about the boundary, because it is where most white-label claims quietly overreach. Branding here is applied per organisation once the customer signs in — it is not a separate website on your own domain, and it is not a custom-built application. If your requirement is a portal served from shop.yourbrand.com with your own HTML, that is a web development project, not a TMS setting, and it will cost far more than the 49 €/month, 149 €/month or 399 €/month on the pricing page.

What you get for that price is the part that is genuinely hard: the pricing, the isolation and the confidentiality described in the next two sections.

The naive implementation sends the whole calculation to the browser and hides the sensitive lines with a display rule. That is not confidentiality — it is a stylesheet. Anyone who opens the network tab sees the buy rate, and any future bug that renders one extra field leaks it permanently.

The durable approach separates the data before it is stored. One quote document holds what the customer may read; a private sub-document holds what only the broker may read. The split is enforced by the security rules, not by the interface, so a customer account asking for the private document receives a permission error rather than a filtered answer.

The second half of the problem is that the price must not be forgeable. If the browser sent the price it wanted, a customer could send a lower one. In Cargavo, a TMS for freight brokers, the portal never submits a price: it submits a shipment description, and the server recomputes the quote from the org's grids and the customer's margin configuration before writing anything. The margin itself uses the margin formula p/(1-m), applied per customer, per grid or per weight bracket.

The full architecture, including what happens on re-quotes and exported documents, is covered in how to show a customer a price without revealing your buy rate.

Take a real request as a customer would type it into the simulator: 3 non-stackable pallets of 1.2 × 0.8 m, 780 kg in total, Lyon to Barcelona, tail lift required at delivery.

The engine first computes the chargeable weight, because 780 kg of pallets occupy far more floor than they weigh. Three pallets of 1.2 × 0.8 m is 2.88 m² of floor; divided by a 2.4 m trailer width that is 1.2 loading metres. At a configured conversion of 1,850 kg per loading metre, that is 2,220 kg — well above the 780 kg actual weight, so 2,220 kg is what the grid is read at. The loading metre calculator reproduces that step on its own.

The carrier's weight_zone grid prices the 2,000–2,999 kg bracket for that zone at 14.20 € per 100 kg, so the buy transport line is 22.2 × 14.20 = 315.24 €. From there the two sides diverge:

Two details are worth reading twice. The margin is applied to the transport line before the fuel surcharge, so the surcharge is computed on the sell base — this is why the sell surcharge is 36.52 € and not 29.95 €; a system that surcharges the buy base and marks up afterwards produces a different number, which is how the same shipment gets two prices in two tools. And the realised margin is 17.97 %, not exactly 18 %, because the tail lift carries its own sell price rather than the percentage. See fuel surcharge for the indexation side.

The customer's screen shows one line: 454.96 €, valid until a stated date, under your company name. Cargavo, a TMS for freight brokers, writes the left-hand column to the quote's private record in the same transaction.

This is where most self-service portals break. They are built on the assumption that a rate always exists, so an uncovered lane produces an error screen and the customer goes back to email — permanently, because they now believe the portal does not work.

A brokerage's coverage is the union of the tariffs it has negotiated, and that union always has holes: a new destination country, a unit above the last weight bracket, an ADR class the carrier excludes, a full-truck request against a groupage grid. Treating those as failures throws away the requests most worth having, since an uncovered lane is often a new customer testing you.

The correct behaviour is to demote, not refuse. Cargavo, a TMS for freight brokers, returns no price when nothing matches and offers a manual quote request instead, pre-filled with the origin, destination and units already typed. The request is stored with mode manual and status pending, draws the next number in the same Q-YYYY-NNNN series as automatic quotes, and notifies the broker by email. The broker sources a spot rate, types the sell price into that same quote, and the customer accepts it exactly as they would an instant one.

Three consequences follow, and they are the real argument for the design:

• Uncovered lanes become countable. A lane quoted manually three times is a lane that deserves a grid.
• The customer experience does not fork. Same portal, same reference, same acceptance flow, whether the price came from an engine or a phone call.
• Nothing is lost in a mailbox. The request has a status, so it can be chased.

The full off-grid workflow, including how long a hand-priced quote should stay valid, is in quoting a lane with no rate grid.

A portal that stops at the price is half a portal, because the questions that generate the most email come after booking: has it been collected, where is it, can I have the proof of delivery.

Booking is the hinge. On the quote detail screen each carrier line carries a booking action; choosing one calls a server function that re-validates the quote, converts it into a shipment and assigns an S-YYYY-NNNN reference linked back to the Q-YYYY-NNNN quote. The buy-side financials are copied into the shipment's own private record, so the margin follows the job rather than being recalculated later from a stale grid.

The shipment then moves through five states the customer can read: pending, confirmed, in_transit, delivered, cancelled. The broker sets them. Documents the broker uploads — CMR, proof of delivery — appear on the customer's shipment detail, and a tracking link can be attached when the carrier publishes one.

Say plainly what this is not, because the honest boundary is what makes the rest credible. Cargavo, a TMS for freight brokers, has no carrier API and no EDI connection, so statuses are entered by the broker rather than streamed from a carrier system. It is not a load board, not a tendering marketplace, not a fleet or dispatch tool, and not accounting software. What it does own end to end is the quote, the booking, the shipment record and the conversation attached to both.

That last one matters more than it sounds. Message threads are attached to a quote or a shipment, so the reply about Thursday's collection sits on the shipment it concerns rather than three levels deep in an email chain. See carrier integration without APIs for how the same no-integration constraint shapes the buy side.