Chat Application - Web/Desktop

Cancelled Posted Jun 30, 2006 Paid on delivery
Cancelled Paid on delivery

Basic specification details:

This software will be used to provide support to our customers. Will have customer facing web interface, agent side (vb) on desktop, and a seperate admin section.

No frills, client side must be clean, professional, but good looking.

Client Side:

>use a session variable on the customer web side to prevent multiple chats. >>cookie needed here as well.

>use php/html >>simple scripting, but very good looking and easy to customize the interface for client side

>No file transfers, no smilies, just clean professional desgin for client side

>security is a must, must remove all links, scripting, and everything related when enetered by a client

>This will be installed under https

>Client entry screen will have 2 screens(one ad, disclaimer) that are customized via the admin, when the client enters.

>Client entry screen must be customizable via admin to request information before chatting (name, email, acct #, etc)

>Ability to save, print, email transcript of chat at the end of the chat.

Agent side:

>Written in VB, this program will be clean and easy to look at, ergonomic in design

>Will communicated from individual desktops to HTTPS script that manages the data from MySQL and the software.

>Simple text chat with client is required, easy access within the window to all features

>Individual agent should be able to save their own, special chat scripts, up to 400 character limit for sending

>allow sending of http / ftp / www / nntp links

>Needs an accessible API for customer data to allow additional scripting on desktop in the future.

>Needs to accept incoming API arguments for at least 2 distinct variables which will be discussed later. (ticketing)

>Agent must accept the new incoming client chat, agent times out automatically after 30 seconds here, client goes to next agent

>>Once Agent accepts the chat, their greeting is automatically sent into the chat to the client

>Even distribution of incoming client chats to the agents, the queue will be discussed further in the admin section.

>Ability to send a transcript of a chat to a client or supervisor only, no other emails should be accepted here for security of the client.

>Ability to create an email to a supervisor on behalf of the client, this will accommodate supervisor requests in the chat queue.

>Show customer IP, browser, OS to agent with customer data they entered.

>Ability for agent to 'one click' ping the client IP from the chat server and not the agent's workstation.

>Chat time display for agent to track time elapsed from start to end. Timer should stop when the chat is done and they can close the window after.

>Agent must be able to accept up to 4 chats at a time in this software>>perhaps a main window and child windows with client chats in them.

>A very small display that shows how many clients are in the chat queue waiting

Admin:

>Client enters chat, enters queue, goes to next available agent

>Agent queue is simple in principal; done by contact order, not just any agent.

>>Queue: the longest waiting agent is the next one who gets the next incoming chat

>>This is to ensure a fair distribution of chats, and must be fully logged and have reports to show who was waiting/how long/chats/times/etc.

>When client enters the queue, they should be given a timestamp (to them) to show that they entered the queue successfully.

>Admin area needs to be thorough so every detail can be customized easily, client side banner, ad, disclaimer, special text

>Easy to create agents, reset agent password, set details such as (id,showname, lname,passphrase(md5))

>Agent id is created in a different system and will be manually entered here, it is a distinct value and should be checked for that.

>>Easy to enable/disable an Agent login for the chat system to allow for vacation, etc.

>Auto save EVERY transcript of EVERY chat with clear identifiers. Must be saved in a format to avoid script executions when loaded and displayed.

>Extensive reporting is required:

>>Agent, time available, time chatting, average chat times by agent, number of chats in a defined time (enter times/dates)

>>System, same reports as agent, but add load, daily 24hr, peak hour, lowest hour, busiest 4 hour period, total chats,

>>>total chats by agent

>>Transcript lookups by client, agent, time of day / date, email address or other identifiers (should remain flexible).

>Easy, semi-automated script to export transcripts and reporting data to files for use on a different system/archive

>>and the data should be cleaned (wiped) from the live database to keep it healthy and avoid bloating.

>Way to block incoming users by IP, name, email address or other criteria as needed

>>Must be easy to manage blocked clients

>There must be a way via the admin to 'open' and 'close' the chat queue. This system will be designed specifically with this

>>in mind because it will not run 24 hours/day at first, but will in the future. When an admin closes the chat queue, all agents will not

>>be booted, nor will current chats >>other chats in queue will be directed upon their next refresh to create send an email instead

>>Once the queue is closed, all queued chats and new incoming (to the queue) will be redirected to an email form

>>Once the queue is closed, no Agents should be able to log into the system, only the Admin area should allow logins now.

>Chat time tracking is very important >>from the time the client enters the queue until the chat is closed, not closed windows

>>Perhaps use an 'End Chat' button on both client and agent windows for this.

>Provide departmental canned responses, like Agent responses, but will contain up to 1000 characters and accessible to all in that dept.

Additional Features: (Not Required)

>If there is anything else you would consider important to a client / business chat software program, then please do forward that and we will discuss it.

*Ability to have multiple chat queues, and assign agents to a queue

>Have a supervisor queue that agents can transfer a client into

>Queue would be tracked on the web server

>Incoming chats must obtain much customer info such as reverse lookups, name, phone/email, etc.

>Will need to meet ALL specs in above sections.

- - - - -

Target Date: 40 days, Starting last week of July 2006.

Target Budget: Justify budget in your RFQ Response.

- - - - -

Quotes meeting the following criteria will be considered:

1. Well formatted RFQ response.

2. Excellent English, grammar, and spelling.

3. Detailed plan of how you will execute your goals.

4. You have provided verifiable work experience in your RFQ resonse.

Please note that the price / time guideline as listed in this RFQ is flexible. If you have a different target date and cost, list it in your response.

We look forward to seeing your bids!

PHP Visual Basic

Project ID: #70868

About the project

11 proposals Remote project Active Jul 8, 2006