Treadstone Associates
Article · 10 min read

Does a small carrier need a customer portal?

Truck count is the wrong test. Retrieval volume is the right one — and there are three ways to serve it that are not a software build.

Treadstone Associates · Updated 2026

Key takeaways

  • • A customer portal exists to serve four artefacts: proof of delivery, status, invoice and claim file. Serve those four well and the portal itself is optional.
  • • The trigger is document-retrieval requests per week, not trucks. A 40-truck dedicated fleet may need nothing; a 12-truck LTL operation may need something.
  • • Building one takes on privacy obligations you did not previously have, because the portal holds personal information — consignee contacts, signatures, driver names.
  • • Carriers who transmit customs data by EDI or through a service provider already get a free eManifest Portal account from the CBSA, which covers cross-border status without any build.

The short answer

Usually no — not as a build. When a shipper says they want a portal, what they almost always mean is that they are tired of emailing you for the same four things: the signed proof of delivery, the current status of a load, a copy of an invoice, and the file on an open claim. All four can be delivered without writing software, and three of the four you are already required to keep.

The honest test is not how many trucks you run. It is how many times a week somebody at your office stops what they are doing to find a document for a customer. Below a handful, a portal is a solution looking for a problem. Above a couple of dozen, the retrieval work is a job, and a job is worth automating.

The four artefacts, and where they already live

Proof of delivery. In British Columbia the bill of lading regime is prescriptive: each bill of lading must be issued in triplicate or more, with one copy delivered to the shipper and one retained by the carrier for a period of at least 3 years, during which time the carrier must make it available for inspection by the director or by a peace officer. You are holding it either way. The only question is whether a customer can reach it without asking you.

Status. This is the ETA and event feed, and it is generated by the telematics you already run for hours-of-service compliance.

Invoices. Tax law sets the retention floor. Under the Income Tax Act, records must be kept until the expiration of six years from the end of the last taxation year to which the records and books of account relate, and the Excise Tax Act sets the same period for GST/HST: every person required to keep records shall retain them until the expiration of six years after the end of the year to which they relate. Both statutes add that a person who keeps records electronically shall retain them in an electronically readable form.

Claim files. Correspondence, photographs, weights, the bill of lading, the notice. Rarely requested, but when it is requested it is urgent.

The test

Count document-retrieval requests for four weeks. If one person is spending more than a few hours a week finding files for customers, automate the retrieval. If they are not, the portal will be a login your customers forget and you maintain.

What a portal costs that a shared folder does not

A portal is a system holding personal information about identifiable people — the consignee’s contact at the door, the signature on the delivery document, sometimes the driver’s name. That brings federal private-sector privacy law into scope in a way an internal filing cabinet did not, and it is worth understanding whether PIPEDA applies to your business before you open one.

Three practical consequences follow. You will need a privacy policy that reflects what the portal actually does. If the portal is hosted by your TMS vendor, you are sharing customer data with a third-party provider and that relationship needs to be papered. And you need a plan for the day it goes wrong — the Privacy Commissioner publishes guidance on responding to a privacy breach at your business, and it is easier to read before the incident than during it. Whether to carry cyber liability cover for customer data becomes a live question at the same moment.

None of this is a reason not to build. It is a reason to count the build as more than the build.

Four cheaper things that satisfy the same request

Push instead of pull. The single highest-value change most small carriers can make is emailing the signed delivery document automatically when it is scanned, attached to the load number and the invoice reference. Most portal requests are proof-of-delivery requests. Remove the request.

Use the TMS you already pay for. Most transport management systems ship a customer view. It is generally worse than a purpose-built portal and enormously cheaper than building one.

Send status by EDI where the customer can take it. A shipper large enough to demand a portal is usually large enough to consume a status message directly into their own system, which they would rather have anyway.

Take the free customs portal. If any of your freight crosses, note that carriers who choose to use electronic data interchange or a service provider to send their advance commercial information are eligible for a free eManifest Portal account, and that the Portal lets you verify the status of trade data, whether it is transmitted through the Portal or by EDI. That is border status handled without a line of code.

A worked example

A 22-truck British Columbia carrier with four regular accounts logged retrieval requests for a month: 61 requests, of which 44 were for a signed delivery document, 11 for an invoice copy, 4 for status and 2 for claim documents.

They did not build a portal. They changed the scanning workflow so the delivery document is emailed to a named contact within the hour, with the load and invoice number in the subject line, and they put invoice copies behind a self-serve link in the accounts-receivable system they already had. Retrieval requests fell to single digits, all of them status questions during weather.

The freight did not move because of a login screen. It moved because the document arrived before anyone asked.

When you actually should build

Three signals, all of them about volume rather than size. Retrieval is a role rather than an interruption. A customer’s scorecard measures document turnaround and you are losing points on it. Or you are running enough LTL that consignees — not shippers — are calling you, which is a different and much larger population than four accounts.

Where AI fits

The useful work is matching and retrieval, not chat. Reading a scanned delivery document, extracting the load number and delivery date, matching it to the right load, and filing it where a search will find it. Answering “where is the POD for load 8841” from your own records. Drafting the reply and attaching the file.

It should not decide a claim, release a document to someone whose identity has not been checked, or determine what personal information may be disclosed. A person signs those.

Common questions

Will a portal win us freight?

Rarely on its own. It removes a reason to leave rather than creating a reason to join. Service, price and a clean safety record are what move a tender.

If our TMS vendor hosts it, who is responsible for the data?

You remain accountable to your customers for the information you collected, whatever the hosting arrangement. That is precisely why the vendor relationship needs to be documented — see the guidance on sharing customer data with a third-party provider.

A shipper is insisting. What do we say?

Ask what they want to do in it. If the answer is “get PODs”, offer automatic delivery instead and show them the turnaround. If the answer is “feed our system”, offer the data feed. Both are usually better for them than a login they will not use.

Stop losing hours to paperwork you already have the data for.

A 30-minute call is enough to tell you whether AI pays for itself in your back office.