New Linnworks users go looking for the customers screen and discover there is not one. There is no customer list, no customer record, no CRM tab. Customer details in Linnworks exist in exactly one place: stamped onto individual orders. For pure marketplace sellers that barely matters. For anyone taking repeat B2B, phone or trade-counter orders, it is a daily tax. Here is how the data actually works, why it hurts, and how to get a working customer lookup without migrating platforms.
Where customer data actually lives
Every Linnworks order carries the customer details it arrived with — name, email, billing and delivery addresses, phone number. Those fields belong to that order. There is no underlying customer entity linking them. If Dave from Acme Builders has ordered from you forty times, Linnworks holds forty separate copies of Dave's details, each frozen at the moment that order was placed, and no concept anywhere that they are the same person.
The consequences follow directly:
- There is no screen listing your customers.
- You cannot pull up a customer and see their order history in one place; you can only search orders and hope the spelling matches.
- If a customer moves premises, old orders keep the old address forever — and nothing warns you when you copy details from a stale order.
- There is no record of what a customer usually pays, which matters enormously in trade where prices are negotiated per account.
Why repeat B2B ordering hurts without one
Picture the standard trade phone call: "Morning, it's Dave at Acme, usual delivery address, can I get another two boxes of the 50mm fixings — same price as last time?"
Every part of that sentence is a lookup Linnworks cannot do. Who is Dave? Search open and processed orders by name and hope. What is the usual address? Open an old order, squint, copy it field by field. What did he pay last time? The retail price on the SKU is not it — Linnworks stores one retail price per SKU, and Dave's negotiated trade price lives nowhere in the system. So you are into a side spreadsheet, or an email trail, or asking Dave to tell you (and trusting the answer).
A two-minute order becomes ten minutes of archaeology, with a re-keying error waiting at every step. Multiply by every repeat customer, every day. We wrote more about the phone-order version of this pain in taking phone orders in Linnworks without re-keying.
The workarounds sellers use
The customer spreadsheet
Most trade sellers end up with one: names, addresses, contact details, agreed prices. It works until it does not — it drifts out of date the moment someone updates an address on an order but not the sheet, two people edit conflicting copies, and negotiated prices from eight months ago are anyone's guess. The fundamental flaw is that it is maintained by hand, parallel to the system of record, and nothing reconciles them.
Searching old orders
The other habit is treating processed-order search as a CRM. It half works, but search matches exact-ish text (was it "Acme Builders" or "Acme Builders Ltd"?), it shows orders rather than customers, and — a trap worth knowing — recently processed orders take roughly 12 to 24 hours to appear in the search index, so yesterday afternoon's order may simply not come up this morning.
A full external CRM
Some businesses bolt on a proper CRM. Legitimate, but heavy: another subscription, another integration to maintain, and a sync problem for order data that never really ends. For most sellers the need is not pipeline management — it is "recognise this customer and fill their details in".
The better answer: derive the database from your orders
Here is the reframe that makes this tractable: you already have a customer database. It is sitting in your processed orders — every name, address, email and phone number for everyone who has bought from you, along with exactly what they bought and what they paid. It is just stored order-by-order instead of customer-by-customer.
What is missing is the aggregation layer: something that reads through the order history, groups orders into customers, keeps the most recent details as canonical, and makes the whole thing searchable. Build that once and maintain it automatically, and you get a live customer lookup that can never drift out of date, because it is derived from the orders themselves.
This is exactly how Trade Order POS works. On setup it reads your last three years of processed Linnworks orders and builds a searchable customer index from them — then keeps refreshing it as new orders arrive. At the point of sale you type a few characters of a name or company, pick the customer, and their details auto-fill onto the order. No spreadsheet, no data entry project, no separate CRM to keep in sync.
Price memory is the other half
Because the index is built from real order lines, it also knows what each customer actually paid for each SKU last time. When Dave orders his 50mm fixings, his negotiated price comes up automatically instead of the retail price — which quietly solves the "one price per SKU" limitation for trade sellers without touching your Linnworks pricing at all. Combined with one-click reorder from a previous order, the ten-minute archaeology call collapses back into a two-minute order.
The honest summary
Linnworks is an order management system, not a CRM, and that is unlikely to change. Your customer data is not missing — it is fragmented across thousands of orders. Spreadsheets rot, order search is slow and misses the newest orders, and a full CRM is more machinery than most sellers need. Deriving a customer lookup automatically from your own processed-order history is the approach that stays accurate without anyone maintaining it, because the orders are the source of truth anyway.
Trade Order POS builds a searchable customer database from your last three years of Linnworks orders automatically — with auto-filled details and per-customer price memory at the point of sale. Try it free for 14 days at trade-pos.mcp-g.com.