Project Detail

Description

I require a telephone message manager application (primarily Inbound) that will require the following (preferences only, will consider options).

1. PHP (or equivalent)-based app. with screens to enter Subjects, Supervisors, and Reports. Will consider programming languages other than PHP.
2. Freeswitch scripting or other open source that will work with a SIP provider
3. MS SQL (Express)
4. Software solution only, I do not want any special telephony hardware – needs to work from a desktop/server
5. XP/Vista
6. Open source Test To Speech engine.

Open source approach preferred to control costs.
Summary:
1. It is expected that this app will involve PHP for a web-based solution, plus SQL (Express preferred) and Freeswitch (open source telephony). This is a phone-based solution which shall be accessed and configured by a web-based application.
2. The app is designed to accept calls from Callers (who report to Supervisors) who will call a toll-free number (plan is to use a SIP service, so app must not involve any special telephony hardware). App must work in Canada, and will eventually reside on a hosted sever, but for development and testing purposes, it will be acceptable to write code that can be executed from installation on a local machine (intranet).
3. App will be managed by 1-6 Operators and 1-2 Admins.
4. Caller will call in, and app will use a 2-step process to ‘identify’ the Caller:
a. App will read and collect ANI info from the originating phone line used by Caller, and;
b. App will accept a 7-digit number keyed in by Caller
5. For Caller data, input screen will allow for entering tombstone and other data associated with Caller.
6. App will also manage a System ID number (SID). App must be allow Operator or Admin to enter a SID of their own choosing to see if it already exists in the database *or*, if desired, the app must generate a pseudo- random number which will be assigned to Caller for duration of his enrolment in system as the System ID number (SID). The function of generating, storing, and controlling random numbers for use with the App needs to be carefully coded:
a. Do not want duplicate SIDs.
b. The Caller’s SID will be a unique ID number given to the Caller, which the Caller will have on his person when making inbound calls.
c. When a Caller’s enrolment in the system is terminated, the SID assigned must be ‘freed up’ by the app and made available for another future Caller.
d. Usually, Caller will be calling from phones where ANI information is available, and the App will play a greeting wav file, and may also play a special message, then prompt the Caller to enter the 4-digit SID number assigned. The App will compare what the Caller entered against the SID in the system’s database for the Caller.
i. When the Caller enters a recognized SID number, the app will process as a non-exception:
1. App will prompt Caller to choose one of up to 9 options using touch tone phone.
2. After the selection, the app will prompt Caller to record one or more brief messages, which will be stored as wav files, or perform other simple functions (e.g., transfer to another person)
3. After the recording, the app will prompt Caller to make any other choice, or press * to terminate the call.
4. The app will generate an automatic email to the Supervisor assigned to the Caller, based on the SID. The email will contain the text of the prompts, the key pressed by the Caller and all the wav files as attachments.
ii. When the Caller does not enter a recognized SID number, the app will prompt for the ID a second time. After a second failed attempt, the app will process as an exception and follow the “Exception Process” described below.
iii. The app must provide the ability to print off (from within the app itself) *and email* to a designated recipient (default=Supervisor) a one-page summary that the Operator would hand to the Caller at Enrolment and show:
1. The name of the service
2. The inbound toll-free number for Caller to use
3. Instructions to follow, prompts to expect
4. The Caller’s SID Number to be used by the Caller
5. The Caller’s primary phone number registered in the system
7. In some cases, the Caller will not enter the correct SID, even after a second opportunity (which the app must allow). In this case the app will manage as an Exception. The Exception Process will be as follows:
a. App will play a wav file, indicate “We cannot find your record, please hang up and try again with the correct System ID number. Good-bye.
b. The app will store the call details for later retrieval as needed.
8. The app must include an open-source Text To Speech engine which will be used to playback to Caller digits that he will enter during the inbound call.
9. Prompts that Callers will hear from the app will be mostly pre-recorded standard phrases recorded by the Operator or Admin as wav files (8000 hz, 16 bit, mono or equivalent).
10. App will play 1-2 wav files (preference will be given to app that will allow Operator or Admin to record standard wav files from within the app, and easily store, organize and retrieve these wav files for later use/editing)
11. App will execute a small number of prompts; Caller to use touch tone keypad to register choices for each prompt (some choices will be Yes/No, some will require Caller to use keypad to register a time, a name, etc.). App will record all choices and store for reporting and analysis. Logs of all calls will allow for sorting by Caller, Date, Time, Duration, Reason for Call (there will be 4-8 defined Reasons for Callers to call into the system) etc.
12. App will also optionally allow for Caller to record 1-2 brief verbal messages which will be stored as wav files and easily accessed later by Operator.
13. At the end of the call, the app will populate tables with all data and wav files collected. App will automatically email a compact text summary of the Caller’s session (showing text of prompts and Caller’s responses), and any recorded wav files will be emailed along as attachments. The email will be sent to the Caller’s Supervisor (based on the SID data collected), and app will allow Supervisor to select whether this email is sent out i) immediately (after each call by Caller) or ii) at a certain time each day (e.g., if Caller made 3 calls, all 3 calls sent as separate email messages, each with its own attachments) or iii) based on a flexible recurrence scheme (e.g., if Supervisor wants to receive all sessions only once a week, or every Monday and Thursday at 15:00, etc. , or iv) immediately based on a rule determined by one or more responses entered by the Caller.
14. The app must allow Operator and Admin to pick one or more or any call session reports to email to Supervisor on request.
15. App will store all data related to unlimited number of call sessions (storage to be limited only by size of local hard drive)
16. App will allow Operator or Admin to create reports of Call sessions from a Start Date and Time to and End Date and Time, and export to Excel or pdf, and allow to email to any recipient from within the app itself, i.e., no need to save a report and send from Outlook.
17. The app will include some functionality to allow for testing and to confirm ongoing proper functioning, e.g., ability for Operator or Admin to ‘test’ system functionality at any time with a Test Account, and ensure that all system functions are working and automated internal diagnostic functions that will notify i) if the app is not functional and ii) generate internal testing to confirm that the app is functional. This app will be generating many calls during the day, perhaps simultaneous calls, so the preferred solution must be able to manage multiple outbound calls simultaneously, or if this entails too high a cost, please describe how your proposed solution will manage multiple outbound calls scheduled for the same time.
Detailed Requirements:
1. The preference is that the app will contain a built-in recording function to record wav files to be used by the app, and this function must record wav files at the appropriate Hz, Bit, Mono parameters to work with the open-source telephony app (e.g. Freeswitch). If the app cannot contain this function (or if too expensive) then at minimum the app will allow the Admin to easily organize, store and retrieve wav files that have been recorded. In the description that follows, it is assumed for simplicity that the recording function can be built-in.
2. The app will require Admin and Operator roles. The app will allow data entry for Admin and Operator data (e.g., name, address, phone numbers).
3. The app will require data entry screens for i) Roles (Operator, Admin), ii) Agencies (the app will allow Admin to setup several agencies each with their own set of Callers and Supervisors), iii) Callers, iv) Supervisors, v) Reports, vi) Default Setup Variables (key variables that the Admin or Operator can control), vii) Prompts (that Callers listen and respond to) and Response Choices (that Callers will select by pressing keys on their touch-tone phone)
4. The app will have screens to capture or store/retrieve wav files to be used by the app.
5. The app will allow Callers to enter 1-9 for response choices, and to use the * and # keys. The app will be able to record brief messages from Callers. The app will allow Callers to transfer to an outside phone number or live person if desired.
6. The app will be designed to accept inbound calls at any time of day, 24 hours a day, 365 days a year with very little or no downtime required for maintenance.
7. The app will flag and document calls from Callers who do not complete their calls because of hanging up too early, bad connection, etc., any time after the ANI or ID information is recorded.
8. The results of the call session will be sent to Supervisors by one or more of the following methods: i) email, ii) SMS (truncated message containing Fname, Lname, Call Reason and Call Date/Time), iii) fax, iv) phone (play standardized wav file to notify Supervisor that call received from Caller (fname, lname at date and time using TTS engine). App will also allow all call session notifications to be copied to Admin and Operator via email.
9. App will be expected to be very robust, but will contain an override that can be selected by Admin to play a single wav file indicating that the system is temporarily unavailable, in case scripting or some portion of the system is unuseable, but inbound calls can still be received.
10. The app will allow the Admin to force a short Special Message (wav file) to be played at the beginning of all inbound calls from i) all Callers, or ii) all Callers reporting to a selected Supervisor, or iii) selected Callers. These Special Messages will be recorded as a wav file by the Admin or Operator, starting on a selected Start Date/Time and ending on a selected End Date/Time. This recording will be made by the Admin or Operator preferably through the app.
11. The app will allow user-friendly navigation to record, store and retrieve all wav files in an organized manner.
12. The app will have reporting capabilities to allow the Admin/Operator to view reports and export them as excel or pdf files. Based on Start Date and End Date, the app will allow the Admin/Operator to view all call sessions and results/outcomes and sort them by Supervisor, Caller, Date/Time, Call Outcome (answered, not answered; if answered, can see if a wav file was recorded and can play the recording by the Caller).
13. The app will include some functionality to allow for testing and to confirm ongoing proper functioning, e.g., ability to manage inbound test calls on demand on a test account (by Operator or Admin) and automated internal diagnostic functions that will notify i) if the app is not functional (exception reporting if any process is not working) and ii) generate periodic (e.g., every XX mins) internal testing to confirm that the app is functional (non-exception validation) from an end-to-end perspective.