Standard, Tiered, Burstable, and Metered (STBM)
The Importance of Learning from Failure
Many of us hesitate to discuss our failures, but the reality is that we all experience them. Understanding why we fail—especially when we genuinely strive for success—can be invaluable in preventing similar mistakes in the future.
Today, I want to examine the "Standard, Tiered, Burstable, and Metered" (STBM) internet connectivity products—why they had the potential to be a great addition to an Internet Service Provider’s (ISP) portfolio, and ultimately, why they failed.
The Context: Expensive Bandwidth
At the time of this project, internet bandwidth was a costly resource. While cost efficiency is always desirable, it was far more critical back then than it is today. Unlike now, having unused bandwidth was a significant financial burden.
The core idea behind STBM was to offer customers a flexible way to purchase bandwidth that adapted to their changing needs over time. This flexibility could have given ISPs a competitive edge over those offering rigid, one-size-fits-all plans.
How STBM Was Designed to Work
The product range was built on the premise that businesses often experience fluctuating bandwidth needs. For example, at the end of each month, a company may require significantly more bandwidth than during the rest of the month. A business sending out electronic invoices, for instance, would see a surge in bandwidth usage at month-end and the beginning of the new month.
STBM aimed to let businesses access bandwidth as needed while keeping costs predictable and manageable. The four components of STBM were:
- Standard – A customer purchases a fixed amount of bandwidth (e.g., 100 Mbps) and pays for it as a guaranteed allocation. This means the customer can use 100 Mbps every second for the entire billing period (typically a month, equating to approximately 2.59 million seconds). This is a traditional model with no variability in cost or usage.
- Tiered – This option provided more flexibility. A larger capacity link (e.g., 200 Mbps) would be installed, allowing customers to exceed their base allocation. The additional capacity was divided into pre-agreed tiers (e.g., 101 Mbps, 102 Mbps, etc.), and the customer would be billed based on the highest tier they reached during the month. Even if they exceeded 100 Mbps for only a few minutes, they would be charged for the highest tier they touched for the entire billing period.
- Burstable – Similar to Tiered but more cost-efficient for unpredictable usage. Customers would still have a 200 Mbps link installed, but instead of paying for a full additional tier, they would be billed only for the actual extra bandwidth used, and only when it was used, at a premium rate. This was ideal for businesses with occasional surges in traffic.
- Metered – A fully usage-based model, where all bandwidth consumption was tracked and billed at a premium rate. This was the most flexible but also the most expensive option.
Customers could switch between these models at the end of each billing cycle, allowing them to refine their bandwidth plan over time to balance technical requirements with cost efficiency.
A Real-World Use Case
Consider a nationwide gym chain with over a million customers. At the end of each month, it sends electronic statements and invoices. Occasionally, it also runs promotional campaigns in the first week of the month. Initially, the gym might opt for the Metered plan to understand its actual bandwidth needs. Once it had a clearer picture, it could switch to Tiered or Burstable to reduce costs while still accommodating peak usage. Eventually, it could settle on the Standard plan that best fits its ongoing requirements.
Additionally, seasonal variations could play a role—December might require more bandwidth than February. The flexibility of STBM meant the gym could adjust its service to align with these fluctuations.
A Well-Designed Product with a Strong Value Proposition
The STBM model was smart—it allowed ISPs to generate revenue while empowering customers to fine-tune their services. The sales team loved it because the pitch was simple: "Our pricing is competitive, proportional to your needs, and fully adaptable."
However, pricing alone wasn’t the problem. The failure came from internal disagreements within the technical teams.
The Challenge: Measuring Bandwidth Usage
The key challenge was how to measure bandwidth usage accurately and fairly. If you've ever seen a bandwidth usage graph, you might assume usage is relatively smooth, with predictable peaks and valleys. In reality, usage fluctuates wildly from second to second. The graphs we see are often five-minute averages, which hide these fluctuations.
Since billing relied on accurate measurement, we needed a system that could fairly account for usage. The solution was to apply a 95th percentile calculation, which excluded the top 5% of peak usage moments to prevent extreme spikes from unfairly inflating costs. Customers could see the calculations and would generally agree that this method was fairer than alternatives.
The Internal Dispute That Killed the Project
Despite having a clear, fair approach, we ran into resistance from the technical and billing teams:
- The network engineering team insisted on using NetFlow data for measurement, arguing it was the most precise.
- The OSS/BSS (billing systems) team preferred SNMP polling, as it generated far less data and was manageable within the two-hour processing window at the end of each billing cycle.
Both methods were predictably inaccurate but equally workable, as mathematical adjustments could compensate for discrepancies. Unfortunately, neither team would compromise, leading to a deadlock. Without an agreed-upon measurement method, the product could not be deployed.
What Could Have Been Done Differently?
The failure wasn’t technical—it was a failure of communication and internal alignment. The technical and billing teams were both right in their concerns, but they couldn’t see that it ultimately didn’t matter which method was used.
If we had anticipated these disagreements, early communication and alignment could have prevented the impasse. Instead, the project stalled because two internal teams refused to budge.
A Missed Opportunity
Although bandwidth costs have since dropped, STBM would still be a valuable offering today. The ability to tell customers:
- "We understand your business better than anyone else."
- "Our service adapts dynamically to your exact needs."
- "You get the most value for your money, tailored precisely to your usage patterns."
...would still be a strong market differentiator.
The Takeaway
One of the biggest lessons from this failure is the importance of predicting potential roadblocks and ensuring clear communication from the outset. If internal teams had been aligned on the key focus points from the beginning, STBM could have been a successful and revolutionary product.
While this project ultimately failed, the underlying concept remains powerful: flexibility, fairness, and cost efficiency will always be compelling selling points in any industry.