« Joost: further analysis of a bandwidth hog | Main | LUI Part 4 - The Product Set »
LUI (Leeds Unbundled ISP) - Part II
By jpenston | July 18, 2007 |
|
If you haven’t already done so, read Keith McMahon’s post first, or nothing that follows will make sense!
So here we are, we have a business plan to take over Leeds (or at least 16% of it) with our new LUI offering. What is going to be different about it? For a start, we are not going to use traffic management, caps or fair use policies. If we sell our customer a 20M service, they should be able to get 20M.
You can tell we’re making this up, can’t you…
We now have gigabit links into each exchange and we have migrated our customers across. It took a year and we lost a few percent market share in the process because of downtime issues.
We blamed BT for most of these customers and fortunately most customers believed us. If we were honest though, we would have to say that a lot of the problems were caused on our side by the size of the task, which was much bigger than we expected and just didn’t have enough project management and technical support staff to deal with the enormity of it all. Now that we are up and running, we hope to quickly make back what we lost because our service, now that it is stable, will be first rate.
Without a base to migrate across, the costs would have killed us. Why? Because before we unbundled we had a much greater degree of granularity to our costbase - now, in addition to the huge steps in capital that you have all heard about, we also have huge steps in operating cost. This only made sense because we had well over a thousand customers on each exchange…
In fact, we would be paying less today if we’d taken LES 100 circuits (or 2 x LES 100 circuits in 6 cases) because bandwidth per user has not reached the 75kbps tipping point on a customer base our size that would make it more effective to go with gigabit backhaul yet.
This is the part that a lot of commentators find hard to understand, and even harder to simplify into a soundbyte - with fatter backhaul circuits comes a lower cost per bit, but this has to be counter-balanced by a much lower utilisation factor.
The fill factor depends on the user numbers, which vary wildly by ISP and by exchange and the costs depend on the distance from the exchange to your core network, which also varies wildly by ISP and by exchange. You have to make a lot of assumptions to arrive at a soundbyte which is why they are so easy to pick apart.
The typical modus operandi for an operator is to make aggressive assumptions that give great fill factors at fantastic price points, only to find after the capex is spent, that the amount of money a customer is willing to spend increases by very little (flat revenue), although their expectations are of much higher speeds.
Unbundling is another example of capital expenditure largely justified by a cost-savings business case. The necessary evil of spending more to keep the same recurring revenue coming in is a cycle in telecoms. It starts with a regulatory shift that opens new opportunities, then companies pile in with forward pricing to exploit the new capability only to find everyone else doing the same. The floor falls out of the market and the price war takes everyone back to where they started only with a big financing cost and a capital asset that offers no differential advantage.
LUI is being realistic, we have unbundled not because we expect margins to improve. We have unbundled because were in the market already and we needed to lower the cost per bit so that the cost of servicing a flat revenue profile did not escalate beyond our means as traffic grows. We are going to have to make our margins some way other than by selling capacity, that much we know.
Even with this negativity in the background, it was a slam dunk choosing the new BNS product from BT. Not because it offered us better costs today though. The reason was because we knew we are going to need to capacity tomorrow and beyond and BNS gives us a better cost that a LES/BES or a similar service from NTL, Fibernet, C&W or anyone else.
We are under no illusions, video is being consumed online in increasing volumes. Data from Nielsen/NetRatings shows that there are now nearly 140m viewers of online video, up from just under 60m a year ago. YouTube has managed to grow its share of the market (37% up from 33%) in spite of advances by Yahoo! (11% up from 5%) and AOL (11% share in 2007).
All this will quickly push our capacity requirements skywards and for this reason alone, we need to be prepared. With our network in place, everything between here and about 300kbps per user is effectively free to us as we are just filling up the capacity we have just installed. This is why we are not bothered by customers using line rate - we have the bandwidth, so they might as well use it.
Where we need to be concerned is what happens when that 300kbps tipping point arrives. That sounds like a lot, but it works out as around 25GB during peak hours per user per month. Add in the off peak utilisation and you are probably looking at around 40GB per user per month total. We’d be happy for this 40GB to go up to 50GB or even 60GB as long as it doesn’t affect the 25GB during our busy hours. For this reason we are looking at ways to incentivize overnight usage.
The 300kbps tipping point means a second wave of gigabit circuits and probably beyond that when we reach 600kbps we are looking for 10 gigabit links. I see that Keith has amortised the costs over a 5 year contract, which is probably what most commercial entities would do as it delivers the lowest capex cost (because of discounts) as well as a lower amortised cost (for obvious reasons).
My preference would have been to go for the 3 year contract and amortisation period because personally, I would expect the lifetime of these assets to be something less than 5 years. What lease contracts did you take out five years ago and are you still using whatever it is that you acquired? Or, are the last couple of years sitting on your books not delivering value (or worse, already written off)?
More from Keith shortly…
Copyright The IP Development Network - www.ipdev.net
Phone +44 1763 81 00 20
Email jpenston@ipdev.net
Topics: BT, LUI, next generation networks |