Basicly, the idea is to offer a fully customisable "automated chat" application that will reduce call center costs and provide an enjoyable customer relations experience to the client. Customers will enter their questions as if they're chatting with a live representative, but the response will be pulled from the database.
Please keep reading...
## Deliverables
Since infinite number of possible questions may be asked, we need to setup an algorithm that İnterprets what is being asked. But we still need some data as to what the possible questions are. Companies will be providing this information. Let's say the company is an online shop that sells electronic items. They will be aiming to reduce the number of calls received by their call center, by offering tracking information, payment information, and customer details. So, the customers will be able to get the answers to the questions such as:
- What is the status of my order?
- Did you ship my package?
- Where's my package right now?
- What is the balance on my account?
- I forgot my account password
- Do you have a digital sound recorder in stock?
...and many more.
So, this question database will be provided by the company, and it will be enhanced by us, so that we can cover those questions in any way they might be asked. (Different wording, or possible typos)
Recognizing those questions is only the beginning, so in order not to leave anything out, we also need to prepare a database of single words, and pick up those words if the user mentions any of them, in case we have not recognized the full sentence. A list of keywords for the previous sample could be:
- item
- product
- shipment
- cost
- price
- membership
- account
Let's say the customer entered a question that did not exist in our "question database". Should any words he/she mentioned exist in our "word database", we'll be telling him/her that we recognized that word, but aren't sure what his/her enquiry exactly is. So we'll be asking the customer to repeat the question in another way, so that it might match one of the questions in our database. In such a case, we also need to process the input by groups of two, or even three-word groups in order to decrease the scope. For example, "ship" and "item" could be grouped together. So, let's say the customer entered "My item shipped?" and this is not a wording that we have forseen, so this sentence doesn't exist in the database. Since we have grouped "ship" and "item" together, by checking that those words exist in that wording, we might clarify the question by asking the customer "Are you wondering if your item is shipped?" So, before checking for the "item" and "ship" words seperately, we have a more powerful estimation of the question, thanks to the grouped words. As soon as we get the answer "yes", we're sure what the customer is asking. The answer "no" will take us to a point where we need to ask the customer to re-ask the question in another way.
So, the group "ship, item" matches with our "guiding question":"Are you wondering if your item is shipped?"
The same way, the group "forgot, password" matches with the guiding question:"Did you forget yor password?". So, even if the customer enters "can you believe that i forgot my password?" we'll guide him/her by the right question, and help him/her. The answer "yes" will also help us realize a new way of asking the question, and we'll save the question "can you believe that i forgot my password?" to enrich our question database. It will be added to the database upon administrator approval.
To sum up, we need to implement the features that will handle following possibilities:
1- Does the question exist in our database? If it does, we'll either be responding with our pre-defined answers, or from the dynamic customer database of the company.
2- Should the question not exist in the database, we'll be checking the existence of our grouped words. Should any of them exist in any order in the question, we'll be responding with the matching "guiding questions". If the answer to the guiding question is "yes", we'll respond accordingly, and save that question for admin approval, for the associated answer. If not, we'll ask the user to re-word the question.
3- Should none of the grouped words match, we'll be checking for single words, and list the user a few questions associated with that single word, to figure out what the user meant. Then, we'll be able to associate that type of wording with that answer.
4- Should none of the single words match, we'll ask the user to re-word the question, or enter some (or one) keyword(s) so that we can take a guess about the question he/she is trying to ask.
Since we'll be serving different companies with different questions, sets of keywords and answers, the application will be fully customizable to meet the expectations of the company to serve their customers.
The front end will be modifiable, too. So there will be options such as "Flash interface", "AJAX chat window", "HTML chat window", etc.
1) Complete and fully-functional working program(s) in executable form as well as complete source code of all work done.
2) Deliverables must be in ready-to-run condition, as follows (depending on the nature of the deliverables):
a) For web sites or other server-side deliverables intended to only ever exist in one place in the Buyer's environment--Deliverables must be installed by the Seller in ready-to-run condition in the Buyer's environment.
b) For all others including desktop software or software the buyer intends to distribute: A software installation package that will install the software in ready-to-run condition on the platform(s) specified in this bid request.
3) All deliverables will be considered "work made for hire" under U.S. Copyright law. Buyer will receive exclusive and complete copyrights to all work purchased. (No GPL, GNU, 3rd party components, etc. unless all copyright ramifications are explained AND AGREED TO by the buyer on the site per the coder's Seller Legal Agreement).
## Platform
PHP, MySQL, possibly AJAX