Replacing a shipping workbook with a platform, in production in a day

Every shipment started as a copy of a form tab inside one shared workbook. A technician or an office manager filled in the customer, the machine, the fault, the repair and what went in the box, then printed two documents from two ranges on the same sheet.

The workbook had grown by hand for years. Two unrelated tables shared rows by accident of layout, prose and phone numbers sat in the same columns as shipping items, and codes were prefixed with an underscore to stop Excel reformatting them. Anyone reading it naively would import fifty items where there were fourteen.

Nothing was enforced. A package could be marked shipped without a tracking number, a request could go out without written authorization, and freight figures (weight, volume, density, freight class) were worked out by hand against a printed lookup table every time.

We treated the workbook as the specification. Its structure told us what one shipping request is, and its quirks told us what the import had to survive, so every column is read by its header text and every block has to look like itself before it is trusted.

Small packages and freight are separate flows, because they are shaped differently: freight moves between the company's own sites in both directions, and the billing term follows from the route rather than being typed. Each crate is a record with its own dimensions and weight, and the carrier figures are calculated live as the crate table fills in.

One record produces both printed documents: the internal service report and the packing slip that goes in the box, with no diagnosis or pricing on it. Requests move through clear stages, and a stage cannot be completed without what it needs, such as a tracking number to ship or an arrival date to close.

The team signs in with their existing Microsoft accounts, and a Slack message lands when a request is submitted. Iteration rounds from the team have shipped the same evening they were asked for.