Telco 2.0 and that doctor's office mashup
O'Reilly's 2007 Emerging Telephony shindig had a contest for telecoms mashups this year, which was won by this application to handle out-of-hours calls to doctors, developed by Thomas Howe, whose work we discussed here.
There is a detailed description here; in short, incoming calls are answered using a VoiceXML IVR server, which then routes each call to one of a group of nurses recruited to assess them through Amazon's Mechanical Turk API, and details are sent by SMS to the doctor, with a confirmation message to the patient.
Rather than needing to monitor phone lines constantly, or manage staff doing the same, the Doc only needs to respond if and when an alert comes in; and their patients get meaningful out-of-hours coverage, rather than the right to leave voicemail that gets processed when someone cares. In the original version, enough trade is aggregated to support a group of part-time workers, and the costs spread among many participants. In essence, it's a homemade version of the UK's NHS Direct.
But what would happen if an actual doctor wants this service, rather than a group of techies at an O'Reilly conference? We drew up four scenarios.
Quite simply nothing; this service doesn't exist. And it's unlikely the carrier will invent it; they almost certainly don't know there is a demand for it. This is probably so across all the competing providers.
Perhaps they opt for either a standalone or hosted/centrex PBX system; it's unlikely, though, as these are expensive and cost money to look after. It's not guaranteed that the package your friendly local telco will sell you can actually offer the functions you need, either - and not many people outside that company have the skills to develop them.
Telco 1.0 with added IMS
If the IMS/NGN dream ever comes alive, the chances improve...a little. Vendors of NGN equipment, not to mention telcos themselves, constantly boast of how it will make it possible to develop and launch new services much faster. But the responsibility for developing them, and the power to do so, remains inside the carrier or at best with a small number of large corporate partners.
There's a chance one of these has come up with something; or perhaps they've all done mobile Facebook. And further, seeing as it's the telco customer care people who have to support all the new services, will our customer ever get through to the call centre?
Out on the Internet...
If our customer is unusually technically clueful, and has the time and money to invest, they might fix their problem themselves. They could set up a (free and open-source) Asterisk VoIP server, and look for (or write) a plugin to provide the function they need. They'll also need to find a SIP termination service and an e164 phone number so their telco-bound customers can reach them; either way, the telco has just lost a customer.
Fortunately, not that many people are Asterisk hackers, and the ones who are can command good money, so this is an unlikely scenario. Although, once somebody gets it working really well, they might start selling their service..
It's looking pretty grim, no?
Over at Telco 2.0, though, the situation is rather different.
Telco 2.0: user-driven innovation as applied to telecoms
Of course, like the NGN operator, Telco 2.0 has plenty of standard APIs reaching out like the tentacles of a squid; but rather than restricting itself to the ideas it has in-house, and taking on the burden of supporting every weird idea its engineers have itself, it's open to external innovation.
Telco 2.0 doesn't restrict the use of those APIs to people it likes; but it does restrict itself from trying to invent everything, perhaps setting an HP-like criterion of "fascinating margins" for the ones it will develop itself (or take over). The task of scanning through the solution space is left to anyone with an idea.
And it considers external innovation a line of business in itself; so its commercial terms are part of the package, as much part of the API as the remote procedure calls to look up a subscriber in the HLR. The matching half of this is that the API necessarily includes a payments interface that works -much faster than dire pSMS. Therefore, there's a far better chance that there is already a product that suits our Doc, and the overhead he or she faces in fixing it themselves is dramatically smaller.
Because it's a telco product, naturally, it can use the existing identity attached to telephone numbers as well as any other, and it interconnects with old-fashioned PSTN or GSM, NGN, and the Internet. And the Doc can pay through their bill.
It's just a pity nobody does this yet. Telco 2.0 visited this week's Mashup Event Demo in London. There were not a few charlatans around; the classic sign of a boom sector. But there was good stuff, too. We spoke to Andrew Scott of geographical social network Rummble. He reckons the mobile version will probably rely on GPS-enabled phones for its location functions, "because it's just too expensive to do triangulation, and they [the telcos] are so difficult to deal with."
Asked if he'd use a telecoms API if it existed, Scott thought he definitely would; as long as it doesn't cost too much. Rummble runs on an all-Java platform; which makes it a close fit for jNetX, come to think of it.