What a pair of lanyards taught us about better processes

Sometimes, you don't have to look very far to spot a problem in a process.

A while ago, we ordered a batch of branded lanyards for Open Commerce. We sent the supplier our logo, explained how we wanted it to look, and placed the order.

When the lanyards arrived, something was off.

Part of the logo was missing. The supplier had decided that one element of the design was too small to reproduce properly and removed it from the final version. The stitching also didn't look the way we had expected.

The technical limitations themselves weren't necessarily the problem. These things can happen when you're producing a physical product.

The problem was that nobody had told us.

There was no message asking whether we wanted to change the logo. We had received proof PDFs before placing the order, and those showed the full logo. We had approved that version, but when the supplier made changes to the design, we weren't given the chance to review or approve them before production started.

We only found out when the finished lanyards arrived.

It might sound like a small thing. And in this case, it was. But it also made us think about something we've seen many times in much larger projects: what happens when a process has checkpoints in place, but still leaves room for decisions to be changed afterwards without involving the person who needs to approve them?

A problem we've seen before

This isn't the first time we've come across this kind of situation.

At Open Commerce, we previously worked with a promotional printing company. Their challenge was obviously very different from ours. They weren't dealing with a logo being changed on a lanyard. They were looking at a much bigger problem involving their e-commerce platform, internal systems and business processes.

But there was a common thread.

The company had an existing monolithic system that had grown over time and was responsible for a wide range of functions, including the webshop, ERP, OMS and CRM. At the same time, different parts of the business had developed their own ways of working, creating bottlenecks and inefficiencies.

The obvious answer might have been to replace the old system as quickly as possible.

Instead, we took a step back.

Understanding the problem before changing the solution

Before deciding what the new technology should look like, Open Commerce worked with the company to understand how the business actually worked.

We brought people from different departments into the process and mapped the current situation. Through workshops, service blueprint mapping and event storming, we looked at what was happening today, where things were getting stuck and what the organization actually needed in the future.

That exercise revealed something important.

Not every problem was a technology problem.

Some issues were caused by the way information moved between teams. Others came from unclear responsibilities or inefficient workflows. By mapping the processes first, the company could see where the real problems were instead of simply trying to build a new system around assumptions.

The lanyards made us think about the same thing

Looking back at our own lanyard experience, the same principle applies.

The supplier had a valid reason for thinking that part of the logo might not work. The stitching may also have required a different approach.

But those decisions shouldn't have been made without us.

The process needed a simple checkpoint:

“We've identified an issue with your design. Here's what we suggest. Are you happy for us to proceed?”

That one step would have changed the entire experience.

Instead of receiving a finished product that didn't quite match what we had ordered, we could have made the decision ourselves.

That's a small example, but the principle scales.

In a larger e-commerce or digital transformation project, the consequences of unclear requirements or missing decision points can be much bigger. A small assumption made early in a project can eventually turn into a significant amount of rework.

Building around real requirements

This is one of the reasons we put so much emphasis on understanding the business before implementing technology.

With the company we've worked with, the workshops resulted in a clearer set of requirements and a better understanding of the gaps between the current and desired processes. This then provided the foundation for designing a more flexible, composable software landscape, with Shopware as the main online sales platform.

The technology was important, but it came after the understanding of the problem.

And that's probably the biggest lesson from both situations.

Whether you're ordering a few hundred lanyards or redesigning an entire e-commerce landscape, the same basic rule applies:

Don't make important decisions on behalf of someone else without giving them the chance to be involved.

Better processes don't always have to be complicated

The solution to the lanyard problem wouldn't have required a huge transformation.

It could have been a simple approval step.

But that doesn't make it less important.

Good processes are often about making the right information available at the right time and making sure the right person can make the decision.

That's what we aimed to achieve with our client as well. By taking the time to understand their processes before deciding on the technology, we were able to identify what the business actually needed and give the organization a foundation it could continue to build on.

Our lanyards were a much smaller example, but they reminded us of the same thing.

Sometimes, the best way to spot a process problem is simply to experience it yourself.

And sometimes, a pair of lanyards is enough to remind you why good communication, clear requirements and the right approval moments matter.