Process first. Buy software second.

The software demo always looks the same. A warehouse on a screen. Orders flowing left to right. Inventory turning green. Someone from the vendor says the word "visibility" three times. The ops lead, who has been living in spreadsheets and WhatsApp groups, nods because they are tired.

Six months later the same warehouse is still running on the same WhatsApp groups. The WMS is live. Nobody trusts it. Pickers keep a paper list in their pocket because the last time they believed the screen, they sent the wrong carton to the wrong lane.

I've watched this from the brand side, from inside a 3PL, and from the ugly middle where a new system is supposed to save a process nobody ever wrote down. The software is rarely the stupid part. The sequence is.

Process first. Buy software second. The other way around is how you pay for a dashboard that describes a warehouse you do not actually run.

The demo is not your operation

Every decent WMS, TMS, or OMS can look excellent in a room with coffee and a projector. That's the job of a demo. It shows you the happy path. Scan, pick, pack, despatch. Exception rate of zero. Addresses that parse. Stock that matches. A supervisor who has time to look at a screen.

Your operation is not the happy path. Your operation is the 8% that doesn't fit, the SKU that has two barcodes, the returns that come back without a reason code, the marketplace order that arrives with a name and no phone number, and the Friday afternoon when volume spikes and the "temporary" workaround becomes the real process.

If you have not described those things in writing, the vendor will configure the happy path. Then you will spend a year teaching the system every exception by breaking it in production. That is not implementation. That is discovery, billed as a go-live.

What software actually does

Software is a very expensive way to enforce a process. That's a compliment. Enforcement is useful. Enforcement is also useless if the thing being enforced is a guess.

A WMS will faithfully require a scan at a pack bench. It will not tell you that your pack bench is in the wrong place, that your carton sizes make no sense on a bike last mile, or that your "available to sell" number is a political compromise between finance and the floor. Those are process problems. They were process problems when you were at 500 parcels a day. At 5,000 they become a daily fire.

I've sat in rooms where the answer to a missed SLA was "we need better software." Sometimes the software was genuinely old. More often, three people had three different definitions of "despatched," and the system was being asked to pick a favourite.

You cannot scan your way out of an undefined handoff. You can only make the undefined handoff faster, and more confident, and harder to unwind.

The sequence that actually works

The operators who don't get ambushed do something boring first. They walk the process as it really runs, not as the SOP says it runs. Receiving. Putaway. Pick. Pack. Handover. Exception. Return. They write down who owns each step, what "done" means, and what happens when it isn't done.

They pick the exceptions on purpose. Failed address. Short pick. Damaged carton. Marketplace cancellation after cut-off. Customs query on a commercial invoice that "usually" works. If you cannot describe those, you are not ready to configure a system. You are ready to buy a very pretty way of being surprised.

Then, and only then, they look at software. Not as a strategy. As a tool that will enforce the thing they can already explain to a new supervisor on a Tuesday. The question is not "which WMS is best." The question is "which one will run this process without inventing a second one."

If you cannot brief the process on a whiteboard, you cannot brief it into a vendor's statement of work.

Why the buy-first habit exists

It's understandable. Software is a purchase. Process is an argument. A purchase has a vendor, a timeline, and a slide that says transformation. An argument has to happen between ops, finance, and whoever owns the P&L, and nobody wants to have it.

Head office also likes a system because a system looks like control. A defined process looks like work. One of those is easier to approve in a budget cycle. The warehouse does not care which one was easier to approve.

I've also seen the opposite failure, which is almost as expensive. Teams who refuse to buy anything until the process is perfect. Process is never perfect. You need it clear enough to configure, not sacred. Clear enough means you can tell a 3PL, or a new shift lead, what to do when the scan fails. That's the bar. It is lower than a transformation programme and higher than a WhatsApp group named "ops urgent."

The goal was never a new system

The goal was an operation that still works when the volume arrives, when the exception rate stops being cute, and when the person who "just knows how we do it" is on leave.

Buy software when you can describe the job. Not before. Not as a substitute for the description. The system will not think for you. It will only repeat you, at scale, including the parts you never wrote down.

If your next meeting starts with a vendor shortlist, close the laptop. Walk the floor. Write the process. Then go shopping. In that order.