What a Good Ecommerce Partnership Actually Looks Like

Almost every broken relationship I come across traces back to failure in one of a few places.

A B2B ecommerce platform isn't a website. It's the system your sales team quotes from, your finance team reconciles against, and your customers use to decide whether ordering from you is easier or harder than ordering from a competitor. When the relationship behind that system breaks down, the cost isn't just frustration. It's stalled growth, manual workarounds multiplying quietly across departments, and eventually a second expensive migration to undo the damage of the first.

None of this tends to arrive as a single, obvious event. It builds slowly, in the ordinary business of running a platform, which is exactly what makes it easy to live with for far longer than it should be tolerated. A support ticket that takes a month to get sorted. A feature request that's been sitting in a backlog for a year. A team that's quietly gone back to spreadsheets for many parts of the process. Individually, none of that looks like a crisis. Together, over a couple of years, it adds up to a relationship that's costing far more than the invoice suggests.

Overcomplicating the problem you're trying to solve

This happens more than the industry likes to admit, because proper discovery is slow and unglamorous, and it's much easier for an agency to say yes to whatever's in the brief than to spend three weeks asking why the brief looks the way it does. So a business with genuinely complex pricing and customer-specific requirements gets sold a simplified, off-the-shelf platform because it looks like the safer, easier option, and ends up forcing its own operations into a rigid template built for a different kind of business, rather than a platform that could have been configured and made flexible enough to fit around it. Eighteen months later, that same complexity has just moved into a spreadsheet, because the platform was never designed to hold it. Or the reverse happens: a business gets a heavily bespoke, over-engineered build for a problem that a well-configured, standard implementation would have solved in a fraction of the time and cost.

The second version is the one that tends to do the most quiet, long-term damage, because it doesn't look like a mistake, it looks like investment. Every new requirement gets scoped as custom development. Every edge case becomes a bespoke workflow. A year or two in, the business has a platform so heavily customised that almost nobody outside the original build team fully understands how it works, upgrades become genuinely risky, and the simplest change requires unpicking a web of one-off logic that was only ever meant to solve one specific problem at the time. That's not a resilient platform. It's a liability dressed up as a bespoke solution, and the bill for it tends to arrive gradually, in the form of every future change costing more than it should.

The hard part is that genuine complexity and manufactured complexity can look identical from the outside. Complex pricing, customer-specific experiences and multi-step approval chains are usually the result of years of commercial decisions that reflect how a business actually competes, and a good partner treats that as a real requirement to be properly supported. The difference is whether that complexity gets absorbed into configuration that the business can eventually manage itself, or whether it gets built as one-off custom code that only the original development team ever really understands. The first turns into capability. The second turns into risk, and it's worth asking, honestly, which one you're currently paying for.

Standing still in a world that never does

New sales channels open up that need their own pricing and fulfilment logic. Customers expect the same self-service convenience they get as consumers, applied to business purchasing. Regulatory and payment requirements shift with little notice. A platform that can't absorb any of that isn't neutral. It's actively falling behind the market a business operates in, every single month it stays the same.

The most familiar version of this: requests get logged, acknowledged, and then quietly parked. The roadmap moves at its own pace, disconnected from what customers are actually asking for. Clients in this position don't usually complain loudly. They just quietly stop asking, and start building workarounds instead, which is a far worse sign than a complaint would be. By the time we hear about it, the workaround has often existed for a year or more, has become "just how it's done," and involves a spreadsheet, a manual export, or a single team member who's quietly become the unofficial fix for a problem the platform was supposed to solve.

There's a more expensive version of the same failure, and it deserves its own mention because it's a pattern I hear about often enough that it can't be dismissed as a one-off. A platform tells a long-standing customer that their current instance is no longer supported. To stay operational, they're offered an upgrade, sometimes priced in the tens of thousands of pounds, and told that on top of that cost, some of the functionality they currently rely on won't carry across. Think about what that actually means. You are being charged, at scale, for the privilege of losing capability you already had and were already paying for. That inverts the entire premise of a long-term platform relationship. Tenure should work in your favour, with more capability and a better fit over time. If tenure instead exposes you to a bill for standing still, or for going backwards, the relationship stopped evolving long before that invoice arrived. It just took an upgrade notice to make the stagnation visible.

Left to figure adoption out on your own

We see this constantly with B2B portals. A portal can be built exactly to spec, look polished in a demo, and still sit almost unused six months after launch, not because it's broken, but because nobody knew how to get the sales team and customers to actually adopt it. Nobody told the sales team it would free them up to spend more time on higher-value leads instead of routine order-taking. Nobody changed the internal processes to actually accommodate a new sales channel. And nobody helped market it to the people who were meant to be using it. Good technology without genuine support behind it just produces a well-built system nobody has been helped to adopt.

Genuine support looks a lot less passive than most people expect. It's proactive training and hands-on help when a new feature ships, not just a release note buried in an email. It's a partner who helps articulate the value of a new capability to the people who have to use it day to day, and who works with a business to get its own internal processes lined up so that value can actually be realised, rather than assuming a good build speaks for itself.

The same gap shows up when something breaks. Two suppliers, an agency running the storefront and a third party managing the ERP, start blaming each other instead of fixing it. Neither wants to own the fault, because owning the fault means owning the cost. The client ends up as the unpaid mediator between two vendors who are supposed to be on the same side, right when they need support most.

What good actually looks like

On the problem itself, a good partner asks about the business before proposing the build. They design for the complexity that genuinely exists, using configuration wherever possible rather than defaulting to bespoke development, and they're willing to say a request is overcomplicating things, even when agreeing to build it would be the easier, more billable answer.

On evolution, the platform gets more capable over time, not less. Upgrades and renewals add to what a business already has. They don't charge for the privilege of keeping it, or strip it away in the process. Requests shape a roadmap that keeps pace with how the business, and the wider B2B landscape, are actually changing.

On support, help doesn't stop at go-live. There's genuine assistance with adoption, not just a manual and a login, and when something breaks, a client gets an answer, not an argument, regardless of how many suppliers or systems sit behind the scenes.

Taken together, this describes a fairly simple idea: the relationship should get easier and more valuable over time, not harder and more expensive. If it's trending the other way, that's not your failure. It's a sign.

Of course, the future won't be about forcing every customer into a portal. The best digital strategies will meet buyers where they already are. Some customers will always love self-service. Others will continue sending purchase orders by email because that's how they've bought for the last twenty years. The goal isn't to change their behaviour overnight. The goal is to digitise the transaction, regardless of how it arrives.

That's exactly why I'm excited about where AI is taking B2B ecommerce. Imagine emailed purchase orders being interpreted, validated and processed automatically through your ecommerce platform, without the customer changing a thing. The buying habit stays the same. The business becomes digital. Less manual processing. Better data. Faster fulfilment. Higher adoption. I think that's where the next generation of B2B ecommerce will be won.

A short self-check

If more than one of those answers is uncomfortable, that's not a verdict on your business. It's information about the relationship you're in, and it's exactly the kind of information that's easiest to see from the outside and hardest to see from within it.

It doesn't have to stay this way

None of that is a life sentence. It's a signal, and a useful one, because it tells you exactly where to look and exactly what to ask for from whoever comes next.

If any part of this has described your own experience, it's time to move on, and have that conversation properly with someone who can actually put it right.