# Broker instructions in writing: the note that prevents repeat errors | ClearBorder

Source: https://clearborderhq.com/blog/2026-10-27-broker-instructions-writing-repeat-errors.html

Cross-border operations guide · October 27, 2026


A practical guide to written broker instructions for importers who clear goods through customs and keep brokers honest. It covers how to diagnose the real cause from records, the smallest fix that holds, and how to check after one full cycle whether the change actually worked.

## Start by naming what is actually happening

Written broker instructions rarely fails in one dramatic moment. For importers who clear goods through customs and keep brokers honest, the pattern is usually a slow drift: a setting changed, a supplier changed, a process was skipped under pressure, and nobody wrote it down. The first job is to describe the current state in plain terms, with dates and examples, before anyone proposes a solution.

Pull three recent examples and look at them side by side. Note what they share and where they differ. In most cases involving written broker instructions, two of the three will share the same trigger, and that shared trigger is a better starting point than the single worst case, which tends to pull teams toward extreme and expensive responses.

Write the problem statement in one sentence and share it with everyone who touches the process. If the sentence cannot be agreed, that disagreement is itself useful information. It usually means different teams are measuring the same thing differently, or using the same words for different things, and no fix will hold until that is settled.

## The checks that separate a real problem from noise

Good diagnosis for written broker instructions uses records, not memory. Check timestamps, source documents, and the order in which steps happened. Memory fills gaps with what should have happened, while records show what did happen, including the workaround someone invented on a busy day and then kept using for months afterwards.

Compare a good case against a bad case from the same period. The contrast is more informative than studying failures alone, because it shows which step actually protects the outcome. Teams often discover the protection was one unglamorous check, done by one careful person, that was never written into the process for anyone else.

Quantify the size of the problem before you fix it. Count how often it happens, what it costs each time, and how long it takes to detect. Those three numbers decide whether written broker instructions needs a system change, a training fix, or simply a clearer owner. Without them, every incident feels urgent and every solution feels justified.

## A fix you can put in place this week

Start with the smallest change that addresses the trigger you found. For written broker instructions, that is often a mandatory field, a second pair of eyes at one specific step, a template that replaces free text, or an alert with a named owner. Small changes get adopted. Grand redesigns get postponed, and the problem continues while the redesign is being planned.

Give the change a start date and an owner, and write both down where the team will see them. Then resist adding a second change until the first has run for a full cycle. Layering changes makes it impossible to tell which one worked, and when results improve the team learns nothing it can repeat next time.

Tell the people affected what is changing and why, in one short message. Most resistance is not disagreement, it is surprise. A change that arrives without context gets worked around, and the workaround quietly becomes the real process within a month.

## How to check whether it worked

Measure the same three numbers you took at the start: frequency, cost per case, and time to detect. Compare them after one full cycle, not after a few quiet days. Quiet days happen by chance, and declaring victory early is how the same problem returns with a new name a quarter later.

Look for side effects as well as improvement. A stricter check in one place can push errors downstream, slow a neighbouring team, or create a new queue somewhere else. Ask the teams on either side whether anything got harder, and take their answers seriously even when your own numbers look good.

If the numbers held for two cycles, write the change into the standard process for written broker instructions and remove the old instruction so nobody can follow both. If they did not hold, go back to the three original cases. Most second rounds find a second trigger that the first round missed, not a team that failed to try.

Keep reading: [Customs exam holds: what happens while your shipment waits](https://clearborderhq.com/blog/2026-10-27-customs-exam-holds-shipment-waits.md), [Customs valuation adjustments: when the declared value is challenged](https://clearborderhq.com/blog/2026-10-27-customs-valuation-adjustments-challenged.md), and [Bonded warehouses for small importers: when the maths works](https://clearborderhq.com/blog/2026-10-27-bonded-warehouses-small-importers-maths.md) cover the nearby cases in this series.

## Frequently asked questions

## What is the most common cause of problems with written broker instructions?

The most common cause is drift: a setting, supplier, or step changed under pressure and the change was never recorded. Pull three recent cases and compare them side by side. The shared trigger across two of them is usually the real cause, rather than the single worst incident.

## How much data do I need before acting on written broker instructions?

You need enough to count three things: how often it happens, what each case costs, and how long it takes to detect. A month of cases, or one full operating cycle, is usually enough to choose between a system change, a training fix, and a clearer owner.

## Should I fix written broker instructions with more checks?

Only at the step where cases actually fail. Blanket checks slow the whole process and get routed around under pressure. One well placed check, with a named owner and a clear reason the team understands, holds better than several unexplained ones.

## How will I know if my change worked?

Compare the rate, cost per case, and detection time after one full cycle against the baseline you wrote down at the start. Check for side effects on neighbouring teams too. If the improvement holds for two cycles, write the change into the standard process.