String
Running the operation

What Configuring Shipments by Hand Actually Costs

Published

Every order where a person chooses the box, picks the service, or opens the rate calculator costs you money. It never shows up as a line item, because it is paid in seconds by people who are already on the payroll, and nobody invoices you for it.

It is worth putting a number on, because the number is usually larger than people expect and it is easy to compute.

The arithmetic

seconds per order ÷ 3600 × loaded hourly wage = cost per order
cost per order × monthly shipments = cost per month

Loaded wage means what the person actually costs you, not what they take home. Payroll taxes, benefits, and the share of supervision and floor space that follows a head.

Take a packer at $25 an hour loaded, spending 45 seconds per order choosing a package and entering the details:

It scales linearly, so the per-order figure is the one worth knowing. Substitute your own two numbers and multiply by your own volume. The point is not my figures, it is that a decision costing thirty-one cents is invisible on the order and material on the month, and those are the same fact.

Forty-five seconds is only the package step. If your team is also picking the service, checking rates, or handling exceptions, the per-order figure is a multiple of that. Configuring ShipStation properly takes upwards of ninety seconds per order out of the whole process, which gives you a sense of the range.

The second cost, which is larger and never counted

Labour is the obvious half. The expensive half is what people choose under time pressure.

A packer who is unsure reaches for the bigger box. It is the safe error: the order ships, nothing is damaged, nobody comes back to them about it. The cost lands weeks later as dimensional weight on a carrier invoice that nobody traces back to a Tuesday afternoon.

So manual configuration is not simply slower than automation. It is systematically more expensive in postage as well, and it is biased in one direction. Nobody ever accidentally picks a box that is too small.

That second cost does not show up in the arithmetic above, and on most catalogues it is bigger than the labour.

What removes most of it

Worth being clear that ShipStation handles a large share of this natively, and if that is your situation you are done.

For a lot of operations that is the whole problem solved, and the honest advice is to configure those three properly and stop.

What is left

The decisions that survive are the ones that depend on the particular combination of items in the order rather than on a property of one product or of the order as a whole.

A multi-item order with SKUs of different sizes has no correct box on the product record, because the box depends on what else is in the basket. That is cartonization, and it is a computation over the item dimensions rather than a rule anyone can write down ahead of time.

Those are the orders where the packer is still deciding, which means they are the orders still costing you both halves — the seconds and the conservative box. They are usually also your largest orders.

If that residue is a small share of your volume, a person handling it is genuinely the right answer and the arithmetic above tells you how small it has to be. If it is not small, work out what it costs before deciding what to do about it.

Whether this is happening in your operation

String builds and maintains logic like this inside existing ShipStation accounts — cartonization, rate selection, batching, inventory-aware holds, cold chain rules. No dashboard, nothing for your team to learn.

Typically for operations past 6,000 orders a month with a dedicated fulfillment team.

See which of the eight patterns are in your own data