Introduction, When Structure Feels Like Support, Not Constraint

In many businesses, systems design tends to be viewed through a narrow lens, something technical, something handled by IT. It’s often associated with compliance, control, or data integrity, and rarely with more human concepts like communication, teamwork, or shared understanding.

But in our experience, system design, done well, isn’t just about infrastructure. It’s about people. It can be one of the most enabling, unifying forces in a business. It can reinforce trust, reduce unnecessary complexity, and make collaboration across departments feel natural, not forced.

That doesn’t happen because the system is “right” in some abstract way. It happens when the structure is designed with care, clarity, and consistency, and when it reflects the real needs of the people using it. Not just to complete tasks, but to make sense of the business itself.

The article you’re reading isn’t about prescribing the “correct” way to do systems design. It’s not a playbook. There is no one-size-fits-all method, and in our view, good design is about finding what’s right for your business, not following what worked for someone else. It’s about asking: What makes our business easier to navigate, for our staff, our customers, and our partners?

It’s also about creating an environment where people feel supported by the structure, not constrained or controlled by it. Mistakes will happen and systems should be forgiving rather than rigid in their attempts to enforce rules to avoid mistakes. Where the system gives people the confidence to ask questions, take responsibility, and focus on solving problems instead of defending themselves.

In the story that follows, we’ll share one approach we found valuable. It began, not just with a technical need, but with an intention, to create a system that could act as a communications tool as much as a service identifier. The goal was to build something that could carry meaning between systems and between people.

What started as a means to represent service instances, track customers’ accounts and product information and grew into a shared language. A structure that supported not only our operations, but also our culture, relationships, and ability to scale. It wasn’t perfect. But it was consistent, deliberate, and designed with people in mind. And over time, that made all the difference.

 

 

The Golden Thread, A Framework for Clarity in Your Own Business

Every business has its own kind of complexity. Customer journeys are rarely linear, and internal processes often stretch across multiple departments, systems, and responsibilities. Support, billing, CRM, engineering, finance, these functions don’t operate in isolation. Touchpoints between the functions and between the business and customers and partners are many, and often processes overlap and touchpoints between functions are concurrent.

In that kind of environment, it’s easy for things to become disconnected. Data gets duplicated or lost. Responsibilities get blurred. Customers get frustrated. Staff get overwhelmed.

What helped us hold it all together was something deceptively simple: a shared internal structure that acted as a kind of golden thread, a consistent reference that ran through the entire business. A map which at any time could be referenced to know exactly where one was in a process or system. Not just within systems, but between teams. Not just to connect data, but to connect people.

In our case, that structure was made up of three things:

• The Debtors Code, which identified each account or sub-account.
• The Mnemonic, which identified each individual service instance, down to location, product and function.
• The Product Code, which identified the product type, configuration, and commercial packaging.

These weren’t just operational tools. Together, they formed a framework that created traceability, structure, and shared understanding at every level. And while this exact structure may not be the right fit for every organization, the rationale behind it is widely applicable.

When you implement a structure like this, especially one that’s consistent across systems and functions, you create a kind of internal map. Staff know where they are and what they’re looking at. Systems know how to talk to each other. Reporting becomes more meaningful. Communication becomes clearer. Fewer things fall between the cracks.

In many cases, it’s possible to retrofit this clarity into existing systems. It takes effort, yes, but the payoff is significant and perpetual. Once the framework is in place, every new system, process, and team has something to anchor to. Over time, that stability becomes one of the most valuable assets in the business. If done well it contributes to customer experience and brand equity.

And crucially, it’s not about rigidity. It’s about navigability. Much like the mythological golden thread that guided Theseus through the labyrinth, a clear structure can guide your teams through overlapping responsibilities and shifting business conditions. It doesn’t force them down a fixed path. It simply gives them a way to find their way through.

 

 

Naming Things Well, The Power of Human-Legible Identifiers

Whether you call them configuration items, assets, or service instances, one thing holds true across all types of organizations: if you can’t see it, name it, and place it, you can’t manage it.

That’s where well-designed identifiers make all the difference. In our business, three identifiers, used everywhere, by everyone, formed the foundation for how we understood what was happening in the business.

• The Debtors Code gave each account a consistent identity. It could represent a parent account or a sub-account, and it was clear, human-readable, and predictable.
• The Mnemonic identified each service instance, whether a data centre rack, a network interface, or an MPLS endpoint, with a short structured code that described its customer, location, and function.
• The Product Code defined the type of service, its commercial model, and how it was billed, provisioned, or supported.

Together, these identifiers made the invisible visible. They allowed staff, whether in engineering, support, finance, or sales, to understand what they were looking at without needing to dig through multiple systems or chase someone down for context.

For example, if someone saw a mnemonic like AND010-mpls-cti-003, they didn’t need a diagram or documentation to know it was the third MPLS instance for customer AND010, located in Cape Town Industrial. A product code linked to it would describe what had been sold, how it should behave, and how it should be billed. And the Debtors Code told them which part of the customer’s organization it belonged to.

This kind of clarity wasn’t just useful internally, it bridged the gap between the business and its customers. Especially for customers with multiple sites, branches, or departments, it allowed us, and them, to trace service details quickly and without ambiguity.

In fact, this structure played a vital role in how we built some of our internal tools and platforms. One example was SLAM, our Service Level Agreement Manager, a SaaS platform that allowed customers to monitor, review, and query SLA performance. It worked because every service instance was clearly defined, named, and associated with a location. Without that, SLAM wouldn’t have been feasible.

And this idea isn’t limited to telecoms or ISPs. Any business with:

• Recurring services,
• Distributed infrastructure or customer bases,
• Complex relationships between customers, teams, or sites

…can benefit from a naming structure that turns complexity into clarity.

When you give names meaning, and make that meaning consistent, people don’t just understand the system, they understand the business. And that understanding is the first step toward better decisions, smoother handovers, and stronger customer relationships. It becomes part of the lingua franca, part of the sense of belonging, a shorthand that everybody speaks. 

 

Triangulation and Traceability, Finding Clarity Through Structure

One of the most powerful effects of a well-structured system is that it enables people to work out where they are, with very little information.

In our design, the identifiers acted like coordinates. A Debtors Code gave you the customer (and often the region). A Mnemonic gave you the service type and location. A Product Code gave you the commercial and technical profile. You could take almost any one of those, and “triangulate” your way to everything else you needed to know.

This structure worked because it was both tight and flexible. For example, we used block allocations of Debtors Codes (e.g., ANDRE010, ANDRE020, etc.) to manage customers that had similar naming roots but needed separate commercial accounts. Mnemonics and Product Codes carried predictable structures, too, letting someone identify a router in Gallo Manor, a VPN in Cape Town, or a set of interface cards with just a glance.

The result? Anyone in the business, support, sales, engineering, operations, could work out exactly what they were looking at, without digging through layers of unrelated data. It also meant that:

• Multi-branch and multi-site customers were easy to support.
• Reporting and reconciliation were reliable and efficient.
• Customer handovers and escalations didn’t need translation layers.

 

A Real-World Example

Imagine a customer calls with a billing question. They’re not sure whether a particular charge is valid, or whether to hold back payment. The call centre agent asks for just two things: the Debtors Code and the Mnemonic.

That’s enough to immediately retrieve:

• The product that’s been sold
• The configuration of that specific service instance
• All historical billing and contract data tied to that service
• The customer’s organizational structure and contact points

If needed, the case could be passed to a debtors clerk, or escalated directly to the relevant product owner, because product codes were mapped internally to the right person. It was fast, accurate, and transparent.

Even better, account managers were looped in automatically. Because the system knew which sales resource owned the account, the manager could reach out proactively, even if the issue had been raised by a technician or junior admin, not the primary buyer. That quick call to say “We’re aware of it and handling it” helped strengthen trust, and often led to follow-up conversations that created new opportunities.

 

Supporting Indirect Channels Too

This same clarity benefited our indirect sales channel. Resellers using our pre-sales resources were able to speak the same language as our internal teams. They could easily collaborate on SLA models, invoicing mechanics, product configurations, everything down to how a service instance would be named or billed.

That shared language made them feel part of the business, not outside it. And in a channel-driven model, that kind of integration is invaluable.

Across all of these scenarios, the lesson was the same:

When systems speak clearly, people work better together.

Whether that’s between departments, across borders, or with partners, the right structure helps everyone find their place in the system and move forward with confidence.

 

 

Scaling Through Complexity, From Federated Structures to Mergers

As businesses grow, they rarely grow in a straight line. Structures change. Markets shift. Teams expand across geographies. And sometimes, entire companies join or merge. What makes these transitions work, or fail, isn’t just the business plan. It’s whether people can make sense of the complexity and continue working effectively through it.

Our organization operated as a federated business. Each business unit owned its own P&L, its own operational decisions, and often its own customer base. That kind of model brings a lot of autonomy, but it also demands clarity.

The structured identifiers we used, Debtors Codes, Mnemonics, and Product Codes, made that clarity possible.

They enabled:

• Transparent sales ownership
• Precise billing and revenue allocation
• Clear segmentation by region, account type, or business unit
• Frictionless support coordination across countries or teams

For example, if a customer in Belgium submitted a ticket for an MPLS endpoint located in South Africa, the call centre agent could instantly identify the service instance, flag the responsible support team, and coordinate with the Network Operations Centre in Johannesburg, all without losing accountability. The customer case stayed local, but resolution became global and seamless.

This also helped resolve one of the most common tension points in sales: territory overlap. With services like international VPNs or multi-branch access, it was often the case that more than one salesperson was involved in a deal, especially across states, provinces, or national borders. The platform made ownership clear. Deal attribution could be split, commissions calculated fairly, and internal friction minimized.

And this clarity scaled all the way up to the most complex transitions: mergers and acquisitions.

We went through seven acquisitions of our own and were acquired three times.

In most of those cases, our systems were adopted by the acquirer. That’s unusual. Typically, the acquired company has to migrate onto the parent company’s platforms. But when our systems were reviewed by integration teams, the reaction was often:

“This is actually better than what we’re using. Let’s switch to this.”

For the people in the acquired business, that made a difference too. M&A can be destabilizing. There’s uncertainty. New offices, unfamiliar teams, changing roles, new expectations. But having a clear, shared system helped people find their feet faster. They could navigate accounts, understand workflows, and build confidence in a world that was otherwise shifting underneath them.

Even when we kept a product from an acquired company, we’d often migrate it onto our systems. Not to impose control, but because the customer experience was better on our platform. The structure gave us a competitive edge, and in a market where differentiation is hard, that mattered.

The system also helped during tough times. When staff reductions happened, it meant the remaining team didn’t drown in chaos. When we scaled up again, it made onboarding smoother and faster. It helped ERP platforms like SAP keep track of commissions and revenue streams. It created structure in the midst of change.

And that’s the bigger lesson:

Structure doesn’t resist change. It absorbs it.

When you design your systems with consistency and clarity in mind, they don’t just scale, they adapt. And they help your people do the same.

 

 

Checks, Balances, and Smart Limitations, Discipline Through Design

One of the strengths of any structured system is its ability to set boundaries that enable good decisions. A well-designed system doesn’t just keep things organized, it prevents mistakes, enforces quality, and promotes responsibility across the board.

Our structure achieved this through simplicity and consistency. Most notably, nothing could be quoted, sold, billed, or configured unless the proper identifiers existed. If a new product didn’t have an approved Product Code, it couldn’t be added to the CPQ tool. It wouldn’t appear in proposals. It wouldn’t be recognized by the billing platform. There was no workaround.

This might sound rigid, but it wasn’t restrictive, it was effective. It created a natural rhythm for product development. When launching something new, one of the earliest steps was defining the Product Code and making sure it was aligned with the business model, support workflow, and technical design. Once added, it was immediately usable, everywhere.

Sales used our in-house CPQ tool, Sales Generator, to build proposals. The moment a product had an approved code, it became quote-ready. No code, no quote. No code, no billing. This wasn’t bureaucracy, it was built-in alignment between product, sales, and finance.

This discipline flowed into every part of the business:

• Engineers couldn’t requisition stock unless it appeared on the approved BoM.
• Picking slips from stores were generated based on product codes, ensuring accurate fulfilment.
• Revenue reporting was precise, because every product had a traceable code that linked back to the sale.
• Mistakes were easier to catch and fix. If revenue looked off, we could pull a product-level report and spot the anomaly immediately.

Even customers benefited. The same product codes appeared on:

• Contracts
• Invoices
• Usage reports
• Graphing dashboards

This consistency built trust. When something didn’t look right, the customer noticed, and so did we. And because everything was standardized, it was easy to diagnose. If a wrong product appeared on an invoice, it wasn’t a mystery, it was usually a data entry error, easy to trace and resolve.

That’s the beauty of thoughtful constraints. They don’t slow the business down. They keep it honest, focused, and resilient, even as things get faster, more complex, or more distributed.

Mistakes will always happen. But with the right structure in place, they don’t turn into chaos. They get spotted early, understood quickly, and resolved without drama.

 

Enabling, Not Enforcing, How Structure Built Culture

When people think about systems, they often picture cold logic and rigid rules. But in the right environment, structure doesn’t restrict culture, it shapes it for the better. When systems are designed to be inclusive, consistent, and easy to understand, they help build a stronger, more connected organization.

That’s what we experienced. Because the same codes, Debtors Codes, Mnemonics, and Product Codes, were used across all departments, it created a shared language. People in sales, support, engineering, finance, product, and marketing didn’t need to “translate” between systems or explain context over and over. They all knew what AND010-mpls-cti-003 meant. They could act on it. Talk about it. Build around it.

This made collaboration faster, smoother, and more confident. New hires could get up to speed quickly. They didn’t have to memorize exceptions or chase tribal knowledge. The structure guided them. They could understand how services were structured, what customers had, and who was responsible, often from just a single line in a system.

That same clarity had an even bigger impact during moments of transition and change.

When we acquired new businesses, or were acquired ourselves, the clarity of our systems helped people settle in faster. Mergers can shake the ground under people. New reporting lines, new colleagues, unfamiliar systems, changed career paths. But when the identifiers made sense, when they reflected real-world logic, people could find their place in the new structure.

Instead of being one more thing to worry about, the system became something to lean on.

Even in integration projects, we found that acquired teams or partners often said the same thing:

“This is actually easier than what we were using. We can work with this.”

This cultural cohesion extended to external partners and resellers as well. Because our systems used human-legible, meaningful identifiers, indirect sales partners could collaborate with our pre-sales engineers and support teams as if they were in the same room. They could discuss product bundles, service locations, invoice mechanics, or SLA expectations using the same language. And in doing so, they became part of the business, not just outsiders trying to interpret it.

Ultimately, the structure didn’t just keep our operations in sync. It created an environment where people could be proactive, confident, and supportive, of each other, of customers, and of the business itself.

Good systems don’t just run things. They reinforce values.

  

Final Thoughts, Designing for People, Not Just Platforms

When we talk about systems design, it’s easy to focus on speed, automation, or cost savings. But the most valuable systems, the ones that keep delivering year after year, are the ones that are built to support people.

The structure we developed wasn’t flashy. It didn’t rely on expensive platforms or cutting-edge frameworks. It was grounded in three simple identifiers, Debtors Codes, Mnemonics, and Product Codes, that were used consistently across the business. That consistency gave us room to grow, to adapt, to weather change, and to collaborate across boundaries.

It helped people make better decisions. It gave teams a shared language. It made onboarding easier, mistakes easier to spot, and customer interactions more confident and connected. It supported our culture just as much as our operations.

Most importantly, it reminded us that systems design isn’t about getting everything “right.” It’s about creating something useful, navigable, and supportive, especially when things are uncertain or complex.

So if you’re building (or rebuilding) your systems, consider this:

• Do your identifiers help people find what they’re looking for?
• Can your teams work across departments without having to interpret each other?
• Can your systems scale as your structure evolves, through growth, restructuring, or acquisition?
• Will a new hire, a reseller, or a partner feel included and informed, or overwhelmed and lost?

If you’re not sure, that’s okay. These are hard problems. But they’re worth solving, because the benefits compound. Every step toward clarity improves collaboration, speed, accountability, and trust.

And you don’t have to do it alone.

If you’d like help figuring out what kind of structure would serve your business best, we’d be happy to explore that with you. Not by telling you the “right” way, but by helping you find the one that fits.