Intro

The great Shopify unification has begun.

A number of large, internationalised brands running multiple stores across regions — the US, Canada, UK, Japan, Korea, Europe, etc — seem to have reached a consensus: right now is the moment to begin consolidating to single store.

In this post I’ll answer:

• Why?

• Why now?

• Is now the right time?

• What are the migration challenges?

Let’s go!

Why?

The benefits. Ohhhhh the benefits.

Including but not limited to…

In Customer Experience

Consolidating to 1 store is a massive step towards ‘unified commerce’ for brands.

All customer data in one Shopify system unlocks big CX benefits.

Customers buying online in the UK, or buying in-store anywhere in the world — with a single Shopify store — have a ‘joined-up’ experience.

If the customer wants to return something in-store in LA they bought in the UK — easier.

If store staff want to pull up customer’s order history — easier.

If the customer wants to use a discount code in any store in the world — easier.

Managing loyalty schemes: 1 Shopify store, 1 customer account = easier.

In Operations

1 product catalog for Shopify. No more ‘sync to 1 store then duplicate to remaining stores and enrich in 8 places’. Big time-saver for eComm teams.

Unified reporting/analytics for Shopify data. No more manual merging datasets together to get a source of truth.

Much cleaner setup for inventory. Brands serving multiple Shopify stores from 1 warehouse, at the moment, either have to split stock between the stores (creating underselling), or show all stock on all stores and mitigate overselling using an app in the middle to reduce inventory on each store when orders are placed (which usually needs gets turned off during BFCM because it can’t process fast enough). That won’t be needed anymore.

1 set of ecomm and app costs. 1 Shopify store. 1 Matrixify. 1 Re-Charge. No need for Syncio. Consolidated Klaviyo costs. Lower Yotpo costs. Lower Algolia costs. Gorgias, LoyaltyLion, etc etc etc. Could add up to strong savings for brands. And, even if the cost of certain apps is the same with single store, the ease of management is greater, so still a win.

Lower integration/iPaaS costs. If their integrator(s) charge by ‘stream’ and/or data volume processed, given that brands will be significantly reducing the number of streams and data processing needed, they will also be significantly reducing their costs with their integrator(s). Say a brand has 10 stores. Now, instead of 10 sales order streams to ERP and/or WMS, it’s possibly as low as 1. Product streams down 10 to 1. Inventory streams down from 10 to 1. Fulfilment streams down from 10 to 1. The result = savings.

Why Now?

A perfect storm of:

• The maturation of the Shopify platform

  • Developments in Markets (now “International”) and Markets Pro (now “Managed Markets”) are making single stores for localisation redundant.

  • Checkout customisation has improved.

  • Regional shipping and payment methods are now supported.

  • Payouts in multiple currencies from 1 store now supported.

• The trend towards ‘unified commerce’

  • Brands better understand the benefits to the customer experience of getting all customer data unified into a single platform .
    

• Brands like Passenger, Adanola and Rains providing social proof

  • 5 years ago the DTC model of the market leaders, like Gymshark, was multi-store. Any brand expanding with purpose into new markets spun up a new Shopify store.

  • Single store was for brands doing lots of domestic business and very little international. There were very few examples of an internationally successful brand using single store.

  • Now, there are.
    

• The macro-economic conditions putting cost-cutting back on the agenda

  • The covid-boom in the rearview mirror, de minimis loophole closed, tariffs, cost of living issues affecting consumer behaviour, et al.

Is Now The Right Time?

All considered, my view is yes.

The direction of travel is inevitable.

Eventually, brands are going to do this.

Brands that get there first get the benefits earlier.

Not to make the migration sound easy because it won’t be, but big picture — the tech looks to be there or thereabouts, so there are few obvious technical reasons not to do this.

The only question is whether brands see enough benefit in the making the change now to justify enduring the cost and disruption that comes with the change process.

Some brands will argue that waiting and migrating later will mean the migration process is easier, cheaper and less risky.

In some ways that will be proven right. The front-end migration process has been ‘playbooked’. The back-end process will be soon. And, Shopify’s releases consistently make the product stronger. In 2 more editions, maybe cross-border is a lot easier? Maybe order routing is a lot more advanced?

But, those brands shouldn’t forget to calculate the opportunity cost of not getting to single store sooner.

They also shouldn’t forget that the longer they use multi-store, the more embedded they likely become with those stores, and the harder it may be to eventually move.

Whenever this migration happens, it’s going to be difficult. My read is that the gains of waiting and moving later will likely be outweighed by the opportunity cost of not making the switch sooner.

What Are The Migration Challenges?

Perhaps quicker to list what aren’t the migration challenges. There’s loads of stuff going on here. Considerations for a number of teams inside the brand.

For finance there’s payouts and currency conversion fees. Shopify supports payouts in 8 currencies in a single store, their chatbot reluctantly confirmed…

… meaning a brand using a single store to sell in Australian Dollars, Canadian Dollars, US Dollars, HK Dollars, Norwegian Krone, Swedish Krona, SA Rand, Japanese Yen, Pounds, Francs, Forints and Zloty, for example, would only be able to get paid out in 8 of these currencies, bringing conversion charges on the rest where previously there might not have been any.

For Ops & Tech there’s a big list of questions to answer.

How will a single Shopify store handle per-market nuances in taxes and duties across all of the markets brands operate in?

Are Shopify’s order routing features compatible with how the brand wants to fulfil?

How does the move impact system integrations?

How best to migrate the customer data into the single store?

What are the digital and real-world steps to integrate PoS into the single store setup?

What other suppliers are affected by the migration?

Customer service will all be working in one site — if some of those teams are outsourced, how to make that happen harmoniously?

And the questions keep flowing for the eComm team…

Are they fully aware of the localisation limitations of single store?

What changes are needed to maintain site performance post-merge?

Will the checkout run slow under sheer weight of market-specific payment and shipping options?

How to mitigate the SEO impact of the change?

Are all apps used today compatible with a single store WoW?

How to nail market-specific discounts and promotions?

For Merch, there’s a change of process in how products and pricing are pushed to online. Market-specific products have to be handled differently now.

For Retail, there is a cutover process to be done with in-store staff.

For Brand, there’s a new challenge to strike the right balance between cohesive branding across the one store, and localised elements.

You get the picture! Lots to think about. But, nothing too big and scary if approached with clear thinking and patience.

Summary

Thanks for sticking with me folks: I know I have a tendency for the verbose (like in this very sentence, come to think of it…).

If you take anything away from this, let it be these points:

• Multi-store, internationalised brands are starting to move on single store now.
  

• Which makes sense, because the benefits are potentially huge.
  

• The unification projects will be very tough, and some hidden limitations of Shopify are certain to be revealed in the process, making compromise a necessity for success.
  

• It might not pay to wait on this. Unification will likely always be difficult, and while-ever you’re multi-store while single store is an option, you’re leaving money and time on the table.

Until next time.

Disclaimer

I’ve tried not to make this a piece about how special and complex our challenges are and how smart and brave we are for facing them every day…

What this hopefully is, is a proportional analysis of what is unique about delivering tech change in retail, what makes it difficult, and how to make it easier.

And, when I say ‘a unique risk profile’, I don’t mean ‘more risky than everything else’, I mean ‘risky in a way which is unique because of its context’. It’s not saving lives, we know that. It’s not as complicated as running a government, we know that too.

Enough disclaimer.

Why are retail tech projects different?

The Direct-to-Consumer Relationship

Often intimate. Great brands evoke strong emotions.

Most retail tech is built for consumers to use directly. Unlike in healthcare, pharma, defence, energy, and others — the organisation that delivers the project (the retailer) is the same organisation that fronts up to the end user (the consumer). No go-betweens. No protective layer. No masks.

And, it’s not a great risk/reward balance. The consumer expects the tech to work. So, it’s not like the risk of immediate negative consumer feedback if the tech is flawed is offset by the opportunity for immediate consumer gratitude if the tech works perfectly.

The rewards for a project well done are revenue-based (retention, growth) for the retailer, and professional pride for the project team. These are far less tangible benefits than the very tangible un-benefit of hyper-critical social media shit-blizzards (‘shitstorm’ feels tired) when things go wrong.

The Problem of Scale

An ostensibly cosmetic issue, like neglecting to test each special character to determine which a WMS can accept and missing that it has some rather Brexit-y preferences (“ß? What is this… Das Kapital??”), could mean that a surge of orders from Europe’s biggest economy will see hundreds, nay thousands of orders not reach the warehouse. Not be shipped on time. Social media turdnado incoming.

What I’m getting at, for fans of more direct rhetoric — a small problem magnified over 5k, 10k, 50k, 100k orders is no longer a small problem. Minor mistakes can be punished major in retail tech.

Inventory Complexity

The retailer with multiple 3PLs, perhaps even a warehouse of their own, or a central DC, an armada of bricks and mortar stores, stock on consignment with 3rd parties, stock at franchises which they might buy back, stock unsold at popups being ‘warehoused’ at a founder’s house, wholesale distributors in several countries and wholesale stock pools in some of those 3PLs — stock on multiple continents, subject to different tax legislation, managed by different 3PLs on multiple systems and serving different sales channels (sometimes simultaneously). The objective — never oversell, never undersell. Easy.

And if a new project so much as tickles this delicate house of cards; breathes near the wobbling CX jenga tower — it can all come crashing down. Alert reverberating off the jigs and jags in the rubble — barely audible over the human air-raid sirens — says: “Inaccurate stock levels — oversells reported — wholesalers miffed — consumers triple-miffed”.

The Robustness Delusion

A lot of business leaders — a lot — simply don’t think that a bad software project is a real threat to their interests. “What’s the worst that can happen?”, they say. I don’t criticise. The bravery is admirable, really. We, the normies, nervously fidget and twitch in awe at your microscopic amygdalae, oh fearless ones.

But this thinking can mean retailers pushing ahead with projects with more red flags than a Chinese military parade; launching things before they’re ready; blasting off to the inhospitable planet of ‘live’.

Nothing unique about that, right? That’s not industry-specific. Lots of business leaders ignore the informed advice of their specialists and do what they think best.

True. But in retail, selling product is the lifeblood, and in a worse case scenario, a badly delivered project can stop you selling product. Then you’re a body without blood, which tend not to last very long.

That is different to other industries. Fintech, for example. If a dodgy update gets deployed to a banking app there’s consumer blowback, but the bank still has the consumers’ money, they’re still getting paid for premium accounts, they’re still making their NIM, and if they’re an ‘old-school’ bank, their customers can still go to a physical bank if they need to.

Just like humans live most of their lives blissfully neglecting awareness of how fragile life is, retailers go day-to-day without living in fear of losing their lifeblood — sales of product. This is the robustness delusion.

The Hyper-Competition Environment

A bad software project delivered for the public sector is backed by a long and gnarly contract, so the unlucky end users’ best course of action is probably just to deploy patience.

A bad software update to a social media app is inconvenient but, again, as a user, are you really going to switch to using a different platform? What about all of your previous posts, followers, etc. You’re baked in. You wait out the problems.

Even projects which affect products post-purchase — a bad update to Peloton (for example), do you really take the bike back? Maybe, but it’s a bit of a pain to do that, isn’t it? May as well just wait until they release the patch.

But in retail, if the consumer can’t buy from you, the retailer, unless they have elite brand loyalty they just go and buy from one of the many, many alternative options. Makes sense, right? It’s a helluva lot easier than moving from Twitter to Threads, returning a Peloton, moving banks, cancelling a government contract, etc.

Alllll of that money, time and creativity that goes into getting a customer into a buying position with you in the first place — to waste that opportunity… it’s a cardinal sin of retail.

The upshots for tech change project teams: you may be re-tracking as the trains continue to run, but any passenger disturbances are (understandably) unacceptable.

Count them up

It’s these 5 aspects—

• DTC relationships

• Problem of scale

• Inventory complexity

• Robustness delusion

• Hyper-competition

—that can (though not always) create a risk profile heavily weighted on the wrong side: lots of immediate risk, little immediate reward.

Classic examples:

• ERP migration

• iPaaS implementation

• Website overhaul

In all three of these endeavours, for predominantly DTC retailers, the risks are stacked in such a way as to exacerbate each other and compound.

One small technical mistake in the project can be exposed over and over again by a high volume of transactions. The delicate equilibrium of cross-system inventory accuracy can be easily disturbed. Against good advice, projects can be pushed to completion faster than is advisable, exposing even more technical issues to the outside world. The hard-earned bonds a retailer has with its customer base can be damaged. And, swathes of competitors are ready to swoop in and capitalise if that happens. Even the camels are sweating now.

Lots of tech directly affects consumers. Lots is challenged by huge volumes of users and data. Lots has inventory complexity to deal with. Lots is used by leaders’ who occasionally steer their ships unwisely. Lots is used to power vital perpetual selling. And, lots exist in hyper-competitive industries. But does anywhere other than in retail tech risk having all of those be at play in a single project?

“Sounds terrible — What Can We Do?”

First of all, don’t fret too much. Not all projects have this potentially lethal mix.

Maybe the classic Pareto ratio. 80% of retail tech projects won’t bite your head off and chew. It’s just the remaining 20% that could. Nay, will, if you don’t get your shit together.

And re getting said shit together. It’s pretty simple, actually.

1. Have the right people running the project.
   
   People who really understand this stuff. People who are so scarred by projects that went wrong they’ve become totally militant on details and organisation. People who know all the edge cases to test. People that know what can happen if you don’t test the edge cases. People you trust. People you can have difficult conversations with. Top collaborators.
   

2. Listen to them.
   

Me and several thousand others attended the Retail Technology Show at the ExCeL Centre in East London last week.

(With a newsletter called The Retail Technologist it felt somewhat obligatory).

A free 2-day event with notable speakers (Theo Paphitis, Steve Hewitt, reps from Google, Sainsburys, Toshiba, Asos, etc), hundreds of stands, and a fairground theme (and ride), the event hustled by quickly. Fortunately, some of us were taking notes.

So. What did the event tell us about the industry right now?

Everything is AI-driven now, whatever that means

This one you could’ve predicted without going.

Nearly every product stall advertised AI technology in their product.

I’m sure all of those products use AI to varying degrees. What struck me while walking around the event was just how far ahead adoption of AI is compared to understanding of AI, even in the technology sector. A boom time to be a genuine AI expert, no doubt.

Tech companies need to better market what their product’s AI element actually does to succeed in standing out. I use AI to generate images for this newsletter, so I guess theretailtechnologist.com is AI-driven too.

Omnichannel is dead — Long live ‘Unified Commerce’

Are they different?

Are they the same?

Does anyone really know?

Does anyone really care?

Retailers have been trying to join up the customer experience cross-platform ever since the rise of online shopping. All that’s changed are the terms they use to talk about it.

The truth is still that there is no truly unified commerce platform worth having.

Do you really want the same company that built your PoS and your website (Hi Shopify!) to also build your mobile app? What about wholesale? What about marketplaces? What’s your stock master in this situation?

Shopify is the closest thing out there to unified and it doesn’t get close. It can’t. The big beasts don’t want Shopify PoS. Mid-market brands+ want their own apps. Shopify still isn’t the platform for B2B. Any brand with a 7-figure turnover and up has a separate stock master system.

That’s OK. One platform to rule them all still isn’t realistic. Just like it wasn’t realistic 10 years ago. Just like it won’t be realistic in 10 years time. Best-in-breed + quality iPaaS is still the best vehicle to customer experiences that power growth.

MACH Attack

Microservices. API-first. Cloud-native. Headless. MACH.

The TLDR — a modern framework for building software which champions architectural flexibility, stability and integration with 3rd party systems.

And can I just say before I continue — I, for one, am appreciative to the MACH alliance for swooping in just in the nick of time to provide a much-needed acronym to an industry which for too long has humbly struggled with being too plain-speaking.

Anyway. MACH popped up more than I expected and now looks firmly on the march to becoming the industry standard certification for tech platforms looking to prove they’re not going to weigh a tech stack down by being too much of a pain in the arse to integrate or change.

Universal Macro-Economic Gloom

“Times are hard”. “Tough times ahead”.

Many a version of this sentiment was on evidence at the expo.

Retailers across the board said they were working to “sell more, spend less” initiatives.

Stalls for tech designed to prevent store theft and store staff abuse were a fixture.

Tech suppliers were urged to focus on trying to reposition their platforms and services from a cost to a measurable value provider to avoid being culled in cost-cutting measures.

Where are retailers looking for value from the tech? Helping them to do the basics near-perfectly. Keep stock levels accurate. Keep product quality high. Protect the customer experience in-store and online.

Beware Data Swamps

Credit Rob Barnes (Asda CIO) for this one.

In the past, as he tells it, “people used to think that collecting the data was the job”.

And now, across mid-market and enterprise retailers, there are chaotic masses of unorganised data, yielding no insights, solving no problems — swamping things up, big time.

The journey needs to be to turn data swamps into data lakes. Turn chaos into order. Turn opacity into insights. The benefits are clear.

Customer first, tech second; even at the Retail Technology Show

Retailers should deliver the tech their customers want if they are serious about success. Not the tech their staff thinks is cool. Not the tech their leaders think they should implement. So say the retail panelists at RTS 2025, anyway.

And, in contrast to the rapidly accelerating capabilities of various technologies, the message from retailers was that their tech ‘best practise’ is to be evangelically utilitarian — i.e: all tech must have a very clear purpose; especially in relation to keeping in-store experiences simple.

Sensible messaging on how to do tech change

It was good to hear tech leaders at the top of the retail industry saying the right things about how to change/improve tech use.

Tips I noted down and agree with:

• Create/identify advocates in the business at all levels who support and understand the change — they are all components in your engine to drive change.

• Easy-to-use UX is fundamental to smooth adoption of new systems.

• Don’t underestimate the difficulty of change. It probably won’t be a ‘tap in’. Thinking it will might cost you a helluva lot.

• Test, test, test. The most important part of any project is UAT.

• “Don’t let rumours go ahead of the tech” — you, as a tech leader inside a retailer, should set the narrative about what is coming, not chase it.

Who showed up?

A whistle-stop tour of the technologies that were represented at the expo:

• Store security

• Cybersecurity (a little bit)

• PoS (quite a lot, mostly enterprise)

• PIM (a lot)

• RFID

• Payments

• PLM

• Robotics (one stall)

• iPaaS (a little bit)

And the attendee demographic? Discounting the exhibitors (all suppliers) it was skewed a lot more towards ‘Consultants’ than retailers, in a way which some exhibitors understandably felt wasn’t particularly helpful to their cause. At the end of one talk Andrew Busby repeatedly asked the audience not to sell to the (retailer) panelists as they left the stage.

That’s something the organisers will presumably look to rebalance next time in favour of a heavier retail presence.

Where is this all going?

What follows is a framework to retrieve all bad system implementations.

It’s written to be actionable and memorable.

All you’ll need to remember at the end of this piece is the mnemonic below.

Let’s go!

Let those without mistake cast the first withering glare

We’ve all been there, right?

That thing just isn’t meeting your expectations.

It happens in our personal lives – perhaps more than we’d care to admit.

The person you thought was trustworthy, isn’t.

The car you thought would make you happier, hasn’t.

The holiday you thought might de-stress you, didn’t.

So, what to do when a new system implementation doesn’t deliver everything you’d hoped?

Problems, problems everywhere

Let’s set the situational foundations.

You decided to go through a tech change project.

This means resources were put into:

• Identifying a problem.

• Finding solutions.

• Setting a budget.

• Scrutinising best fit.

• Requirements analysis.

• Implementing.

• Testing.

• Training.

• Launching.

• Bedding in.

And now, it’s live.

The system; your castle: a fortress against those tyrannical problems hampering growth. Inside the walls of the castle, your community of users can thrive.

But, instead of thriving, the castle inhabitants are murmuring discontentedly.

It’s awkward to admit given the scale of the effort, but something is just… not right.

(Here we seamlessly break from metaphor and start just talking about systems — pretend not to notice).

Perhaps there’s a functional gap.

Perhaps there are performance issues.

Perhaps users weren’t trained well enough.

Perhaps the UX is just not good enough.

Either way, the reality is unavoidable. Users aren’t taking to it. It’s not working. Higher-ups can see. A castle might’ve been the aim, but you’ve ended up with a folly, mon ami.

(“The metaphor is back now — make up your mind. And did you make that rhyme on purpose??”)

And so the question becomes, “With little budget, time, or will to do an immediate ‘rip and replace’”, what is a brand to do?

Fear Not

Reasonable organisations accept mistakes as part of a learning cycle, as long as those mistakes aren’t a total disaster (which some botched system projects can be).

Fortunately, we’re not talking here about the Sistine Chapel being burned down.

No invasive species were unwittingly released into an ecosystem, razing to the ground pre-existing natural habitats.

You didn’t just create a machine with general intelligence far greater than a human. (Quite the opposite! Artificial Stupidity.).

Anyway… whether the blame lies with you or not, in your position as a tech leader within a brand there are opportunities to turn this folly folly (not a typo…) into a positive perception of you and your work.

Here’s how…

Step 1: Recognise

(TLDR: publicly acknowledge the challenges.)

Start before the ‘why’.

Leap not to ‘Why is this happening?’, nor ‘What shall we do about it?’. We’re getting there, but via ‘it is happening’.

A ‘public’ acknowledgement of the problem is foundational.

Here’s why it matters:

• Having a leader acknowledge a problem puts everyone at ease: simply, they see that you see.
  

• Acknowledging problems early builds trust in your perceptiveness, communication and competence.
  

• Being the first to acknowledge a problem sets you up to manage it as you think it should be managed. Think of it as your own little ‘first-mover advantage’.
  

• Acknowledging challenges creates an environment where people feel comfortable sharing their insights on the issues. You strengthen your hand by getting that feedback.
  

• You feel good for exhibiting behaviours you want to see from others — this is being a role model.

The Actionable Bit

Here’s a plan to front up the castle/folly dilemma. Slightly different executions for in-office vs remote businesses.

In-Office:

Do the acknowledgement in person, at a ‘Town Hall’ or ‘All Hands’ meeting if your organisation already has one of those.

If not, do via Loom video (or akin) and share it on Slack, Teams, email; whatever comms channel will reach all necessary parties.

Remote Business:

Straight to a Loom video with a quick follow-up meeting scheduled for you to answer questions (and increase the probability everyone watches the Loom).

The structure:

⦾ Context — Explain why you’re giving the address. No judgment, no blame.

⦾ Issue acknowledgement — A quick overview of the issues you’re aware of to date.

Really — keep it short. Non-technical stakeholders (and probably some of the technical ones…) will glaze over if you don’t keep this bit to an overview. The deep dive comes later. You’re doing this bit so your audience knows what you are aware of at an issue-level, ready for the next step in this list.

⦾ The resolution plan — your space to say:

• What steps will be taken to resolve the issues.

• What timeline you’re working to.

• How often updates will be communicated.

• Where updates will be communicated.

• What you need from everyone else.

The Result

Team coherence and unity around the challenges. Increased confidence that the challenges will be met.

Step 2: Explore

(TLDR: data work, basically).

This is a witch-hunt!

Figuratively, only, of course. The witches are safe for now. It’s for problems the torches are burning.

Get all of the issues out in the open.

Up to now, you might only have a partial view of why the system is failing. Step 2 — get a full view.

The Actionable Bit

Start by getting the issue management system right.

Related databases for Issues and Actions mean easier tracking of multiple actions against one issue and a lot less effort on data entry.

I use Notion — other tools are available!

Who you ask for input, and how you ask, is what matters next.

1. Get time with your stakeholders

2. Show them the format you want the issue data in

3. Share the issue manager

4. Agree a timeline for them to input

5. Follow up until done
   

The Result

All issues are known and visible to all stakeholders. The ‘problem outline’ is complete. Everyone feels more in control.

Step 3: Troubleshoot

(TLDR: AKA, root cause analysis.)

You — being the talented, dynamic problem-solver we know you are, immune to flattery and internet charm — already have your methods for identifying the underlying problems causing issues in your tech stack.

Here is the step in the process to do just that.

This article gives an overview of some established RCA (root cause analysis) frameworks if needed.

The Actionable Bit

Bring a ‘Root Causes’ database into your Issue Manager.

Then:

• Relate the databases to:

  • Generate actions from the Root Causes table.

  • Roll up the root cause data and bring it through to the Issues and Actions table so that all tables have root cause data.

• Set up notifications to ping the appropriate people in Slack/Teams whenever noteworthy things happen/don’t happen in the tables.
  

The Result

Problems are properly understood. Solutions are therefore easier to find.

Step 4: Resolutions

(TLDR: create a set of solutions for your team to choose from.)

Some issues from the implementation, like—

• ‘Our suppliers are not supporting us well after launch’

• ‘Our team is showing resistance to the new system/change’

• ‘Some of our customers had a bad experience with us because of issues with the new system’

—have many possible actions which could form a solution.

This step in the recovery process exists for these cases, where there isn’t any one clear path forward for an issue because of its size, complexity or generality.

This step in the process is to create an array of solution options against those issues.

The Actionable Bit

Against each relevant issue, create a list of potential solutions.

Use the actions table to chair a solutions meeting with stakeholders and get their feedback.

Also for the meeting:

• Take feedback from stakeholders

• Welcome additional ideas for actions

• Discuss which actions should be taken

• Determine the priorities of actions

• Confirm owners of actions

• Add deadlines
  

The Result

Team confidence builds in you and the recovery process. The plan gets stronger with multiple brains inputting solutions.

Step 5: Iterate

Simple. Make your actions better by refining them with the feedback gathered in the last step.

Step 6: Endorsement

(TLDR: get sign-off on your plan.)

You’ve done things properly so far.

Owned the challenges.

Got a full picture of what the issues are.

Given everyone visibility of what’s happening.

Found the root causes of the issues.

Come up with lots of solutions.

Got feedback from stakeholders.

Improved your actions with that feedback.

Kept everybody in the loop as you went.

Now, tick the final box — get the endorsement of the stakeholders on what you plan to do.

The Actionable Bit

Keep the format simple.

“These are the issues we all see”.

“These are the root causes”.

“From the solutions we worked on, these are the ones I’m going to action”.

”This is when I’ll update you again”.

“Everybody happy with the approach?”

Once you’ve got a ‘yes’ from all the key stakeholders, move to the next step.

The Result

You have a solid, logical plan, formed with stakeholder input and full endorsement to action it.

Step 7: Venture

(TLDR: go forth and do.)

Plan approved. Time for you to venture forward.

(You think I’m stretching things a bit to fit the mnemonic now, right? Is thou back not stiff from sitting on that high horse all day? You get the gist. Do you know how hard it was to think of a word beginning with ‘v’ that fit here?).

Go and execute the plan.

Step 8: Evaluate

(TLDR: reflect and learn from the experience.)

Probably the most valuable step of all.

By this point, you’ve clawed it back. Either the system implementation is retrieved, or you’ve attempted to retrieve it correctly.

Now to capitalise on the hard-earned lessons from the experience.

The Actionable Bit

Run a project retrospective.

Gather as many valuable actions from the retro as possible.

The Result

Everyone feels more empowered to handle comparable work better next time.

Well Done, Friend

You’ve climbed the steps to a better place!

It wasn’t easy. The staircase is long and steep.

But, you were the difference-maker. The leader. The architect of recovery. Bravo. I hope you learned something valuable.

I’ll leave you with the mnemonic one more time, below.

Until next time!

Suggestions for further learning.

If you like the ideas here, you’d probably get something from learning more about ‘Intellectual Humility’.

For a quick intro, I wrote a LinkedIn post about it and how it applies to a retail systems context.

I also wrote a second LinkedIn post trying to example intellectual humility by telling a story about a mistake I made in a previous job, and what I learned from it.

For a more in-depth overview, my source material for those posts was this podcast.

It’s 2025.

Yes — really…

Let’s get straight to it. Here’s what you get out of reading this article.

It delivers on the title; so you get what that promises.

It’s not played safe with a ‘not in order of priority’. The priorities are in order. Strong opinions welcome on those.

And, lots of (gratis) recommendations. Like a Consultant would do, except without the 10k-a-day invoice.

Spoiler-not-a-spoiler — yes, this piece contains reference to AI. Avert your eyes should you already be incurably sick of reading about it.

Here we go…

1. Up your projects game

Why the cognitive dissonance?

Every ambitious organisation is continuously changing, and that means projects.

Most brands I’ve worked with have a veritable banquet of active tech change projects.

Projects underpin brand operational changes, drive growth initiatives, and are crucial to staying ahead of (or at least on par with) the competition.

Yet, projects are mostly hauled, huffed, grunted and painstakingly edged over the line by well-meaning, under-resourced brand teams; sometimes acting without best-practice knowledge and governance.

We want the change. We want the change to be done properly. But we don’t always give projects what they need to succeed. Why the cognitive dissonance?

If we were commissioning a delicious birthday cake — a Black Forest Gateau, let’s say — and so provided our star baker with the baking powder, the vegetable oil, and a few cherries, then told them to have it ready in a couple of hours, they’d rightly look at us like we’d just blown our nose on their sleeves.

Brands nailing change projects in 2025 will be a big difference-maker in turning OK years into good years, good years into great years, and great years into game-changing years.

And, here’s the thing. It’s not that difficult.

An article on excelling in technical project management for retail systems is coming soon — the below image is a quick preview. For now, check out my recommendations and stay tuned.

Recommendations

• For tips to get into projects on the right terms, read this and this.
  

• Quantify, quantify, quantify. We can make better cases for projects being given enough resources. Boil everything down to numbers, even if just rational estimates. If you're dedicating 0.5 days a week to a project instead of the recommended 1.5, and suspect it might slip without more input, quantify it: By how much? Why? How will it delay other work, and at what cost?
  

• Bring in outside help. Pros and cons of permanent hires, right? We can all advocate strongly for hiring permanents. But, for stretched teams with a daunting project backlog, bringing in trusted specialist help that can hit the ground running (if you’re lucky enough to know someone like that…) can be a game-changer.
  

• Recognise the value of a dedicated PM. It’s a terribly under-appreciated specialism, but I’ll get into that in the upcoming piece. For now, just take my word for it. Hire a great PM (there are plenty of average ones), focus them solely on PM work, and watch your projects deliver faster, with better results, with more control, lower stress, and suppliers taking notes on your approach.

2. Put data-driven decision-making (even more) front and centre

Data totalitarianism, this is not.

There is plenty of room for ‘gut feel’, instinctual decision-making.

Sometimes, there just isn’t data on which to make a decision, and good instincts naturally fill in the gaps where data can’t yet be.

Sometimes, the data tells us one thing, but we just know it’s pointing us in the wrong direction. We should trust that instinct. At worst, we’re wrong and we learn something. Ignore our instinct and have it proved right, and we might harden around instinct-oriented decision-making in future cases where data might be the better option.

(There’s a ‘but’ coming…)

But: when reliable data can be flexibly manipulated to answer targeted, important questions, and that can happen on demand, quickly, without manual work or lead times — that’s amore…

I worked with a streetwear brand in 2024 to set up a better stock automation into their Shopify sites.

As part of the launch of the automation we needed to establish, based on historical order data, how high order volumes were likely to be in:

• A specific 1hr window

• On a certain day of the week

• For customers in a specific timezone (the Shopify site served multiple timezones)

The brand was using PowerBI and got the answer in a couple of minutes. It confirmed the volumes would be very low in our chosen launch slot.

Getting that decision quickly meant that we saved hours planning a more complicated go-live, and possibly even avoided putting a holding page up on the site temporarily to allow the stock to be added to the store safely.

Imagine if that level of clarity could be given to all of your departments to assist their most important decisions.

Recommendations

• Tool up on BI. (If you already use a tool and are happy with it, ignore this bullet). It’s time to put more time and money into the pro BI tools. Specialist tools will pay for themselves many, many, many (many, many, many…) times over if utilised well.

• Create a BI knowledge hub (in Notion or your equivalent) to make your BI tool more accessible for everyone. Here you can answer FAQs, provide how-to videos, document successes, publicise a feature roadmap, take requests — whatever helps build a culture of seeing value in data insights. (PS — Notion has built-in AI functionality to help generate 1st drafts of documents, and Loom is easy to use. It won’t take as long as you think. See priority 4!).
  

• Start a Slack/messenger channel for BI comms which the hub doesn’t cover. Consider diverting relevant BI hub updates here via webhook.
  

• Use cross-departmental work to identify where BI can support other teams. The more cross-departmental exposure tech leaders have, the better they’ll perform — our systems serve all departments, after all. If such opportunities are scarce, create them. Sitting in on a few extra meetings each month with merchandising, eComm, CS, Product, et al, shouldn’t be too demanding.

• Again — quantify, quantify, quantify. Nothing proves value better than clear numbers: How much time is saved? How much profit is added?

3. Deliver value with AI

AI is here.

It’s very hyped, often misdefined, and it has actually been here for a while, but for the sake of a snappy opening gambit, let’s just say ‘it’s here’.

After months of exploring AI to understand and simplify its capabilities in our field, here’s my take:

• AGI is still a way away, if it will ever be possible. (So don’t build your bomb shelters just yet).

• Generative AI is helpful but output must be verified before production use.

• Most AI projects don’t deliver profit. (Some stats suggest 85% of AI projects don’t even get finished).

• Most AI ‘Agents’ are automation or AI workflows in disguise. (Learn about the difference here).

• True AI Agents can deliver value but not without hard project work, lots of learning and some compromise.

• The potential of AI is very real, but the current position is closer to potential than easy profit.

But the arrow of time points in one direction — greater and greater outsourcing of human work to machines via automation, workflows and AI tools.

I primarily work with and write for brands with annual turnovers of £20m–£200m. These brands have been outsourcing to automation for years, and that trend will continue.

But, the next evolution is to outsource more and more work to AI.

Right now that might just be customer service chatbots, smarter search tools for website shoppers, ideas generation from ChatGPT, etc, but soon the capabilities of AI tools are likely to be much more advanced.

When that moment comes, the scale-up/challenger brands moving quickly and smartly on AI will have a clear advantage over their competitors.

Recommendations

• Make ‘AI Research’ a part of someone’s role. Hiring a dedicated AI specialist internally might be overkill now, but may not be for long. For the moment, assign someone to regularly check where AI functionality is and think about profitable applications for you.
  

• If you don’t have the team for the above bullet, consider engaging with a recommended AI Consultant. But, only if you have genuine use cases where AI can better what automation or other, readier tools can do.
  

• Start taking in trusted AI content. I like this blog. This podcast. Some voices on LinkedIn seem pretty sensible, example. But, find your own too. (And if you find good ones please share them back with me. There’s too much for any one person to sift through…).
  

• Set a goal to deliver X profit with AI tools by the end of 2025. This is a win-win, really. You can set the target high and achieve it, in which case, great! You can set it low and achieve it; also great. Or, you can set it anywhere and fail (which, given the stats, might be a pretty likely outcome). In this case, the experience will still mean you’re much better placed to capitalise on the proliferation of different tools heading our way soon.

4. Make this the year you finally document everything

I know, I know.

‘There’s never enough time to document things’.

‘We tried to document things but ended up just kind of…stopping’.

‘Some things change so quickly documenting them is a waste of time’.

You agree with me on the principle, though.

We know that documenting ‘as we go’ is worth the effort.

We know it pays us back in droves later on.

And I know from painful experience that it’s not easy to do.

We’re busy.

There’s always a higher priority.

People don’t always use the things you do document.

I get it.

But thanks to various improved tools, providing good documentation has never been easier than it is now. Therefore, it might be time to psych yourself up for another crack at it.

Now, I’m not on commission by Notion (…), but I have been using it a lot recently.

Once I got over the clunky early stages of the learning curve, it’s been great.

With a bit of persistence and some upskilling, you can build something pretty good, fast.

So, inspired by my recent Notion experiences (but substitute in your preferred tool — hopefully it’s as good or better than Notion!), here’s how I’d make creating documentation easier.

• Templates for all different page types, page sections and buttons.

• Buttons that generate those templated pages with one click. (Means pages are uniform in format and content).

• AI to create first drafts of knowledge hub documents.

With all of the above set up, a user could have a 1st draft of a new how-to article set up in under a minute.

Carve out 20–30 minutes a week for a select group of people in the business to work on documentation, and in a month you should be seeing significant results.

5. Find the hidden savings

It seems we’ll continue through challenging economic times for growth in 2025.

Most of us are (at best) uncertain about the impact on the global economy of the impending 2nd Trump term.

Growth in the UK (where most of my readers are) is flatlining.

Take out the US, and growth in the G7 as a whole is pretty insipid.

These are the macro conditions we find ourselves in and they affect us whether we acknowledge them or not.

Now is a good time to get the tech stack as lean as possible.

Recommendations

• Create a tools inventory with associated ongoing costs (if not already available).
  

• Go through a ‘right-sizing’ process. Remove under-utilised tools. Identify tools with overlapping functionality and scale back as necessary. Check user licenses adoption. Unused test environments. Etc.
  

That’s all folks

Thanks everyone for giving this a spin — all my winter well-wishes to you.

A quick summary:

• AI = warm, not yet hot. But, start getting acclimatised now lest it cook us all in the near future.

• Projects still a priority and often under-valued. We can make them better.

• Data-driven decision-making still under-utilised in Retail and adds demonstrable value.

• It’s never been easier to master documentation, and we all know what that unlocks. (PS, try Notion).

• 2025 might be a great time for thriftiness given the macro picture.

Until next time.

Desire paths are burrowing their way around your systems.

You Talkin’ Uh’Me?

You are a tech leader in a retail brand.

You are passionate about what you do. Motivated. Smart.

(I see you nodding as you read this — ‘Yes, I am pretty great aren’t I?’).

In half of your waking hours on this earth, you urge your corporeal self, logic, wisdom, and creative soul into your work.

Why?

To auteur beautifully designed systems, of course.

Palaces of productivity and light: guiding people towards their potential via honeyed panaceas for the mundane modern workplace experience.

Or, you just implement systems for a retail brand. Wherever you are on the scale of poetic description is fine by me.

Spreadsheet Insurgency

But at work, you’re seeing things that concern you.

The users of your systems aren’t meeting your gaze as they used to.

A suspicious number of spreadsheets are open when you walk through the office.

The sales report you’ve just been handed clearly wasn’t generated from the ERP.

The users are not following the workflows.

Conflict is resolved from a starting position of both sides agreeing the other has a point.

Desire paths are burrowing their way around your systems in ways you were blissfully unaware of, until now.

You are frustrated.

‘We designed this together?’

‘We sat through session after session agreeing how this would work.’

‘You said you needed it this way!’

‘Now it’s live and you’re just… freestyling?’

Fair points.

But conflict (even very minor, as in this case) is resolved from a starting position of both sides agreeing the other has a point.

So, what is the user perspective?

Why are the users trampling down the grass at the verges of your ERP (for example), instead of following your planned route?

When you observe desire paths, what opportunities are created?

Reasons, Examples, And Jungian Silliness

Potential reasons abound:

• The workflows are not optimal.

• The menu options could be more intuitive.

• Something might have been missed in the design. (It’s possible — that’s all I’m saying!).

• Users weren’t trained well enough.

• The system documentation doesn’t support the post-live phase.

• New people have joined since live and don’t know the right process yet.

• System labelling could be better.

• The system hasn’t evolved with changing needs.

Of course, there’s also a selection of reasons which nest under the ‘wrong operators in place’ category, but this article presumes you’ve got good people in the right seats.

“Tom, this is all quite abstract — what does a desire path even look like in the retail software context?”

Very specific question imaginary reader… And frankly, a bit wordy. Also, curiously timed given what’s coming next. I sincerely hope you’re not a narrative device posing as a legitimate reader/writer interaction?

Here are real-world examples from brand teams of desire paths in retail software.

1. Creating products directly in the eCommerce site rather than the product master system.

2. Manually adjusting stock levels in the eCommerce site.

3. Selling custom products on PoS transactions.

4. Producing reports and analytics in Excel/Google Sheets rather than inside the tech stack.

5. Bypassing automated replenishment workflows to order stock via email from suppliers.

6. Manually triggering iPaaS syncs instead of letting them run on schedule.

Can these instances create issues for you? Yes.

Tech teams inside brands scurrying around fixing the fallout of colleagues’ ‘off-roading’, as you well know, oh so clever reader, is a part of the job. But how big a part of the job is up to you.

So, let’s think about it a different way. When you observe desire paths, what opportunities are created?

Each one of those examples tells us something. Take the one below.

Producing reports and analytics in Excel/Google sheets rather than inside the tech stack.

This suggests that either:

🥉 The reporting capabilities inside the stack aren’t rich enough.

OR…

🧑‍🔬 They are, but the users aren’t yet skilled enough on the system to produce them.

OR…

🤔 Users are perfectly skilled at generating system reports but view doing that as less effective than exporting data for manipulation in spreadsheets.

Any of those creates an opportunity.

In fact, whichever example from the 6 above is chosen, all create an opportunity, to either:

1. Make systems better.

2. Make processes better.

3. Make documentation better.

4. Help someone who needs more training.

Viewing things this way, rather than as wanton destruction of your pristine palace, fosters growth for users, yourself, and the systems.

Ego does not a good software make. It’s like Carl Jung said…

“Through pride we are ever deceiving ourselves. But deep down below the surface of the average conscience, a still, small voice says to us, 'They’re not breaking process because they’re idiots, mate. It’s probably at least partly the system."

The Paths Not Seen

So there are the desire paths you can observe, and then there are the ones you can’t.

Perhaps someone on your team is too shy to admit a process isn’t working for them, or fears your reaction to their feedback.

They might be too busy to document what doesn’t work and why, feeling pressured to 'push ahead and make it work' to save time.

Or they don’t want to ‘get in trouble’.

Or, they don’t even know they aren’t following the process!

What to do about that category of scenarios — the paths not seen?

Unaddressed, these paths can make small issues big.

For example, point 6…

Manually triggering iPaaS syncs instead of letting them run on schedule.

Imagine that over some months, someone on your eComm team notices your integration not updating stock on certain products as it should.

Initially, the issue only affects a handful of items, so they quickly add the stock manually on Shopify and forget about it.

They repeat this a few times over the months, dismissing the issue as too minor to report: 'It’s just a couple of products; it’s quicker to fix manually’.

But that problem is about to become much bigger.

A certain product type (let’s say, footwear) is missing from your 3PL's stock files, preventing your integration from updating its stock on Shopify.

That’s a small issue now because you only have one or two ‘path-finder’ footwear products.

But tonight is the big launch of your marquee footwear product, a key strategic move to capitalise on the success of a pathfinder trainer.

And the eComm team member who had been quietly fixing the stock issue left the company last week.

It’s 6 pm, and a raft of new product listings were added to Shopify earlier in the day. They have beautiful images, carefully crafted descriptions optimised for SEO, tags. A lot of marketing spend went into this campaign. But… there’s no stock?

‘Why is there no stock!?’

‘The integration ran an hour ago — all the other products have stock? Why do the trainers have no stock??’

You call the integration provider but it’s outside of their working hours. They scramble a developer to look into it. The sale launches in 30 minutes.

20 minutes pass.

The developer looks into the file. The footwear SKUs just aren’t there. It’s a 3PL issue. Now you need to contact the 3PL. 10 minutes to go…

This kind of thing happens. I’ve seen it.

So, how can those issues be pre-empted?

Solutions

Happily, there are many ways to capitalise on the opportunities created by desire paths.

Some methods are technical, others involve process and system choices, some require strong soft skills. A few are quick to implement, others not. A mix of the options below may work best.

Here we go!

Feedback Systems

• Operate an internal support desk and make it easy for your colleagues to create tickets.

  • Effort level: Medium.

  • Process:

    • System users in the business raise a ticket if they:

      • Encounter a technical issue.

      • Use a workaround (i.e. create a desire path!).

      • Don’t know how something is supposed to be done.

  • Tips:

    • Keep ticket creation simple with minimal mandatory fields — users are more likely to act when it's easy.

      • The helpdesk will also support users raising tickets via email.

    • Set up a regular review process and follow-ups; people will stop raising tickets if they feel ignored or see no resolutions.

    • Plenty of helpdesks are available, but avoid Zendesk; its reply threading can make long interactions confusing.

    • Most support desks can prompt users to check relevant 'how-to' guides or knowledge-base articles.

• A shared document for logging system feedback. If a helpdesk is too much work.

  • Effort Level: Very Low.

  • Process:

    • Set up (something as simple as) a Google Sheet, or your organisation’s equivalent. Create columns for the data you want to be filled in.

    • Share it with key users you want to input.

    • Use a Loom video (or equivalent) or hold a meeting to explain what to do, why it matters, and gather feedback.

  • Tips:

    • Have your key users add the document to their bookmark bar to remind them to use it.

    • Better yet, if they’re willing, ask them to set the document as their new tab page (I use this Chrome extension).
      

• Surveys and feedback forms.

  • Effort Level: Very Low.

  • Process:

    • Easy — create form, list recipients, send form, gather feedback, decide actions.

  • Tips:

    • Keep the form simple to boost engagement. Save the detailed stuff for a follow-up after the fact. Asking for too much information in the form will decrease engagement.

    • Send the form out with the explicit message that it takes sub 1-min to complete!
      

• Regular, quick sessions with key users. (My favourite solution).

  • Effort Level: Low

  • Process:

    • The format is simple — “Re the systems you use, what’s good? What needs change?”.

    • Could be 15 minutes once a month to start with.

  • Tips:

    • Encourage users to note down ideas on what’s good/what needs change in between meetings.

      • There’s gold in them there hills…

Observation & Analysis

• Implement a technical screen monitoring solution, like HotJar.

  • Effort Level: Unknown.

  • Process:

    • Disclaimer: I haven’t used this tool before and understand it’s primarily for tracking website user behaviour. But, I’m curious about its potential for identifying friction points encountered by browser system users (e.g. Netsuite, Shopify, Airtable).

  • Tips:

    • Crucial — this absolutely has to be done with prior user consent. Don’t be a ***** and start spying on your teammates.
      

• Audit of ‘Shadow IT’.

  • Effort Level: Very High.

  • Process:

    • Lots of planning. Data collection. Analysis. Stakeholder updates. Reporting. Possibly different approaches for remote/office workers.

    • A quick search suggests there are tools which help do a more automated version of this (like Lansweeper and ZScaler) but I can’t speak to cost, setup or effectiveness.

  • Tips:

    • Be wary about this option. People sometimes see ‘audit’ and hear ‘witchhunt’. Plus, doing it thoroughly is weeks of work. If you decide it’s worth doing, go into it with your eyes open.

    • Unless you’re in an organisation which is too big to take a more personal, collaborative approach, this option isn’t preferred.

• Task-specific audit.

  • Effort Level: Medium-High. (Hard to define without knowing the tasks, but shouldn’t be unworkable).

  • Process:

    • There are lots of thorough guides on how to do this online — I’ll leave it to the pros.

  • Tips:

    • Remember, the goal isn’t to ‘correct’ or catch users out, but to learn things which create opportunities to improve the tech setup.

• Shadow key users.

  • Effort Level: Medium–High.

  • Process:

    • List ideal key users for different systems.

    • Schedule appropriate slots to sit with them, and learn by watching how they use the system and asking questions.

  • Tips:

    • Make it ‘light touch’ (short periods with each key user and not too frequent) and informal.

    • Don’t try and implement this with remote workers! In-office businesses only.
      

Culture Change

• Culture setting around giving constructive feedback.

  • Effort Level: Medium-High (but worth it).

  • Process:

    • Get the message out that feedback is welcomed.

    • Include in that message how you want to get feedback, and the type of feedback you are looking for.

    • Lower the barrier to giving feedback (and keep lowering it). A simple form, or a simple format. Don’t ask too much! If possible, ask so little that not giving feedback seems almost rude.

    • Reward givers of feedback.

    • Let users give feedback anonymously if they’d prefer.

    • Show vulnerability — acknowledge your mistakes. Users are more likely to suggest improvements if they see you're open to feedback and learning.

    • Actually implement the good ideas… Starting with quick wins to build a sense of ‘this feedback actually makes positive change’.

    • Get feedback into your culture from top down. It’s powerful when leaders openly seek feedback. Nobody is above improvement — show that.

    • Sell the value of the feedback back to everyone. Show where feedback was given, received, appreciated, acted upon, and led to measurable improvements.

• Tips:

  • This is where your soft skills need to kick in. Show gratitude in getting the feedback (which is best done by actually being grateful…). Give off positive energy in all of your messaging around this initiative.

  • Keep repeating the above steps and use your charm (!) to mean that doesn’t get annoying.

    • Get the way you want people to deliver feedback, the type of feedback you want, and the value of having the feedback so deeply ingrained in the organisation that it’s an unconscious part of the environment. That’s done through repetition, which doesn’t have to be boring.
      

Species Survival

We as systems people can be prone to being Intelligent Design evangelists.

We know what our users need. We create it. They thrive.

But, in reality, it comes down to this.

There’s how you plan for systems to be used, and then there’s how they are actually used.

Systems thrive by evolution just like we do. Desire paths might well point you towards the gene pool being selected.

Or not? If you missed the first instalment, it’s here.

Let’s get into it.

6. How do we know we’ve found the right system and partner?

We know why this is so important, right? I don’t need to cover that? OK — I’ll do it very quickly…

Simply, the right system implemented by the wrong partner won’t be right for the brand.

And, even the right system properly implemented but not supported into the future can’t grow with the brand.

So how do brands know when they’ve found the right system?

Here’s what to look for…

1. Functional fit

   1. Basically, the system can do what the brand needs it to do.

      1. Less basically:

         1. The system has the required functionality for now.

         2. The system has the required functionality for the future as well.

            1. Or the potential or plan to develop that functionality.

         3. The required functionality is accessible to the brands key users in a way which they are going to find viable! I.e, the UI/UX feels good to use every day.

            1. Key user buy-in is essential for implementation and post-live.

         4. The system gives the brand the data visibility they need.

            1. The system will likely contain data that the brand finds valuable — can they access it easily to derive insights from it? Or better yet, does the system have insights-giving capabilities built in?
               

2. Stability & Performance

   1. The system is performant enough to handle your data at peak volumes and at 1.5x, 2x and 5x. (Change the numbers to fit your projected growth volumes…).
      

3. Scalability

   1. The system can support every step of the businesses plan to scale.
      
      Opening new physical stores? No problem.
      
      Moving into new product lines? Fine.
      
      Expanding into a new market? Seen it all before.
      
      New sales channels? Completed it.
      

4. Ease of integration

   1. For brands with a dedicated integration partner — the system has a public API to work with.

   2. For brands without a dedicated integration partner — the system has the pre-built integrations you need.

For best results, brands cannot compromise on those four points.

So how do brands find a supplier to implement well in the now, and be invested in the long term?

Brands need to partner with suppliers they can go through adversity with — everyone (nearly…) can keep a relationship strong when times are good.

“Retailers in the UK say major ERP projects take 6 months longer than estimated to get live (an average 200-day delay)”

(enterprisetimes.co.uk).

Here’s what to look for on the partner side.

1. It’s obvious they know their domain extremely well.
   

2. They have a track record of delivering well for brands like yours, and customers that will attest to that.
   

3. There’s a ‘culture fit’ between their team and yours.

   1. When speaking to the partner team, think, ‘would I be happy to have this person, or these people, working directly in my team?’. If it’s an obvious ‘yes’, you shouldn’t have any issues working with them as a partner. If you’re not sure, you’ll benefit from resolving those uncertainties before you commit to working with this vendor.
      

4. They have a consultative, detail-oriented approach to sales.
   

5. They can convincingly walk you through their implementation process and field your questions.
   

6. They can evidence support statistics which assure you won’t face prolonged technical issues.
   

7. They can demonstrate that they operate with a partnership model.
   

8. They are open about where their business plan takes them, and theirs aligns with yours…
   

9. They can introduce you to several team members and all are knowledgeable in their domain.
   

These teams exist. Brands — go and find them.

7. How Long is This Really Going to Take?

Project overruns are quite common.

Hubspot research in 2020 found that 47% of organizations did not complete their ERP project within the expected timeline.

Truly convincing data on implementation delays of retail-specific software isn’t plentiful, but available figures suggest anywhere between 30–50% of retail software implementations are delayed, which doesn’t sound outlandish.

💡 The Standish Group CHAOS report from 2015 puts the number even higher for software implementation projects on the whole. 

OK, you say. But… why?

There are so many answers to that it warrants a blog post in itself, but here’s the skeleton.

• The timeline was unlikely from the beginning.
  
  Possibly because the supplier didn’t want to scare the brand away with long timelines.
  
  Possibly because timeline pressure came ‘from above’ and just wasn’t realistic.
  
  

• Scope creep.
  
  Subjects of Project Managers anxiety dreams from least to most stressful:

  • Falling.

  • Being chased.

  • Wanton scope creep.
    
    

• Someone missed something in the design stage.
  
  Implementation projects can be complex and intricate.
  
  Miss one small detail in solution design and it can add weeks down the line.
  
  Miss a handful of small details…
  
  

• Project Management isn’t done properly.
  
  This will be a blog post by itself (!) so no elaboration available at this time...
  
  

• The project isn’t resourced properly.
  
  I’m looking at both of you here — suppliers and brands! See point 9 of this article.
  
  

• Unreliable 3rd parties.
  
  Ah… yes.
  
  It’s not just the brand and the supplier which need to be on their game.
  
  It’s all of the 3rd parties. Anyone who the implementation affects needs to be lined up and supporting effectively.
  
  

• Team turnover.
  
  Churn on the project team can kill momentum.
  
  Lose one key SME (subject matter expert) from the project and all of a sudden questions which one person can answer in 5 minutes now have to be answered by committee and take 2 weeks.

So what can the brand do to get a realistic timeline from the start from its vendors?

Ask for reference projects from the vendors and ask them how long those projects took.

Then, ask for an introduction to those reference brands so you can correspond the timeline (and experience) on those projects.

If the vendor can’t provide a single reference project that is comparable to the one you’re working on, it’s likely either because:

• They haven’t done one before (🚩), or;

• They have, but they don’t want you to speak to those brands (🚩🚩🚩…).
  

If the supplier can give great reference projects, and the reference clients correspond the suppliers timelines on those projects, then increase your confidence that the given timeline will be hit.

8. How do we take everyone with us?

Imagine — the year is 300 BC, and you are a village elder in a Mapuche tribe living in what is now Chile. (Can you tell that AI didn’t write this?).

One day the tribe leader comes to you and explains that the volcanic soil around the Calbuco volcano is known to be better for farming, and that he plans to take the tribe North so that its agricultural output can flourish. You agree.

You hear nothing for some weeks.

One morning, the tribe leader approaches and tells you he and the others are leaving in 5 minutes.

You’d be forgiven by most for responding with … ‘frustration’.

Big change — the kind which affects someone’s day-to-day life, like them using a new system to deliver their work — happens better when you:

1. Involve all stakeholders early in the change process.
   

2. Clearly communicate your (killer) why — why is this change happening?
   

3. Keep reminding everyone of the benefits of the change through the process.
   

4. Give all stakeholders plentiful notice of key dates so they can prepare.
   

5. Deliver detailed, thoughtful training. And, resources to be used ongoing.
   

6. Identify those who are ‘with you’ in the change process and recruit them to your cause.
   

7. Regularly — and publicly — recognise positives/wins after launch.
   

8. Listen! Systems survive by evolution. Keep making the system better using the feedback you (make sure you) get, especially from users and management.

9. How do we resource this project properly?

If you are the type of organisation that has meaningful conversations around this question, that alone is a great sign.

Some of your competitors won’t spend much time in this area, and they will be weaker for it.

The sub-questions here, are:

• How many person-hours will this project cost us?

• What skills do we need?

• What roles do we need to fulfil on the project?

• What roles will our supplier(s) fulfil on the project?

The easy one first — suppliers should give brands an estimate of how many person-hours the brand is expected to contribute to the project.

Given how well you did point 6 from this list, your chosen supplier probably volunteered this information and it’s probably accurate. However, if this info isn’t volunteered, ask for it.

Next, the roles/skills.

Brands should prepare to fulfil at least 4 key roles in a project.

(Note: one person could fulfil more than one of these roles.)

1. Project manage the implementation, especially when the implementation involves more parties than just the brand & one supplier. Why?

   1. Both suppliers and brands juggle multiple projects, often sharing key resources like time and people. If the brand doesn’t create a clear plan for everyone involved, no one else will — unless they’re specifically paid to.

   2. Without a unifying plan to align everyone, dependencies aren’t met on time, milestones are missed, and then delays, delays and deadly looks on Teams calls.
      

2. Provide an SME (or SMEs) to be available throughout. This person:

   1. Knows in detail what the project needs to achieve.

   2. Has the subject matter knowledge to get the supplier(s) aligned on what the system(s) need to do.
      

3. Provide a Key User representative to be available throughout. This person:

   1. Speaks for the eventual users of the system while the system is being designed and built.

   2. Sees things everyone else doesn’t see!

   3. Becomes a leader in the project during User Acceptance Testing, training and post-launch.

4. Provide an IT/Systems expert to be involved during the design, and on hand during the testing and launch.

Resource the project properly and it will:

• Be less likely to overrun. (Saving you money).

• Be more likely to deliver the desired benefits. (Making or saving you money, depending).

• Strengthen your reputation in the supplier industry. (This way comes perks and benefits…).

• Boost staff morale (being part of an elite team feels good).

10. What is still abstract?

Even a rigorous process might not define everything.

Organisations run out of time. Or budget. Or have things they can’t yet finalise. Or just miss things.

That’s normal.

Before you sign, just take a moment to map out what you still don’t know.

Maybe you’ve left the very fine details of your returns process almost defined.

Or you’re waiting on approval from a tax authority to go bonded but don’t know when it’s coming.

You might be planning to change shipping options and haven’t yet taken the final decisions.

Whatever it is, own the unknown.

Find out what you still don’t know, and manage it.

Track it as a risk in the project.

Add it as an important action for asap.

Delay sign-off if you have to…

The final check can pay off big time.

1. Is our ‘why’ good enough?

It’s an interesting paradox.

Every software supplier sees the conscientious people inside brands.

Yet, when it comes to systems, these same brands sometimes fail to fully answer the fundamental question: ‘why’ — why are we adding a new system to the business?

Why are we doing this? Are the reasons good enough? Are we clear on what the benefits of this selection are?

Reasons for adopting new systems range in quality.

At one side of the spectrum is a partially considered approach.

Perhaps a brand hears that competitors, or brands to which they aspire, have implemented ‘System A’.

Once the brand hears that enough times, they begin to see implementing ‘System A’ as just ‘the done thing’, without doing a full analysis of whether implementing ‘System A’ is the right thing for their requirements.

“If it’s good enough for ‘X’, it’s good enough for us”. There’s logic to that.

But, it pays to be on the other side of that spectrum.

There, on that side, are the battle-hardened CTOs, systems managers, finance teams and ops leaders.

They have seen first-hand the digital trench warfare of ERP implementation, survived the psychological blitzkrieg of a platform failing during BFCM, and know that the foundational decision to avoid tech pain and achieve tech gain, is to make the right system choice in the first place.

Because here’s the reality: brands on the second side of that spectrum grow faster than they would if they were on the first side.

So, brands, thumb your nose to ‘that’ll do-ism’. Re-scrutinise your ‘why’.

Ask yourself, “why are we doing this?”

”Are the reasons strong enough?”

”Are the benefits absolutely clear?”

2. What will this really cost?

It pays — literally — to have a deep understanding of every cost factor before you start adding a new system.

Being able to accurately calculate Total Cost of Ownership (TCO) enables a brand to make the most informed procurement decisions.

Below is a breakdown of the cost factors. It’s not a list to scare anybody; it’s a list to empower.

Disclaimer: it’s a long list. More pictures have been added as a peace offering.

Here are the ones most brands tend to consider automatically:

• Licensing/subscription fees.

• Implementation costs.

• Hardware costs (if applicable).

• Support costs.

Here are the ones less considered:

• Return on investment.
  
  The true cost of the system should factor in the value you derive from it as well as the costs incurred.
  
  Example — if brands expect to get big efficiency gains from automating data flows or using AI agents, that’s a saving on person-hours which should be calculated and offset against the costs.
  
  

• The cost of doing nothing.
  
  What is your current setup costing you that your new setup wouldn’t?
  
  (This eBook gives some ideas on that and explains technical debt quite well, pages 7–11.)

  

• Data migration

  
  Suppliers don’t always want to handle this, and sometimes charge extra for doing it. Check in each case how they want to work.
  
  

• The cost of any system customisation.
  
  It’s possible your new supplier charges extra for this; check with them.
  
  

• Integration costs.
  
  The system being added likely needs integration.
  
  That may or may not be provided by the new supplier, maybe at an extra cost. If you have an integration partner, factor in their costs to work on the project.
  
  Also, integrations are typically an ongoing cost (servers, maintenance, support, etc).
  
  

• Costs for existing partners/systems.
  
  If you’re integrating this new system into your current stack and the suppliers of other systems are affected, they might charge you to help.

• The cost of your team’s time for:
  

  • Training.

  • Change management.
    
    Someone needs to manage the change process to ensure everyone is kept aligned to the vision and objectives — the ‘why’ (!) — and delivers the results.
    

  • Testing.
    
    Fundamental to the success of an implementation. Test it thoroughly to make sure it’s working well before you set it loose in your organisation.

  • System maintenance.
    
    Someone needs to stay on top of the system admin! Even at the simple end of the scale:

    • Users need to be managed.

    • Integrations need to be monitored.

    • Issues need to be managed.

    • Upgrades need to be coordinated.

    • Data quality needs to be maintained.

• Launch.
  
  Depending on the scope of the system, even the launch process could be a time cost worth calculating. Big ERP projects can knock multiple people out of the business for days, even weeks.

• How your costs will grow over time.
  
  Work with your supplier to forecast how their costs could grow beyond year 1.

• Opportunity costs.
  

  • Downtime during implementation.
    
    Launching a new eComm site, for example, might involve a period of the site being offline — calculate the cost and factor it in.
    

  • Lost productivity for a short period after launch.

    
    Staff might not work as well on the new system straight after the transition. This is a cost worth working out and potentially mitigating.

• Decommissioning legacy systems.
  
  Find out whether your old supplier needs to be involved in the cutover to your new one and whether that has a cost impact.
  
  Check whether there any closing down activities with the soon-to-be legacy system which your old supplier may charge for.
  
  If there was hardware used with your legacy system, the cost of disposing it — or indeed the money to be made re-selling it — can be factored in.
  

• Exit costs.
  
  What your supplier/partner might term ‘stickiness’, others have labelled ‘vendor lock-in’.
  
  The true cost of a system, especially one you know you will outgrow at some point in the future, includes the cost of switching away to its successor.

• Contingency budget.
  
  Optional but advisable. Better to have it and not need it than the reverse.

Yes, it’s a long list, but with it the power is back in your hands.

No going back the project sponsor asking for more money.

No billing surprises in year 2 of a new system.

Just a clear picture of value.

3. How will the new system impact our existing systems and processes?

OK.

So you have great reasons for taking on a new system. Good start.

And, you have a clear picture of the costs of doing that. Muy bien.

But how exactly will this new system impact the way you do things today?

And, to what extent are you in control of that impact?

The TLDR answer — unless a brand builds its own software, it will almost certainly need to tailor the way it works to the software it selects.

Making a software completely configurable is unachievable, and actually should not be strived for, lest that software becomes a Frankenstein’s monster: grotesque; vengeful; determined to make its creator pay for their unchecked idealism.

Taking eCommerce platforms for an example — it’s predominantly vast retailers which build their own platforms successfully. Nike, Asos, Amazon, all build their own and have flexibility to fit their eCommerce tools around their business processes.

For everyone else, there are ready-made platforms out there to select from.

Those systems — even ones which are heavily modularised and come with a rich app and developer ecosystem — will mean compromise on your existing business processes.

Here’s a simple set of steps to remain in control:

1. Map out your current processes. (Whimsical is free and has some useful templated process diagrams).

2. Map out the desired process state.

3. Consult everyone who needs to input into those process diagrams.

4. Evaluate the new system for how good a match it is to your desired process state.
   (Note: your supplier should be prompting you do this in the sales process).

5. Identify the gaps. Where does the new system not fit exactly with the way you want to work?

6. Decide whether those gaps are plugged with a change of process, or by customising the system (if that’s an option).
   

That’s it!

A simple exercise; one that will improve the adoption of a new system by getting ahead of its impact on the way you work.

4. What are the biggest challenges we pose to this type of system, and can it handle us?

Brands — from a systems perspective, you do weird stuff.

All of you. No exceptions.

Every brand does something idiosyncratic which will give their prospective new system supplier(s) something to think about.

Here are some real-life examples & why they were a challenge:

1. Category: extremely high data volumes, especially if surge-y.

   1. Example: a brand does 100k orders in under an hour on BFCM.

   2. Why it’s a challenge: because a lot of retail systems still don’t ‘auto-scale’. They have infrastructural limits. Sudden, large volumes of data might result in slowness, timeouts, even outages.
      

2. Category: complex fulfilment requirements.

   1. Example: a brand has 3 fulfilment centres: one in the US, one in Europe, one in the UK.
      
      They also have 8 Shopify stores serving different purposes.
      
      The brand wants their systems to be smart enough to direct all orders for European countries, regardless which site they are placed on, to the EU 3PL, all North American orders to the US and all UK orders to the UK.
      
      But, it also wants a secondary layer of logic which allows certain orders to be fulfilled partly from one fulfilment centre and partly from another if the items ordered by a customer are not in stock in their closest fulfilment location. Follow that?

   2. Why it’s a challenge: SO many scenarios to account for.
      
      An order placed on a German site, well you send to the EUR 3PL, right?
      
      Oh wait, it’s being shipped to the US for some reason, so let’s fulfil from there.
      
      But, ah… it’s a multi-line order and 1 line is out of stock in the US, so we’ll fulfil that line from the EU.
      
      So now one of our systems needs to split that order into 2.
      
      So now I have 2 order numbers, will my ERP allow 2 orders with the same order number?
      
      OK, I’ll prefix one.
      
      But what does that mean for the fulfilment data coming back?
      
      And, returns? Oh god, returns.
      
      Ah FFS the EU is out of stock of that line too!

The action for the brand:

Recognise the things you do which are likely to pose challenges to your proposed new suppliers and put it to them early — in the sales process.

Ask them, how would you handle this? Do you have reference customers we can speak to for whom you’ve handled this before?

If you don’t bring it up, they might not think to. And, if it’s not explored early, the relationship might begin with vulnerabilities which could have been surfaced at the start.

5. Are we thinking far enough ahead?

It’d be like taking a 737 from London to Brighton; by the time you’d got it up and running it’d already be coming down.

There are a lot of variables here.

• What size of brand? (turnover and headcount).
  

• What type of system is involved? (ERP? WMS? eComm? CRM?).
  

• What is the year-on-year growth forecast? (a brand growing at
  15% will be faced with different technology challenges to one growing at 100% year-on-year).
  

• How far ahead has the brand planned? (if the brand is young, agile and reacting to new trends all of the time, they might not have a 5-year plan to align technology with).

The killer question is, “how often do you really want to re-platform?”

For key systems, a good rule of thumb is “if this new system can’t support us for at least 3–5 years (building in a buffer for type of system — ERP, for example, 5 years and beyond), we are not thinking far enough ahead”.

Why?

Systems take time to properly select, implement, learn, master and start delivering value.

Change them too soon and you won’t realise their value.

It’d be like taking a 737 from London to Brighton; by the time you’d got it up and running it’d already be coming down.