Why order management breaks at the second channel

A single-channel operation does not need order management software, because the marketplace already is the order management system. Everything is in one place: the order, the buyer, the message thread, the dispatch button. The process is invisible because it has no seams.

The second channel introduces the first seam. Now there are two queues, and no screen shows both. That is survivable — most sellers survive it for a long time — but the cost is real and compounding:

  • Re-keying. Order details get read on one screen and typed into another: into a courier's system, into a spreadsheet, into an invoice.
  • Divergent stock. Each channel holds its own idea of availability, and they drift apart the moment one of them sells something.
  • Split attention. Nobody can see the day's actual workload, because the workload is spread across tabs.
  • Inconsistent process. Each marketplace has its own dispatch flow, so the team develops per-channel habits instead of one habit.

By the third channel this stops being an annoyance and starts being the constraint on growth. Adding a fourth channel should be a commercial decision. When operations are fragmented, it becomes an operational one — and the answer is usually no.

The four states every order actually has

Marketplaces each use their own vocabulary, but strip the labels away and an order in a physical-goods business moves through the same handful of states. Getting explicit about them is most of the work.

  • New — the order exists and is not yet dispatched. This is the only queue that should be in front of a packer.
  • Dispatched — it has left, with a tracking number recorded against it, and that tracking has gone back to the marketplace.
  • Archived — it is finished and out of the working view, but still fully searchable when a buyer asks about it in six weeks.
  • Reship — something went wrong and it is going out again. This is the state most operations lack, and it is where stock and money quietly go missing.

The reship state matters more than it looks. If a reship is handled by just sending another unit, the stock ledger is now wrong and nobody knows why. If it is a first-class state, the stock movement and the ledger entry follow automatically.

What to centralise first

You do not have to solve everything at once, and trying to will stall the project. There is a sensible order.

  1. The order queue. One list, every channel, with the platform and account visible on each row. This alone removes the tab-switching and gives you a real picture of the day.
  2. Stock. One central count that every channel draws on. Until this is done, every other improvement is built on a number you cannot trust. See the inventory guide.
  3. Dispatch. One process for rate comparison, label purchase, bulk printing and paperwork, so the warehouse does the same thing regardless of where the order came from.
  4. Tracking return. Automatic push-back of tracking to the originating marketplace. This is pure re-keying elimination and it is the step people are most surprised by.
  5. Listing visibility. One view of what is live on which channel, so a simple question does not mean four seller portals. Valuable, but it can wait until the daily operation is calm.
  6. The money. Invoicing, payments and supplier payouts against the orders that actually shipped.

Resist the temptation to start at step five because it is the most visibly annoying. Tidying up listings is gratifying, but the queue and the stock count are what make the rest hold.

Why bulk actions are the whole point

An order-by-order process scales linearly with volume: twice the orders, twice the clicks. The operations that cope with growth are the ones that flipped to batch working.

Concretely, that means being able to select a filtered set of orders and act on all of them at once — print every label, mark them all dispatched, archive yesterday's completed work. It also means being able to bring data in the same way: uploading tracking numbers by CSV rather than typing them, importing a catalogue rather than entering it.

The test is simple. If doubling your order volume would mean roughly doubling the time spent in software, the process is not batched yet.

What to look for when choosing a system

Whatever you evaluate — including Fulfillio — these are worth checking specifically, because they are the things that turn out to matter after the demo:

  • How does it authenticate? Connections should use the marketplace's own authorisation flow, so you are not handing your seller password to a third party and you can revoke access from the marketplace side.
  • Can it hold several accounts of the same marketplace? Multi-account is different from multi-channel, and plenty of tools only do the latter.
  • Does tracking go back automatically? If a human is re-typing tracking numbers into a marketplace, the system has not finished the job.
  • Is there a reship state? See above.
  • What happens when a marketplace API is down? The honest answer is queue and retry, with affected orders flagged. Be suspicious of an answer that implies it never happens.
  • Can you get your data out? CSV export and API access matter on the day you leave, which is exactly when nobody will help you.

How Fulfillio approaches it

Fulfillio pulls orders from every connected account into one queue with new, dispatched, archived and reship states, and shows the platform and account on each row. Orders can be bulk-archived, bulk-dispatched and bulk-labelled, and tracking can be uploaded in bulk by CSV as well as pushed back automatically when you buy a label.

Central stock decrements as orders pull in, so the count behind every channel moves at the moment of sale rather than overnight. Connections use each marketplace's own authorisation flow, and several accounts of the same marketplace can sit in one workspace, each tracked independently.

The detail is on the order management page, and the integrations pages cover how each specific channel connects.