To the title of this post, I was on a tech support call with AT&T/Apple this afternoon. Facing surprising SMS overage charges on my mobile account, I wanted to know if Twitter apps like Tweetie might be using the SMS channel to conduct their transactions. I figured not but the Tweetie site gave me no info.
So I asked the support person, who knew about Twitter (better than AT&T) but not about whether Twitter iPhone apps use SMS. She put me on hold to ask a support specialist. About 15 minutes later she came back with a reasonable response (“they probably don’t use SMS”) and a suggestion to talk to the app vendor.
All this had me thinking about the huge inefficiency at play with the responder trying to locate the specialist, get their attention and time, probably juggling multiple phone lines, to then give me one person’s measured response. I imagined a not-too-distant future where the call responder typed my query into a local Twitter-clone running on the tech support network inside AT&T/Apple. This query would immediately push out to subscribers – some required by their manager to subscribe to all tech support feeds, and others who just want to see the problems customers are encountering. I then imagined that some of these subscribers would run search filters on the messaging stream in order to be alerted to those queries they were most interested in tracking.
So somewhere in the bowels of tech support there’s a guy who is a Twitter power-user, or an engineer who wrote the SMS api’s, or a community developer that helps 3rd parties like Tweetie write iPhone apps… and they get pinged every time a tag of interest comes across the network. They see “iPhone Twitter SMS” and respond with the info. With enough of these transactions the call responder will have an archive of tech support tweets they can search through to see if someone has already responded. Of course, this archive provides another layer of analytic data that can be mined to get more info about the problem areas most often reported to tech support.
This concept isn’t particularly new. Businesses have been trying to do this with IM for years. The difference is that IM only gets you access to one person at a time and you have to think to contact them specifically. Then you get caught up in a conversation when you really just need an answer. The Twitter broadcast model quickly gets your query out to a pool of possible responders. Even more importantly, by subscribing to the posts of others throughout the business (eg sales, dev managers, support, evangelists, brand managers, etc…) employees extend their sensors out to include many more valuable inputs. Once they get beyond a certain size, most businesses inevitably Balkanize into distinct units that gradually build up walls and grow insular. Enterprise Twitter (for lack of a better term) would help dissolve these boundaries. This is especially critical in an age of convergence where even the most diverse businesses are feeling the need to integrate and build interoperability across their portfolios.
Again, enterprise Twitter isn’t a new concept but it’s one that so far seems to have escaped either the demand side of the equation – businesses (I’m constantly amazed by the deep endemic failures of communication within companies), who desperately need better & more efficient forms of internal communication; and the supply side, which remains unable to provide any sort of internal enterprise-grade broadcast messaging solutions.
[Updated: Check out Mike Gotta’s note on Enterprise Version’s of Twitter.]