AI adoption is moving, and moving fast

At OX1, 63% of operators were in regular use or actively rolling AI out across their organisation. By OX3, that number is 77%. The share who had never used AI at work fell from 5% at OX1 to zero at OX3, and regular use in their own workflow rose from 38% to 52%.

The returning operator data pushes it further. Operators who came to both OX1 and OX2 went from 59% in regular use to 82%. A 23% jump in three months from the same group of people.

Stockholm brought a different mix of operators from Manchester and London, so some of the OX3 shift will come from the room as well as from people progressing.

Founders, MDs and C-suite made up 31% of OX3 registrations, up from 13% at OX1.

What operators are worried about has shifted

The free-text answers across three events show a clear change in what operators are bringing into the room.

Reporting and analysis dominated at OX1, showing up in half of all free-text answers. By OX3, that had dropped to 11%. Data and systems has moved the other way, from 10% at OX1 to 22% at OX3. Workflow automation and manual work has eased from 40% to 25%.

Operators are now asking whether their systems are fit for purpose and whether the data moving between them can be trusted. At OX3, accurate data flows between systems was the most selected challenge, chosen by 43% of operators.

Merchandising, buying and planning have grown as a remit across the room too, up 16 percentage points from OX1 to OX3. The operators thinking about AI in the context of stock decisions and range planning are showing up in larger numbers each time.

If data moving between your systems is the problem your team keeps returning to, that is where many of your peers are focused too.

The people who keep coming back

Six operators have been to all three events, across two different countries. The OX community is where these conversations continue between events. Slack, WhatsApp, LinkedIn. The pub after events.

Brand-side operators can apply to join at operatorexperience.ai

So don’t frame it as connecting system A to Shopify. Frame it as moving a product through different levels of readiness, without rebuilding the data every time it crosses a team boundary.

If you’ve got an ecom team spending hours reformatting and cleaning product data before they can do any actual trading work, you’re seeing the cost of that broken handoff in the most expensive place. And you’re also guaranteeing tension, because the last team in the chain will start protecting itself with workarounds.

Start with identity not with Shopify

The pipeline starts when the product is first defined, not two weeks before launch. If you only collect product data at the end, you’re forcing someone downstream to make up structure under pressure, and then you’ll automate that bad structure forever.

This is also why the PLM conversation matters even if your immediate pain is Shopify. When you treat PLM as infrastructure, you stop obsessing over pretty workflows and start obsessing over the data model, governance, and who can change what.

Go look at your own product setup and ask a boring question. When a style becomes real, can everyone agree on what it is, how it splits into variants, and how it will be identified in six months when it’s on promo and you’re trying to reconcile margin.

Once identity is stable, you can decide what should reach Shopify early, and what shouldn’t. You’re not debating tooling at that point, you’re debating readiness.

One pattern that works is creating draft products while development is still underway, so digital teams can get started on enrichment and campaigns.

That’s the right instinct, by the way. The mistake is tying early visibility to customer-facing readiness.

Draft and live are different jobs

Shopify is brilliant at storefront work. It’s not where you want your teams re-keying SKUs and barcodes because somebody upstream didn’t decide the structure.

In one recent project, the intent was clear. Let the operational system handle the heavy lifting, SKUs, barcodes, pricing, weights, and sync that into Shopify so ecom can focus on imagery, descriptions, and merchandising. That’s the whole point of a pipeline.

So build two states and make them explicit.

One state is visible internally, safe for trading and marketing teams to prep against, safe for finance and ops to plan against, but not sellable. Plenty of brands already do versions of this with publish flags or whatever controls they’ve got, even if they’ve never written the philosophy down.

The other state is approved for sale. Different bar, different consequences.

Don’t make this abstract. In your data model and your workflow, separate the question can the team see it from the question can the customer buy it.

One source of truth still needs boundaries

The phrase source of truth is where teams go to feel good about a diagram. Then they ship the integration and realise nobody agreed what happens when two systems disagree.

Field-level ownership is where undocumented estates actually hurt. It’s not the connections themselves, it’s the overlaps, two systems both writing to the same field, in different formats, on different schedules.

The operator move is boring and absolute. Name a source of truth for product data and write down which system wins when systems disagree.

You can take it further and do it per attribute, not per system, because the right answer for price is often not the right answer for copy.

This is also how you avoid the dumbest possible outcome, which is building a central product layer that tries to replicate everything Shopify does. That path just creates more admin, more conflict, and a bigger gap between how people actually trade and how the data model expects them to behave.

If you want a practical check, pull up your integration spec and highlight every field that someone edits in Shopify today. For each one, decide if that edit is corrective, meaning fixing upstream mess, or if it’s intentional enrichment, meaning real channel work. If it’s corrective, move the fix upstream. If it’s enrichment, protect it.

Workflow and interfaces decide whether it sticks

A lot of data initiatives die because we pretend humans don’t exist. You ship a PIM or a new product master, then everyone quietly carries on in spreadsheets because the interface is hostile and the approvals are vague.

The best principle I’ve seen here is simple. People shouldn’t be editing tables unless they absolutely need to. Guide the inputs, validate them, and make your best-case flows faster, not just your worst-case scenarios less painful.

If you don’t, you get the classic failure mode. One team’s using the PIM, one team’s ignoring it, and one team’s keeping a mirror spreadsheet just in case.

Syncing isn’t success

Even if you nail identity, ownership, and states, you still need to know what actually landed in Shopify. And you need to keep approval, queued, sent, and correct in Shopify as separate ideas, because they are.

This is why the unsexy stuff matters. You want explicit submission and review steps, minimum-field checks, and a clear way to spot what failed validation versus what failed on the way into Shopify.

If you’re about to tackle this, don’t start in middleware and don’t start in Shopify. Start with a map and some decisions.

• What’s the minimum dataset that makes a product operationally usable, and where does it get created.

• What’s the minimum dataset that makes a product ready for commercial prep, and how do you keep it non-sellable.

• For the fields that matter, which system wins the conflict, every time.

Before you throw another tool into the mix, take a proper look at what you’ve already got, where the data is coming from, who owns it, and whether the workflows are written down or just passed around in Slack. If any of that is fuzzy, the connector isn’t your biggest problem. It never was.

The PO keeps changing after it’s sent

A PO goes out from the ERP, then delivery dates and quantities get renegotiated with the supplier over email and logged in a merchandising tracker. A colour code gets corrected, or a barcode is reissued, and the product record updates while the 3PL is still expecting what the original PO told it. Within a few weeks, the ERP and the tracker have drifted apart, the supplier’s confirmation says something else again, and the factory ships against whichever version it has.

We’ve spoken to brands where around one in four POs had a problem by the time the stock reached the warehouse, from wrong barcodes on cartons to stock booked for one market arriving in another. Changes to a PO belong on the PO, checked before release, where the supplier and the warehouse can both see them.

Complete fields can still be wrong

Buying usually enters composition first, from the supplier’s spec. Garment tech then checks it against the test certificates. If the website and the wholesale platform both pull from the PLM before that check happens, the unverified version goes live. We’ve seen the wrong composition published to customers this way.

Most PLMs show a completeness score. It tells you a field has something in it and says nothing about whether it's right. Approval statuses help, but only if the website and wholesale feeds are set up to wait for them, and often they aren't. It's worth checking whether yours can hold a product back until garment tech has signed it off, and whether anyone checks the physical care label against the record on the production sample.

Next season shouldn’t be able to overwrite this one

Carryover styles are where PLM to ERP syncs get risky. A product running into a new season keeps its identity, but its price and status change for that season. If the sync treats the newest record as the truth, a change made for next season can overwrite this season’s RRP while the product is still on sale.

The business has to decide which season is allowed to publish to the ERP, before anyone builds the integration.

Wholesale can’t sell what it can’t see

Wholesale orders are often taken against a preseason forecast that never makes it into the systems. Merchandising buys to cover it, but nothing connects the wholesale order to the supplier PO that’s meant to fill it. When availability is shown to agents and stockists, the only reliable number is what’s already in the warehouse, so lines get dropped from orders after they’ve been taken.

A wholesale catalogue has to be backed by incoming stock and allocation. Listing the products is the easy part.

The integration ran, so everything must be fine

Integration monitoring tends to check whether a feed ran. In one rollout, wholesale orders synced into the ERP as expected, and every one of them arrived in the DTC sellable location. In another, short-shipped lines on partial dispatches stayed open and left availability negative.

The useful check is where the order ended up and what state it’s in once it gets there.

Finding yours

None of these is solved by a new system. Each one comes down to a named owner at the point the data changes hands, and someone checking what arrived on the other side.

Start with the spreadsheets that exist before the PO. Every brand calls them something different, from range master to product master, and one of them usually ends up as the source of truth without anyone deciding it should be. If nobody can find a current process document for a handoff, you’ve probably found one of the weak ones.

Ask anyone there and they’ll tell you the spreadsheets are the problem. We’d want to know what the spreadsheets are hiding before anyone replaces them.

This one is for whoever owns product data without it being in their job title. That’s often the head of ecommerce or operations, and sometimes product or merchandising. You’re probably being asked to choose a PLM or a new ERP module this year, and you’ll probably be the one asked later why it didn’t fix things.

Every team already has its own definition

Merchandising has one definition of a confirmed product and finance has another. The warehouse usually has the most reliable version, because it gets checked against physical stock every day.

Spreadsheets keep those definitions apart, so for a while nobody notices the gap. A shared system puts them side by side from the first week. That’s why so many rollouts feel worse in month one. The mess was already there, and the new system shows it to people who couldn’t see it before.

We saw the same thing at another fashion brand. The PO master lived in one tool and the bill of materials in another, with a third added later to cover whatever didn’t fit either. There was no shared validation between them. The people closest to the product were each working from a different definition of it, and each was right about their own part of the business.

Ask when the critical path was last written down

A quick test is to ask when the critical path was last documented in full, start to finish, somewhere everyone can see.

If the answer is a long pause or a date from two years ago, you’re looking at an ownership problem dressed up as a data problem. Nobody was made responsible for the thing everyone downstream depends on, so nobody built it until the pain got bad enough to force it.

Agree what a product is before you buy software to hold it

None of this is an argument against spreadsheets, or against buying a PLM or a new ERP module. Sometimes buying one is the right call, and the risk sits in the order you do things in.

If the system arrives before the definitions and owners are agreed, you’ll spend the next eighteen months configuring software around a disagreement it can’t resolve. What was missing was one governed version of what a product is, and a clear rule on who is allowed to change it.

Do that first, even roughly on a whiteboard, before the vendor demos start. Otherwise the new system tends to become spreadsheet eighteen, with a nicer login screen and a bigger invoice.

If you’re the one being asked to pick the system, take this into the room before the demos. Find out who owns the critical path and who is allowed to change a product after the PO goes out. If nobody can answer, that’s the first thing to fix, and it costs a lot less than the software.

This article is written for operations, product data and compliance leads at brands selling into the US and EU, and is worth forwarding to finance, ecommerce and whoever manages your customs broker.

A range can be signed off and booked into the warehouse with a launch date agreed, and still be unsellable in a market. What usually stops it is proof that the product is what you say it is and that a named legal entity is responsible for it. That proof has to survive the trip through every system between the product record and the customs entry.

Tariff codes don’t tell you what testing applies

Take one apparel SKU going into the US and the EU.

In the US, Consumer Product Safety Commission (CPSC) eFiling became mandatory for most imports on 8 July 2026. Certificate of compliance data now goes electronically to US Customs and Border Protection (CBP) as part of the import entry. The rule adds no new testing. It changes how certificate data you should already hold reaches CBP.

CPSC publishes a list of US tariff codes it expects to flag for eFiling and says plainly that the list isn’t exhaustive. If a product is regulated, the obligation applies whether or not its code appears.

Children’s sleepwear is the clearest example.

• The tariff schedule has headings for pyjamas and nightdresses, but none of them tells you whether a garment counts as children’s sleepwear under US safety rules.

• Whether it counts depends on what the garment is intended for and the size range it’s sold in.

• General clothing only has to meet the basic US flammability standard (16 CFR 1610).

• Children’s sleepwear has to meet much stricter flammability standards, under 16 CFR 1615 for sizes 0 to 6X or 1616 for sizes 7 to 14.

• Garments for babies aged nine months and under are exempt from the stricter tests, as are tight-fitting styles that meet set measurements. They still have to meet the general clothing standard.

• Merchandising and product need to agree intended use and age range with compliance before anyone picks a tariff code, because that decision sets which tests apply.

In the EU, the listing is the sticking point

The EU’s General Product Safety Regulation (GPSR) has applied since 13 December 2024. For anything sold online, the listing has to identify the product and the manufacturer, with contact details. Where the manufacturer sits outside the EU, the listing also needs an EU responsible person, an EU-based business that takes on safety duties for the manufacturer. Any warnings have to be in a language shoppers in that market can understand.

So whether a SKU can be sold in Germany is now partly a product-record and localisation question. Physically compliant goods can still be held up by a listing that’s missing one of those fields.

French EPR is more than one number

France adds category-specific extended producer responsibility (EPR). Products in the textiles and footwear category need registration and volume declarations, with eco-contributions (a per-unit fee) paid on what you declare. Packaging is a separate obligation.

A brand can be obligated for apparel and packaging at the same time. Which entity holds each obligation depends on who is actually placing that category on the French market, and with DTC running alongside wholesale that isn’t always the same entity.

The new EU guarantee rules need two different owners

Since 27 September 2026, two EU requirements apply that look alike on a Jira board.

The first is the harmonised legal guarantee notice, a standard EU notice telling consumers about their legal right to a minimum two-year guarantee. An ecommerce site can meet it with a general notice on the site, which makes it a site-level change with legal sign-off and localisation behind it.

The second is the GARAN label, the EU’s harmonised label for a producer’s voluntary guarantee that a product will keep working for a stated period. It only applies when that guarantee is free and covers the whole product for more than two years, and the standard two-year legal guarantee doesn’t qualify. Where it does apply, it becomes product-level work. The producer supplies the guarantee information and the seller displays the label in a fixed design, which has to show the guarantee duration alongside the brand and model identifier.

Not everything is a product passport

Plenty of teams use DPP as shorthand for any EU rule that touches product data. The product identifiers GPSR requires on listings today are a separate thing from a textile Digital Product Passport, a digital record of a product’s composition and sustainability data that the EU is introducing category by category under its ecodesign rules. The Commission is still drafting the detailed rules for textiles, so there’s little sense building batch-level complexity around a guess.

That isn’t a reason to ignore what’s already live. Stable model identifiers linked to their evidence, plus a named owner for each market role, help with GPSR and US certificates now and will make any future passport easier to meet.

Customs refunds don’t arrive on their own

In February 2026, the Supreme Court ruled that the International Emergency Economic Powers Act (IEEPA) doesn’t authorise tariffs. CBP stopped collecting those duties from 24 February, and on 20 April opened a refund module in its ACE (Automated Commercial Environment) system, called CAPE (Consolidated Administration and Processing of Entries).

The money goes to the importer of record, the party legally responsible for the entry and its duties, or to a third party the importer authorises on CBP Form 4811. It also needs ACH (the US bank transfer network) refund enrolment in ACE, and an ACH setup used only for paying duty doesn’t count. CBP’s own reporting lists refunds rejected for missing ACH enrolment.

If you sell through a merchant of record (the business legally selling to your customer) or use a third-party importer, CBP still pays the importer of record or their designee. Your contract decides who is commercially entitled to the cash, so it’s worth checking before the refund arrives.

First sale is a paperwork programme

First-sale valuation gets talked about like a setting you switch on in a spreadsheet.

It lets you declare customs value on an earlier sale in the chain, typically factory to middleman, instead of the later sale to the US importer. It only holds if you can evidence a genuine sale clearly destined for the US and made at arm’s length (on normal commercial terms).

Without that evidence there’s no saving, and doing it properly means every team touching the supply chain agreeing with your broker on what gets documented and where it’s kept.

The asset is the line between product and proof

The thing worth building is a traceable line connecting the physical product and the legal entity to the evidence and to each channel’s product record. Without it, SKUs keep turning up ready to ship but not ready to list, or imported under one entity and refunded to another.

Trace one SKU from the product brief to the customs entry and look for the hand-off where a system assumes an answer nobody has signed off. The rules will keep changing, and a business that can answer these questions from its own data spends less time and money each time one of them becomes a new field.

The problems operators picked belong to more than one team

When operators registered for Stockholm we asked which challenges they recognise most. Accurate data moving between systems came top, picked by 43% of brand-side operators so far, with decisions made on incomplete data next at 33%. Neither of those sits with a single department. They show up where a product passes from the person who created it to the teams downstream who have to buy it, trade it and report on it, and they tend to outlast every fix that has an owner’s name on it.

The free text said the same thing in plainer language. People wrote about systems that don’t sync and the admin that fills the gap between them. They also wrote about getting AI out of trials and into the working week, and about finding time to do that on top of the day job.

Everyone in the room is after the same number

Every brand at OX3 and every partner around it is working towards one outcome, which is making and selling product at the best margin they can and growing from there. Nobody in that chain gets there alone any more, whether it’s a merchandising team relying on clean product data or a finance lead waiting on figures from three different systems.

The partners in the room can show what the technology does once it’s joined up. We play the brand-side team trying to do the joining, because that’s the part most businesses find hardest.

How the afternoon runs

OX3 is at Blique by Nobis in Stockholm on Thursday 22 October, starting at midday. I (Luke) open by setting out what the day is for. Brands then take the stage for the show and tells, each talking through something they’ve put live this year and what it changed inside the business. The brand tells the story and the partner who worked with them helps set it up.

After that the room splits in two. The Make half follows a product from concept through costing and buying to getting it live. The Sell half picks it up once it’s on sale and covers trading, merchandising, performance, returns and margin.

Each room starts with the concept of a single product walked along a chain. We’ll share specific AI use cases to serve as inspiration and to get the rooms warmed up. Every partner picks it up at the point where they do their job, and Commerce Thinking plays the brand side holding it together. Then it’s close to an hour at the tables on problems operators raised when they registered, with time either side to meet people and talk to the specialists in the room. Both rooms are captured and everyone gets the takeaways from each.

Who you’ll be working alongside

Operators from Liverpool FC, & Other Stories, Lindex, Björn Borg, Nudie Jeans, Houdini, Asket, Drake’s and House of Dagmar are among those registered so far, with more approvals going through each week. Titles range from CEO, COO and CFO to operators of ecommerce, production and operations.

Dema are headline sponsor. You’ll hear from Dema, Centra, Resourced and Emfas, who lead the walkthroughs in the two rooms. Torque, HighCohesion, Loop, Pro Carrier, Vervaunt, Commerce Thinking and Whānau will be at the tables, each working on the part of the chain they know best.

What you take home

We want people to leave with a clearer view of how the systems in front of them now connect, from the first product sketch to the line in the P&L. We also want everyone to go home with one change they can make to how their own team works the following week, and a few people they’ll want to whatsapp for some guidance.

OX is for brand-side operators. If you run part of the chain inside a brand and haven’t registered yet, apply at operatorexperience.ai.

By then their input arrives as a change request. It gets priced and argued about against a plan everyone has already agreed to, and some of it gets dropped because go-live is now too close to peak.

So this one is written for the person doing the early research. You are probably in finance or operations or digital, and you are probably the one who has to explain the cost of this later. Here is who needs to be involved, and when.

Merchandising decides more of the build than anyone expects

Merchandising is the domain most ERP programmes never really cover, which is why it is worth naming first.

Why merchandising gets left out

Nobody sets out to exclude them. Their involvement never gets made mandatory, by the brand or by the systems integrator, so it comes down to one short high-level session and then nothing genuinely useful again until UAT. The people gathering requirements do not really understand merchandising, and the merchandisers have not been shown what an ERP can and cannot do for them, so everyone leaves that session thinking it went fine.

A merchandising calendar also has no quiet period, so the hours that ought to go into the project go into trading, planning and managing the year instead. Go-live tends to get planned around the finance calendar or peak trading, which puts UAT and training exactly where ranges are being signed off and orders placed with suppliers.

Some of it is not an ERP problem at all. A good deal of the upstream work belongs in a modern PLM, and vendors and SIs tend not to raise it, so the brand finds out late and the gap limits how useful the ERP ever becomes.

Product data is where the damage compounds

Product means different things in different brands. Buying, product development, or both, plus whoever raises the purchase order and manages intake with the supplier. Wherever it sits, it is the function that creates the record every other system depends on.

A field added to satisfy one report can break something two integrations away, and the break usually shows up somewhere else entirely, weeks later, as a data problem nobody can trace back.

Finance treats multi-entity as a discovery rather than a decision

Multi-entity and multi-currency are design decisions. They get found halfway through instead, when a brand opens a US entity or starts selling in a second currency. Reconciliation is the same shape of problem. Designing it in costs a conversation in week two. Bolting it on costs a bad month-end, and then several more.

Operations knows how the 3PL actually behaves

Purchase orders and commitment visibility belong in one place, and operations is the function that can tell you what one place means in your business. Inbound and allocation have to match how your 3PL behaves in practice rather than how the contract describes it. The people dealing with that gap daily are the only ones who can describe it.

Three more, and they have the same problem

Digital and ecommerce, wholesale and retail each get their own piece. Wholesale runs on its own clock and does not survive being modelled as DTC with a different customer record. Retail does not inherit the DTC playbook.

“When you do an ERP, you have to take people on the journey. That time never got carved out of their day jobs, so it didn’t really happen.”

The common factor is timing. Each of these teams gets brought in after the decisions that affect them most have already been made. Bring them in at the start and the specification gets better, because they are reacting to something real rather than describing a system they have never used.

What Atelier is for

Atelier is what we already know about how each of these teams works, written down before a project starts. Every department is covered, including the ones a programme usually gets to last.

That means the standards and the questions arrive on day one rather than at the end. A merchandiser does not have to invent their requirements from a blank page in the middle of a trading peak, because the process is already described and their job is to correct it rather than author it. The same holds for product data and for intake.

It also means the upstream gaps get named early. If something belongs in a PLM and not the ERP, we would rather say so in week two than have it arrive as a change request during UAT.

None of it is complicated. It has just never been handed to anyone at the start of a project.

This isn’t a failure of any individual decision. Every connection got made for a reason, usually a good one, usually under time pressure. The gap sits above the individual integrations, in the space nobody was asked to own.

Three parties, three versions of how it currently works

The cost appears when more than one party has to touch the same systems at once. An internal team is mid-build while a new platform is being onboarded. A consultant arrives to fix something specific and gets briefed by whoever happens to be free that week. Everyone is working from their own understanding of the current state, because no diagram exists that anyone has agreed is accurate.

You can test this in about ten minutes. Ask three people who know the stack to draw it on a whiteboard separately, then compare. The disagreements are never about the big boxes. They’re about direction of travel, what happens on failure, and which connection is still live.

The question that stops the room

Ask a brand which system owns the price for a given SKU and you’ll usually get an answer. Ask what happens when two systems disagree about it, and the answer gets slower. Ask the same about stock, about product status, about the tax code, and at some point somebody says they’ll need to check with the person who built it.

Field-level ownership is where undocumented estates actually hurt. Not in the connections themselves, which tend to be fine, but in the overlaps: two systems both writing to the same field, in different formats, on different schedules, with a last-write-wins rule nobody chose deliberately. That’s the bug you find at 4pm on a Friday during peak, and it’s the one that takes three days to trace because the trace has to be rebuilt from scratch every time.

Why it never gets written down

Mapping has no natural owner. It isn’t a sprint goal, it doesn’t close a ticket, and it belongs to no single team. The person who understood the last integration best has usually moved on to the next one, or moved on entirely.

It’s also the first thing cut. When a project runs late, documentation is the line item that can be dropped without anything visibly breaking that quarter. The cost lands eighteen months later, on someone else, in a different budget. That’s a structural incentive problem rather than a discipline problem, which is why telling teams to document more has never worked.

What a usable map contains

Most estates have some form of diagram somewhere. The reason it doesn’t help is that it stops at the boxes and arrows, which is the part everyone already knows.

A map that earns its place covers:

• Every live connection, including the ones built for a project that ended

• Direction of travel per field, and which system wins a conflict

• Sync frequency and what queues up behind a failure

• Who owns the credentials, and what expires when

• Which environment the connection exists in, and whether the sandbox matches production

That last one gets skipped more than any other. Sandbox and test environments that are current, rather than merely present, are the cheapest way to find out where the picture is wrong before production tells you.

The map matters most when something is about to change

A replatform, a migration, an ERP swap, a new marketplace. These are the moments several parties need to agree on how the system behaves now before anyone can safely change it. Discovery on a replatform is largely the cost of rebuilding a map that should already have existed, and it gets paid at consultancy day rates by a brand that already knew the answers somewhere in the building.

The same applies to a new hire. Someone senior joining an ecommerce or systems team spends their first two months asking five people the same question and reconciling the answers themselves. Handing them an accurate map turns that into a week.

A map nobody maintains is worse than none at all

Here’s the uncomfortable part. A diagram last updated in 2023 is actively dangerous, because people trust it. They plan against it, scope against it, and brief vendors from it. An absent map makes everyone check. A stale one makes everyone confident.

So the maintenance question has to be answered at the same time as the mapping question. Someone owns it, it gets reviewed when a connection changes rather than annually, and it lives where the people who need it already work. A map maintained in a tool only one person has a licence for has already started rotting.

Why we’re the ones saying this

Commerce Thinking shares co-founders with HighCohesion, an iPaaS platform built off years of hands-on integration work. Integrations aren’t an add-on service for us, they’re where the firm started. We’ve built this picture for 30+ brands, across most platform combinations you’d expect to meet.

If nobody internally has the time or the remit to own the mapping, that’s the work we do, and it’s usually faster than the internal version because we’ve seen the same shapes before.

Every new system and every new consultant is a chance to add to a shared map or to quietly work around the absence of one. The first costs a little time now. The second costs considerably more later, usually to someone who wasn’t in the room when the original decision got made.

The last time we hired, Lauren joined as General Manager, after consulting for several brands and, before that, building her career inside Oh Polly. Before her, Amy joined us from a brand-side merchandising and planning career at Acne Studios, Burberry and others.

We’re selective about who we hire. Today we’re starting the search for our next recruit. The role matters to where we’re taking Commerce Thinking, and we have a clear idea of the person we need…

But we don’t have a job title.

Last week we sat down to finalise what this job actually is. Maxime, Lauren and me, on a call Granola was recording. Most of what follows is copied from it, because the conversation was really honest and we landed on a role that’s perfect for the right person looking to take the next step in their career.

So if you’re brand side, love being in the weeds of systems, data, ops, finance and merch, and want a new challenge then read on.

“We’re not looking for a traditional Sys Admin”

That was Maxime, about twenty minutes in, and it settled a big question.

The traditional version of this hire is a systems administrator with deep specific platform experience. Whether that’s ERP, PLM or something else. Historically businesses will hire an out-and-out expert in that system. Someone whose whole value is one platform isn’t a fit here, they must be able to work effectively across multiple systems at once. Their key value is seeing things across systems, and cross-functionally within a brand. They see how things relate to one another up and down stream.

So we are not hiring a single-system specialist. We are hiring someone who understands how a fashion & lifestyle business actually runs and can work out the systems part.

The best people for this often come from a different department

Maxime again, on where his team at Gymshark came from: “Half of my team at Gymshark ultimately came from the CS team.” Lauren said similar about hers at Oh Polly.

His reasoning: “They tend to understand the business. They tend to know Shopify already. They tend to know NetSuite already. They get how things should flow to/from warehouses and retail stores. They’re not the system experts, but they have a really good cross-functional understanding of the processes that run the business. They understand how data flows, at least on a high level.”

That is the profile. Someone who has been on the receiving end of bad data and has had to explain it to a customer knows something a systems specialist often doesn’t. Similarly, the likes of ops, merch and finance people inside of brands are connected to practically every stock linked transaction so have an in-the-bones understanding of if things are or aren’t working correctly.

We don’t train you from scratch

This was a key part of the call.

I asked whether, as a business, we are set up to develop entry-level people. Maxime’s answer: “developing someone in this role is just spending time with that person, which we don’t have a lot of.” Lauren had the numbers in front of her.

There are six of us. The people who hold the knowledge are the same people delivering the client work, and they do not have a spare day a week to run a training programme. Pretending otherwise would be unfair to whoever we hired.

The way I put it on the call: this is a finishing school, not an academy. If you are already good and stuck somewhere that cannot show you anything new, we’re the right next step in your career. If you need teaching from the ground up, we would be doing you a disservice and we would rather say that now.

The first three months are repetitive

Reconciliation. Imports and exports. Checking data has synced and resyncing it when it hasn’t. Validating a report someone has stopped trusting. An integration event that failed overnight.

That work exists underneath every client relationship we have, it is what our retainers are built on, and it currently lands on (very very capable) consultants. Whoever takes this job spends their first quarter doing all of it, across every client, until they know how each operation runs.

We could have written that more attractively. It would have been a waste of everyone’s time.

Then you get to decide how support should work

Here is the part I would take this job for.

We have never standardised support. Maxime’s version of success in twelve months was not having to be first line any more and becoming an escalation path instead, and the thing that gets us there is somebody deciding what support at Commerce Thinking should actually look like. The tooling, how requests arrive, what gets triaged and what gets escalated, how our systems talk to each other, and how much of that manual list above stops being manual at all.

We have a view. We do not have an answer, and we would rather hire the person who can formalise a plan AND deliver it with us.

What we still haven’t decided

The level. We have landed somewhere around the middle with room either side, and we will move for the right person in either direction.

The title. We have deliberately not put one on it. We think we’ll find the right one when we find the right person.

Why this might be a good move for you

Most people doing this work are doing it inside one brand. First person to get the Slack message when something hasn’t synced, first person they come to when a report returns a number nobody expected, first person they ask to set up a saved search. It is a real skill and it is almost invisible from inside one company.

You would do it across a portfolio of nine-figure brands instead of one, and you would see how each of them is nuanced. That is a massive draw for someone looking to develop their knowledge, experience and further their career inside fashion & lifestyle.

Lauren said it: you do not often get the chance to learn across a wide range of businesses like the roster we have.

The spec is here. If you read this far and thought about someone other than yourself, send it to them.

And email lauren@commercethinking.com if you want to talk about working with us.

What your interview panel could look like…

Ask a hundred operators what they want to fix and you would expect the answers to sort themselves by job. Merchandising asks for one thing. Finance asks for something unrelated. That is not what has come back.

Just over four in ten of the operators registered so far picked data moving accurately between systems. More than a third picked automating work that crosses teams. A third picked being able to analyse performance and get something usable out of the other end.

Those three have one thing in common. Not one of them belongs to a department. They live in the handover, between the person who creates something and the four people downstream who inherit it. Nobody’s objectives mention them, which is how they survive year after year while every problem with a name on it gets fixed.

Which is why the tables are built around problems, not job titles

The afternoon runs as two sessions at the same time. One works on getting a product decided, costed and live. The other works on what happens to it once it is there.

Nobody chooses on the form. We read the registration answers against what people actually do and place them, because those tables only work if both ends of the handover are sitting at them. With a third of the room booked, the balance between the two moves every week and we rerun it on every batch of approvals.

The same goes for the session list. It is built from the answers, it is not finished, and it will not be finished until closer to the day. If you registered and gave the challenge question a one-line answer, go back and give it more, because the free text is what decides the running order.

The partners were not asked for a slot

Dema are headline sponsor. What we have asked them for is not a presentation.

The firms in the room see more brands in a year than any one operator sees in a career. The question put to them is what brands will need to be doing in two years to still be performing, and what they are building now to make that less painful. They open the sessions with that, then work the tables.

After that it is about who is useful on what.

Emfas on product data at the point somebody types it in.

Resourced on what a range really costs and how long it takes before anyone commits to it.

Centra on running wholesale, B2B and D2C off one system, which is a range question long before it is a trading one.

Dema on forecasting at one end and turning a performance read into an actual decision at the other.

HighCohesion on the handover itself, and the job of producing one set of numbers that survives contact with a trade meeting.

Vervaunt on performance and launch.

Loop on returns, and the impact on them across the whole business. Torque and Pro Carrier on the part where the physical thing has to turn up, and come back again if it is returned.

We are Whānau chair one of the two rooms and bring the number the rest of it eventually runs into, which is gross margin and what lands in the P&L. A finance-literate voice at a table of trading and merchandising people changes the conversation about ten minutes in.

Commerce Thinking chair the other room and take the handover session with HighCohesion, and we are across both rooms all afternoon. Because this is where we play.

The particulars

• Thursday 22 October, Blique by Nobis, Stockholm. Midday, through the afternoon, drinks after

• Brand side only, senior operators, capped at around 70. Roughly a third booked

• Confirmed so far includes H&M, Damson Madder, Klättermusen, Ellis Brigham, Nudie Jeans, Björn Borg, NN.07, Nordic Knots, & Other Stories, Ro&Zo, Drake’s and more

• Discounted rooms held at the venue for the 21st and 22nd, code goes to everyone approved

• No UK member is expected to travel for this one. If you want to be there anyway, tell us and we will see what can be done

• If you know operators worth knowing in Stockholm, introduce us

Every registration gets read by a person, and you hear back either way. operatorexperience.ai.

Atelier is our delivery model and is being built for fashion and lifestyle brands. It’s built out of more than 60 years of collective experience in that sector.

Look at who’s in the room on the partner side

Map the people who implement ERP for a living. Most come from finance or from systems and technology, and most have a consulting background behind that. It’s a decent set of skills for configuring a system, and I’d want all of it on a project.

Very few of them, however, have sat inside a brand and owned a process that the ERP was about to change. The overlap between “can configure NetSuite” and “has run buying, planning or ops in a brand doing £20m to £200m” is actually pretty small, and it sits in a handful of places.

Which is why UAT normally goes the way it does. When your merchandiser says this isn’t how buying works here, there is often nobody on the other side of the table who has ever been a merchandiser. And lacks the in the bones knowledge to interpret what’s being feedback.

Most ERP experts interpret your problems through the prism of the system, not your actual needs

The mechanism has nothing to do with how good anyone is at their job. If your client list runs from food manufacturing to industrial distribution to fashion, the only thing you carry between projects is the system. So the system becomes the prism. Discovery gets run through it, and every process a brand describes gets assessed as something NetSuite, Dynamics Business Central, SAP, Fulfil, Sage does well, does badly or doesn’t do.

I’ve watched that on plenty of projects and it’s usually where things start going wrong. For instance, a brand raises a pain point, the answer comes back as a piece of NetSuite functionality, and nobody stops to ask whether it belongs in NetSuite at all. Sometimes it should sit in Shopify. Sometimes it belongs in the WMS or the integration layer. Sometimes its best done in a spreadsheet. Or a homegrown Claude app. And sometimes it’s just a process change that costs nothing.

Fashion and lifestyle brands do a particular set of things. Product gets conceived, ranged and bought against a critical path. Stock gets split across DTC, wholesale and retail, and wholesale runs on its own clock with its own terms and its own allocation. Size curves and holdback are decisions the merchandising team needs to control rather than raise a ticket for. A delivery model built for that starts from the operating model and treats the system as one of several places where the answer sits.

There’s a finite number of ways to get a product concept to a purchase order

Everyone thinks they’re the exception, and roughly one time in twenty they are.

A PO approval flow that matches how a fashion brand actually signs off intake looks much the same across most of the brands we work with. So does the shape of range critical path tracking, and the way a made-to-order line has to behave differently from the rest of the catalogue. None of that needs designing from scratch on your project. It needs deploying, then testing against the handful of things you really do differently.

Specialism also buys certainty. You can configure NetSuite thousands of ways, and most of the value is in knowing which one makes sense for a brand of your size and shape. Then being willing to say so on the call, rather than presenting you with options and calling it collaboration.

Where the 60 years came from

Between the team at Commerce Thinking, there is more than six decades of experience in this sector, and most of it was earned brand side rather than in consulting. On merchandising and planning desks, and in ops and systems roles, inside brands going through the growth stages the ones reading this are in now. That is what got built into Atelier, and it’s why there is a standard configuration to deploy at all.

We then have two co-founders (me and Andy), who also co-founded two leading integration platforms (HighCohesion and Patchworks) and have worked on hundreds of back-office transformation projects. When you’ve got that depth and breadth of experience you see the trends better than anyone else.

It also means we say no to things. Brands on platforms we’ve decided not to work with go elsewhere, and every so often a good one goes to a partner who said yes to something we wouldn’t.

I put a version of a NetSuite partnership to someone senior there last year, and what came back was that the market doesn’t need more generalist partners. It needs people doing something distinct in one vertical who can prove they do it differently.

The part specialism doesn’t fix

Where I’ve seen implementations go badly wrong, it has usually been governance rather than the partner. That looks like too many projects competing for the same handful of people, or the team that owns the outcome turning over halfway through. Being right about the industry doesn’t rescue a programme the business hasn’t committed to, and any partner telling you it does is selling.

What specialism does buy you is a shorter, cheaper argument about the things that are actually yours, and a team who can tell the difference between a real quirk and a habit.

If you’re weighing up an ERP decision, reply to this and come and see it working.

By the time the sell-through numbers came in, the damage was already six to twelve months old. That’s the real sting of this problem: it’s invisible at the point it’s created and expensive by the time it’s visible.

It’s not really a buying problem

It’s tempting to file this under buying, and it does show up there most visibly, because a range is where the overlap finally becomes countable. But the underlying issue isn’t specific to buying at all. It’s a visibility problem that happens to be most expensive in buying, because that’s the point where a lack of a shared, cross-functional view turns directly into cash tied up in stock nobody needed four versions of.

Buying happens category by category, person by person, each doing a good job within their own patch. The person buying jumper A doesn’t see jumper B, C and D landing in adjacent categories with the same silhouette and a marginally different neckline. Each decision looks sound in isolation. The overlap only exists in aggregate, and aggregate is exactly the view nobody’s job description covers.

The catch-22 that keeps it unfixed

We speak to brands all the time, and a lot of the teams we’ve worked with over the years have an extremely stretched buying and merchandising function - stretched enough that there’s no real capacity to try new processes, test new tools, or even take a call from a tech partner who might help.

That’s the trap. The fix for this kind of visibility gap is usually more visibility - a shared view across categories, checked before commitment, not after. Building that shared view takes time from a team that’s already too busy dealing with the consequences of not having it. They’re too stretched to fix the thing that’s causing the stretch, which is about as complete a catch-22 as operations gets.

Six to twelve months of lead time

The uncomfortable part of this pattern is the lag. A range that’s about to over-index on similar products doesn’t announce itself until sell-through data comes in, by which point the buy has already happened, and the stock is already committed. Catching this requires looking earlier than feels necessary - at the point products are being selected, not the point they’re being marked down.

Brands who catch it early do noticeably better, and the reason is almost always the same: the conversation happened at the right moment, not the convenient one. A five-minute check before four teams each commit to their version of a jumper is a very different exercise to a post-mortem after the sell-through report lands.

The fix costs less than the markdown

A structured range review, done early enough to change a buy rather than just explain it afterwards, is cheap compared to the alternative: several products competing for the same customer, most of them destined for a discount rail - or a pallet heading to a clearance retailer - regardless of how good any individual buyer’s instincts were.

Nobody plans to over-range. They just don’t notice they’re doing it until the sales report says so, months too late to do anything but discount.

If this resonates, reply to this or contact us here.

Most of it is aimed at the wrong target.

NetSuite is a serious system. So is Business Central, so is SAP. They are going to be very good in the AI era, because a system of record with clean data underneath it is exactly what any of this needs. I’d argue the systems aren’t what’s failing.

What’s failing is the way they get delivered and adopted. That hasn’t meaningfully changed since about 2016, and it’s the bit nobody puts in the case study.

The question at the start of every project is unanswerable

The moment it starts going wrong happens in week two.

A partner asks what you need. Your team answers as well as anyone could, which is partially, because nobody in the room has run this system before. The detail of what the system requires also lives in fifteen people’s heads and half of it has never been asked for or written down.

Those answers become requirements. The requirements become a scope. The scope becomes a fixed price and a date.

Nine months later you’re in UAT. Your merchandiser sees a purchase order screen for the first time and says “this isn’t how buying works here”.

The requirements were flawed from the start.

Because on one side of the table, were brand side stakeholders who didn’t have the experience or system knowledge to know how to answer the requirements questions asked by a vendor or traditional SI at the beginning of the project.

On the other, a project team working in an outmoded delivery model that captures requirements upfront, locks scope, and puts big lead times in front of users actually getting a chance to work in or familiarise themselves with the system. Often by discovery and design “experts” who have little context experience (i.e. they’ve never been a merchandiser in a brand, or haven’t actually worked as a financial controller, or managed a project from the brand-side).

The truth arrives at the moment it’s most expensive

Look at when a brand actually gets to see the new system doing its job. The first tailored demo, if there is one, lands around week seven (or later). Real hands-on time usually comes with training, which can fall as late as month five of a nine to twelve month programme.

So the entire scope is agreed months before anybody on the brand side has enough context to have an opinion worth having. And when the opinions finally arrive, they arrive as change requests. New cost, new risk, and a date that moves.

This was rational, right up until it wasn’t

Here’s the part the industry hasn’t caught up with.

That sequence made sense when the technical build genuinely was the expensive, slow, uncertain part. If configuring the system, wiring the integrations and testing the whole stack is six months of specialist work, then of course you nail the scope first. You can’t afford to find out late.

But in most scaleup and grownup brands, that’s no longer true, and it stopped being true fairly recently.

Most of what a fashion or lifestyle brand does has been done before. There is a finite number of ways to get a product concept to a purchase order. A finite number of ways to allocate stock across DTC, retail and wholesale. Brands think they’re the exception, and they are, in roughly one place out of twenty. The other nineteen are the same shapes we’ve all seen dozens of times.

Which means the standard configuration, the integration patterns, the test suites and the documentation don’t need building from scratch every time. They need deploying. And the tooling to do that properly, including generating test coverage and documentation off the build itself, didn’t exist a few years ago.

So the sensible order has inverted. You can now ask, build, ask, build, ask in a much more dynamic way.

Deploy the standard. Connect it to the brand’s own store. Pull their products and their purchase orders through it. Then put it in front of them and let them react to something real, in week one, while changing your mind is still free.

The handful of things they genuinely do differently show up immediately, because that’s precisely where the standard doesn’t fit. You find them in week one, price them in week one, and build them alongside the standard rather than discovering them at UAT.

The saving doesn’t go where you’d expect

One honest caveat, because this is where I think a lot of the AI-in-delivery talk falls over.

Training can’t be compressed. The person learning how their month end changes needs the same hours they always needed. Adoption is a human process and there is no version of this where a brand’s team absorbs a new operating model faster because the build was quicker.

So the time that comes off the technical work shouldn’t come off the invoice as a discount and disappear. It should move. Into the part that decides whether any of this actually works: your team knowing what to do, and having the confidence to do it.

That’s the whole argument, really. The build is commoditising but the judgement isn’t.

We’ve been building this

I’ve spent a good chunk of this year putting that into a proper delivery model rather than a strong opinion. It’s called Atelier, and it’s how we’ll be delivering NetSuite into fashion and lifestyle brands in the future.

I’m not going to put numbers on it yet. We’ll publish those when we can prove them rather than when they’d be useful to me.

But if you’re staring down an ERP decision and the six-to-nine-to-twelve-month version of it is making you flinch, reply to this. I’d rather show you than describe it.

If you have ever had the warehouse swear blind you have units on the floor while NetSuite says zero, you already know the pain. It turns into the same mess of exports, emails and a snap decision that ends in cancellations or dead stock.

NetSuite should be the place you control inventory, and for most brands it eventually is. What breaks first is the assumption that control means one number. That falls apart the moment you run more than one location, or more than one definition of sellable.

Your stock number isn’t one number

There are a handful of stock buckets. Teams will mix these up and end up arguing which one's right, distracting them from infinitely more valuable work:

Physical stock is what the warehouse can actually locate. It’s specific to a bin and a status. It includes the awkward stuff like damaged or quarantined units, plus the cartons nobody can find.

Recorded stock is what NetSuite says exists based on transactions. Receipts, fulfilments, transfers, adjustments and the like move this number around. Finance cares because it drives valuation.

Sellable stock is recorded stock after you apply the rules you use to decide what can be allocated to an order. Location matters, inventory status matters, and commitments matter.

Published stock is what you let the public buy. Often you're taking what NetSuite holds and deducting from it buffer stock and the like, to reach the figure you share with your sales channels. It should trace back to NetSuite with named deductions that merch can control in NetSuite.

This is where it starts to unravel because NetSuite’s just doing NetSuite. On hand, committed, available and backordered are different buckets; if you treat them as interchangeable, you’ll end up reconciling noise and shipping problems.

It gets worse because other systems use the same labels to mean different things. It’s common for the warehouse on-hand number to include inventory that’s still in intake, while NetSuite only reflects it once someone’s actually done the receiving.

That’s comparing two different states and calling it a discrepancy.

Sometimes it's the opposite. Two brands can run near-identical setups, a few tens of thousands of child SKUs across a couple of locations, and one will sit within a handful of units of NetSuite at any point in the day while the other is out by hundreds and can't tell you why. The difference is whether the team doing the recon agreed on what they were measuring and when.

Timing matters. Treat it like part of the setup, not an annoyance.

Real-time doesn’t make it true

Real-time stock events cut lag. They don’t make the number right.

Real-time integrations can still miss weird sales order edits, especially when lines get changed after the initial order comes in. The boring fix is a scheduled full sync or comparison, so missed events don’t drift forever.

If you want SKU visibility, stop chasing a prettier dashboard and start insisting on a consistent level of detail. In a fashion or multi-location setup, the smallest unit that matters is a child SKU, by location, by inventory status, with a timestamp.

Anything more aggregated is how you convince yourself stock exists when it’s the wrong size, the wrong warehouse, or the wrong status.

Make the variance explainable

The most useful report isn’t total stock. It’s an exceptions report that tells you exactly how you got from NetSuite availability to what the channel is publishing.

Go look at your own reconciliation today. If a discrepancy shows up, can an operator tell whether to wait because an inbound receipt is still in intake, or whether they need to fix the transaction, change the status, or escalate it?

If the answer is no, you haven’t got visibility. You’ve got visibility theatre.

Start by separating the two boundaries you’re actually managing.

Warehouse to NetSuite is about whether the physical work has actually landed in the ERP. Missing receipts, transfer mismatches, and status mapping failures all live here. So do warehouse-only states. If the warehouse moves stock into locked or suspense because it can’t be found, and that state doesn’t map to a NetSuite status or location that affects availability, your website will happily keep selling ghost units. Then you get the death spiral. Short shipments, negative adjustments, stock mysteriously reappearing a week later when someone finds the carton, and nobody trusts any number.

NetSuite to channel is about whether the intended sellable quantity has been published correctly. Latency windows and missed events live here.

A single warehouse to Shopify comparison can’t tell you which boundary broke, so it can’t tell you what to do next.

Keep your fixes separate

If units exist but shouldn’t be sold, make them unavailable by status or a controlled location model. If units exist but are in the wrong place, transfer them properly. If you care about the in-transit state, use transfer orders so you can see the stock move from committed to in transit to received.

If you’re deliberately reserving stock for stores, wholesale, or a strategic drop, that’s a commercial holdback. If you’re hiding stock because you don’t trust the warehouse versus NetSuite position yet, that’s a temporary reconciliation buffer, and it needs a reason, an owner, and an expiry.

And if you’re using inventory adjustments to stop Shopify selling something, you’re using an accounting transaction to solve a storefront control problem. NetSuite adjustments change quantity, and they can change value. They post to an adjustment account. They should close a confirmed variance after you’ve done the work, not paper over uncertainty.

Counts need the same discipline. NetSuite takes a snapshot at the start of a count, and if stock keeps moving during the count window without a process that accounts for movements, you can manufacture variances that were just normal receipts and picks.

Once you’ve got this right, NetSuite becomes what ops needs it to be: the place where stock gets controlled and surfaced. And you can stop living in spreadsheet land where everyone has their own version of stock and nobody can prove they’re right.

SKU visibility is being able to explain, at a consistent unit and point in time, why physical stock, NetSuite stock, sellable stock, and published stock differ.

If you can’t explain the difference, you don’t have a stock figure. You’ve got an argument waiting to happen.

Two events in, and the format is the same. Brand show and tells from operators who have put something live, followed by small group sessions built around the challenges attendees bring when they register. Most of it comes back to practical AI adoption: what is earning its place in the operation and what is noise.

How the day runs

Lunch from midday in the ground floor lounge, which gives everyone an hour to talk before anything formal starts. Content runs from half one to half four, with the main room split into sections so the small group work can happen in parallel rather than one table at a time. Drinks from half four. There is something on in the evening afterwards for anyone staying over, and we will confirm that separately.

Who is in the room

Around 70 senior operators from brands in fashion, beauty and lifestyle, all of them brand side. They come from ecommerce, digital, product, tech, data, ops, logistics, CX, merchandising, commercial and finance, because most of the problems worth an afternoon do not sit inside a single function.

Sponsors and partners are in the room to facilitate the small group sessions and to take part in them. Every show and tell slot goes to a brand.

What people are working on

Registration asks you to pick up to three challenges from a list of fourteen, plus anything else you are wrestling with. Those answers set the session topics and the table plan, so the two minutes it takes are worth spending. A sample of what is on the list:

• Range planning and buying decisions made on incomplete data

• Getting useful output from the tools you already have

• Product data quality at the point it is created

• Stock visibility across channels and markets

• Building internal buy-in for AI adoption

• Working out where AI helps and where it is a distraction

Why Stockholm

OX grew out of a straightforward observation. The conversations brand-side operators actually need are not happening at the events that exist. The advice landscape is loud, vendor-heavy, and mostly pointed at the wrong people. What operators kept asking for was time with peers in similar brands, doing similar work, prepared to share what worked and what did not, without flogging something at the end of it.

Stockholm is the next room. Dema are back as headline sponsor, on home ground this time. Centra, Emfas and Resourced are alongside them. HighCohesion, Vervaunt, Loop, Torque, Pro Carrier and Whānau are travelling over from the UK.

Travel and staying over

Rooms are held at the venue at a discounted group rate for both the night of the 21st and the night of the 22nd. Registered attendees get the code and book direct, so hold off on booking anything else for now. There are fewer rooms held for the 21st, so if you are travelling in the day before, say so when you register.

For UK members, there is no expectation that anyone travels for this one. If Stockholm appeals and you want to be in the room, tell me. Between us and our partners there may be a way to make that work, so it is worth asking rather than ruling yourself out.

How it works

Registrations are read and approved one at a time, and we come back to you either way. OX members and everyone who came to OX1 or OX2 have first pick of the room, before opening to our wider network.

The room is for senior operators from brands in fashion, beauty and lifestyle. If that is you, or someone you know, the details are at operatorexperience.ai.

This is the demand and inventory planning gap, and it’s close to universal among the brands we speak to - particularly the ones running a core system for finance alongside a separate planning process that finance never fully sees.

The target and the buy are built in different rooms

Finance sets a revenue target, usually top-down, informed by growth ambitions and last year’s numbers. Merch turns that target into an actual buy - which products, how many, in what sizes, from which suppliers - usually in a completely separate tool, on a completely separate timeline, with no shared translation layer between the two.

Both processes are reasonable on their own terms. The problem is that “reasonable on their own terms” doesn’t guarantee “adds up to the same number,” and by the time anyone notices the gap, stock has already been committed.

Amy, who owns Product Ops internally at CT, years as a merchandiser and a head of planning before this, puts it simply: the finance number and the merch number are almost never built from the same starting assumption, and nobody’s job is to reconcile the assumptions before the numbers get compared.

It’s a data integrity problem before it’s a reporting problem

The instinct, when finance and merch numbers disagree, is to build a better dashboard that reconciles them after the fact. That helps people see the disagreement faster. It doesn’t stop the disagreement from being built into the plan in the first place, because the actual root cause sits earlier - in whether both teams are working from the same, governed version of the underlying product and sales data, or from two versions that have quietly drifted apart.

That matters even more now that more of this analysis is AI-assisted. Feed a forecasting or reporting tool inconsistent, ungoverned data, and it won’t flag the inconsistency - it’ll just produce a confident, well-formatted answer built on top of it. What you put in is what you get out, whether the thing doing the calculating is a person with a spreadsheet or a model with a prompt.

Why more reporting doesn’t fix it

The actual fix sits earlier: a shared translation between the target finance sets and the buy merch makes, built on data both teams actually trust, checked at the point of planning rather than discovered at the point of reporting. That’s a process and data-integrity change before it’s a tooling change, even if the tooling ends up needing work too.

What this actually costs

Every quarter this goes unaddressed is a quarter where a board pack gets two numbers for the same department and someone has to explain, again, why they don’t match. That’s not a data hygiene issue. It’s a planning process that was never designed to produce one number in the first place.

Fix the translation layer and the underlying data agreement, and the reporting disagreement mostly disappears on its own, because there was only ever one gap to begin with - it just showed up twice.

If you want to talk it through, book time with the team

This is one of the most common patterns we see in brands scaling past the point where informal systems should still be working. It’s rarely framed as a risk internally, because the person carrying it is usually excellent, well-liked, and at the same time entirely too busy to document how any of it actually works. It’s come up in conversation after conversation recently, with different brands, in almost identical terms.

Efficient, right up until it isn’t

A system built and maintained by one person is, for a while, the fastest possible way to get things done. No committee, no sign-off, no waiting for a change request to clear a queue. That speed is real, and it’s exactly why nobody wants to slow it down by asking someone to document it properly.

The cost of that speed shows up later, and it shows up all at once. A holiday, a resignation, an unexpected absence, and the business discovers that an entire operational process lived in one person’s head, with the system itself as a set of clues rather than a set of instructions. The automation everyone assumes is running quietly in the background, except it doesn’t run when the one person who checks it isn’t there to check it. The workflow that grinds to a halt because it only ever ran from one laptop, and that laptop is currently at the airport.

Ownership isn’t the same as control

The brands who get this right aren’t the ones who take the system away from the person who built it. They’re the ones who separate “this person built it and understands it best” from “this person is the only route through it.” Plenty of brands are explicit about wanting exactly this: they don’t want to depend on an external partner, or a single internal specialist, for every change. They want the tools they use to actually belong to the team running the business day to day.

That’s a different ask to “hire more people.” It’s an ask about whether the knowledge is written down, whether more than one person could make a routine change without asking permission, and whether the system would survive its architect leaving on good terms tomorrow.

The audit that actually matters

A useful exercise, and an uncomfortable one: pick the three systems your operation would struggle most without, and ask how many people could rebuild each one from documentation alone if the original builder vanished tomorrow. If the honest answer is one, or none, you’ve found where the real risk sits - not in the system itself, but in the fact that it only exists properly in someone’s head.

This isn’t a case for slowing everyone down with process for its own sake. It’s a case for writing down the two or three things that would actually hurt if they disappeared with a person, rather than everything, because trying to document everything is how documentation projects die. Do the exercise this week. Pick the three systems. Ask the question. Whatever the answer is, it’s more useful than not knowing.

The system usually isn’t the fragile part. The single point of failure almost always has a holiday calendar, and no idea they’ve become one.

This is something we spoke about in detail at OX2 London this July. We’ll no doubt talk about it again at OX3 Stockholm on 22nd October. If you want to be involved in those conversations, apply for a spot below.

https://operatorexperience.ai/

That might look like doing ourselves out of work. It’s the only honest way we know how to advise a client. When it’s not the right time for an ERP, it’s not the right time, whatever that means for us commercially - and it’s a far more useful outcome than most ERP projects produce, because most ERP projects start from “we need a new system” rather than “what problem are we actually trying to solve,” and the two questions lead to very different answers.

Sometimes twenty people need a process, not a platform

At a brand of around twenty people, the more honest fix wasn’t a new system at all. It was clearer process and better-defined roles. A platform can’t fix a business that hasn’t yet agreed who owns what. Buying one at that size usually just moves the disagreement into a more expensive piece of software.

This is the sequencing question in miniature: process and people first, system second, and only once the first two have actually settled down enough that a system would be configuring something real rather than something still being argued about.

We don’t sell a system. We sell the sequencing.

We’re vendor-neutral in the sense that we don’t push, sell or promote a specific product or agenda. What we’ve got instead is pattern-matching across enough different brands’ systems to know, with some precision, what tends to work, when, and why. That means we can be specific: this system, at this point, for this reason, and here’s what needs to change first and what shouldn’t be touched at all. It’s tailored to the individual business, not to a template.

We’ve written before about the tier question - which rung of the ladder actually fits a brand at a given size, and the specific graduation signals that tell you it’s time to move up one. This is the layer underneath that conversation, not a replacement for it. Tier selection assumes the timing question has already been answered. Most brands haven’t answered it - they’ve just skipped straight to comparing vendors.

It’s almost always people and process, not technology

Across enough brands now, the pattern repeats: the real gap is people and process, not the system. That’s where we focus our own time and resource, even when it’s less exciting to sell than a shiny new platform, because bringing in new technology without fixing the underlying process is how adoption falls apart. Teams don’t use what they don’t trust, and they don’t trust a system that’s just automating a broken handoff faster.

Part of doing this properly is being honest about where roles aren’t clearly defined, where a business might need someone new to actually own a function rather than share it informally, and where a team is already stretched thin enough that a new system will add workload rather than remove it, at least at first. None of that’s comfortable to say out loud in a sales conversation. It’s necessary to say it anyway.

Deploy with real data before you commit

Where a system decision is genuinely due, the useful move isn’t a slide deck of vendor comparisons. It’s someone standing up a working version with the brand’s own data and demonstrating it back to them, before anyone signs anything.

We try to show things practically wherever we can, not just describe them, and bring people along through the process rather than present them with a decision at the end of it. That single step removes most of the scope creep that comes from making a big decision on assumptions rather than evidence.

These are frequently six-figure decisions. Getting one wrong is considerably more expensive than getting it done slowly and correctly, which is why we’d rather a client have realistic expectations going in than a fast yes that unravels eighteen months later.

The sequencing question is the real decision

ERP versus PLM versus middleware versus “fix the process first” isn’t a menu you pick one item from. It’s a sequence, and getting the order wrong is the single most expensive mistake available. Systems bought to solve a problem that was actually about ownership, definitions, or process discipline don’t solve it. They just give the same disagreement a bigger, more expensive home.

The question worth asking before any ERP conversation starts isn’t which platform. It’s whether a platform is actually what’s missing, or whether that’s just the easiest thing to buy when the real answer is harder to agree on.

Start the conversation by contacting us.

That’s something worth talking about. The symptom always turns up in the same place - the inbox - while the cause is almost always sitting further upstream, in a system or a process that nobody’s watching closely enough to catch before a customer does. Or something that hasn’t been cleanly mapped out, so no-one truly understands. Or has the time to fix.

CS is usually downstream of something else

At record store Rough Trade, the volume of “where is my order” queries in the inbox was a genuine drag on the team, until they built an inbox classifier that now resolves around two-thirds of enquiries automatically by checking order status directly. This was work we wrote about in more detail after OX2, alongside the returns platform they purpose-built.

The point isn’t the specific numbers, though. It’s the way they fixed it. They treated a CS problem as a systems and process problem first, and the CS burden dropped as a result, rather than the other way round.

Different teams catch the same gap at different times

At Bluebella, discrepancies between the storefront, the ERP system and the warehouse used to fall through the cracks and get caught reactively by whichever team happened to notice first. They built a daily dashboard that flags the mismatch before a colleague or customer has to notice and complain about it. And showcased it at OX2.

That’s the wider pattern across pretty much every brand running more than one system for order fulfilment: the gap gets found at the most inconvenient possible moment, for whichever team is closest to it that day, and it’s rarely the same team twice. One week it’s warehouse ops mid-pick. The next it’s CS mid-inbox. Eventually it’s a brand or PR issue, because enough customers hit the same gap at once.

If someone’s genuinely responsible for watching the systems upstream, most of this never reaches that point at all - and it’s easier to build that watching function now than it’s ever been.

What actually reduces WISMO volume

Not a better help centre article, for a start. What actually moves the number is closing the gap between what the customer sees and what’s true in the warehouse, before they have to ask.

That looks like proactive status updates instead of reactive lookups. Order tracking that actually shows a customer where their order is, in real time, rather than a static “processing” screen or an “order is in progress” that means nothing.

And if they do reach out, customer service systems should be properly integrated with order and fulfilment data, so customers get a real answer immediately that recognises who they are and what they ordered, and the customer service team are enabled to do their jobs properly without chasing down the ops and logistics team.

Importantly, WISMOs should not turn into a request for the customer to jump through hoops or a queue with a two-day SLA before a human even looks at it. That’s not the experience anyone’s aiming for, and it’s entirely avoidable with the right plumbing upstream.

The real cost of the tax

Every hour a CS team spends manually chasing a warehouse booking or explaining a sync error is an hour not spent on the customer interactions that actually need judgement. That’s the WISMO tax - not the query itself, but the fact that a systems problem gets paid for, every single day, out of a team’s capacity to do the part of the job that matters.

Fix the upstream reconciliation, and the WISMO volume mostly takes care of itself. Don’t just add headcount to answer the same broken question faster.

If this resonates, commercethinking.com

Here’s the workflow. A retail partner with a return agreement decides to send stock back. Sometimes an email arrives first, vague about contents. Often it doesn’t. What arrives is a box. Sometimes 400 pieces in it. No usable manifest, no link to an order, no warning to the warehouse.

The brand can’t raise a normal purchase order because they don’t know what’s in the box, and experience says it won’t match whatever the email claimed anyway. So they raise a dummy purchase order. One line on it. The warehouse receives the box against the dummy, fills it up with whatever physically arrived, and sends the completed fiction back to head office. Only then does anyone know what came home. A credit note gets drafted, checked against what the retailer claimed, and the two rarely agree.

And then, mostly, the brand just accepts it. Disputing a discrepancy on a seventy-dollar wholesale piece costs more in admin than the credit is worth.

The retailer knows this.

“They’re trying to save money, we’re trying to save money, but they’re bigger than us. They get the efficiency, we get the pain.”

Why this is a process smell, not a software gap

The instinct is to blame tooling, and it’s true the software market has ignored this. Five years of investment went into consumer returns portals while B2B returns, the majority of revenue at brands like this one, still runs on boxes and guesswork.

But before you go shopping, look at the process, because most of this is fixable inside the ERP and warehouse setup you already have. The dummy PO exists because the process was designed around a document (the purchase order) instead of an event (stock is coming back). Flip that and the workarounds start disappearing.

What good looks like.

RMA-first receiving.

Every inbound return gets a returns authorisation record the moment the retailer signals intent, however vaguely. The RMA is allowed to be wrong. Its job is to exist, so the warehouse receives against a real object instead of a fictional PO, and so head office has a record that predates the box.

Blind receipt as a designed workflow, not a hack.

Most WMSs support blind receiving properly. Receive what’s physically there, line by line, against the RMA, and let the system generate the discrepancy report automatically. That’s the same work the warehouse does today filling up the dummy, except the output is structured data instead of a returned fiction.

Probabilistic invoice matching.

The hard problem in wholesale returns is attribution. Stock comes back at season end, six or nine months after shipping, and the same SKU has shipped to the same retailer many times in between.

The ops lead’s image was perfect: “You shoot the beast, and it comes back nine months later, and you could have shot the same beast ten times.”

Deterministic matching is impossible, so stop demanding it. A good guess, most recent shipment of that SKU to that partner, FIFO across open invoices, whatever rule finance can live with, beats no match. Configure the rule once, apply it consistently, and reserve human attention for the exceptions.

Codify the economics of surrender.

If you already auto-accept every discrepancy below a certain value because disputing costs more, that’s not a failure, that’s a policy. Write it down, put the threshold in the system, and stop paying people to perform a dispute process whose outcome is predetermined. The dishonest version of this is what most brands do now: pretend to check everything, actually check nothing.

Triage sellable stock at receipt.

Most of what comes back in wholesale has nothing wrong with it. It’s sellable product that sat on a shop floor too long, and by the time it’s travelled back it’s aged into dead stock. The receiving workflow should route it to its next best destination, outlet, partner, clearance channel, at the moment it’s scanned, not after a quarterly stock review finds it.

The uncomfortable bit

None of this needs new software categories. It needs someone to admit the current process was never designed, it accreted, and to spend a few unglamorous weeks in the ERP and WMS configuration making the return an event the system expects rather than an ambush it survives.

The consumer side of returns got beautiful because it was customer-facing and venture-funded. The wholesale side stayed ugly because it’s internal and nobody’s demo ever shows it. If your process involves a dummy anything, that’s the tell. The system is telling you it was never asked to handle reality, and reality showed up in a box with 400 pieces in it.

If any part of this is running inside your business right now, dummy POs, unmatched credit notes, a returns process nobody designed, get in touch. This is the kind of ERP and WMS reconfiguration we do.