This might be the most complex project ever posted here.
After reading this overview, please let us know if you would like the full 23 page RFP with all of the details. The project will only be awarded to a candidate that has submitted a complete proposal with design, deliverables, and architectual explanations of how the project will be done.
Overview:
NSA is company engaged in the business of receiving chats from our clients websites. We answer the chats with live operators, using pre-designed scripts, and FAQ lists. Up until this point, we have been using a traditional support chat software from a third party where we create a button, send it to the client to paste on their web pages, and we use the client and server software of a third party to answer the chats which are then forwarded to the client. We provide pre-sales lead capture, customer service, and technical support.
At this time, we have determined that we want to develop our own proprietary system. We will name this system chatstaff. We currently have a back office system which tracks all client account information, and each of their services they subscribe to (pre-sales lead capture basic, pre-sales lead capture advanced, basic customer service, advanced customer service, and tech support). The services are also offered in multiple languages. Our back office system is an intranet web application written in python+django with a MySQL datasource. Out system considers each service plan/language a different website (or service the client subscribes to under the clients account). Each site/service/language is billed with a flat monthly fee and a per chat charge.
The new system will store all chat archives, customer info, script info, and chat window configuration info in the existing MySQL database for the back office. The idea is to use openfire 's open source server as the open standards xmpp chat platform, where chat sessions will temporarily be stored until being stored in our database. Openfire allows you create an MySQL for its data storage as well. We will use Jive Forums open source knowledge base to store a copy of script information as an item under a topic, and the FAQ's will be stored using this system as well. An AJAX client will be created for our client web pages to offer a browser based chat client, as well as two Spark (open source) plugins will be created to offer an operator client for our operators to answer chats, and customer version which our customers will use to receive and monitor chats, as well as make modifications to their knowledge base.
Once an account is subscribed from our website, a client account is created in the back office, along with the various websites (service plans, languages) that the client subscribed. Configuration information for each of the websites is also stored in the back office. At this time a topic with the website id must be created in jive forums, with the script and FAQ's for the subscribed website/service/language. The chat button script may be generated from our website or manually using the back office. An AJAX chat client will also need to be create for embedding into the web pages where the button will be placed. When the button is pressed on the client's website, a request is sent to openfire with specific origin information and the website id which identifies where the chat is coming from and how to handle it. A plugin will be created in openfire to handle all incoming chats. When the request is received, openfire will request the window configuration information, routing information, and data regarding how to handle the chat from our back office. Once the requested data is received, open fire will communicate the window configuration, wait message, operator busy wait time and message if any, and answer greeting to the AJAX client along with any other data necessary.
At the same time openfire, which maintains presence of all customer or operator spark clients currently online, will route the chat to first available operator based on the routing information received from the back office. Should none be available, it will place the request in a queue and alert the AJAX client with a operator busy wait message and time, if this feature is enable for this website.
Once the chat session is successfully routed to the customer or operator spark client, a spark plug in which will need to be created to handle multiple incoming sessions separately from internal instant messaging sessions, the plug-in will receive the website information and answer greeting as well as other session details. A tab will be created for the chat session and a browser tab opened. In the browser tab, the topic from jive forums will be called and restricted to the topic for this website id. The default display will be the chat script. As multiple chats enter, multiple chat and browser tabs will open and follow the same functionality. Once the chat is answered, the answer message stored on the customers profile and previously received by openfire will be transmitted to both the spark and AJAX clients.
Chat messages back and forth will then been stored in a temporary record in a table in the openfire MySQL data source along with other session and origin information. All functionality of jive forums will be given in the browser window for the chat session but restricted to the website ID which will be specific topic in Jive Forums.
A plug-in will be created in the operator spark client which will parse the incoming chat text for keywords, and on carriage return, search the jive forums topic of the current website for content related to the keywords. The topics will then be displayed. A feature of the plug-in will be the ability to select content in the browser window, edit it below, and paste it directly to the chat in the pane on the left.
The operator version of the spark client will have this ability however the customer version will not. The customer version will be able to view all chats as they arrive, as well as see the browser tab with the topic for the specific website and have all functionality of jive forums, however the active searching and cut and paste will not be available in the customer version. The script however will default and be displayed for the chat session. Should they customer disable chat forwarding, the routing will be updated in the back office and chat will only begin routing to the customers spark client. Once the spark client is closed or routing is enable, the routing will resume to the default.
Once a session is terminated by the AJAX or Spark client, the end message, which was previously received by openfire, will be send by openfire to the AJAX and Spark clients. The Spark client, based on the service type of the website received at the initiation of the session, will then prompt the chat operator for certain billing information. Once answered the billing information will be sent to openfire and the session terminated. The chat archive, billing information, origin, and other session data will then be stored in the back office and deleted from openfires temporary records.
With the customer Spark client the billing information is not requested, and the chat is terminated, and marked non-billable. However the archive, origin, and session information is copied from open fire in the same fashion and the temporary record deleted.
Openfire's standard features for internal messaging will also be used, but no modifications will be necessary with the exception of enabling authentication based on the user/group tables in our back office.