A request every Monday
A wholesale customer's logistics manager emails every Monday for last week's delivery report: how many delivered on time, how many failed and why, and PODs for a list of invoice numbers their own customers are disputing. Someone in your office exports jobs, filters them, builds a spreadsheet, finds the PODs one by one and zips them up.
Another customer wants the same thing monthly in a different format. A third is running a tender and wants a year of performance figures by Friday.
Why reports are built by hand
Courier systems record jobs and PODs, but reporting tools for customers are often basic. Each customer defines 'on time' differently. PODs are stored per job, not in a form that can be pulled out by a customer's reference. So each request is a small project.
| Customer asks for | What it takes today |
|---|---|
| On-time delivery figure | Export, filter, count, per customer's definition |
| Failed delivery reasons | Reading driver notes |
| PODs for a list of references | Searching job by job |
| Performance for a tender | Rebuilding a year of data |
| Regular report in their format | A new spreadsheet each time |
What it costs
Office time every week. Slow responses to customers who need PODs to settle their own disputes. And a missed chance: good performance that you cannot show easily is worth less than it should be when a customer is reviewing couriers.
Inconsistent figures are a risk too. Two reports built by different people can disagree, which invites questions.
POD requests have a clock on them. A customer asking for proof of delivery is usually in a dispute with their own customer, who is refusing to pay an invoice. Every day the POD takes to arrive is a day their money is held up, and they remember which courier made that easy.
And the reporting burden grows with every account you win. The office that copes with three customers asking for weekly reports does not cope with ten, so success in winning larger accounts turns directly into admin that someone has to absorb.
The reporting portal we build
- A secure login for each account customer, showing only their jobs.
- Performance figures by week and month: delivered on time by their definition, first-time delivery, failed reasons, with the underlying jobs listed.
- POD search by their own references, such as order or invoice numbers, and bulk download as a single file.
- Scheduled reports sent automatically in the layout each customer wants.
- Export of any view to a spreadsheet for their own analysis.
- Your branding, so the portal is part of what you offer when bidding for work.
Definitions of 'on time' are agreed with each customer and set up once, so the figures do not become an argument.
Failed delivery reasons are only as good as what drivers record, so part of the work is making the reason codes on the driver's screen short, clear and required. That improves the reports and your own view of why deliveries fail.
What changes
Customers get reports and PODs when they want them, without waiting for your office. Your staff stop compiling spreadsheets. And you can show prospective customers the reporting they will get, which is a real difference for a regional courier bidding against national carriers.
Signs you need a reporting portal
- Staff compile delivery reports for customers by hand.
- POD requests mean searching job by job.
- Each customer wants a different report format.
- Tender requests for performance data cause a scramble.
- You cannot show your performance easily to prospects.