1947_2.XLS
XLS spreadsheet 33 KB Posted
- Attached to
- IT- Interactive Voice Response (IVR) Solution
- Contract number
- 505ENT-W07-IVOICER-01
- Issued by
- Wisconsin
About this file
This document is a vendor question and response sheet for Wisconsin Request for Bid (RFB) 27824-LAA for an Interactive Voice Response (IVR) Solution, dated October 26, 2006. The procurement involves the State of Wisconsin and four agencies (designated as Agency A, B, C, and D) seeking to acquire IVR systems and services from qualified vendors through a competitive bidding process.
The contract covers comprehensive IVR system implementation including VoiceXML 2.0 compliant platforms, text-to-speech capabilities in English and Spanish (with optional Hmong language support), speech recognition and authentication features, database integration capabilities, web services interfaces, and reporting systems. The procurement requires vendors to provide development, acceptance, training, and production systems with configurable call handling, real-time processing capacity, and industry-standard reporting capabilities. Vendors must submit six complete bid copies and meet all mandatory requirements including open platform compatibility, application conversion services, and comprehensive training programs for administrators, supervisors, and end users. The document indicates that some Agency D systems require redundancy through load balancing across multiple IVR systems, though full redundancy without degradation is not required. Specific deployment schedules, call volumes, and go-live dates were not available at the time of the vendor inquiry period.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 1947_0.DOC | DOC document | |
| 1947_1.DOC | DOC document | |
| 1947_17.XLS | XLS spreadsheet | |
| 1947_22.XLSX | XLSX spreadsheet | |
| 1947_5.PDF | ||
| 1947_7.PDF | ||
| 1947_10.DOC | DOC document | |
| 1947_11.PDF | ||
| 1947_14.DOC | DOC document | |
| 1947_16.PDF | ||
| 1947_21.PDF | ||
| 1947_3.PDF | ||
| 1947_8.PDF | ||
| 1947_12.DOC | DOC document | |
| 1947_15.DOC | DOC document | |
| 1947_19.PDF | ||
| 1947_4.PDF | ||
| 1947_9.PDF | ||
| 1947_13.DOC | DOC document | |
| 1947_20.PDF | ||
| 1947_6.PDF |
Show all 21
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Sheet1
| Vendor Question | State of Wisconsin Response |
| Item 3.5, Page 11 states, "Proposers must submit six (6) complete copies of bid responses . . .". Can we safely interpret this statement to mean one (1) original copy and five (5) reproduced copies? | Yes. |
| Please clarify what you mean by "partitioning" in section 4.6 under "General Bid Requirement Response" | Refer to Section 2.0, Definitions. |
| The IVR must answer all calls within a customizable number of ring cycles under normal operating conditions, with the ability to increase or decrease the number of rings as application designs require. Please describe a situation where you would not want the system to answer the phone as quickly as possible. | This specification, from a 1993 RFB, was intended to provide a mechanism allowing for completion of tasks (determine if host (mainframe) is available, check access database to determine hours of operation, etc). before the phone was answered. Explain how your system will meet this requirement (or intent of this requirement) in Additional Vendor Comments. |
| Section 6, is a separate development, acceptance, training, and production system required? | Agency D (Section 6.4) requires a mix of systems as specified in this bid. |
| Is an interpreted VXML language, i.e., running VXML under a shell program environment, preventing portability of applications to other VXML platforms OK? | Use of an interpreted VXML language is acceptable as long as 1) it is a proven, stable industry standard, 2) it provides complete compliance with VoiceXML 2.0 (and newer versions as they evolve) standards, coding, operability, functionality, etc., and 3) allows for portability to another VXML system if/as required by the State. If not portable, vendors must provide a method to maintain VXML in a native format, allowing migration to a different VXML based system if/as required in the future. |
| Our platform does not support or generate Voice XML scripts. Should we still respond? | Bidders must meet all mandatory requirements. |
| The RFP states that an Open platform is required. Question 5.146 indicates that VXML 2.0 or ProC is required. Pro C is proprietary to Avaya only and is not open. Is an open platform running native VXML required? | Specifications 5.139 & 5.146 reference Pro*C, but do so with the qualifier of "or equivalent". To further qualify that statement: |
1. ScriptBuilder limits the number of Oracle databases and database fields that can be accessed. We read/update remote Oracle tables that are large, requiring an alternative to ScriptBuilder programs. To resolve that problem, Pro*C programs were written that are called from Script programs that are called from ScriptBuilder programs. If there are no database limitations, this need goes away.
2. Pro*C is used in scheduled batch processing. For example, we store a large number of client recordings and these client recordings have associated Oracle database records that allow us to access them. On a frequency that we determine, we purge both the client recordings and the associated database records via Pro*C programs. If the vendor's platform can accomodate batch processing of database records (e.g. C or a variation of it, Visual Basic, .Net, Java), this need goes away.
| 3. ScriptBuilder limits the number of remote databases that can be accessed from ScriptBuilder programs. We can only access one remote database, but because our IVRs have joint education/production applications, we need to access more than one remote database. We can do this via Pro*C programs, thus eliminating any restriction. If the vendor's platform can accommodate access of more than one remote database, this need goes away. Note - if there is no need to "share" a platform, or if the various environments are totally separate, this need also goes away. |
| 4. Pro*C is used to extend the flexibility of non-database processing. For example, Unemployment Insurance processing depends on date manipulation that is totally unique to UI. We need to determine what "week" of the year we're in, the Sunday and Saturday ending dates of that week, what a claimant's base period is and what a claimant's benefit year is. All of these concepts are totally outside the programming capabilities of ScriptBuilder. A Pro*C program performs these date manipulations. We also have several other Pro*C programs that are critical to our processing, such as the PIN encryption routine, the DOT algorithm routine, and our whole LVIS callback system. If the vendor can migrate a program written in Pro*C to their platform (see above), this need goes away. |
Provide your responses to each of the above in Additional Vendor Comments.
| Our platform is script (VB Net) based for maximum flexibility in integrating with 3rd party tools (like callcenter). As such it does not have a GUI for building simple applications. Should we still respond? | Bidders must meet all mandatory requirements. |
| Please clarify: the IVR must have the ability to act as the liaison between the IVR script and web services components. | Disregard as long as specification 5.56 is met. |
| Please clarify: Section 5.179, can we assume WSDL and Web services descriptions provided in documents 10736_0 and 10736_1 represent a complete set of requirements to be used by the IVR to facilitate the interface within IVR and back end databases? If any new web services are needed by an application will they be provided by the third party mentioned in the document 10736_0? | Yes, you can make that assumption. New web services are outside the scope of this procurement. |
| Our platform is not a voice mail system and does not support AMIS. Should we still respond? | Bidders must meet all mandatory requirements. |
| Connectivity wise, what is the current screen scraping application? Is the plan to retain this functionality? | The RFB did not make reference to screen scraping. |
| Section 5.59; please confirm the language(s) in scope for both speech and text-to-speech. | English and Spanish are required; Hmong is optional. |
| Section 5.6, can we assume that prompts will be a mixture of pre-recording and text-to-speech only and that speech recognition will be barge-in active? | Speech recognition, if utilized, must be configurable, just like interrupts. |
| We are unable to find text to speech or speech recognition for the Hmong language. Should we still respond? | English and Spanish are required; Hmong is optional. |
| Section 5.64 states the "IVR should offer speech authentication, allowing for the authentication of callers". Does this refer to speaker verification? | Yes. |
| Please clarify: The IVR must have processing capacity to provide real time support for reporting related tasks to improve response time for users. | The IVR must have sufficient processing capacity to meet specification 5.144. |
| Please clarify: industry standard historical and real-time IVR reports | Refer to 5.65+, Reporting Requirements. |
| Please clarify: configurable call statistics reporting system. | Reports must be configurable (date ranges, groups, etc). |
| Please clarify the type of information Technical or Marketing and the format that is requested in section 1.2.14. | Provide documentation detailing all features, whether technical and/or marketing. |
| Tab 13, Bid Response Submission Checklist, Page 13 shows a reference to Section 1.2.14. We have been unable to locate this specific Section. Was Item 1.2.1.4, Page 4, the intended reference? | Yes. |
| Based on Section 1.3, when quoting application conversion costs, should we assume that the applications will remain DTMF and not incorporate speech recognition? | Yes. |
| Please provide the estimated number of personnel projected to participate in Administrator, Supervisory, End User, and Customized Training as called out in Section 8. Also please provide a summary of anticipated skill levels for each. | Refer to updated Section 8.0. |
| Can we have the average call/hold time for each application on each of the four agencies (A, B, C, D)? | Not available. |
| In what order will the agencies be deployed? | Not available. |
| What is the anticipated go-live date(s)? | Not available. |
| Will there be any parallel upgrade projects that would impact to the IVR schedule? | Not available. |
| Attachment B, Form DOA-3333 displays Bid Number 27834-LAA. The Bid Number shown on other documents throughout your RFB is 27824-LAA. Should the Bid Number shown at the bottom of Attachment B, Form DOA-3333 be the same as the Bid Number displayed on other documents throughout this RFB? | Corrected to read 27824-LAA. |
| Would the RFB Evaluation Team accept submission of proposal material on CD media? | Yes, in addition to the required hard copies. See amended Section 3.5. |
| What is the busy hour call volume and the duration of the calls for each Agency and IVR? | Not available. |
| Is full redundancy with no degradation a requirement? | No. Some systems for Agency D in this bid (Section 6.4) require redundancy, meeting that requirement by load balancing critical applications on multiple IVR systems. It is acknowledged that if there is a problem with one IVR system/application, temporary degradation will be experienced. |
&CRespose to Vendor Questions RFB 27824-LAA for Interactive Voice Response (IVR) Solution October 26, 2006
Sheet2
Sheet3
File details come from the government source that posted it. Updated .