The first four weeks with a new customer decide whether the account is profitable

Signing a new account feels like the finish line. It is closer to the starting gun. The margin on a contract is decided far less by the rate you agreed than by how much unpaid work the account generates every week afterwards — the address nobody has, the reference nobody put on the invoice, the booking that arrives as a text message to a driver. Almost all of that is either put in place or avoided in the first month.

What follows is a checklist. Not a philosophy of onboarding: an actual list of things that have to be true before an account can honestly be called running, with a note on what happens when each one is skipped.

Week one — the addresses and references, captured once

Get the master data from the customer in one pass, before the first booking. Not because it is tidy, but because the alternative is collecting it one phone call at a time from whoever happens to answer.

• Every collection and delivery address they will use, with opening hours, any dock or vehicle restriction, and the name of somebody who answers the phone at that site.
• Their own reference field. Order number, purchase order, project code — whatever their systems key on. It has to survive onto the booking, the proof of delivery and the invoice line, or their accounts team cannot match what you send them.
• Contacts by role, not by person. Who books, who chases a delivery, who pays. At most customers those are three different people, and a single “contact” field is how a request for a POD ends up in the booking inbox.
• Standing requirements, written where a planner will see them: tail lift, temperature, ADR, timed windows, whether pallets exchange, whether the site has to be booked in.

Skip it and: addresses arrive one booking at a time, typed by whoever took the call. Six weeks later you have four spellings of one industrial estate, your planning tool believes they are four different stops, and the day a driver is sent to the wrong gate nobody can say which version was correct.

Week one or two — the price list, agreed and loaded

• The rates in writing, surcharges included. Fuel, waiting time, out-of-hours, ferry, tolls, redelivery. A rate card that only covers the clean case is a rate card you will be arguing about within a month, and a fuel surcharge only holds if its trigger was agreed in advance.
• Loaded into the system that prices the booking, not into a spreadsheet somebody keeps a copy of. The price the planner sees and the price the invoice carries have to come from the same place, or they will disagree exactly once, in front of the customer.
• Tested against three or four real jobs before the first invoice goes out. Use volumes from their own tender if you have them. A price list that is right in principle and wrong for the lane you actually run gets discovered at invoicing, which is the most expensive place to discover it.
• The review mechanism, agreed now: what moves the surcharge, when, and who tells whom.

Skip it and: the account runs on a price somebody remembers. Every unpriced exception is settled by whoever is on the phone, and the first attempt to work out whether the contract is profitable finds nothing solid to compare against.

Week two — one booking channel, chosen on purpose

Decide how work arrives, and then have it arrive that way.

• A portal for customers who book a handful of shipments a week and want to see them afterwards. It also produces the cleanest data you will ever get, because the person who knows the address is the one typing it.
• EDI or an API where their volume justifies the setup, or where their system is the system of record. The choice usually follows counterparty size rather than preference.
• Email, if that is genuinely what they will use — but with a defined format and one address, not four inboxes and a mobile number.

The rule that matters more than the choice: one channel per customer. Two channels means two chances for a booking to exist in only one of them, and the day that happens it is a missed collection, not a data problem. Whatever the channel, the booking must land in your system without being re-typed; a channel that ends with somebody copying an email into a form is not a channel, it is a queue.

Skip it and: the parallel channel appears on its own. Somebody gives out a planner’s mobile number “just for the urgent ones”, and within a quarter the urgent path is the normal path.

Week three — the invoice, in the shape their accounts payable accepts

The first invoice is a test, and failing it is expensive: a rejected invoice does not come back with a correction, it goes to the back of a queue that runs on their calendar rather than yours.

• Which of their references goes on which line, exactly.
• What has to be attached — signed consignment note, proof of delivery, weighbridge ticket — and in what form. This is the argument for capturing the paperwork digitally at the stop rather than waiting for the folder to come back from the truck.
• Cadence. Per shipment, weekly, monthly — and if it is periodic, which day the period closes.
• Where it is sent: an address, a portal, or an e-invoice network. Ask, and confirm the first one arrived rather than assuming it did.
• Who approves it on their side, and how long they take. Payment terms are not the same number as time to cash, and the difference is theirs.

Week four — one hour comparing what you sold to what you run

Book it now, while the account is new enough that changing something is routine. Put the assumptions the price was built on beside the first month’s reality: average weight and pallet count, time at each stop, waiting time, failed deliveries, out-of-hours work, and how many bookings arrived through the agreed channel.

You are not looking for a verdict — one month is short, and a new account is clumsy at the start. You are looking for the assumption that is wrong by a factor rather than by a margin, because that one compounds every week it is left. Do it again at month three.

Two habits that quietly cost the most

• The unnamed owner. An account with nobody named on your side has nobody to notice it drifting. This is a person, not a committee.
• The favour that becomes the standard. The unpriced extra call, the out-of-hours drop done once as goodwill. Do them if you want to — but record them as exceptions, with dates, or in six months they are the service level you are held to and nobody can remember agreeing to it.

The one-page version

1. Addresses, opening hours and site contacts — captured once, from the customer.
2. Their reference field, carried onto booking, POD and invoice.
3. Contacts for booking, for problems, for payment.
4. Standing requirements visible to the planner.
5. Rates and surcharges in writing, loaded where bookings are priced.
6. Priced against real jobs before the first invoice.
7. One booking channel, agreed and used.
8. Invoice format, attachments, cadence and destination confirmed.
9. A named owner on your side.
10. An hour at week four, comparing what was sold to what is run.

None of it is difficult. All of it is easier now than in month four, when the account has habits.

Where navichain stands

navichain holds customers, their sites and their contacts as records rather than as text typed onto a booking, so an address is entered once and reused — including by the customer themselves through the customer portal, which is included on every plan alongside EDI, an API and freight-network connections as ways for work to arrive. Price sheets are set per service by weight, distance, time or geographic zone, and the booking, the run and the invoice read the same record, so what a planner sees is what the customer is billed; issued invoices are sealed, and the documents behind them travel with them. Every plan runs the full platform — plans differ by scale, not by capability. The platform page shows what is inside, and pricing what it costs.