Business process automation by freight forwarders, for freight forwarders
bp0.work applies agentic automation to the rules-based, repetitive parts of freight forwarding operations — quotations, invoicing, reconciliation, compliance checks — while leaving every judgment call exactly where it belongs: with a person.
The problem
Most forwarders already know they should automate. What's missing isn't motivation — it's a clear starting point.
A 20% increase in quotations or invoices usually means hiring to match. There's rarely a way to grow throughput without growing the team in step.
Annual leave, sick leave, turnover — when a repetitive process lives in one person's hands, their absence becomes the operation's bottleneck.
The handful of people who really know the process end up carrying it. The business is one resignation away from losing institutional knowledge.
Automation is talked about everywhere, but rarely in a way that maps to how a forwarding operation actually runs — so most never begin.
How it works
Every process bp0.work automates is built around the same principle: the system handles what's repeatable and rules-based, and routes anything that requires judgment straight to a person — with full context, not a blank ticket.
Nothing is automated by guesswork. Every automated step follows logic your team has defined and can inspect — not a black box making silent decisions.
Intervention points are designed in from the start. When something falls outside the defined rules, it's routed to a person with the relevant context already attached.
Data stays where you control it. Nothing is handed off to a third party to process on your behalf.
In practice
These aren't pitches — they're how the philosophy actually gets built.
Automates accounts receivable, accounts payable, bank reconciliation, and treasury workflows — the high-volume, repetitive core of finance operations.
Approval authority is hard-coded by role: operational sign-off and financial sign-off are kept strictly separate and non-bypassable. The system never makes that call — a person always does.
Built on a simple premise: the same customer's supply chain looks like a different story depending on whose seat you're in. A BDM sees the opening for new business. A KAM sees the relationship and renewal risk. A TLM sees the trade lane performance. A vertical head sees the pattern across an entire industry. SCRM surfaces customer intelligence, churn risk, and cross-trade opportunity through whichever of these lenses the role actually needs.
Explainability is built in throughout — every signal the platform surfaces can be traced back to why it's there.
Where this fits
Forwarders already know the two conventional paths — and their tradeoffs.
Lower cost, but you give up control
Control, but the labor stays
Control and throughput, together
The real return
A 20% increase in quotations or invoices traditionally means hiring to match. Agentic automation breaks that link — the system absorbs the repetitive load, and the team only grows for the judgment-heavy work that actually needs people.
The defined rules for what gets automated and how — written down, not assumed.
Connections into the systems already in use — TMS, accounting, document stores.
Clear, explicit triggers for when a case routes to a person instead of completing automatically.
A traceable record of what the system did and why — so outcomes can always be audited.
A reality check
Development, deployment, and testing are rarely what determine whether an automation project succeeds. The real risk is how well the process being automated was actually defined before work started.
That's harder than it sounds. Process knowledge is usually held by a select few, not freely shared, siloed across people and departments, and inadequately documented — so defining a process often means reconstructing it first, not just writing down what everyone already agrees on.
That time has to be spent somewhere. Spend it upfront, doing the work of clearly defining the process — or spend more of it later, fine-tuning a system against a process nobody fully mapped out. The second path is where automation projects get frustrating, lose momentum, and sometimes fail outright — not because the technology didn't work, but because the process it was asked to automate was never clearly defined.
