Inspiration
Imagine a world where you are not held up for ages in order to talk with customer support, but one in which you will be called at a time of your choosing, with a real person on the other side of the phone. What a rarity these days! A few days before HackDFW, I had the misfortune of my ever-fickle internet connection showing its hostility towards me and not working precisely the moment I had a huge project due, forcing me to seek the refuge in our school's computer lab. However, the fact the internet was down was not the biggest issue that disconcerted me. It was the fact that I waited four hours (really, four hours!) over the phone in order to talk to somebody who might be able to diagnose my chronic internet issues. Sometimes, my phone disconnected, and other times, something else happened, but after that incident I could not forget the Vivaldi's four seasons that played throughout that time of waiting, waiting, waiting. I was determined to find something that would minimize the chance that this happened to others.
In a survey conducted by Time magazine, 71% of people polled were "tremendously annoyed" when they had to wait in order for customer support over the phone. The same survey brought into attention the fact that 86% of consumers report being put on hold every time they call a business, and that the average person spends 13 hours a year waiting on the phone. What a waste of time! If only somehow this situation can be mitigated...
What it does
Our application (or rather, the set of applications) we created supports scheduling a phone call for the user such that it calls a number on behalf of the user, and removes the usability barrier of asynchronous menu options over the phone. We implemented natural language recognition to further streamline a SMS-based replacement service for these menus. This application has the potential to saves tens of minutes per month, if not hours, of users' time by scheduling and actually making phone calls on behalf of the user, and only calling back to the user (by transferring the call) when an actual customer support representative or human being picks up the phone. Our SMS interface makes menu options more convenient for customers. Over time, user responses map the entire tree of menu options.
How we built it
Cisco's Tropo platform allowed us to automate phone calls and implement question answering. We take pride in getting our phone bot to communicate with another automated phone bot using DTMF. We hosted our Python application on Heroku and pointed Tropo's portal to our root endpoint, which allowed us to implement better architecture with control over our server side. Most of the time was dedicated in optimizing the Heruko server to accept such requests, as well as a artificial intelligence platform to get queries in a semi-automatic way.
Challenges we ran into
We learned that transcribing messages takes non-real-time time, meaning we couldn't transcribe messages and then send users text messages and expect a response at the same time, making us restructure the code that had the prior assumption. We also ran into some trouble in creating the server that would host our software, specifically because of the unfamirilty between the primarily script-oriented platform.
Accomplishments that we're proud of
We are proud that our server really works! We are especially proud of our mapping of NLP SMS to menu-based options.
What we learned
We learned to brainstorm about using an API to solve common problems and develop strong use cases for the product. And while building it, we learned to collaborate over creating several parts of a primarily server-side application.
What's next for Queueless
We may be able to develop it further to support more phone numbers, and advance the AI it uses. We also need to support free entry in automated phone systems, as well as authentication for sensitive information.
Log in or sign up for Devpost to join the conversation.