Transactions: telcos’ future in one word
As well as customer data, a huge theme at the last Telco 2.0 event was transactions. So many of the delegates were interested in how telcos can facilitate them, earn money from them, bill for them, secure them, authenticate them… we’ve said in the past that the future of value added services, at least, is in creating a huge transaction processing platform. For the first time, we had an excellent practical example.
Amazon.com CTO Werner Vogels’ presentation was an inspiring example of just what can be achieved by understanding both transaction processing, and the business model you need to generate the transactions.
Recap: Economics of Telco 2.0
To begin with, let’s go back to some Telco 2.0 economics. We often talk about “trading hubs”. This can sound like empty business school jargon. But they are real, and they have some well-characterised properties. Specifically, they emerge in markets which exhibit high transaction costs, usually due to asymmetric information. And they tend to show increasing returns to scale.
Our standard examples are stock exchanges, which exist because otherwise, the cost of trading stocks would be very high indeed. (Imagine trying to find another individual to buy your shares in company X without one.) Further, asymmetric information would make it very risky to trade in securities at all; without an exchange, you’d be forced to accept whatever price a buyer you found offered. There would be a very good chance of getting ripped off. But if you could go to any one of many other brokers, there would be little point in trying to buy or sell at a price very different to that prevailing. That given, it turns out that the exchange works better the more people use it; liquidity goes to liquidity.
Increasing returns mean there is no going back
Another standard example is a container port; since containerisation at the end of the 1960s, more and more of world trade has moved through a small set of very large ports known as load centres. These emerged because the new and extremely expensive ships had to go where there was enough trade to fill their capacity. If there was more traffic in Rotterdam than Felixstowe, that would be where the ships went, and therefore anyone wanting to ship goods would get more choice of routes and times and better rates there. So the volume of trade there would grow, and that in itself attracted more ships. A very similar process occurred with the emergence of Internet exchange points at the end of the 1990s.
These principles are astonishingly powerful; one of their most important consequences is that transient changes at the right moment can have dramatic long-term impact. Paul Krugman won the Nobel prize for economics for applying them to international trade and economic geography. New York, for example, was a port not much bigger than Boston or indeed any of the other ports of New England until the construction of the Erie Canal. The canal was only used seriously for a few years, but it immediately made New York the leading port of the Northeastern U.S., which also made it the industrial centre of the region. As soon as the railway was built, traffic on the canal fell away - but because of the canal, the railway was built to New York, and the rest we all know. Activity attracts activity, in a self-similar process of growth.
In our own industry, there are no shortage of examples of this — there is, after all, only one Google, only one iTunes, and only one Amazon.com. Similarly, the US only had one AT&T before the government decided that was one too many; since then, however, the RBOCs have been doing their level best to return to the days of one Ma Bell.
Amazon - building a giant platform
Amazon.com is founded on a very similar insight. Vogels describes the two main drivers of the business as selection and low prices (selection here might be better put as “choice” or “range”). By offering much more selection — aiming to be the world’s biggest catalogue — Amazon makes it much more likely that transactions will occur. This attracts customers, which further fuels the process.
Egad! A flywheel with two sides!
But the crucial step was becoming two-sided — inviting other merchants to sell through Amazon. They were attracted by access to Amazon’s customer base and IT systems, Amazon by further additions to its selection of goods. Similarly, other merchants can also sell products from Amazon’s catalogue through their own Web sites, still using the same infrastructure. And until a transaction actually occurs, it’s free. It’s also free, both to Amazon and to the affiliate, to link to books (or anything else) on Amazon.com; but when a transaction happens and someone buys it, the affiliate makes a small but significant percentage. It pays to send Amazon more traffic.This “flywheel” drives growth in the volume of transactions; scale and operational excellence drives cost saving and hence low prices.
The upshot is not only Amazon’s success, but the fact that now there really isn’t much point competing with them directly, just as building a new container port next door to Singapore would be insane. Other major retailers — Marks & Spencer, to take an iconic and large example — now use Amazon’s IT systems to run their own businesses. (As a result, although not one cash register exists within Amazon, its software and business processes have to provide for them.)
This further suggests that telcos have to get cracking, before someone else cracks it and closes the opportunity off for ever. You can be certain that Amazon, Google, or someone we’ve never even heard of yet, will move faster than a telco industry standardisation group; you can be certain that four to six different and incompatible transaction platforms in each market will be a disaster.
The good news, however, is that we do have a historical example of how to build a huge platform business collaboratively - the major inter-bank consortia that operate card payments systems. Visa and Mastercard’s internal pricing is specifically designed so that it benefited each bank who joined and each merchant who accepted the cards, whilst also subsidising the issue of cards in order to maximise the customer base.
The LINK network of ATM operators in Britain originated with the UK’s small mutually-owned banks (called “building societies”). As their competitors, the national commercial banks (the clearing banks, in British parlance), installed more and more ATMs hoping to achieve nationwide coverage, the building societies were faced with a serious problem. As (mostly) small local institutions no one society could hope to offer national card service, and it could be expected that the clearing banks would exact a high price to let a small competitor use their system. However, precisely because their territories rarely overlapped, a society that joined LINK hugely increased its coverage at once. More members meant more value, and also helped spread the costs of the shared infrastructure. Eventually, it was the clearing banks who had to swallow their pride and join LINK.
LINK is also an interesting case study because it demonstrates that platforms behave differently in terms of competition law than almost anything else. It could be argued that the societies were illegally agreeing not to compete; it could also be argued that they were cross-subsidising ATM service to end users and therefore competing unfairly with the clearing banks. And in fact it was, as the banks made a last-ditch attempt to make LINK impose charges on users. But even if LINK was anticompetitive, the result was that any British card holder could use any British ATM without paying a fee, and you try arguing that’s against the public interest.
And, of course, there’s GSM roaming.
Your IT architecture is who you are
Another interesting feature of Vogels’ presentation was the way some principles of IT architecture pervade the company. In a sense, Amazon is the data model which describes its giant catalogue, customer base, and partner relationships. Its business strategy is based on creating as many ways of perceiving and interacting with this model as possible. Geeks call this a REST architecture (here’s an article specifically about REST and Amazon), or a Model-View-Controller system, depending on which kind and generation of geek you’re talking to. What they mean is that the core model is strictly separated from the ways its content is represented, added to, and interacted with. The aim is to make it as reusable and adaptable as possible, so it can be integrated with other systems, remixed to suit the user, given different user-interface skins. Exhibitor Infonova has built a next-gen BSS infrastructure around this “white label wholesale” model.
Can your telco change its skin?
Can people do this with your company? In essence, a telco is a big pile of CDRs and certain specific technical capabilities, which we either address through e164 telephone numbers or not at all. The aim of Telco 2.0, it is becoming increasingly clear, is to create as many ways as possible to interact with these core assets, so that as many transactions as possible happen, on which the telco can collect what Matt Bross of BT Innovate described as a “thin layer of value”.
However, it’s worth remembering that even if the layer of value is thin in terms of the user’s margin, it’s pretty thick in terms of the telco’s margin — the activity on the network that results is like HLR traffic rather than (say) streaming video, so the marginal cost of a transaction is extremely low. Like SMS, the margin for the telco could actually be very high. Using Turkcell’s Mobile Signature as a guide, we estimated that the total VAS opportunity worked out to 103,000 transactions a second across the world. The two questions you need to answer are “How can I maximise my share of those transactions?” and “How can I reduce the marginal cost of a transaction?”
Conclusion: customer intimacy through operational excellence
Platform businesses are a fine example of the first fundamental strategy — operational excellence. The product of a trading hub is usually very close to the homeogenous product of classical economics; trading stocks is very much the same in Frankfurt or Amsterdam. But unlike the classical economist’s world, rather than many equals competing, the effects of increasing returns to scale result in an oligopoly. Among the oligopolists, then, there is essentially no scope for the second fundamental strategy — new product. Pricing is restricted by oligopolistic price stability, and is anyway entirely dependent on operational excellence to cut the underlying costs.
Customer intimacy is deliberately abstracted out of the transaction platform: we’re leaving it to people who really know their customer to generate the transactions, and providing them with the tools. Note that Amazon.com works internally to build its customer relationships, but also provides the same tools to other parties. This means that not only do the upstream customers — merchants in Amazonspeak — benefit from Amazon’s knowledge of its customers, but Amazon benefits from the merchants’ superior closeness to their own customers.
Similarly, future Telco 2.0 carriers’ capabilities will be available to their upstream customers, using their intimacy with customers to generate transactions, to their own internal service developers and marketers, using the telco’s data assets to generate traffic for its own account, and also to upstream customers who want to use the telco’s customer intimacy to generate transactions in their own businesses.
In this way, a crucial paradox is resolved. How can you have “customer intimacy” with telco-sized customer bases? The answer is simply that it grows out of operational excellence. And Amazon is the quintessential operational excellence company.
Comments
You guys have nailed this one! In the past 18 months we began exposing our infrastructure for Transaction Processing & the response has been amazing. The costs & resources that are needed to develop such a solution are not insignificant & as a result companies are finding it much easier to rely on Transaction Processing engines such as NetworkIP's. Just as we did with our telephony platform, we developed a simple to use web services API to access our Transaction Processing engine, this made it even easier for customers to run their products & manage their accounts without having to invest in any infrastructure costs of their own.
Posted by: Brian Kirk | November 25, 2008 2:41 AM
Wonderful, Brian. Can you tell us more about how the telcos make new revenues from what you're doing?
Posted by: Simon Torrance | November 26, 2008 6:55 PM
Great article.
Posted and linked here:
http://www.jonathanmacdonald.com/?p=2264
Posted by: jMac | November 27, 2008 2:21 PM
Great explanation of the Telco 2.0 aspects of the Amazon model. Amazon have been at this for a over a decade now. It takes time to spin up a flywheel - even in the world of e-commerce. It seems that one challenge the telcos have with this transactional flywheel is that they don't do transactions. Their business model is subscription based for the most part in the world of data - they are converging on selling all you can eat Broadband access subscriptions. Even in the mobile world bundles of subscriber options are now sold e.g. 500 free SMSs 400 minutes of voice etc. How do you see Telco's developing a transactional process to spin up the flywheel? Where are the Erie Canals for the Telco's? Is there only one? Or doesn't it matter as long as there is one Telco who finds one Erie Canal? Would that Telco then rule the world with an ever accelerating flywheel? There seems to be room for only one Amazon - would there be room for only one New York'ed Telco?
Posted by: John Woodget | November 27, 2008 5:07 PM
We think that it will be very important for telcos to cooperate in order to build scale; if the platform remains balkanised, there are fairly tough natural limits. VISA, LINK, and GSM roaming hubs are examples of how operators could cooperate to provide interoperability on the platform.
As far as getting from here to there goes, well...the first step is to identify the key processes, then repackage them as modular APIs, and then seek upstream partners to commercialise them. It will be crucial to ensure that actually making money from this is part of the core data model, not the outer layers of middleware and presentation.
We're about to begin work on a report on just this question.
Posted by: Alexander Harrowell | December 17, 2008 11:12 AM