Packit

The problem

Multi-channel sellers work out of one seller portal per marketplace. Stock counts live in a spreadsheet that someone updates by hand after checking each portal in turn. The counts are correct at the moment they are typed and drift from then on.

Two things follow from that drift. Orders wait because nobody has looked at the right tab yet, and stock gets sold that is already spoken for, because the spreadsheet does not know about the order placed on the other channel a minute ago.

What we built

Packit is a multi-channel e-commerce operations platform that runs Amazon and eBay from one screen. An overview dashboard opens on total revenue, active orders, low-stock items and the number of connected channels, with a sync indicator showing when the data last refreshed. Revenue is charted by weekday and split Amazon against eBay.

Packit's order dispatch queue is the screen operators live in. Orders arrive from both marketplaces and sort themselves into piles, each pile named for what is blocking it: waiting on payment, SKU not recognised, listing not linked to warehouse stock, unusable address, not enough stock to allocate. Orders that clear every check land in “ready to dispatch” with their stock already reserved. An operator reads the pile name and knows what to fix without opening the order.

How it works

Packit treats a parked order as something to re-check rather than something to repair by hand. Every order walks the same ordered set of gates — paid, SKU known, listing mapped to stock, address usable — and a failed gate parks it with the reason recorded against it. The check is safe to re-run any number of times, so when the cause is fixed the order un-sticks itself on the next sweep. Fixes also target: importing a listing wakes the orders that sold it, and booking in a delivery wakes the orders that were short of that product.

Stock reservation is all-or-nothing inside a database transaction, with each product row locked in id order to avoid deadlocks. If any product on the order is short, nothing is taken and the order parks as unallocated, naming the exact SKU and shortfall. This is what stops the overselling that the spreadsheet allowed.

Marketplace latency is kept off the operator's screen entirely. Sync runs as Sidekiq jobs on a schedule — orders every ten minutes, FBA quantities every fifteen, Buy Box prices every two hours, listings nightly — so a slow marketplace response delays a background job, never a page load. A Redis lock prevents two sweeps overlapping, since a long eBay pass stacking behind another would starve the worker.

The result

Order state is now recorded rather than inferred, every blocked order carries a written reason for being blocked, and resolving a cause clears the affected orders automatically instead of requiring someone to find them.