The Business Problem

Every business reaches a point where its systems stop keeping up with its ambitions. Not dramatically, there's rarely a single moment of failure. It happens gradually: a workaround here, a manual process there, a report that takes three days to produce because the data lives in four different places. By the time the problem is visible, it's already expensive.

The project we're describing here started with exactly that kind of pressure. A B2B telecommunications business was operating a portfolio of connectivity services, Dial, DSL, Fibre and Mobile Data, each with its own commercial model, its own billing logic, its own geographic reach and its own customer expectations. Layered on top of that was a reseller channel: third-party businesses who sold those services onward to their own customers and needed the infrastructure to do it, provisioning access, billing data, usage reporting, customer management, all within their own independently managed environments.

The business knew what it was selling. It understood its customers. It had the commercial relationships in place. What it didn't have was a system capable of holding all of that together coherently, one that could manage the full lifecycle of every service, across every customer type, within a structure that reflected how the business actually operated and how revenue actually flowed.

That gap, between commercial intent and operational reality, is where most of the cost, friction and lost opportunity tends to live. It's not unique to telecommunications. Any business managing multiple service lines, multiple customer tiers or multiple commercial models will recognise the dynamic. The systems exist. The products exist. The customers exist. But the connective tissue, the architecture that makes everything work together in a way that supports rather than constrains the business, is missing.

The brief, therefore, wasn't primarily a technology brief. It was a business brief: design a system that encodes the commercial model, reflects the operational reality, and gives every tier of the business, from reseller to end customer to internal finance team, exactly what they need to function.

Technology was the means. Revenue integrity was the objective.

Insight: "Understanding each layer of the customer relationship, internal users, resellers, customers and end users, as distinct, with distinct needs and distinct stakes, was what made it possible to frame the requirement correctly in the first place. You can't design a system around a customer you haven't properly defined."

 

 

Turning Systems into Revenue Architecture

A system can process transactions without supporting a revenue model. The distinction matters more than most businesses realise until the gap becomes painful, in reconciliation effort, in billing errors, in the manual processes that accumulate quietly between what the system does and what the business actually needs.

In this project, the commercial model wasn't simple. Four service types, each with different billing characteristics: Dial carried a flat subscription with no data transfer charge, a deliberate competitive decision. DSL and Mobile Data attracted both subscription and usage-based fees, meaning the system had to capture, process and present usage data accurately, at scale, across a distributed customer base. Fibre operated on its own commercial terms. A single billing engine had to accommodate all of it, coherently, without compromise.

But the more revealing design challenge wasn't the billing complexity itself, it was the question of who the revenue architecture needed to serve. The answer, in a reseller model, is never just the provider.

Resellers are running businesses. They have their own margins to protect, their own customers to invoice, their own need to understand what they're earning and whether the numbers are right. A common approach in the industry was to require resellers to pay full list price, invoice separately for their margin, and wait for a credit or payment in return. The intention is understandable. The consequence is a process that introduces labour for both parties, erodes the reseller's margin before it's even realised, and creates reconciliation overhead that scales badly.

The approach here was different. A multi-tier discount structure, applied directly from the price list, meant that resellers received their margin automatically, without a process to follow and without a claim to make. Revenue flowed cleanly. Errors were rare, but when they occurred, they were visible: the financial reporting available to resellers through the portal gave them the transparency to identify discrepancies without having to request data or wait for a statement.

The same principle extended downward. Resellers were able to input their own sale prices into the console, meaning their customers saw accurate, appropriate pricing, and had the reporting available to check their own invoices independently. The same was true for direct customers throughout the platform. Every tier had the visibility it needed to operate with confidence.

Access to technical configuration was deliberately restricted. Provisioning and service configuration carried direct billing implications, getting those wrong wasn't just an operational problem, it was a financial one. That access was reserved for resellers and internal staff. It wasn't a limitation on the customer experience; it was a protection of the revenue integrity the whole system was designed to support.

The result was a platform where revenue didn't just flow, it was measurable, auditable and appropriately visible at every level of the business structure.

Insight: "We didn't make resellers claim their margin. We built the discount structure so their revenue was automatic. Eliminating that process meant eliminating the labour cost that would have eroded the margin they were earning in the first place."

Insight: "Giving every tier of the business, resellers, customers, end users, the reporting they needed to check their own numbers meant fewer queries, fewer errors escalated upward, and a platform that people trusted."

Designing Around the Customer, Not the Technology

There is a version of every complex system that works, technically. The billing is accurate, the provisioning is reliable, the reporting is correct. And yet the people who use it daily find it difficult, work around it where they can, and quietly erode the efficiency gains it was supposed to deliver. The system works. The customer experience doesn't. They are not the same thing.

This project was built around a deliberate and non-negotiable principle: the complexity of the underlying architecture was our problem to solve, not the customer's problem to navigate.

Consider the practical reality of the end user. An employee of a B2B customer, not a network engineer, not a systems administrator, simply someone who needs to connect to work, might be in their home country on a given Monday and in a different city on a different continent by Wednesday. They need connectivity in both places. They need access to their corporate network in both places. And they need to achieve that without consulting a technical manual, raising a support ticket or calling a helpdesk.

The answer was a unified software client with a design philosophy that reduced every connection decision to its simplest possible form: where are you, what do you need to connect to, and connect. A dropdown populated with the correct local dial numbers for whichever country the user was in, across up to 195 countries, meant that a travelling employee never had to research connection details independently. The system surfaced exactly what they needed, exactly when they needed it. Whether they were connecting via the Dial Access Network, DSL, Mobile Data or Fibre, and whether that connection was to the open internet or to a corporate network via a Secure Internet Gateway, the experience was consistent and familiar.

Single sign-on was a non-negotiable part of that experience. Customers who manage multiple systems, multiple credentials and multiple authentication processes carry a cognitive overhead that accumulates invisibly but consistently. Removing that friction, ensuring that access to the platform, to services and to reporting required a single, trusted authentication, was a design decision made in the customer's interest, not the system's convenience.

Software updates presented a subtler challenge. A connected device on a charged service shouldn't be the prerequisite for keeping the client software current. The infrastructure was designed to allow updates to be delivered and applied without requiring an active, billable connection, a detail that most users would never notice, and that was precisely the point. The best customer experience decisions are the ones the customer never has to think about.

The reseller model added another dimension to this. Resellers provisioning services for their own customers needed confidence that those customers would have an independent, capable experience, one that didn't route every query or problem back through the reseller's support team. Giving end users their own reporting interface, their own visibility of usage and billing, their own ability to verify their invoices, was a design choice that reduced the support burden on resellers while giving end users a level of autonomy and confidence in the service they were receiving.

The hierarchy of the platform, resellers, customers, end users, was reflected not just in the commercial structure but in the experience each layer received. Everyone had what they needed. Nobody had access to what wasn't theirs.

Insight: "The complexity of a multi-country, multi-technology network was our problem to solve, not the customer's problem to navigate. A connect button isn't a simplification of the technology. It's a commitment to the customer."

Insight: "Giving end users their own reporting interface meant resellers spent less time answering billing queries and more time growing their customer base. Good system design reduces the cost of the relationship for everyone in it."

Managing Complexity Without Losing Coherence

A system that handles simple scenarios well is a starting point. The measure of a well-designed platform is what happens at the edges, when the service type is unusual, the customer structure is complex, the geography is unfamiliar, or the user's requirement doesn't fit the standard pattern. That's where poorly designed systems fracture, and where well-designed ones demonstrate their value most clearly.

This platform was built to handle the edges as reliably as the centre.

Four connectivity types, Dial, DSL, Fibre and Mobile Data, each carried meaningfully different technical architectures. DSL could connect users to the open internet or, via BRAS infrastructure using L2TP or IPSec, directly into an MPLS VPN, bypassing the need for a Secure Internet Gateway entirely. Mobile Data services operated through APNs that could be locked down and routed to the internet, to a corporate VPN, or to both simultaneously. Dial services, available across up to 195 countries, required an entirely different provisioning model, temporary, user-initiated connections with no usage-based data charge, but with the same expectation of reliability and the same need for corporate network access where required. Any of these connection types could route through a Secure Internet Gateway for access to corporate WANs. Each combination had implications for provisioning, for billing and for the end user experience.

Getting any single one of those configurations wrong had a direct consequence: a user who couldn't connect, a billing record that didn't reflect the service consumed, or a support query that couldn't be resolved without escalation.

The answer wasn't to simplify the architecture, the architecture existed because the customer requirement demanded it. The answer was to ensure that the complexity was fully understood, fully documented and fully encoded into the systems and processes surrounding it before a single service was provisioned.

That began in pre-sales. A skilled sales engineering function, supported by CPQ tooling built specifically for this environment, meant that solution architecture was determined before the commercial conversation concluded. Every option, every pricing component, every usage charge, every technical dependency was visible and configured at the point of sale. By the time a provisioning engineer touched the console, the design was already complete. By the time the customer connected for the first time, every layer of the system, the remote access platform, the billing engine, the reporting console, was already aligned to their specific configuration.

The reporting infrastructure carried that discipline through to support. Whether a query came through an internal support team or a reseller's helpdesk, the data needed to diagnose and resolve it was available to the right person, at the right level of the hierarchy, without requiring escalation or manual intervention to surface it.

The objective was simple, even if the architecture wasn't: an executive in a hotel room in London or Los Angeles should be able to connect to the office, collect email, use VoIP, or access the open internet, without knowing or caring about any of what made it possible.

Insight: "Complexity in the architecture is the provider's responsibility to manage. The customer's experience of that complexity should be: it works."

Insight: "Pre-sales engineering and CPQ tools meant that by the time a service was provisioned, every decision had already been made correctly. Good implementation starts long before the build."

From Requirement to Reality, Managing the Build

Delivering a system of this complexity isn't primarily a technology problem. It's a management problem, and the way a development process is run determines, as much as anything else, the quality of what it produces.

The development of this platform was deliberately collaborative. Requirements were clear and non-negotiable, they had been defined by the business, by the customer structure, by the commercial model. But how to meet those requirements was treated as an open question, and the team was trusted to answer it. Ideas came from every level: from developers who understood the technical implications of structural decisions, from support staff who understood what broke under pressure, from sales engineers who understood what customers actually needed in the field. That breadth of input produced better decisions than a top-down specification ever could have.

One example illustrates the principle well. The question of how to structure the software for sufficient modularity, critical for a platform that needed to support four connectivity types, multiple customer tiers and ongoing development without becoming brittle, was resolved not by an architect working in isolation, but through structured discussion with the developers themselves. They understood the codebase. They understood the trade-offs. The decision was better for their involvement.

Not every decision produced a perfect outcome. The white-labelling capability, which allowed resellers to present the reporting and end-user interfaces under their own brand, a genuinely valuable commercial feature, required a CMS that was more complex to configure than the rest of the platform. That was a known compromise. The justification was pragmatic: a reseller would configure it once, at onboarding, and again only if they rebranded. The frequency of use didn't warrant the development cost of making it simpler. The team made that call with full awareness of the trade-off, and it was the right call.

Process discipline was equally pragmatic. A hybrid methodology, drawing from both Waterfall and Agile, was adopted not as a philosophical position but because different parts of the team worked differently. Software developers, comfortable with Kanban and iterative delivery, operated within an Agile framework. Finance, engineering and operational teams, more familiar with sequential, milestone-driven planning, worked within a Waterfall structure. The methodology served the team, not the other way around. Delivery was the objective, and the process was shaped to support it.

That flexibility, applied consistently and with clear oversight, meant that a project of significant scope and complexity was delivered without the kind of structural failures that tend to emerge when a single rigid methodology is imposed across a team with genuinely different working patterns.

The lesson, applicable well beyond this project: the best-run builds are the ones where the requirement is fixed, the approach is flexible, and the people doing the work are trusted to contribute to how it gets done.

Insight: "The requirement was fixed. How we met it was a team conversation. The developers who understood the codebase made better structural decisions than any top-down specification would have produced."

​Insight: "We didn't choose between Agile and Waterfall. We used whichever methodology suited the team doing the work. Delivery was the objective, process was the tool, not the rule."