The buyer is not the user
In most trade-account checkouts the person clicking through the order is not the person paying for it. They are an authorised purchaser working against a job, a cost centre or a project code that finance set up that morning. The checkout exists to capture that context cleanly enough that the invoice lands against the right account and the order makes it through approval without a phone call.
That is a different design problem from a consumer checkout. The B2C playbook optimises for friction reduction in a one-person decision. The B2B equivalent optimises for the accuracy of the metadata that travels with the order, because that metadata is what the business uses to decide whether the order can be placed at all.
The four fields that earn their place
Job reference. Not a free-text field. A typeahead against the list of open jobs the customer has set up, with the ability to create a new one if the buyer has the permission. The cost of getting this wrong is reconciliation work that finance will eventually push back to the buyer, who will eventually stop using the site.
Cost centre. Usually inherited from the job, sometimes overridden. Make the inheritance visible and the override deliberate. The buyers who use the override are the ones whose business you most want, and they will not tolerate a checkout that hides it.
Delivery instructions tied to the site, not the order. Site offices have gate codes, contact names and crane availability that do not change between orders. Capture them once at the site level and surface them in the checkout. Most teams keep asking for them on every order and then wonder why the buyers ring the trade desk instead.
Required-by date with a calendar that knows the supplier cut-offs. A required-by date that the system cannot meet is worse than no date, because the buyer plans the rest of their day around it. If the cut-off has passed, say so in the basket, not in the confirmation email.
"A one-click checkout in a trade-account site is a solution in search of a problem. The buyer needs three deliberate clicks that map to how the order will be paid for."
Approval chains as a checkout concern
Approval chains belong in the checkout, not after it. A buyer who places an order without knowing whether it will be approved is a buyer who phones the trade desk to ask. Show the chain, show the current approver and show the likely turnaround at the point of submission. Where the order is below the buyer's autonomy limit, say that too. The clarity is worth more than the design tidiness it costs.
On larger catalogue projects we have seen approval drop-off rates fall by a third when the chain was made visible in the basket. The driver is not the chain itself. It is the buyer understanding what is going to happen next.
What to stop doing
Stop importing B2C checkout patterns wholesale. Express checkout, guest checkout and one-click reorder all have their place, but the place is rarely the trade portal. The trade buyer wants speed inside their workflow, not speed past it.
Stop hiding the order metadata until after the order is placed. The buyer is the person who will be asked to fix the reference if it is wrong. Let them see it and edit it before the order is submitted, not after.
Stop measuring the checkout on conversion alone. Measure it on the proportion of orders that complete without intervention from the trade desk. That is the number the business actually cares about, and it is the number that moves when the checkout is doing its job.
