« Symbian — Its Role in the Mobile Jigsaw | Main | GupShup — ad-funded mobile services done right »

Telco 2.0 Use Case: Trading Hub for the Transport Industry

Telco 2.0 readers will be well aware that we’re very keen on any application that uses telco capabilities to remove friction and inefficiency from the wider world of business - perhaps the fundamental insight in the 2-sided business model is that the telco doesn’t only sell telephone calls as a finished product to end users, but also a much wider range of functions for upstream businesses to integrate into their production process. In terms of economics, these communications-enabled business processes usually exist to reduce transaction costs and thus facilitate trade that would otherwise not happen. Alternatively, they help larger enterprises to overcome their internal diseconomies of scale.

This use case is of the first kind; the telco platform as a trading hub, allowing the many companies that would never be able to build the mass-production IT systems that their bigger competitors use to benefit from increasing returns to scale.

You’d be surprised how significant backloads are for the transport industry and the economy more broadly. At first sight, the economics of a truck route would seem trivially simple; you pay for diesel and wages and capital, collect rates from customers, and costs scale by the mile - right? But it becomes a lot more interesting when you realise that the profitability of a marginal load is highly dependent on whether it is carried on the way out or back; as the truck has to come back anyway, the costs of both trips must be accounted for in the price of the trip out, so the margin on the trip back can be 100%.

backload1.png

This can have profound consequences - the phenomenon of fresh fruit and vegetables from eastern Africa showing up in European supermarkets, for example. Airlines providing cargo service to Kenya and other places noticed that the return trip tended to be empty, and unsurprisingly the answer was to drop freight rates dramatically. Any price at all was better than simply shipping air. It therefore became possible to export produce on a large scale, which has become one of these countries’ biggest sources of foreign exchange.

At a more micro level, the problem for an individual firm or owner-driver is finding a backload in the first place. Unless you can arrange it in advance, this is a major source of uncertainty, and one that may grant bigger companies increasing returns to scale - they can afford a monster IT system to track all their vehicles and customers and match them up, and they have more locations, staff, and vehicles out there looking for backloads. They can dedicate salesmen full-time to searching out and buttering up regular backload customers.

backload2.png

The text-book approach to this is to start an exchange; if everyone brings their supply (i.e. trucks looking for loads) and demand (i.e. loads looking for trucks) to the same place, the chances of a good match are dramatically increased for everyone. The more business the exchange does, the better it gets; prices are more stable, the range of deals on offer wider, and you can have greater confidence that you can buy or sell when you need to. Liquidity goes to liquidity. This dynamic is well-known, and can be perceived in stock markets, Internet exchanges, ports, produce markets, Web search engines, and dive bars. It’s interesting that some of the very first commercial exchanges of this kind were for freight - specifically shipping. There’s a good reason why the London freight bourse is called the Baltic Exchange when it trades in shipping to every port on the planet; when it started, that was where the trade went.

Telcos might create such an exchange, have a share in it, or simply be suppliers to it - this will vary between markets and territories, just as it makes sense for an operator to be a bank in Kenya but not in Germany, or it’s possible to make money from MMS in a human-machine application but not in a human-human one.

But doing this raises some big technical challenges, as set out in this slide from the 2-Sided Business Model report.

backload3.png

If you’re Maersk Logistics, these aren’t such big issues. You can afford to build this kind of capability, and you can pay IBM Global Services to do a lot of it (which is what Maersk did). And you’re a big enough customer that your friendly local telco is likely to be receptive to a wholesale deal. If you’re Charlie Cox, not so much. But Telco 2.0 could change this. It’s all about commercialising the core telco assets by making the key capabilities that spring from them available in forms which allow third-party businesses to use them in new ways, right? In this case, we’re using the telco’s secure messaging capability, its location capability, its identity capability, and its payments capability, just as all of these would be used to deliver an SMS message; we’ve just taken apart that finished product and built something new out of the parts, which we can only do if the telco doesn’t supply it in a sealed box.

While we were researching this for the 2-Sided Business Model report, we calculated that improved backload finding could be worth up to £218m a year in the UK, on the basis of a 5% improvement in load factors. So there’s serious money to be had in there. It’s not surprising we also encountered a number of start-up freight exchanges trying to do just that - one of them is even offering an application for Windows Mobile devices in order to mobilise their IT system. That sounds like an ideal partner for a telco.

This is a special case of our general model for the telco future. At the bottom of the stack, telcos own huge legacy assets which we’ve characterised as pipes, packets, and platters. These produce certain functional capabilities that grow out of them - we’ve described those as the seven questions and various other things. Traditionally, these were then combined into a standardised product by telco engineers and commercialised by telco internal marketers direct to end users. In the future, however, we think they will be sold in three ways - as plain APIs for third-party developers, as integrated products created by third parties in partnership with the telcos, and within products the telco offers under its own brand.

telco2vennmodel.png

To share this article easily, please click:

Post a comment

(To prevent spam, all comments need to be approved by the Telco 2.0 team before appearing. Thanks for waiting.)

Telco 2.0 Strategy Report Out Now: Telco Strategy in the Cloud

Subscribe to this blog

To get blog posts delivered to your inbox, enter your email address:


How we respect your privacy

Subscribe via RSS

Telco 2.0™ Email Newsletter

The free Telco 2.0™ newsletter is published every second week. To subscribe, enter your email address:

Telco 2.0™ is produced by: