This is a case study. It describes a problem found in many traditional freight forwarders, what that problem costs them, and where we started fixing it, one step at a time. The company and its figures are left out on purpose.
The short version
- The problem: many traditional freight forwarders still run on manual steps: paper forms, phone calls, chat messages and memory. Work gets slow, money leaks, customers wait, and managers cannot see what is going on.
- How we found it: after many complaints about delays, I followed the way work really moved through one forwarder, from start to finish, to find where it kept getting stuck.
- Where we started: payment approvals. Every job needs payments, and nothing moves until the money moves.
- The answer: one online system for requests and approvals, built on tools the company already had, as the first step in digitising the business slowly and safely.
- Where it stands: built, tested and being rolled out. I am not claiming results I have not measured yet.
A problem that is common in freight forwarding
A freight forwarder is a company that arranges for other people's goods to travel across borders. It books the ship or the plane, deals with customs, pays the port, and keeps the paperwork right. Freight forwarding is one of the oldest trades in the world, and many traditional forwarders still run it the old way: paper forms, signatures, phone calls, chat messages, spreadsheets, and what one person remembers.
Paper itself is not the enemy. Some papers are still needed: customs documents, signed vouchers, bills of lading. The problem starts when paper, or one person's memory, is the only record. Then nobody can see where a document is, how long it has waited, or who is holding it up.
That works while the company is small. It stops working as the company grows. Think of a restaurant where the waiter must walk every order to the owner for a signature before the kitchen can start. With five tables it is fine. With fifty tables, food goes cold, customers get cross, and the owner has no idea which table is waiting.
What it costs a forwarder that has not gone digital
None of these problems looks big on its own. Together they are expensive.
| Where it hurts | What it looks like |
|---|---|
| Lost productivity | Skilled people spend the day chasing signatures, searching for papers and asking "where is it?" |
| Money leaking out | A container waits for a payment while the port and the shipping line charge for every extra day. Mistakes found late cost more to fix. |
| Unhappy customers | Delays, missed timelines, slow answers and late goods. The customer never sees the paper form, only the wait. |
| Poor control | Nobody can see all open requests in one place. Spending limits depend on people remembering them. |
| No useful information | Managers cannot answer simple questions, such as how long a payment takes and where it waits longest. |
| Dependence on certain people | If the one person who knows how things work is away, work slows down or stops. |
How we found where to start
There were many complaints, mostly about delays and slow answers. The easy response to complaints is to tell people to work faster. That does not help, because the people were not the problem. The way the work moved was.
So I did what you would do to find out why a parcel arrives late: I followed it. I took real requests and traced each one from the first step to the last, writing down every hand it passed through and every place it stopped.
The same place showed up again and again: payment approvals. In freight, goods cannot be released from a port until the charges are paid, so every job depends on payments. Each payment needed a paper voucher (a form that asks for money to be paid), and that voucher needed up to five or six signatures, one after another, often in different offices and different countries. Forms sat on desks. Nobody could say where a form had got to. A missing signature could hold up a container for days.
Why we began with approvals
- Everyone touches it. Every job and every office needs payments approved, so the benefit shows quickly.
- It is clear and measurable. A request has a start, an end and a time for each step, so improvement can be checked with real data.
- It builds trust. Staff accept change more easily after one small thing works well. A big change that goes wrong makes people suspicious of the next one.
- It lays the ground. Once requests and approvals are kept in one place, the same records can feed reports and later steps.
What we built
I built it on Microsoft 365, the office tools the company already had, so there was no new software to buy. Three of those tools do the work. SharePoint is a safe online filing cabinet. Power Apps is a way to make a simple app for phones and computers. Power Automate is a robot that does a set of steps for you, every time, without being asked.
- One online form for requests, with a version for phones, so an approver can say yes or no from wherever they are.
- An approval route that works itself out. The form looks at the type of cost, the office and the department, then sends the request to the right people in the right order.
- Checks before submitting. The form will not go forward if a required document is missing or a limit is broken. A mistake is caught in the first minute, not the last day.
- A signed PDF at the end. When the last person approves, the system makes the final voucher itself and files it in the right folder. We did not throw paper away: if a signed copy is needed, it can be printed from the PDF.
- Emails and reports. Approvers get a short summary of what is waiting for them. Managers get a daily summary, and the company gets weekly and monthly reports.
- Tidy-up. Old, finished requests move to an archive by themselves, so the live list stays quick.
How a request now travels
| Step | What happens |
|---|---|
| 1. Someone raises the request | They fill in the form and attach what is needed. The form checks it as they go. |
| 2. The route is chosen | The system reads a simple table of who approves what, and builds the list of approvers for this request. |
| 3. Each approver is told | They see it in their summary, open it, and approve or send it back with a reason. |
| 4. The last approval finishes it | A signed PDF is made and filed, the person who asked is told, and the payment team can act. |
Five design decisions, and why
This is the part I am proudest of, because the thinking matters more than the screens.
1. The routes live in a table, not in the code
Companies change. A manager leaves, a new office opens, a step is dropped. If the routes were buried inside the app, every change would need a programmer. Instead the routes sit in a plain table that a trained administrator can edit. Changing who approves what takes a minute, and nobody has to touch the app.
2. A route is frozen when the request is sent
If the table changes while a request is half way through, the request keeps the route it started with. People are never surprised by a rule that changed under them, and the record always shows what was true on the day.
3. Fewer emails, not more
The easy way to build this is to email everyone at every step. That quickly turns into noise, and people stop reading. So approvers get one summary a few times a day, and only urgent requests are sent at once. The aim is that an email still gets read.
4. The system blocks mistakes instead of reporting them
Rules such as a cash limit, a ceiling for purchase orders and the documents required for each cost type are built into the form. The cheapest time to fix an error is before it is sent.
5. Write for the person who is new
I wrote a guide for staff, a guide for the administrator, a getting-started page and a troubleshooting page. A system that only its builder understands is a risk, not an asset.
Going digital slowly, not all at once
Some companies try to change everything in one go. It usually fails, because people are still doing their normal jobs while the change happens. Our approach is to digitise one process at a time:
- pick the process that hurts most;
- build a simple version and test it with real people;
- fix what does not work;
- train people and write the guides;
- measure, and only then move to the next process.
Approvals came first. Other parts of a forwarder's work, such as quotations, job tracking, customer updates and reports, can follow the same way, each one standing on the records the last one created.
What I learned
- The hard part is not the technology. It is agreeing how the business really works. Every office has habits and rules, and some of them were never written down. The system is only as good as the rules you give it.
- Complaints are a clue, not the cause. Slow answers and late goods were the symptoms. Following the work showed the cause.
- Build for the change that is coming. People and routes change every few months. A design that expects change lasts. One that does not breaks.
- Testing on a real phone matters. Screens that look fine on a computer can overlap or get cut off on a phone. I found and fixed several of these by testing on real devices.
- Measure from day one. The system records the time of every step, so the real answers will come from the data: how long a request takes, and where it waits longest.
What I am not claiming
This system is new. I have not published any savings, time gained or money made, because I would rather show a number I measured than one I guessed. When there is enough data I will update this page with real figures.
Is your forwarding business still running on manual steps?
If your team still passes forms or chat messages around for approvals, quotes or job updates, the same method can work for you: follow the work, find where it gets stuck, fix that one thing, and build from there. I would be glad to talk about it. You can email me or see the portfolio.