Dispatch List & Shipping Log

What this tool does

CM8-273 is a working dispatch list and shipping log for outbound goods. One row per shipment — an order or a consignment — carrying the promise (what quantity, by when), the execution (what actually left, and when), the paperwork state, the carrier and tracking reference, and a named person who checked the pack. From those rows it builds the day's dispatch list, measures your OTIF rate month by month, and shows which customers are bearing the cost when dispatch slips.

Dispatch deserves this attention because it is the last promise-keeping step in the whole business. Everything upstream — the quoting, the scheduling, the production, the quality checks — is invisible to the customer. What the customer experiences is whether the right goods arrived, complete, when you said they would. The van leaving on time is the product, as far as the customer can see. A business that makes brilliantly and ships carelessly is, from the outside, a careless business.

Everything runs inside this single file. There is no account, no upload and no network request of any kind, so your customers, volumes and delivery performance never leave the computer you are using.

The daily dispatch list

The discipline is simple: run the day from the due list, not from memory or from whoever shouts loudest. Today's dispatch list on the Reports tab shows every order that is due or picked, in promised-date order, with the quantity, the carrier, who checked the pack and whether the paperwork is done. Anything overdue is flagged in capital letters, because an overdue promise is not a scheduling detail — it is a customer waiting.

Two habits make the list work:

• Paperwork before picking. The docs checkbox — delivery note, certificates, customs documents where the destination needs them — should be ticked before anyone pulls stock. A pallet that is picked, packed and wrapped, then held for a missing certificate, blocks the bay, invites double-handling and usually ships late anyway. The Docs incomplete tile is the pre-flight check: it counts due and picked orders whose paperwork is not done, and the number you want to see at the start of the day is zero.
• Move the status as the goods move. Due when the order lands on the list, picked when it is packed and checked, shipped when it physically leaves, delivered when the customer confirms. The dispatch plan chart shows the next seven days plus an overdue bucket, so tomorrow's crunch is visible today, while there is still time to book the extra collection.

OTIF, defined honestly

OTIF — on time, in full — is the one number that summarises dispatch performance, and it only works if it is defined without wriggle room:

Note what this refuses to do. There is no partial credit: a shipment that was on time but two cartons short is not 95% OTIF, it is not OTIF, because the customer still had to chase, still had to adjust their own plan, still received a broken promise. Averaging fill rates or counting "nearly on time" produces a flattering number that correlates with nothing the customer feels. Binary per shipment, then a rate across shipments, is the honest arithmetic — and it is the convention your larger customers almost certainly use when they score you.

Two boundaries of the measurement to be clear about. First, this log measures OTIF at dispatch — against the actual ship date, not the date the goods arrived. That is the part of the promise dispatch controls; carrier transit failures happen after the log's line of sight, and the delivered status is there to close the loop when you have confirmation. Second, the rate is computed over shipments marked shipped or delivered. A shipment sitting on the problem status is not in the rate — so resolve problems to their final status once the outcome is known, or the rate will quietly flatter you by leaving the failures out.

The trend chart plots the rate by month against your target (95% by default, set on the Settings tab). In a small operation, read the counts as well as the line: one late order in a ten-shipment month is a ten-point swing, which is arithmetic, not a crisis.

Shorts and over-shipments

A short — shipping less than the customer ordered — is a process failure, whatever caused it. Either the stock record was wrong, or the pick was wrong, or the promise was made against stock that did not exist. The Shorts this month tile counts them and totals the quantity gap, because a pattern of shorts is a stock-accuracy problem wearing a dispatch costume, and the fix is upstream.

Over-shipments are also failures, which surprises people. Shipping more than was ordered gives away stock, confuses the customer's goods-in, generates credit-note admin, and usually means the pick or the paperwork was wrong. The tool blocks a shipped quantity above the ordered quantity until you have checked it — if a genuine over-shipment was agreed, adjust the ordered quantity or record the agreement in the notes, so the log tells the truth.

The packing check — four eyes

The packing checked by field records a second person who verified the pack against the order: right product, right quantity, right labels, right address. It is deliberately a name, not a checkbox, because a name is accountable and a checkbox is a reflex.

The reason for the field is where shorts actually come from. Most short and wrong shipments are picking errors, not stock errors — the stock was on the shelf, the wrong quantity left it. A thirty-second four-eyes check at the bench, by someone who did not do the pick, catches the transposed label and the miscounted carton while they cost nothing. The same errors discovered at the customer's goods-in cost a credit note, a replacement shipment and a little bit of trust. The dispatch list prints the field, so a picked order with nobody's name against it is visible as UNCHECKED before it leaves.

Handling problems fast

The problem status exists so that refusals, damage and shortages get owners instead of email threads. When a customer reports two cartons crushed or refuses a delivery, mark the row as a problem and write the detail — the tool insists on it — including what is being done: claim opened, replacement booked, credit raised. The Problems open tile keeps the count in view, named by customer.

The point is speed. A damage claim reported to the carrier the same day is a routine claim; the same claim three weeks later is an argument. A short acknowledged before the customer notices, with the replacement already booked, is service recovery — the same short discovered by the customer is a complaint. Once the problem is resolved and the outcome is known, move the row to its final status so the OTIF rate reflects what really happened.

Carriers and cut-off times

The carrier field is free text — courier, pallet network, own transport, customer collect — and the donut shows the mix, with this month's shipment count in the centre. Two things the mix tells you:

• Cut-off times run the afternoon. Each method has a real deadline — the courier collection, the pallet network trunk, the customer's haulier — and the dispatch day should be sequenced around the earliest one, not around whichever order was picked first. Put the cut-off in the notes if it is not second nature.
• Concentration is exposure. If most of the volume rides one network, that network's bad week is your bad month. That is not automatically wrong — volume earns rates — but it is worth knowing before the peak-season surcharge letter arrives.

Measuring by customer

The Who suffers most chart counts late, short and problem shipments per customer. Failures never distribute themselves evenly, and the concentration is information: sometimes the suffering customer is the one with the tightest promises, sometimes the one whose product is hardest to pick, sometimes simply the one you ship to most. Whatever the cause, the chart is the apology call list — the customers at the top should hear from you before they have to ring you, and a customer who hears "we know, and here is the plan" stays a customer far longer than one who has to open every conversation with a complaint.

Inbound is a different log

This tool is for goods going out. Deliveries arriving — checking supplier consignments in, recording shortages and damage against purchase orders — is the opposite direction with opposite questions, and it belongs in the Delivery & Goods-In Log, which is built for exactly that. Keeping the two directions in one list muddles both: your OTIF rate is a measure of promises you made, not promises made to you.

FAQ

One order shipped in two consignments — one row or two? Two rows, one per consignment, sharing the order reference. Each consignment has its own promised date, carrier and tracking number, and each keeps or breaks its own promise. If the split itself was agreed with the customer, note it and set each row's ordered quantity to its agreed share, so neither row reads as a short.

The customer moved the date — which promise counts? The one currently agreed. If the customer asked for a later date, update the promised date and note the change. If you asked for a later date, the honest move is to leave the original promise in place — a renegotiated failure is still a failure, and logs that rewrite promises always show 100%.

What counts as the actual ship date? The date the goods physically left — collected, loaded or handed over. Not the date the label was printed, and not the date the order was picked.

Should customer collections be in the log? Yes. The promise on a collection is that the goods are complete, checked and documented when the haulier arrives — the promised date is the agreed collection date, and a pallet not ready when the truck shows up is late in every way that matters.

What OTIF rate is good? Convention more than law: many operations target 95%, and sophisticated customers often expect it contractually. What matters more than the level is the trend and the honesty of the measurement — a true 88% you are improving beats a flattered 97% every time.

Saving your work

Shipments, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the time of the last save. That storage belongs to one browser on one computer: another browser, a private window, a second machine or a clean-up tool that clears site data will not have it.

Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the log for spreadsheet work and includes every filtered record, not only those drawn on screen. Reset asks twice, then erases everything this tool has stored. There is no undo.

Accuracy & disclaimer

The arithmetic here is deliberately simple — dates compared, quantities compared, a rate over a stated population — and the tool does it faithfully. What it cannot verify is the inputs: whether the promised date recorded was the one actually agreed, whether the shipped quantity matches what was on the vehicle, and whether problems are resolved to their final status rather than left out of the rate.

OTIF in this log is measured at dispatch, against the actual ship date. It is not proof of delivery, and the log is an internal record — not a contractual delivery document, a customs declaration, proof of export, or evidence in a carrier claim. Export and retain what your contracts and your jurisdiction require.