Back office: surcharge baskets
The back office bundled carrier surcharges by hand every Monday. We automated it — and kept the human checkpoint that almost got automated away.
Web
B2B
Logistics
Automation
Role
Product Designer
Primary user
The back-office team
Timeline
2023–2026
Status
Live
Methods
User Interviews · Desk Research · Process Modelling · Lo-fi Prototype · User Shadowing
A surcharge basket in verification: one carrier, one currency, 9 surcharges, a number that never gets reused.
Overview
Back office was the part of the business nobody on the design side understood yet. So we didn’t start with screens — we started by learning how money actually moves through this company.
This wasn’t a track I got added to. We had finished the operational surfaces, the client said it was time for the back office, and the work carried on with the same people. What changed was the subject matter: instead of trucks and routes, it was invoices, surcharges, payment terms and tax law.
So the first stretch went into research rather than design. How a surcharge gets registered and by whom. What happens to a carrier’s invoice between the moment it arrives and the moment accounting closes it. Which of the rules in play are law, which are the client’s own policy, and which are habits the old system taught them. “One order, one invoice”, for example, turned out to be the client’s invoicing policy rather than a legal requirement — worth knowing before you design around it as if it were fixed.
Surcharge baskets came out of that research. The back office was spending a standing slot every Monday bundling small carrier charges by hand, and we had to move that process into the new system anyway. My argument was that we shouldn’t move it as it stood: if the system can see which charges belong together, it can build the bundle, and the person can spend her time checking it instead of assembling it.
Problem
Every Monday the back office blocked out a standing slot for manual basket-building — and the old system had quietly normalized broken numbering.
The old system did surcharge baskets — bundling carrier surcharges per carrier, currency, and period — manually. The back-office lead would pull up the week’s registered surcharges — 80, sometimes 100-plus by her own estimate — filter by carrier and currency, eyeball which belonged together, tick checkboxes, click “create basket”. Then again for the next carrier. A standing Monday block of roughly ninety minutes — that’s her account from interviews; nobody measured it. The error rate wasn’t catastrophic, but it was constant: a PLN surcharge bundled into a EUR basket, a basket left half-built when a fire pulled her away, a carrier surprised by a late charge.
The most damaging flaw was structural. Changing a basket in the old system meant deleting it and building a new one — and the new one came out with a new number. Only a handful of baskets out of several hundred ever got deleted, and it was still enough to hurt: the number was what every downstream lookup ran on, so filtering stopped being reliable and reports stopped adding up.
We were porting this process into the new TMS. My principle going in: if we’re rebuilding, don’t replicate the old system’s flaws. Legacy flows are evidence about what users do — not a spec to implement faithfully.
Research
Back office runs on rules other people wrote — tax law, accounting practice, the client’s own policy. You can’t design against rules you can’t name, so I spent two years naming them.
Back office in road freight is a forest of small, regulated rules. Surcharges for parking, ADR cargo, tunnels, overnight stops, usually €10–20 each. Baskets bundling them per carrier per currency per period. Invoices gated by KSeF — Poland’s national e-invoicing platform, which every invoice has to clear before it counts. Early-payment discount windows, trade credit, cabotage, dead freight. The ERP as the ledger we feed but don’t own. Each term has a legal meaning, an accounting meaning, and a workflow meaning, and they don’t always agree.
Over 2024 and 2025 I built a private vault of feature notes — the admin flow, KSeF, surcharge baskets, document structure. Most began as me transcribing what engineering or the client had decided, in my own language, with the unanswered questions flagged at the bottom. Then I’d take those questions to the back office, the forwarders, the developers, and write down what they told me. The notes weren’t deliverables. They were how I made the domain mine.
Two things happened that I didn’t plan for. First, I became the person who could answer a question across the modules I worked on — if a surcharge lands after the basket has already gone out, where does it end up? Second, when I started disagreeing with proposed changes, my disagreement carried weight it hadn’t in 2023 — not because I was louder, but because I could walk through the actual flow and say precisely which step the change would break.
In June 2026 I put the notes to a second use. A new designer joined the project and I ran her onboarding on them — the fastest path into a domain that had taken me two years to learn, and what we used to divide the product between us.
Key decisions
Four decisions, all about where automation should stop.
Decision 01 · Automation
Auto-create the baskets; move the human from construction to verification
Monday morning, from her side of the screen. Surcharges have been landing all week and the system has been dropping each one into an open basket for its carrier and its currency. She opens one: sixteen items, one carrier, one currency, under the thirty-item cap, so the whole thing fits on a screen. She reads down it. A tunnel charge from a carrier who overbills tunnels. An ADR line with no attachment. She fixes both and sends it, and the number the basket was given the moment it opened goes out with it. On Thursday the carrier disputes a line, so she withdraws the send — the basket becomes editable again — corrects it, and sends it again under the same number. Both versions stay on the record.
Before this, that Monday opened with ninety minutes of assembling those baskets by hand.
Instead of asking the back office to group surcharges into baskets, the system auto-creates them as surcharges come in — one open basket per carrier per currency, new surcharges falling into it. The human’s job shifts from constructing the basket to verifying the basket the system already built. Her expertise — knowing when an ADR charge looks wrong, remembering which carriers overbill tunnels, catching a missing attachment before it becomes a phone call — was being wasted on clicking checkboxes.
Auto-creation only works if the basket is bounded tightly enough to verify at a glance. Three hard constraints: one carrier per basket, one currency per basket, maximum 30 items — at 30, the auto-creator closes the basket and opens the next.
Why
The bounds resolve a paradox of automation: the more of it you put upstream of a human checkpoint, the more expensive the checkpoint gets. A 60-item mixed-currency basket would be unverifiable — she’d either rubber-stamp it (defeating the checkpoint) or spend so long the automation gain disappears.
Trade-off
Hard bounds reject valid edge cases — which is why the design also ships a place for them to live (Decision 03). The only signal so far that the trade is worth it came from a low-fi prototype session, not from data; the formal research comes after launch.
Decision 02 · Compliance
A basket number that never gets reissued — and a send you withdraw rather than edit around
The basket number — BSK-00001/02/2026, sequential, locked to month and year — is assigned the moment a basket opens, before it goes anywhere, and it never changes. It’s the key everything else matches on: the carrier quotes it on their invoice, the back office matches that invoice back to the basket, accounting files against it. Get the number wrong and the whole settlement chain loses its handle.
Which is what the old system did. There, correcting a basket meant deleting it and creating a new one, and the new one got a new number — so the number the carrier already had in hand stopped pointing at anything. The fix isn’t clever: never reissue a number, and never make someone delete a basket in order to change it.
That second half is a rule about sending, not numbering. A basket that has been sent can’t be quietly edited in place. When a carrier disputes a line, the back office withdraws the send — an explicit undo that makes the basket editable again — fixes the line, and sends again, under the same number. Every version a carrier ever saw sits on the record as its own send.
The status lifecycle — Draft → sent to the carrier → sent to the ERP → invoice available — is built to close its own loop: the target version flips the last two statuses automatically, as the basket flows through the ERP integration and the carrier’s invoice lands. The first release still sets them by hand; the automation ships with the integration.
Why
KSeF holds sent invoices immutable anyway; mapping the basket lifecycle onto that discipline turned a regulation into the user’s own need — an auditable settlement trail.
Trade-off
The first version of this rule was stricter: a sent basket was locked for life, and fixing one line meant cancelling and rebuilding all thirty. The team walked that back in July 2026, because rebuilding a full basket to fix one disputed line punishes the verifier for the carrier's mistake. Withdraw-edit-resend keeps every send explicit while making corrections survivable. The rule softened when it met the workflow, and the softer version is the better one.
Decision 03 · Edge cases
The cases that don’t fit the automation get a visible place to live
The loose-surcharge pool. Not every surcharge is sitting in a basket. Charges that arrive unassigned collect in a shared pool for their carrier-and-currency pair, and the back office resolves them at her own pace instead of the system forcing them into a basket they don’t belong in. Whenever you automate a workflow, you also design where the cases that don’t fit go to live — otherwise the automation becomes brittle (rejecting valid edge cases) or dishonest (silently miscategorizing them).
Negative balance. A carrier’s week can net negative — damage charges outweighing the surcharges. The first design blocked negative baskets and routed the case out to a manual debit note. The team reversed that in July 2026: the basket simply keeps accumulating below zero, and the direction of settlement gets resolved downstream. I’m keeping the reversal in this story on purpose — the original block was me being cautious about a case I didn’t have data on, and the reversal is what happens when the design meets people who do.
Why
A visible pool is what makes the automation safe to trust — nothing gets silently miscategorized to keep the happy path clean.
Trade-off
A pool of unassigned charges is a place for work to pile up unnoticed. It needs its own visibility — a tab and a count, not a buried filter.
Decision 04 · The checkpoint
The client proposed auto-send. The user defended the checkpoint — because the design let her
Late in the design phase, the client proposed taking automation one step further: if the system can auto-create the basket, why does a human need to verify it? Auto-send to the carrier the moment the basket hits 30 items or the week closes.
It was a reasonable proposal, and it was wrong. Auto-send removes the only point in the flow where a person catches the small wrong things: the carrier mis-tagged by an upstream typo, the suspicious ADR charge, the surcharge that should have been split between two orders. Those errors are not frequent, but each one becomes a phone call, a corrected invoice, or a quiet error that lands in the ERP and stays there.
The back-office lead said plainly that she wanted to look at a basket before it went out, and the client agreed. She could say that because the checkpoint was structural, not a toggle. The Sent to carrier status was the checkpoint. A basket could not reach a carrier without passing through her hands, so removing it meant rebuilding part of the flow. The design had made her position the default.
Why
Build the checkpoint into the structure of the flow, not into a setting. A setting gets switched off in one meeting. A status has to be redesigned.
Trade-off
The checkpoint costs verification time on every basket, forever. Whether bounded automation is right — or whether auto-send becomes justified once the verifier role has bedded in — is a question only post-launch behavioral data can answer.
Outcome
Surcharge baskets are in implementation. Launch moved back to make room for the client portal, and the questions below are the ones I will answer once it is live.
80–100
surcharges a week the back office bundled by hand, user's estimate
~90 min
every Monday spent building baskets manually, user's account
30
item cap that keeps an auto-built basket verifiable at a glance
“We no longer have to do all that mindless clicking.”
— a back-office user, reacting to the low-fi prototype
Once it ships I will know: what share of auto-created baskets go out without modification, how long verification takes per basket, whether the numbering holds up against real deletion cases, and whether the bounds match the shape of production data.
Surcharge baskets are the best-documented work I have done on this product. The automation was my idea, and the trail from research through trade-offs to stakeholder negotiation is on paper. The back office had been bundling surcharges by hand for years. I expect this to be the change those users feel most, and I will replace “expect” with a number after launch.
Reflection
Three questions from the design phase — two got answered before implementation, one is still open.
Negative balance — answered. The debit-note workaround assumed negative baskets were rare enough to route out manually. Implementation planning killed the assumption before production data could: the block fell, negative baskets accumulate normally. I’d designed a fence around a case the workflow could simply hold.
Post-send edits — answered, softened. The original no-edit rule would have cost a full cancel-and-rebuild per disputed line. It evolved into withdraw-edit-resend. The open part now is behavioral: how often the withdraw path gets used, and whether “explicit undo” stays explicit in practice or becomes a reflex that erodes the audit trail.
Deletion impact on ERP matching — still open. A basket number is never reissued — that’s the audit fix. But what happens to the ERP’s matching when a basket disappears mid-cycle? That’s outside what I know, and I don’t have confirmation from the integration team yet.