Notes from running European operations.

Open as its own page: The hidden cost of operational fragmentation in European commerce

Operational fragmentation is not a sudden event. It is an accumulation: each new market, each new vendor, each workaround that was never resolved. By the time leadership notices it, the cost is already significant: slower decisions, repeated exceptions, margin that disappears between functions rather than at any single identifiable point.

The interface problem

In most European commerce operations, fragmentation concentrates at the interfaces between functions. Commerce hands off to logistics without a governed escalation path. Logistics reports to finance without shared definitions. Data sits in three systems that no single person owns. Each interface is, in effect, an unmapped gap, and gaps are where execution cost lives.

The pattern is remarkably consistent across markets and brand types. A brand that runs smoothly at one or two markets begins to struggle at four or five, not because the markets are harder, but because the operating model was never designed to scale. What worked through individual knowledge and informal coordination stops working the moment it needs to operate without the people who built it.

What fragmentation actually costs

The financial cost of fragmentation rarely appears on a single line in a P&L. It is distributed: over-ordering to compensate for poor inventory visibility; manual intervention costs absorbed by operations teams; customer experience variance that erodes repeat purchase without a clear signal; partner SLA breaches that get managed reactively rather than prevented. In aggregate, across a multi-market operation, these costs typically represent 8-18% of operational budget, and they are almost entirely recoverable through governance.

The structural intervention

Resolving fragmentation is not primarily a technology problem. Systems can surface data, but they cannot create ownership. The structural intervention is governance: explicit decision rights per domain, documented escalation paths, a fixed control cadence, and a single owner for each interface. When these elements are in place, fragmentation stops accumulating, because every gap has a named owner whose job it is to close it.

MSQUARE Works deploys this governance model as an operating function, not a consulting deliverable. The result is an operation that can scale without fragmenting, because the model that governs it scales with it.

Open as its own page: Why European market entry fails: a governance perspective

The narrative around failed European market entry typically centres on market misread: the wrong product, the wrong price point, the wrong channel. In practice, most failures we encounter are not market failures at all. They are execution failures. The market was right. The operation was not built to serve it.

Three patterns that repeat

The first pattern is localisation without governance. A brand adapts its catalogue, pricing and payments for a new market, but does not establish who owns the ongoing operation of those adaptations. When a payment provider changes its API, or a carrier revises its SLA, there is no owner to respond. The response is reactive, slow, and expensive.

The second pattern is vendor proliferation. Each market entry adds a new 3PL, a new carrier, a new localisation partner. Within two or three markets, the organisation is managing six to twelve vendor relationships with no unified governance model. SLA definitions differ. Escalation paths differ. Reporting differs. The result is an operation that cannot be managed from the centre, because the centre has no common language with its parts.

The third pattern is individual dependency. The Europe expansion is owned by a senior individual who holds the market knowledge, the partner relationships and the decision logic in their head. When that person leaves, or is pulled onto another initiative, the expansion stalls. There is no operating model to run without them, because the operating model was never written down.

What governance-first entry looks like

Governance-first entry establishes the operating model before the market is live, not after it is struggling. This means: explicit ownership per domain before the first partner is contracted; documented escalation paths before the first order is shipped; a weekly control cadence before the first exception occurs. The investment is low relative to the cost of entering without it, and it is the difference between an expansion that scales and one that eventually requires a rescue operation.

Open as its own page: Returns as a controlled capability: governing reverse logistics for margin recovery

Returns are the part of European commerce that most operations manage defensively: absorb the cost, process the refund, move on. The result is that reverse logistics sits outside the governance model: no triage logic, no recovery pathways, no reporting that connects return volume to margin impact. Every return erodes margin silently and without accountability.

What governance transforms

When returns are brought under governance, the first thing that changes is visibility. Triage rules define what happens to each returned item at inspection: restock, refurbish, liquidate, or destroy. Each pathway has a margin profile. With that data in place, the operation can see, in real time, what the return rate is costing, and where recovery is being lost.

The second change is partner accountability. Returns typically touch multiple partners: the carrier who collects, the 3PL who receives, the refurbishment partner who processes. Without governed SLAs and a unified exception playbook, each partner operates to their own standard and timeline. Items sit in transit or at warehouse longer than necessary. Recovery windows close. Governed SLAs, with clear escalation triggers, reduce cycle time by 20-40% in the operations where we have deployed them.

The margin case

The margin case for governed returns is straightforward. If a European brand processes 15% of orders as returns (which is conservative for apparel) and 40% of those returns are refurbishable but currently being written off due to absence of process, the recoverable margin at scale is material. More importantly, it is predictable once the governance model is in place. Returns stop being a variable cost and become a managed one, which is the precondition for protecting margin as the operation grows.

Open as its own page: Building a single operating backbone across 44 European markets

The ambition of operating across all 44 European markets on a single operating model is often treated as aspirational: a goal for a later stage, once the organisation is large enough, funded enough, or organised enough to build it. In practice, this is backwards. The single operating backbone is easiest to build at the beginning, and hardest to retrofit when each market has developed its own local model and each local model has developed its own dependencies.

What a single backbone actually means

A single operating backbone is not a single system. It is a single governance model: consistent ownership structures, consistent escalation logic, consistent reporting definitions and consistent partner SLA frameworks, applied across all markets. The technology stack can differ by market where necessary. What cannot differ is the operating language: who owns what, how decisions are made, what the cadence is, and what documented output looks like.

This distinction matters because most attempts to build a single backbone fail at the system level, trying to force a single platform onto markets with different logistics infrastructure, different regulatory requirements and different payment landscapes. The governance-first approach accepts market-level variation at the system layer while enforcing consistency at the operating layer. The result is an operation that the centre can actually manage, because the centre and the markets are speaking the same operational language.

The governance requirements

Three governance elements are non-negotiable at scale. First: explicit domain ownership across every market, documented and reviewed on a fixed cadence. Second: governed partner interfaces, meaning SLAs that are defined, measured and escalated consistently, regardless of which market the partner operates in. Third: unified operational reporting that surfaces exceptions across all markets in a common format, so that leadership can identify patterns rather than managing individual incidents. With these three elements in place, the single backbone holds. Without them, each new market becomes an exception, and exceptions, at scale, become the norm.

Open as its own page: The marketplace complexity trap: SLA governance across multi-channel commerce

Adding a marketplace channel looks simple from the outside: integrate, list, sell. What it actually introduces is a new set of SLA obligations, a new exception vocabulary, a new carrier profile and a new set of integration failure modes, none of which map cleanly onto the operating model built for the brand’s own channels. Multiply this across four or five marketplaces, and the operation is managing five parallel SLA regimes, five exception taxonomies, and five escalation paths that no single person or system fully owns.

How complexity compounds

The compounding effect is not linear. Each new channel does not simply add its own complexity; it creates interaction effects with existing channels. Inventory that is simultaneously available on three marketplaces and the owned DTC channel requires orchestration logic that most operations do not have. When a stock position is incorrect, the exception touches all channels simultaneously. When a carrier misses an SLA on one channel, the fulfilment routing logic for other channels may be affected. The exceptions do not stay within their channel boundaries, but the governance model typically does.

The unified governance layer

The solution is not to reduce marketplace presence (which would sacrifice revenue) but to build a governance layer that sits above the channels and manages them as a portfolio rather than as independent operations. This means: unified SLA definitions that translate marketplace-specific requirements into a common internal language; cross-channel exception routing that identifies ownership regardless of which channel triggered the exception; and unified reporting that allows the operation to see fulfilment performance across all channels in a single view.

The operations where we have deployed this model see OTD (on-time delivery) improvements of 5-12 percentage points within the first quarter, not because the carriers or marketplaces have changed, but because the exceptions are now being caught and resolved rather than accumulating. The complexity does not disappear. It becomes managed.