University of Oregon Directory System RFI



Request for Information

Telephone Directory Access System with Voice Response Interface

RFI # TEL2003-01

The State of Oregon, acting by and through the State Board of Higher Education, on behalf of the University of Oregon, hereinafter referred to as the University, requests information from vendors as to the acquisition of a telephone directory access system with a voice response interface.

This Request for Information (RFI) is for information only. It does not constitute a solicitation for bids or an offer of a contract. Responses will not bind the vendor to the University contractually or monetarily, or in any other way, but will provide the University with information and comparables if the University does go forward with a Request for Proposals (RFP). It is the intention of the University to generate a RFP based on information received from this RFI.

Responders are requested to:

1. Be brief and to the point.

2. Not respond by sending marketing brochures or offering unsolicited information over the telephone.

3. Base responses on feature sets which are incorporated in your existing product and service offerings. Features which require additional development or testing may be mentioned but must be clearly distinguished from existing features.

4. Suggestions for change should consider that the University desires open competition. Suggestions for changes, if made, should not be of a manner which would restrict competition among viable vendors.

If multiple voice response system configurations are available, responders may submit multiple responses.

Please submit your responses to Eric Fullar at the address below. Responses must be received by 4:30pm on Thursday, February 27. Questions and comments should be directed to Eric Fullar at 541-346-1015 or efullar@uoregon.edu.

Purpose

The University is requesting information for the procurement and maintenance of a telephone directory access system with a voice response interface. This voice response system (hereafter referred to as the “system” or “voice response system”) will be used to provide assistance to callers who do not know the telephone number of the person or department they wish to speak with. The system shall be capable of searching a database of faculty, staff, student and department names based primarily on the pronunciation of the names by the callers. Once the requested telephone number is determined, the system will read the number to the caller and/or connect the caller to the requested number.

Background

The University of Oregon is located in Eugene, Oregon and has a student enrollment of approximately 20,000 students. The University is affiliated through the Oregon University System with state universities in six other locations throughout the state.

An Avaya G3r PBX is used to provision on-campus telephone services at the University of Oregon. This system currently serves approximately 9,000 stations and is configured for analog and digital stations, analog and digital trunking as well as call vectoring and ACD functions. This system is covered under a maintenance contract with Avaya. It is at software release 10 and will be upgraded to release 11 in 2003.

Telecom Services currently staffs an operator group with one to four operators from the hours of 7am until 6pm Monday through Friday. For the most part, this group provides basic directory assistance services for on campus and off campus callers who are trying to reach a person or department at the University.

The University utilizes a web based directory system for campus operator telephone number lookup, publication of a printed faculty/staff directory and also for online access to faculty, staff, students, and the general public. This system pulls data from the University’s Human Resources Information System which is a module of the SCT Banner family of information systems used throughout higher education. It is intended that the voice response system will pull information from this same system. The University will provide any required customization of this system to provide acceptable input to the voice response system.

It is the University’s intention to purchase a voice response system selected through a future RFP to complement its existing operator services group. Based on system cost and features, the University may elect to use this system to provide directory assistance for off-campus student listings. This would increase the directory size from approximately 9,000 listings to approximately 25,000 to 30,000 listings.

At the discretion of the contractor selected through the future RFP, pricing may be extended to other Oregon public agencies without the requirement for a similar procurement process.

Confidentiality

RFI responses shall be retained by the University for a required retention period and made a part of a file or record which shall be open to public inspection. If a response contains any information that is considered a "trade secret" under ORS 192.501(2), the proposer must mark each sheet of such information with the following legend:

"This data constitutes a trade secret under ORS 192.501(2), and shall not be disclosed except in accordance with the Oregon Public Records Law, ORS Chapter 192."

The Oregon Public Records law exempts from disclosure only bona fide trade secrets, and the exemption from disclosure applies "unless the public interest requires disclosure in the particular instance". ORS 192.501(2). Therefore, non-disclosure of documents or any portion of document submitted as part of a response may depend upon official or judicial determinations made pursuant to the Public Records Law.

The above restriction may not include cost or price information, which must be open to public inspection. An entire response marked as proprietary ("trade secret") is unacceptable. The respondent will be requested to mark only specific pages or text and return the response prior to closing. Responses in which the entire document is marked or otherwise identified in its entirety as confidential or a "trade secret" will be rejected.

Minimal Requirements

Note: These requirements are tentative and may be modified in the RFP.

i. System shall be capable of receiving and processing calls from individuals who require directory assistance. Appropriate responses shall be determined through two way voice interaction with the callers.

ii. Upon request, vendor must be able to provide three references of clients with installed directory systems that serve more than 25,000 listings. References must be using systems which are functionally equivalent to that which is being discussed in the response.

iii. Vendor must offer comprehensive maintenance services for proposed system(s).

iv. Users of system shall have the option of being re-directed to a live University operator.

v. System shall provide the option of connecting users to the listing they requested. In the case of POTS line ports, this shall be accomplished through a switch hook transfer.

vi. System shall interface with the university’s Avaya G3r PBX using either analog (POTS) ports, Avaya proprietary Digital Communications Protocol (DCP) ports, or multiple channels on a DS1 circuit.

vii. Directory function shall be provided from hardware located on the University’s premises.

viii. System shall satisfy minimal requirements for directory search accuracy when searches are performed on representative directory listings by a representative group of users. Representative listings and users are to be selected by the University.

ix. System shall support five, seven and ten digit directory listings.

x. System shall have the potential capacity to support a directory consisting of at least 30,000 listings, 200 calls per hour and four simultaneous calls. Initial configuration may have a lesser capacity.

xi. System shall provide responses to callers directory queries within 4 seconds when searching directories with 30,000 listings.

xii. Directory import mechanism shall support automated daily updates from a remote customer system in the form of a tab or comma delimited electronic ASCII text file. The processing of new directory listings in an update shall not involve manual interaction on the part of University staff.

xiii. System shall be configured with a mechanism for remote diagnostics and software support by Vendor. Vendor shall be capable of responding within 4 hours to problems which can be resolved remotely.

xiv. If vendor is providing hardware as part of their solution, vendor shall be capable of responding within 6 hours of hardware related problems. Provisions must be available to provide repair parts in a timely manner. Full hardware redundancy may be considered in lieu of some hardware service requirements.

xv. Hardware discussed in this response shall be sufficient to support the directory application at the stipulated capacity for a period of three years without complete replacement by University or at an additional cost to the University.

xvi. Monthly maintenance payments shall cover the cost of telephone based technical support services (for University’s telecom staff), documentation updates, routine contractor provided maintenance service, repair of software failures, on-site repair of hardware failures (if vendor is providing hardware as part of proposed solution)

Features Survey

Please respond to each of the questions listed below. Responses to the questions may be made on a copy of this document or on a separate attachment. If an attachment is used, clearly reference the original question numbers.

1. Product Name:

2. Version / Revision number:

3. Are you a: developer or manufacturer _______ distributor _______

4. If you are a distributor, describe in detail what portions of this proposal would be provided by the developer and what portions would be provided by you, the distributor.

5. Operating system platform: Windows NT, Windows 2000, Solaris, Linux (distribution_____________), other

6. What hardware is included with proposal? If a server is not included, list server requirements.

7. As part of this proposal, is there any hardware that is not commercially available (off-the-shelf)?

8. Is a 19” rackmount server chassis an option? (A non-rackmount server placed on a rackmount shelf does not constitute a rackmount chassis.) Is there an additional cost?

9. Describe hardware redundancy options

a. Hardware RAID disks?

b. Software RAID disks?

c. Multiple power supplies?

d. Complete failover unit?

e. Other? ___________________

10. How many additional ports can be added the proposed system? ___________

11. Which PBX interfaces are available?

a. Analog (POTS)

b. Analog (POTS) with DID

c. ISDN PRI (signaling protocol _________ e.g. National I, National II, DMS-100, etc.)

d. Avaya DCP two pair

e. Avaya DCP one pair

f. DS1 (non-PRI)

12. Is Caller ID and/or ANI supported? If so, how can the calling name or number be used (e.g. reporting, prompt selection, etc.)?

13. Are 10 or 12 digit directory listings supported? Can they be intermixed with 5 and/or 7 digit listings?

14. Can ports be configured with a timer to disconnect over-length calls or forward them to an operator? If so, which action is taken?

15. What is the normal response time to produce a listing for a caller? What is the maximum time?

16. Remote alarming capabilities

a. email or modem call to vendor

b. email or modem call to customer

c. SNMP trap to customer trap handler

d. UNIX syslog message to customer system

e. dry contact alarm output to customer device

17. Remote vendor access capabilities

a. dial-up modem line – password authentication

b. dial-up modem line – hardware based authentication (token, SecurID devices, etc.)

c. Secure Shell via Internet

d. University provided VPN client

e. Telnet / rlogin / xterm

f. other explain

18. Would the university be granted permissions to perform disaster recovery backups and restores of system (admin / root access)?

19. How can directory update files be transferred to system?

a. FTP

b. SFTP (Secure FTP)

c. NFS share

d. SMB share

e. through vendor

20. Can the system be configured as an LDAP client to pull directory listings from an outside LDAP directory? If so, can this process be set up to replicate incremental changes as they occur in the master database as opposed to requesting complete copies? Explain how this would work.

21. Can directory update files be pulled by the system from another location, or are they dropped onto the system from an outside source? In other words, which side initiates the transfer?

22. Is vendor interaction required for routine directory updates? If so, describe the process. Include the turnaround time for updates.

23. Describe how the system handles duplicate names (multiple people with the same name pronunciation).

24. Can the system ask the caller to spell the name they are asking for?

25. Can the system automatically connect some listings and read the number for other listings? What triggers one response or another?

26. Can mechanisms be put in place to prevent callers from “harvesting” directory listings (collecting a large number of listings in a short time interval)? If so, describe how this would work.

27. Can callers request other information from system? (e.g.: department, email address, building)? Is there an additional cost for this feature?

28. Does the system allow individual end-users access to temporarily override their listing from the University’s HRIS database (between an office phone, cell phone and home phone)? If so, describe how this feature works and how user authentication would be handled.

29. Can the system choose prompts or a directory to search based on incoming port or caller ID? If so, can a range of numbers be used as an argument to configure this feature?

30. Can the system maintain its own listing of aliases which gets merged with the base directory, or do they need to be input with each update? If yes, describe the process to update this internal listing.

31. Are aliases included with counts for per-name licensing or maintenance fees?

32. Can callers interrupt prompts which are read by the system or do they need to wait for a signal to begin speaking?

33. Can call handling automatically be changed based on time of day, day of week or date? For instance, can prompts to callers be changed during the hours that operator positions are staffed?

34. Describe the system’s reporting capabilities.

35. Can reports be run on the callers which have been requesting directory services (number pulled from caller ID or ANI)?

36. Can reports be run on the listings which were requested by callers?

37. Describe the system’s troubleshooting capabilities. What mechanisms are available to determine why calls are not handled properly. State whether these features are available to the customer.

38. Can automatic recordings be taken of unsuccessful or problematic calls?

39. Can administrators listen in realtime to caller and system interaction? How is this accomplished?

40. Are reports run by vendor or customer?

41. Can the customer run real-time reports?

42. What interface(s) is provided for customer administration?

a. browser based graphical interface

b. proprietary graphical software utility

c. voice interface

d. command line interface

43. How are names and pronunciations which are unknown to the system handled?

44. If unknown names are recorded as-necessary by the contractor, how long does this process take? Is a temporary recording used? Describe how this process works.

45. Can the customer opt to provide administration of unrecognized names? If so, how would this impact maintenance costs if the University decided to take this route?

46. What customer training is provided?

47. How is customer training handled after the initial installation?

48. What related applications are available?

49. What software updates are provided with maintenance services (select all that apply)?

a. minor feature enhancements

b. major feature enhancements

c. bug fixes as discovered by customer or vendor

d. bug fixes as necessary to address specific observed problematic behavior

e. bug fixes to address security vulnerabilities

50. If not all of the items in the question above are selected, how is pricing structured for the unselected items?

51. What documentation is provided with system?

52. How are documentation updates handled?

53. Is the developer for this system ISO9000 compliant or ISO9000 certified?

54. Is the maintenance/support organization for this system ISO9000 compliant or ISO9000 certified?

Pricing Response Form

Please provide estimated not-to-exceed pricing for the following configurations. This pricing is being requested in order for the University to understand the purchase/maintenance cost structure, perform a cost-benefit analysis and decide exactly which configuration will be stipulated and what combination of user maintenance versus recurring vendor maintenance will be favored in an RFP to be issued after a review of RFI responses. Contractual pricing will be requested in the RFP.

For the table below, assume all Analog PBX interfaces.

|number of listings |number of ports | estimated purchase |estimated |estimated per year |estimated additional |

| | |cost |installation cost |maintenance cost |cost for fully |

| | | | | |redundant system |

|5000 | |$ |$ |$ |$ |

|10,000 | |$ |$ |$ |$ |

|20,000 | |$ |$ |$ |$ |

|30,000 | |$ |$ |$ |$ |

(Vendor should provide any clarification or qualification of these prices it deems necessary.)

Pre-maintenance warranty period months

Additional cost for: ISDN-PRI interface $ non-redundant $ redundant

Avaya DCP interface $ non-redundant $ redundant

Hourly cost for custom programming $ /hour

vendor name

address

sales contact name technical contact name

sales contact phone technical contact phone

sales contact email technical contact email

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download