Shipper login
Secure sign-in with email verification and separate accounts for each client.
A customer portal website for courier companies gives business shippers a secure login where they can track runs, download proof of delivery and check invoices without asking the office. We build the account access, document sharing and request tracking that keep routine questions out of the dispatch room.
Business shippers ask the same three questions every day: where is the run, when was it delivered and where is the signed proof. Those questions arrive by phone, by email and in a group text with the dispatcher, and the answer depends on who is free. A missed reply turns into a complaint about the courier rather than about the question.
Invoices add another loop. An accounts clerk asks for a copy of last month's delivery receipt, the office searches a shared drive, and the document is emailed as a scan that is hard to read. Each request is small, but the dispatcher stops working routes to answer them. Shippers who receive a clean statement with each run listed rarely need to ask the office what a line item means.
A shipping manager comparing courier companies usually searches for a service and a city, then opens two or three sites to see what happens after the booking. They look for a login, an example of tracking and a clear contact for account questions. If a site stops at a booking form, they assume the service ends there.
That shapes the portal project. Put the portal link in the main menu, describe the account features plainly, and state who can see which files. Those details persuade a buyer that the courier can handle a steady account.
An operations manager should be able to create a test account, watch a run move from booked to delivered and download a proof of delivery without help from the developer. Access rules need testing as well, so a user from one client account cannot open another client's documents.
They also need to know what happens when someone leaves the company. Accounts must be removable quickly, with a record of who had access and when, and the portal should keep the history of documents each account used. Put that test into the sign-off list rather than relying on a promise made in a meeting. Ask the test to include a failed login attempt and a locked account, so the team sees how the portal behaves when things go wrong.
Secure sign-in with email verification and separate accounts for each client.
Status for each booked run, with timestamps for pickup and delivery.
Signed delivery notes and photos stored by run and available to download at any time.
Monthly statements and single invoices in one list, filtered by date and account.
New drop points, access hours and contact changes sent for approval and logged.
A logistics coordinator at a regional wholesaler logs in from the office on a Monday. The dashboard shows the week's runs with live status, and one run shows a scanned delivery note with a timestamp. They open the invoice list, filter for last month and download the statement the accountant needs.
The coordinator then requests a new drop point at a warehouse. The request appears in the courier's queue with the address and access hours attached, and the dispatcher confirms it. The coordinator sees the change marked as approved, and the new address appears in their saved list.
Most courier companies run dispatch on a route tool and bill through an accounting package. Onfleet and Samsara are common on the operations side, and QuickBooks or Xero hold the invoices. Before building, we would confirm which system holds the run record, which one holds the invoice and which one is the source for proof of delivery.
Where a clean connection exists, the portal reads status and documents from it. Where it does not, the team uploads proofs by hand for a short period under a clear rule. We would keep the portal read-only for anything that could be changed in the dispatch tool by mistake.
Start with the accounts that send the most runs each week. A short email from the account manager, with a login link and a one-page guide, works better than a general announcement. Ask each account to name one person who will use the portal, so there is a clear owner on the customer side. Start with the shippers who send the most runs, since they feel the change first and their feedback arrives soonest.
Then retire the old routine. Once a shipper has the portal, proof requests by email get the portal link as the reply, and the dispatcher stops sending scans by hand. Review the first month's questions with the operations manager and turn the common ones into short help text on the account page.
The portal is built around a short set of screens: sign in, check runs, download proof, pull invoices and send a change request. Most account users need one walkthrough and a bookmark. We keep the menu deliberately short, so the first visit does not feel like training.
In many cases, yes. Route and telematics tools such as Onfleet and Samsara offer data feeds or APIs, and we confirm which one fits during the scoping call. Where a feed is not available, the portal shows the status the dispatcher enters.
Every account reads only its own runs, files and invoices, and we verify that using two test accounts. Access can be removed when someone leaves, and every login is recorded. We confirm those rules in writing before the build.
The budget range runs $300 to $2,200; account types and feeds set where a given project falls. The scoping call defines the first release, and the price arrives in writing before any build begins. Support continues after go-live if you want changes.
Post-launch support covers fixes, copy changes and new accounts, and you decide how much help you want on an ongoing basis. Your office keeps the content current, and we train the person who does that during handover. Changes to the scope are agreed in writing first.
Share who needs an account, what each account should see, and which systems keep your runs and invoices. Scope and price will come to you in writing once we have spoken.