(Pic: Matt M of Wordpress)
Sometime back we had informed through our site about the Future of Web Apps conference that was taking place in Miami at the end of Feb, 08. Since I couldn’t make it, we’ll have to rely on others about what went on there. Apparently besides beer and beach volleyball, the web gurus did manage to brain storm on that latest killer app.
TechCrunch’s Erick Schonfeld is reporting that he moderated a panel where the premise was to come up with a compelling web app in 40 minutes. A lot of good ideas were thrown up but the popular ones centered around communication, frustrations caused by it, and best ways & means to over come them.
Out of all, my favorite was the one suggested to do something about the support call numbers.
Blaine Cook of Twitter came up with an idea for a software which would call up the companies and put them on hold until a human answered. The software would allow you to enter the configuration details like company name and department, it would press all the right numbers and navigate through the phone tree, and then hold for you until a representative answers from the other side.
Perhaps it could be a two pronged approach in the sense the software at the client side, i.e. your telephone and the software at the server side i.e. the company’s communications center, would initiate the process and hold until humans on both sides are ready to talk, at which point it would ring.
Another widely discussed application was the one Digg’s Kevin rose brought up to help manage the email process. An often heard complaint with the emails is that we just can’t keep up with it all. The new application would keep track of your email statistics and habits such as how many emails you have responded to, what is the average response time, including the chances whether you are going to response at all. In short tell the sender that what ever happens, its not you by the receiver.
As rightly pointed out by Eric, there is not much viability or real service here. How does it help to know that my email is number 300 in the receivers queue and may not get a timely response based on past statistics.
However at least the problem has been identified, even though an optimal solution is not in sight. Yet.
