Direct answer
A freight customer portal lets each client sign in and see their own shipments, the documents on each one and their quote history, instead of emailing your team to ask. Statuses are updated by your staff as milestones happen, so what clients see is the same record your team works from. Fewer where-is-my-cargo emails, faster document exchange and a more professional client experience.
LATYNEX builds this directly as custom web application work, scoped per project. It is not a boxed product, and it does not include live carrier tracking or API feeds unless a usable source exists and is scoped.
What clients see
Start from the questions clients email you most often, since those define the first release. For a forwarder they are usually variations of a few:
- Which of my shipments are active, and what is the current milestone for each?
- What documents do you have for this shipment, and what do you still need from me?
- Can I download the documents you have issued?
- What did you quote me, when, and which quote did I accept?
- Can I see my past shipments for a lane or period?
Milestone statuses updated by staff
The simplest reliable design is a short list of milestones that your operations team moves a shipment through: for example booked, cargo received, departed, arrived, delivered. Choose milestones your team can actually keep current, because a status nobody updates is worse than none. Each change records who made it and when, and can carry a short client-safe note.
Because staff enter these, the portal is only as current as your process. If milestone updates are patchy today, fix that habit alongside the build. Showing automatic tracking events from carriers is a separate integration, considered only where an API exists.
Documents
Documents are often the strongest reason clients use a portal. Each shipment has a list of documents with a status: requested from the client, received, issued to the client. Clients upload what you asked for and download what you issued, so nothing travels as an attachment. Keep internal documents, such as cost sheets and supplier paperwork, invisible to clients by design, not by remembering to hide them. The process behind the checklist is described in the shipment document tracking workflow.
Quote history
Clients return to old quotes: to compare, to re-book a lane or to find what was agreed. A portal can show each client the quotes you sent them, with the lane, mode, validity and status (open, accepted, expired). Quotes are shown as you issued them. Internal cost, supplier quotes and margin never appear in the client view. How you assemble quotes internally is covered in the freight RFQ management workflow, and this portal simply gives clients a window on the outcome.
Roles and access
A client company has several people, and you have several kinds of staff. Decide access before building.
- Client accounts belong to one client company and see only that company's shipments, documents and quotes
- Roles inside a client, such as a logistics contact who sees shipments and a finance contact who sees documents only
- Internal roles: operations updates statuses, sales sees quotes, administrators manage client users
- Separation enforced in how data is stored and queried, not only in what is displayed
- A clear process for adding and removing client users
Notifications
Portals are used more when they push. Useful, restrained notifications are an email when a milestone changes, when a document is issued, when you need something from the client and when a quote is ready. Let clients choose what they receive, and avoid notifying on every internal edit. Notifications should link straight to the relevant shipment.
What needs custom scope
Because forwarders differ, several things are scoped per engagement rather than assumed:
- Your specific milestone list and shipment types
- Whether clients can request quotes or bookings through the portal, or only view
- Branding, languages and document formats
- Invoice and payment visibility
- Live carrier or tracking data, only where a usable API exists
- Connection to your existing shipment system or CRM, which is the source of truth
Where the source of truth lives
A portal should read from one shipment record, not maintain a second copy that staff must retype. If your shipments live in spreadsheets, the first job is a proper shipment record, which is what logistics software development covers. For a general view of how we approach portals, see client portal development. A warehousing business serving several clients has a different shape, described on the 3PL client portal page.
What happens next
- 01
We talk through what you need
The problem, the people who will use it and what runs it today.
- 02
We write the scope
What is built first, what is deliberately left out and what needs a decision from you.
- 03
Price agreed in writing
One price for that scope, approved by you before any work starts.
- 04
We build in stages you can review
You see working software along the way, not a reveal at the end.
- 05
Test, hand over, document
Your code, your accounts and your domain, with documentation that lets someone else run it.
Who you would be working with
- Company · Who you would be working with
- LATYNEX Digital is a service line of Latynex Trade OÜ, a company registered in Estonia (EU). Contact: info@latynexdigital.com.
- How we work · Delivery
- Remote, in English, with the person who would run the project. No local office is implied in any market.
- How we work · Commercial terms
- One scope and one price, agreed in writing before work starts. Your accounts, code and domain stay yours; any access we use is granted by you and can be withdrawn.
There are no client case studies on this page, and none are implied. What LATYNEX has built and runs itself is on the portfolio, each system labelled by stage. Published prices are on the pricing page; anything not listed there is scoped and quoted after review.
Questions
Does the portal show live carrier tracking?+
Not by default. Statuses are milestones your staff update. Carrier or tracking feeds are considered per project only where an API exists and is worth connecting.
Can clients request quotes in the portal?+
Possibly. Whether clients only view quote history or also submit requests is a scope decision made per engagement.
Can one client see another client's shipments?+
No. Separation is a core requirement and is enforced in how data is stored and queried, and confirmed during scoping.
Do we need a shipment system first?+
The portal needs a reliable shipment record to read from. If that does not exist yet, it is part of the scope or comes first.
Where should we start?+
A small first release: secure login, active shipments with milestones, documents and quote history. Then learn what clients actually open before extending.