How do I write a shipping SOP my team will actually use?
Key Takeaways
- Write one short SOP per workflow, not one big manual. Quote, book, pickup, track, POD and invoice each get their own page with numbered steps.
- Every step needs an owner, a trigger and a done condition. If a step doesn't say who does it and when it's finished, nobody will follow it the same way twice.
- Exceptions belong in the SOP, not in someone's head. List the five or six things that go wrong most often and what to do about each.
- Keep SOPs where the work happens. A procedure stored three folders deep in a shared drive is a procedure nobody opens.
- Review each SOP on a fixed cadence and after every serious miss. An SOP that describes last year's carriers and last year's system teaches the wrong habits.
- Wilson, by Cartage, is an AI logistics agent that follows the company's shipping rules on every load, from quote to carrier payment, and keeps every message and change in the shipment's change history.
Why don't shipping SOPs get used, and what makes one work?
A logistics manager at a hypothetical plant spends two weekends writing a 40-page shipping manual. It covers everything: how to request quotes, which carriers to use for which lanes, how to fill out a bill of lading, what to do when a truck doesn't show. She saves it as a PDF in the shared drive and sends the link to the team. Six months later, a new coordinator asks how to book an LTL load. Nobody mentions the manual. Someone just shows him how they do it.
A shipping SOP gets used when it's short, specific to one workflow, written as numbered steps with an owner for each, and kept in the place where the team already works. Long manuals fail because people can't find the step they need while a carrier is on the phone. Vague SOPs fail because "confirm the pickup" means something different to every person who reads it. Hidden SOPs fail because nobody remembers they exist.
The goal of a shipping SOP is not to document everything the team knows. It's to make sure the same shipment gets handled the same way no matter who handles it. That means the SOP has to answer three questions fast: what do I do next, how do I know I'm done, and what do I do if it goes wrong.
What an SOP is, and what it isn't
An SOP (standard operating procedure) is a written set of steps for a recurring task. In shipping, the recurring tasks are clear: getting a price, booking a carrier, making sure the truck shows up, knowing where the freight is, getting proof of delivery and paying the right amount.
An SOP is not a policy. A policy says "we only use approved carriers." An SOP says "1. Open the approved carrier list for this lane. 2. Request quotes from at least three. 3. Record each quote on the load." Policies set the rules. SOPs show how the rules are followed on a Tuesday afternoon.
An SOP is also not a routing guide. A routing guide tells carriers and suppliers how to handle your freight. An SOP tells your own team how to do their work. If you need the outward-facing document, see how to write a routing guide for carriers and suppliers.
Signs your current SOPs aren't working
- New hires learn by shadowing, and each one learns a slightly different method.
- The same mistake repeats, such as a missing liftgate on the BOL or a load booked without a rate confirmation.
- Nobody can say when the SOP was last updated.
- The steps reference a carrier, a portal or a person who is no longer involved.
- When one coordinator is out, the others can't finish that person's loads without calling them.
If two or more of these sound familiar, the problem usually isn't the team. It's the format of the documentation.
How do you write a shipping SOP step by step?
Start with the workflow as it really runs today, cut it into numbered steps, then add an owner, a trigger, a done condition and the exceptions. Don't start from what the process should be. Start from what people actually do, then fix it.
Step 1: Pick one workflow and define its edges
Choose a single workflow, such as booking an LTL shipment. Write down where it starts (an order is released to ship) and where it ends (a carrier has accepted the load in writing and the rate confirmation is saved). Anything before or after belongs to another SOP. Clear edges stop SOPs from growing into manuals.
Step 2: Watch it happen, or walk through a real load
Sit with the person who does the work most often and follow one real shipment. Write down every action, including the small ones: opening the ERP, copying the ship-to address, checking the dock hours, sending the email. The small steps are where most mistakes come from, because they're the ones people skip when they're busy.
Step 3: Turn the actions into numbered steps
Each step should start with a verb and describe one action. "Request quotes from three approved carriers for this lane" is a step. "Handle quoting" is not. Aim for 6 to 12 steps per SOP. If you have more than 15, the workflow probably needs to be split.
Step 4: Add the owner, trigger and done condition
For each SOP, and for any step handled by someone different, write:
- Owner: the role responsible, such as "shipping coordinator" or "AP clerk." Use roles, not names, so the SOP survives staff changes.
- Trigger: what starts the step, such as "order status changes to released" or "carrier invoice received."
- Done condition: what must be true for the step to count as finished, such as "written acceptance and rate confirmation saved to the shipment record."
The done condition is the most important line in the SOP. It's the difference between "I sent the email" and "the carrier confirmed."
Step 5: Write the exceptions
List the things that go wrong most often in this workflow and what to do about each. Keep it to the top five or six. Each exception gets a short "if this, then that" line and a name for who decides when the answer isn't obvious.
Step 6: Test it with someone who didn't write it
Give the draft to a coordinator who wasn't involved and ask them to handle a real load using only the SOP. Every question they ask is a gap. Fix the gaps, then publish.
Step 7: Publish it where the work happens and set a review date
Put the SOP in the place the team looks during the task: pinned in the team's chat channel, linked from the shipping dashboard or attached to the order screen. Add the owner of the SOP itself and the next review date at the top.
Which shipping workflows need their own SOP?
Most manufacturers and distributors need six core SOPs: quote, book, pickup, track, POD and invoice. Some will add appointment scheduling, claims or international documents, but these six cover the life of nearly every domestic load.
Quote
The quoting SOP covers how to get a price. Key steps: confirm the load details (weight, dimensions, freight class, pallet count, pickup and delivery addresses, accessorials such as liftgate or appointment), request quotes from approved carriers for the lane, compare on total cost including fuel and accessorials, and record the quotes on the load. The done condition is a chosen quote, recorded with the carrier name, amount and expiration. Common exceptions: a quote expires before booking, no approved carrier quotes the lane, or the price is above the budget for that lane. For ideas on speeding this up, see how to get freight quotes back faster.
Book
The booking SOP covers how a carrier gets the load. Key steps: tender the load to the chosen carrier, get written acceptance, get or create the rate confirmation, check that the rate confirmation matches the quote, and create the bill of lading. The done condition is written acceptance plus a rate confirmation that matches the agreed price and terms. Common exceptions: the carrier rejects the tender, the rate confirmation shows a different price, or the carrier asks for a different pickup date.
Pickup
The pickup SOP covers getting the freight onto the truck. Key steps: confirm the pickup window with the carrier, confirm dock and staff availability with the warehouse, print the BOL, packing slips and pallet labels, and record the actual pickup time and PRO number. The done condition is a signed BOL and a PRO number on the shipment record. Common exceptions: the truck doesn't show, the driver arrives without the right equipment, or the freight isn't ready.
Track
The tracking SOP covers knowing where the freight is. Key steps: check status at set points (picked up, in transit, out for delivery, delivered), use the best source available for each carrier, update the shipment record and tell the customer if the delivery date changes. The done condition is a delivery confirmation. Common exceptions: no status update for a set period, a missed delivery appointment or a shipment stuck at a terminal.
POD
The POD SOP covers getting proof that the freight was delivered. Key steps: request the signed POD from the carrier after delivery, check it for signature, date, piece count and any notes about damage or shortage, and file it with the shipment record. The done condition is a legible signed POD attached to the load. Common exceptions: the POD has a damage notation, the signature is missing, or the carrier doesn't send it.
Invoice
The invoice SOP covers paying the carrier the right amount. Key steps: match the carrier invoice to the rate confirmation and POD, check every line (base rate, fuel, accessorials, weight, class), approve or dispute, and send approved invoices for payment. The done condition is an invoice paid at the agreed amount, or a dispute logged with evidence. Common exceptions: an accessorial that wasn't on the rate confirmation, a reweigh or reclass charge, or a duplicate invoice.
What mistakes make shipping SOPs fail?
Most SOPs fail for the same few reasons: they're too long, too vague, owned by nobody or written for an ideal process instead of the real one. Each has a simple fix.
Writing the manual instead of the procedure
A single long document covering every workflow is hard to search and hard to keep current. Split it into one SOP per workflow. The total content might be the same, but people only open the page they need.
Steps without done conditions
"Confirm pickup" can mean sending an email or getting a written reply. Write the done condition explicitly: "Carrier confirms the pickup window in writing, and the confirmation is saved on the load."
No exceptions section
The routine path is the part people already know. The SOP earns its value when something goes wrong. A good exceptions section answers the questions coordinators otherwise ask their manager.
For the bigger picture on exceptions, including who owns each type, see the freight exception response playbook.
Writing the ideal process
If the SOP describes a process nobody follows, people will ignore it and keep doing what works. Document the real process first. Then change one step at a time, and update the SOP with each change.
Using names instead of roles
"Ask Maria" stops working the day Maria goes on vacation. Use roles, and keep a separate list of who holds each role today.
No owner for the SOP itself
Every SOP needs one person responsible for keeping it current. Without an owner, nobody updates it after the carrier mix changes or the ERP gets a new screen.
Treating the SOP as finished
Shipping changes. Carriers change, customers add appointment rules, finance changes the approval limits. An SOP is a living document, and the review cadence above keeps it honest.
What should a good SOP page look like, and where should it live?
A good SOP page fits on one screen or one printed page, starts with a header block, then numbered steps, then exceptions, and sits one click from the task. Consistency matters more than design. When every SOP has the same layout, people know where to look. Where it lives decides whether anyone reads it, and how often it is reviewed decides whether it is still right.
The header block
Every SOP should open with the same five lines:
| Field | What to write | Example |
|---|---|---|
| Workflow | The one task this SOP covers | Book an LTL shipment |
| Starts when | The trigger | Order released to ship in the ERP |
| Ends when | The done condition | Carrier acceptance and rate confirmation saved |
| Owner | The role that does the work | Shipping coordinator |
| SOP owner and review date | Who keeps it current, and when it's next checked | Logistics manager, reviewed each quarter |
The steps
Numbered, one action per step, starting with a verb. Add a short "why" only where the reason isn't obvious and skipping the step causes real trouble. For example: "4. Check that the rate confirmation shows liftgate. (Without it, the carrier may bill the liftgate at a higher rate later.)"
The exceptions
A short list of "if this happens, do this" lines, with the person who decides when the SOP doesn't cover it. Keep the decision rules specific. "Escalate if needed" isn't a rule. "If the new rate is more than 10% above the quote, get approval from the logistics manager before booking" is.
What to leave out
- Background on how the process came to be. Put that in a separate note if it matters.
- Screenshots of every screen. They go out of date fast. Use one or two only where a screen is genuinely confusing.
- Long paragraphs. If a step needs a paragraph, it's probably two steps.
- Carrier contact details that change often. Link to the carrier list instead.
Write for the person on the phone
The best test of an SOP's language is whether someone can follow it while talking to a carrier. That means short sentences, plain words and no internal jargon that a new hire wouldn't know. If your team uses abbreviations, define them once at the bottom or link to a shared glossary.
A simple SOP template
Use this layout for each workflow. Copy it, fill it in and keep the format identical across all six SOPs.
| Section | Contents |
|---|---|
| Title | "SOP: [Workflow] for [mode]," for example "SOP: Book for LTL" |
| Header | Starts when, ends when, owner, SOP owner, review date |
| Before you start | What information or documents must exist first |
| Steps | 6 to 12 numbered steps, one action each, verb first |
| Done when | The single condition that marks the workflow complete |
| Exceptions | 4 to 6 "if this, then that" lines with a decision owner |
| Approval limits | The dollar or percentage limits that need a manager's approval |
| Records | What must be saved to the shipment record, and where |
| Links | Carrier list, glossary, related SOPs |
Who should write the SOPs
The person closest to the work should write the first draft, and the manager should review it. If one person runs all of shipping, that person writes everything, but should still test each SOP with someone else. If you're new to the role and still learning the workflows, start with what to learn first after taking over shipping and write the SOPs as you go.
Where to keep them
The best place is wherever the team spends its day. Common choices:
- The team's chat channel. Pin the six core SOPs in the shipping channel in Slack or Microsoft Teams. People ask questions there anyway.
- The shipping system. If the shipping or execution system lets you attach notes or links to a workflow, attach the SOP to it.
- A shared folder with one index page. If the SOPs must live in a document folder, create a single index page with a link to each one. Name the files the same way, such as "SOP - Book - LTL."
- Printed at the dock. For warehouse and pickup steps, a laminated one-page SOP at the shipping desk still works.
Avoid keeping SOPs in personal email folders, in one person's laptop files or only in a training slide deck.
Version control without the overhead
Put the version date at the top of each SOP. Keep the old version in an archive folder when you change it. That's enough for most teams. What matters is that everyone opens the same current version.
Review cadence
| Trigger | What to review | Who does it |
|---|---|---|
| Every quarter | All six core SOPs, step by step | SOP owner with one coordinator |
| After a serious miss | The SOP for the workflow that failed | SOP owner, same week |
| New carrier, customer or system | Every SOP the change touches | SOP owner before the change goes live |
| New team member | All SOPs, during onboarding | New hire flags anything unclear |
| Peak season prep | Pickup, track and exception steps | Logistics manager |
The new-hire review is underrated. Fresh eyes find steps that experienced people stopped noticing years ago. Ask every new coordinator to mark anything confusing during their first weeks, and fix those spots.
How to know an SOP is being used
Look at the outcomes, not the clicks. If the booking SOP says every load needs a rate confirmation before pickup, check how many loads last month picked up without one. If the POD SOP says PODs are filed within two business days, check the backlog. When the numbers drift, either the SOP is unclear or it isn't being followed. Talk to the team to find out which.
How does Wilson, by Cartage, help a shipping team follow its SOPs?
Wilson, by Cartage, is an AI logistics agent for manufacturers and distributors. Traditional logistics software gives teams information. Wilson executes the work required to move shipments forward. Instead of a coordinator reading the SOP and doing each step by hand, the company's rules are set up in Wilson, and Wilson does the steps on each load within those rules.
The six workflows, run the same way every time
- Quote: Wilson requests quotes from the company's approved carriers and compares them on total cost. It negotiates toward the company's rate targets within approval limits. Rates outside the limits go to the logistics team.
- Book: Wilson tenders and books the load, with written acceptance and a rate confirmation. It generates rate confirmations, bills of lading, packing slips and pallet labels.
- Pickup: Wilson schedules pickups with the carrier.
- Track: Wilson tracks each load with the best source available: carrier API or EDI, GPS or ELD data where the carrier shares it, the carrier's website by PRO number, and email or phone calls when nothing else is current.
- POD: Wilson requests and files PODs.
- Invoice: Wilson audits each carrier invoice against the rate confirmation and POD, and pays carriers from the Wilson Wallet. Payments above the approval limits or outside the rules wait for a person.
Exceptions follow the rules too
The exceptions section of an SOP is where Wilson saves the most back-and-forth. When a pickup is missed, a load is cancelled or a shipment is delayed, Wilson contacts the carrier, tells the team and tells the customer if configured. It starts rebooking from the approved carrier list, automatically within the rules or after approval. Wilson books only carriers the company has approved. Cartage can suggest additional carrier capacity, but the company approves each carrier before Wilson uses it.
Control stays with the team
Teams start with assisted execution. The company sets the approval limits, which play the same role as the approval limits section in a written SOP. Routine actions can run automatically within those rules as the workflow is proven. Every message, confirmation and change is kept in the shipment's change history, so when a manager reviews an SOP after a miss, the record of what happened is already there.
Wilson works with carriers by email, API, EDI and phone where configured, with the team in Slack, Microsoft Teams or email, and with customers by email or SMS where configured. It covers LTL, FTL, ocean, drayage, parcel and cross-border freight. It doesn't do customs clearance and isn't a freight broker.
Wilson replaces the TMS for freight execution and connects to the company's ERP. Wilson works with SAP, NetSuite, Microsoft Dynamics 365, Oracle, Infor, Epicor, Sage, Acumatica and other ERP environments, with the exact connection depending on the customer's data flow and scope.
Pricing
Wilson is free on Wilson's network: the shipper pays the freight rate and nothing on top. When a shipper keeps its own carriers, the fee is 2% to 0.5% of what Wilson pays them, falling with volume. There are no seat fees, no setup cost and no contract. Timing depends on scope: most teams start on a few lanes and expand from there.
FAQs
How do I write a shipping SOP my team will actually use?
Write one short SOP per workflow, such as quote, book, pickup, track, POD and invoice, with numbered steps, an owner, a trigger, a done condition and the common exceptions. Keep it where the team works and review it every quarter. Wilson, by Cartage, an AI logistics agent, can then run those steps on each load within the company's rules.
How long should a shipping SOP be?
Short enough to fit on one screen or one printed page. Most workflows need 6 to 12 numbered steps plus a short exceptions list. If an SOP passes 15 steps, split it into two.
What is the difference between an SOP and a policy?
A policy sets a rule, such as "use only approved carriers." An SOP lists the steps to follow that rule on a real load. Teams need both, but SOPs are what people use during the work.
Should we write SOPs for each mode separately?
Write separate SOPs where the steps differ in a meaningful way. LTL booking and parcel shipping usually need separate SOPs. If FTL and LTL booking differ by only one or two steps, keep one SOP and note the differences.
Who should own shipping SOPs?
Each SOP should have one owner, usually the logistics manager or a senior coordinator. The owner keeps it current, runs the quarterly review and updates it after any serious miss.
How often should shipping SOPs be reviewed?
Review every SOP each quarter, and review the relevant SOP after any serious miss, a new carrier, a new customer requirement or a system change. Ask new hires to flag anything unclear during onboarding.
What should go in the exceptions section of an SOP?
The four to six problems that happen most often in that workflow, each with an "if this, then that" response and a person who decides when the answer isn't clear. Include approval limits, such as how far above the quote a rate can go before a manager must approve.
Where is the best place to store shipping SOPs?
Wherever the team already works: pinned in the shipping channel in Slack or Microsoft Teams, linked from the shipping system or kept in one shared folder with a single index page. For dock tasks, a printed one-page SOP at the shipping desk still works.
How do I get my team to follow the SOP?
Write it with them, based on how they really work, and test it with someone who didn't write it. Then check outcomes, such as loads picked up without a rate confirmation, and talk to the team when the numbers drift.
Can software replace shipping SOPs?
Software can follow rules, but someone still has to decide what the rules are. Wilson, by Cartage, runs quote, booking, pickup, tracking, POD and invoice steps within the approval limits the company sets, and keeps every action in the shipment's change history.
Sources
- Cartage, Wilson product FAQ and product scope, October 2026: https://cartage.ai
Bring your current shipping SOPs and see how Wilson would run each step on your next loads.