Department of Buildings and General Services
Agency of Administration
Purchasing & Contract Administration 10 Baldwin St. Montpelier VT 05633
[phone] 802-828-2210
[Fax] 802-828-2222
www.bgs.state.vt.us
SEALED BID REQUEST FOR INFORMATION
RFI for Vermont Telephony Services (VoIP) DATE:
02/04/2014
QUESTIONS DUE BY:
02/13/2014 4:30 PM
RFI RESPONSE DUE DATE:
03/05/2014 3:00 PM
LOCATION FOR RFI RETURN: 10 Baldwin St, Montpelier, VT 05633 PLEASE BE ADVISED THAT ALL NOTIFICATIONS, RELEASES AND AMENDMENTS ASSOCIATED WITH THIS RFI WILL BE POSTED AT http://bgs.vermont.gov/purchasing/. THE STATE WILL MAKE NO ATTEMPT TO CONTACT VENDORS WITH UPDATED INFORMATION. IT WILL BE THE RESPONSIBILITY OF EACH VENDOR TO PERIODICALLY CHECK THIS SITE FOR THE LATEST DETAILS.
PURCHASING AGENT: John McIntyre TELEPHONE: (802) 828-2210 E-MAIL:
[email protected] FAX: (802) 828-2222
Contents 1.
2.
PURPOSE ......................................................................................................................................................................... 4 1.1
LIABILITY .................................................................................................................................................................. 4
1.2
CONFIDENTIALITY.................................................................................................................................................... 4
BACKGROUND INFORMATION ........................................................................................................................................ 5 2.1
STATE OF VERMONT WAN DIAGRAM ..................................................................................................................... 6
3.
RFI DESCRIPTION ............................................................................................................................................................. 7
4.
CURRENT STATE .............................................................................................................................................................. 7
5.
SOLUTION ATTRIBUTES ................................................................................................................................................... 8 5.1
GENERAL ................................................................................................................................................................. 8
5.2
CENTREX AND ISDN REPLACEMENT ...................................................................................................................... 10
5.3
UNIFIED COMMUNICATIONS ................................................................................................................................ 13
5.4
PSTN ORIGINATION AND TERMINATION .............................................................................................................. 15
6. Requested Information………………………………………………………………………………………………………………………………………………16 7. Additional Materials …………………………………………………………………………………………………………………………………………………18
1. PURPOSE The State of Vermont is seeking information on solutions that will lower its telephony costs. The State envisions this solution to be a traditional VoIP system utilizing IP phones, PoE switches, some locations requiring survivability, voice and data sharing the same WAN links, prioritized with QoS, dynamically connected to the State’s two datacenters, where traffic is routed out one of the redundant links to either a hosted top tier, well known, proprietary solution, or to a similar local virtualized solution, load balanced between the two datacenters, with SIP trunks out to a provider. The State would like to fund the system through the savings realized though decommissioning the legacy Centrex system, with minimal capital investment. The State would also like to explore the addition of Unified Communications features to its telephony offering, with the expectation that the new telephony system will provide the foundation for Unified Communications and that features can be added while providing a positive return on investment. While the State has a general vision of what this solution would look like, it is open to and seeking other options that will enable it to meet its requirements at a lower cost or with less capital investment – premise based solutions, hosted solutions, or hybrid model solutions, service fee based financing, savings based financing, or incremental capital investment. Any of these variations would need to not substantially decrease the solution’s effectiveness, efficiency, flexibility or quality. The State expects to use the information received from this RFI – solution options, pros and cons of the solutions, estimate of the cost of solutions, potential financing options, an estimate of return on investment, transition strategies to the new solutions – to select a model solution and to seek a formal proposal for implementation.
1.1
LIABILITY
THIS IS A REQUEST FOR INFORMATION (RFI) ONLY. This RFI is issued solely for information and planning purposes – it does not constitute a Request for Proposal (RFP) or a promise to issue an RFP in the future. This request for information does not commit the State to contract for any materials or service whatsoever. Further, the State is not at this time seeking proposals and will not accept unsolicited proposals. Respondees are advised that the State will not pay for any information or administrative costs incurred in response to this RFI; all costs associated with responding to this RFI will be solely at the interested party’s expense. Not responding to this RFI does not preclude participation in any future RFP, if any is issued. If an RFP is released, it will be posted on the BGS bid opportunities web site: http://www.bgs.state.vt.us/pca/bids/bids.php. It is the responsibility of the potential offerors to monitor this site for additional information
1.2
CONFIDENTIALITY
CONFIDENTIALITY: All responses to the RFI will become part of the state’s file and are a matter of public record. If a response includes material that the responsive party considers proprietary and/ or confidential under 1 VSA, Chapter 5, then the responsive party must clearly and specifically designate which materials the responsive party believes to be proprietary and / or confidential. Said designation must include an explanation why such
material should be considered confidential and / or proprietary. The responsive party must identify each portion, section, paragraph, page, or document that it believes is proprietary and / or confidential with sufficient grounds to justify each identified section from release, including the prospective harm to the competitive position of the responsive party if the identified material were to be released. Under no circumstances can the entire response or any included price information be marked confidential. Responses that fail to comply with these provisions will be treated as public record according to 1 VSA, Chapter 5. The solicitation of this RFI does not commit the Department of Information and Innovation or the State of Vermont to award a contract. This RFI is for information gathering purposes only and no vendor will be selected, pre-qualified, or exempted based upon their RFI participation.
2. BACKGROUND INFORMATION The State current communications infrastructure consists of the following: • • • • • •
• • • • •
Approximately 11,000 Centrex lines Approximately 900 ISDN BRI lines Approximately 3,000 mobile phones 288 VoIP phones – using ACD 2 datacenters WAN/LAN o Approximately 130 sites connected via MPLS/VPLS network to datacenters o Approximately 100 sites connected via VPN over DSL/cable o Cisco routing infrastructure o Cisco and HP switching infrastructure Exchange and Outlook for email Openfire and Spark for instant messaging Outsourced on-demand conference calling Outsourced on-demand web conferencing Various small video conferencing deployments including Polycom and Cisco
2.1
STATE OF VERMONT WAN DIAGRAM
3. RFI DESCRIPTION The State is seeking information to replace existing Centrex and ISDN-BRI telecommunications system. The RFI has four key objectives: • • • •
Provide prospective respondents with information regarding the business need, and, Solicit respondent information to assist the State in determining if identified requirements can be met by available software/hardware COTS (Commercial off the Shelf) alternatives. What are the alternatives, pros/cons of alternatives, cost estimates and financing options- capital expenditure vs. monthly flat fee, etc. Transition approach of solution. Modeled estimate of return on investment for each proposed solution
The State is seeking feedback on the information in this RFI and will consider any information, including partial responses, received in response to this RFI. If the State moves forward in the development of an RFP, the RFP process will be open to all respondents regardless of their decision to participate in this RFI.
The State envisions that the solution will support the following high-level goals: To acquire the services of a qualified vendor who will design, install, and provide ongoing support for a VoIP telecommunication and switching solution that will meet our functionality, scalability, reliability, and manageability requirements, and include a robust disaster recovery capability.
4. CURRENT STATE The telephony services now provided at the State of Vermont are based primarily on Centrex and ISDN-BRI phone solutions with some call centers leveraging VoIP and ACD. The State of Vermont has multiple locations throughout the State. These locations vary in size and number of users. Below is a high level breakdown of the locations and the telephony provided (Note that some locations employ a combination of Centrex, ISDN and VoIP): •
•
•
Analog/Centrex: o Small (1-19 phones) = 357 o Medium (20-250 phones) = 103 o Large (251+phones) = 6 ISDN-BRI: o Small (1-19 phones) = 77 o Medium (20-250 phones) = 11 VoIP Call Centers: o Number of Agents = 333 o Number of Call Centers = 12 o Number of PRIs = 20 o Number of Gateways =7 o Number of Media Servers = 4 o Number of Managed VoIP phones = 288
5. SOLUTION ATTRIBUTES The purpose of this RFI is to determine if there are solutions capable of meeting the State’s anticipated requirements and to determine alternatives for meeting those requirements that are consistent with the overall vision for the State. For each solution proposed, please address each item below in your response.
5.1
GENERAL
5.1.1 Overview 5.1.1.1 Clearly identify the trade name(s) of the solution(s) the Respondent would recommend. 5.1.1.2 Describe the proposed system's architecture. Is it a centralized or distributed architecture? 5.1.1.3 Provide a diagram of your proposed solutions. 5.1.1.4 Provide a realistic implementation timeline including planning, design, ordering, receiving, installation, training, testing, commissioning. 5.1.1.5 Provide at least one (1) case study for a completed project of similar size and scope to the State’s. The case study should include a description of the client’s environment prior to implementation, the system configuration provided by the Respondent, a list of features and applications included in the configuration, the total cost of the system provided by the Respondent, and the schedule for implementation. 5.1.1.6 Describe the nature and length of any partnerships/agreements the firm has with other equipment and service providers 5.1.1.7 Is the product section 508 (accessibility) compliant? 5.1.1.8 Is there a demonstration system available that the State can use to evaluate the proposed solution? 5.1.1.9 Does the proposed solution support service oriented architecture (SOA) standards to facilitate integration with business process solutions? 5.1.1.10 Is the system able to scale with increasing demand? 5.1.2 Estimated Pricing and Purchasing 5.1.2.1 Provide detailed, itemized, pricing for the proposed solution indicating what components are optional or mandatory. 5.1.2.2 Provide pricing on system expansion, upgrades and enhancements. 5.1.2.3 Provide pricing on startup costs. 5.1.2.4 Provide pricing on recurring licensing, maintenance and support. 5.1.2.5 Provide pricing on recommended training for the State. 5.1.2.6 Are there other costs involved with the proposed solution? 5.1.2.7 Describe licensing structure for all components of the Respondent’s solution. 5.1.2.8 Is your proposed solution already available for purchase through an existing State contract? 5.1.3 Hosting 5.1.3.1 Is the proposed solution to be hosted by the Respondent or by the State, or hybrid? 5.1.3.2 Can components of the system be virtualized using VMware ESXi? 5.1.3.3 Are components of the system available as an appliance, either virtual or physical? 5.1.3.4 What components must be provided by the State? 5.1.3.5 May the State provide the server hardware required? If so, describe the preferred server configuration(s). 5.1.3.6 Describe the scalability of the system and its limits. 5.1.3.7 Describe the options for connecting to a hosted service and the Respondent's preferred method and why. 5.1.4 Staffing and Support 5.1.4.1 Is the proposed solution vendor managed or State managed? 5.1.4.2 Describe the State staffing and effort required to implement and maintain the system. 5.1.4.3 Describe the recommended training for the State.
5.1.4.4
Describe the software and system upgrade approach, frequency and cost, including the approximate number of software upgrades and patches released each year. 5.1.4.5 What is the update process? 5.1.4.6 Is updating the system service impacting? 5.1.4.7 What is the fallback process if an upgrade fails or has a bug? 5.1.4.8 Provide the name of another company that would be able to support the proposed solution in the event the Respondent ceased operations. 5.1.4.9 Describe the separation of duties between system administrators and call center supervisors within the administrative tools of the contact center solution 5.1.4.10 Describe the process for completing moves, adds, changes, including response times. 5.1.4.11 Describe the Respondent’s support organization’s structure, specifically noting their presence in Vermont and the Respondent’s ability to provide on-site techs. 5.1.4.12 Describe the trouble resolution process from reporting a problem through resolution, including response times and notifications/updates that would be provided to the House. 5.1.4.13 Describe the spare parts strategy. 5.1.4.14 Provide copies of the system installation, administration and user documentation 5.1.4.15 Describe the system’s warranty options. 5.1.4.16 What is the level of support included along with the purchase of the product? Is it available 24/7? 5.1.4.17 Is there a public or private forum of product experts and other users available to provide additional support? If so, please provide the url. 5.1.5 Disaster Recovery 5.1.5.1 If the solution is to be hosted by the State, describe how the State can leverage its primary and backup datacenters to provide failover/redundancy. 5.1.5.2 In a redundant configuration, in the event of a failure, would live calls be dropped? 5.1.5.3 Clearly describe the failover procedures for all redundant components. Include in the description the length of any service interruption during failover, if any manual intervention is required, and how the system is restored to normal operation after repairs are completed. 5.1.5.4 What level of availability (how many 9s) is reasonably achievable with the proposed configuration? 5.1.5.5 Describe the options that exist within the Respondent’s solution for District Office survivability. 5.1.5.6 Describe how a user reestablishes service in an emergency relocation situation. 5.1.6 Security 5.1.6.1 Is the system NIST (National Institute of Standards and Technology) 800-53, 800-58, SC-19, FIPS 199 and 200 compliant? 5.1.6.2 Is the system FIPS (Federal Information Processing Standards) 140-2 certified? 5.1.6.3 Is the system IRS (Internal Revenue Service) 1075 and Section 9.18.13 compliant? 5.1.6.4 Has the system been certified against the IRS VOIP SCSEM (Safeguard Computer Security Evaluation Matrix)? If so, provide a copy of the results. 5.1.6.5 Has the system been certified against the DISA (Defense Information Systems Agency) VVoIP (Video and Voice over IP) STIG (Security Technical Implementation Guide)? If so, provide a copy of the results. 5.1.6.6 Has the system been certified against any other relevant DISA STIGs (ESXi, VM, Windows, SQL, IIS, .Net, etc.)? If so, please provide a copy of the results. 5.1.6.7 What other certifications or validations have been performed on the system? 5.1.6.8 Per IRS Section 9.18.13 do you have a security test plan for commissioning the system as well as for annual recertification? 5.1.6.9 Is TLS used to encrypt system call control information, and how is it implemented to not overwhelm the core with the required overhead? 5.1.6.10 Is all user communication encrypted between all end devices and the system, though SRTP or other means, and how is it implemented to not overwhelm the core with the processing overhead? 5.1.6.11 What type of encryption is employed in the system? 5.1.6.12 Is the encryption used in the system FIPS 140-2 compliant? 5.1.6.13 What kind of role-based access controls are included in your product? 5.1.6.14 Describe the granularity of your security privileges. 5.1.6.15 Describe the types of logging the system is capable of generating.
5.1.6.16
Describe the system's intrusion detection (IDS) and intrusion prevention (IPS) strategies to alert and prevent unauthorized equipment from being attached to the system and unauthorized use of the system. 5.1.6.17 Does the solution have a strategy to authenticate end-user devices? 5.1.6.18 Does the solution support the use of VLANs to separate voice and general data traffic? 5.1.6.19 Does the solution provide a means for user authentication to prevent unauthorized network access (for example a to prevent general use of a publicly accessible phone)? 5.1.7 System Monitoring and Troubleshooting 5.1.7.1 What tools are included with the proposed solution to monitor and troubleshoot it? 5.1.7.2 Does the system support Simple Network Management Protocol (SNMP)? 5.1.7.3 Does the Respondent have experience monitoring the solution in Solarwinds Orion? And to what extent can the system be monitored through Solarwinds Orion? (call quality, capacity, etc.) 5.1.7.4 What capabilities are provided for capacity planning? 5.1.7.5 Does the system provide alerting and reporting for impacting issues? 5.1.7.6 What other reporting does the system provide? 5.1.7.7 Can the State create its own reports in the system? 5.1.7.8 Does the system support XML as a report format? 5.1.8 Provisioning 5.1.8.1 Does the system provide a provisioning tool that allows delegates to request service for a user from a menu of predefined service packages? 5.1.8.2 Can the system be configured to require an administrative approval to complete the provisioning process? 5.1.8.3 Does the Respondent have any experience or knowledge of integrating the system's provisioning functions with LANDesk? 5.1.8.4 Are groups and/or profiles used to help ease administration and provide consistency in the user permissions and offerings? 5.1.8.5 What capabilities are available to end users for self-service (i.e. changing roles and permissions, system passwords, profiles) within the product? 5.1.9 Billing 5.1.9.1 Describe the proposed systems’ billing features. 5.1.9.2 Does the system store CDRs (Call Detail Records) in a queryable database? 5.1.9.3 Provide a list of the data elements contained in your CDR. 5.1.9.4 Does the system provide more usage detail than just traditional voice calls? For example does it keep records for video and web conferences that can be used to bill on the system's total usage? 5.1.9.5 Does the solution provide a means for identifying a user's calls regardless of where in the network they were made? (For example a PIN used to identify a user when a call is placed)
5.2
CENTREX AND ISDN REPLACEMENT
5.2.1 Describe the PBX solution you are proposing. 5.2.2 Technical 5.2.2.1 If the State were to decide to replace the current data network infrastructure at the same time the VoIP system is implemented, what data networking devices (state the manufacturer and product) would be recommended and why? 5.2.2.2 Does your solution require the State provide Power Over Ethernet (POE) switch ports to end-user devices? 5.2.2.3 Does your solution require the State make any LAN or WAN configuration changes? 5.2.2.4 What standards and techniques for quality of service (QoS) are supported to ensure acceptable voice and video quality over the data network? 5.2.2.5 Define the minimum cabling requirements to support connectivity between system components. 5.2.2.6 Identify the standards with which the recommended solution complies (e.g. IETF RFC 3261 (SIP), H.323, IPv6, etc.).
5.2.2.7 5.2.2.7.1 5.2.2.7.2 5.2.2.7.3 5.2.2.7.4 5.2.2.7.5 5.2.2.7.6 5.2.2.7.7 5.2.2.8
Protocols Is the solution standards based or are proprietary protocols used to interconnect devices? Does the solution support G.711? Does the solution support RTP (Real-time Transport Protocol)? Does the solution support G.729a? (narrowband voice with compression) Does the solution support G.722? (Wideband voice) Does the solution support RTCP (Real-time Control Protocol)? Does the solution support MGCP (Media Gateway Control Protocol)? Describe bandwidth requirement to adequately transmit packetized voice conversations. (in IP Telephony) 5.2.2.9 How does the solution's intra-system call quality compare to traditional TDM/POTS service? 5.2.2.10 Does the system support high-definition/wideband voice service? 5.2.2.11 Is the system able to dynamically choose the best codec based on the available call bandwidth? 5.2.2.12 What methods are the proposed systems capable of employing to connect to the PSTN? 5.2.2.13 Describe the product’s support for SIP trunking and SIP endpoints 5.2.2.14 Identify SIP endpoints and trunks that have been certified to work with the system 5.2.2.15 What is the proposed solution's ability to interoperate with existing voice communication resources, such as PBX systems, voice mail systems, conferencing systems, private or public voice networks directly or through software or hardware gateways? 5.2.3 User Features (does the proposed solution support the following features?) 5.2.3.1 Anonymous call rejection 5.2.3.2 Automatic route selection 5.2.3.3 Call forwarding on busy 5.2.3.4 Call forwarding on no answer 5.2.3.5 Call forwarding variable 5.2.3.6 Call hold 5.2.3.7 Call pickup groups (answer a neighbor's phone) 5.2.3.8 Call transfer 5.2.3.9 Call waiting origination 5.2.3.10 Call waiting termination 5.2.3.11 Caller ID 5.2.3.12 Direct inward/outward dialing 5.2.3.13 Directed call pickup with barge-in 5.2.3.14 Directed call pickup without barge-in 5.2.3.15 Hunting features 5.2.3.16 Intercom dialing 5.2.3.17 Multiline hunt service 5.2.3.18 Speed dial 5.2.3.19 Three-way calling 5.2.3.20 Toll diversion 5.2.3.21 Toll restricted line service 5.2.3.22 Trunk answer any station 5.2.3.23 Uniform call distribution 5.2.3.24 Automatic callback 5.2.3.25 Basic circuit switched voice services 5.2.3.26 Bridging 5.2.3.27 Call pickup 5.2.3.28 Delayed and abbreviated ringing 5.2.3.29 Display for ringing call appearances only 5.2.3.30 Drop 5.2.3.31 Feature button inspect 5.2.3.32 Feature function buttons 5.2.3.33 Incoming call display
5.2.3.34 Initiated priority calling 5.2.3.35 Inspect for ISDN terminals 5.2.3.36 Intercom alerting 5.2.3.37 Intercom functions 5.2.3.38 ISDN fast transfer 5.2.3.39 Key system coverage for analog lines (call appearances) 5.2.3.40 Manual exclusion 5.2.3.41 Multiple call appearances 5.2.3.42 Multiple directory number buttons 5.2.3.43 Originating priority calling 5.2.3.44 Shared call appearances of a DN 5.2.3.45 Time and date display 5.2.3.46 Does the solution support redial? 5.2.3.47 Does the solution support distinctive ring internal and external calls? 5.2.3.48 Does the solution offer call parking? 5.2.3.49 Is the solution able to provide visual status of other users' phone status (receptionist)? 5.2.3.50 Is the system able to offer 4 or 5 digit internal dialing? 5.2.4 User Devices 5.2.4.1 What is the end user device you are recommending? 5.2.4.2 What conference phone device do you recommend? 5.2.4.3 Define the power requirements for the handsets. 5.2.4.4 Does you solution support a soft-phone and for what operating systems? 5.2.4.5 Does the solution support a soft-phone running on a virtual desktop such as Citrix or VMware View and a thin client? 5.2.4.6 Does the solution support a USB desktop handset? 5.2.4.7 Does the solution support USB and Bluetooth headsets? 5.2.4.8 What is the maximum number of end points supported? 5.2.4.9 Does your solution support legacy analog telephony devices? 5.2.4.10 How are legacy devices like fax machines and modems handled? 5.2.4.11 Define the minimum cabling requirements to support end devices. 5.2.4.12 Describe the process for qualifying additional third-party equipment 5.2.5 E911 5.2.5.1 Describe how E911 calls will be routed and delivered. 5.2.5.2 Describe how E911 caller location is defined and maintained. 5.2.5.3 Describe how E911 information is dynamically or manually synchronized with the Public Safety Answering Point’s (PSAP) E911 database? 5.2.5.4 Does the system maintain a location log for devices for audit purposes? 5.2.5.5 Is the system capable of simultaneous E911 notification (for example to the building's security office) 5.2.5.6 Can E911 calls be automatically recorded? 5.2.6 Voicemail 5.2.6.1 Describe the voicemail features and limitations. 5.2.6.2 What types of notification can the system provide for new voicemails (message waiting light, stutter dial tone, etc.) 5.2.6.3 Multiple personal greetings (busy, no answer) 5.2.6.4 Message marking (normal, urgent, low priority, confirmation required, future delivery) 5.2.6.5 Message review control (pause, move forward and backwards, speed controls, volume controls) 5.2.7 Auto Attendant 5.2.7.1 Describe the auto attendant features and limitations. 5.2.8 Call Routing 5.2.8.1 What facilities exist for least cost routing in the system? 5.2.8.2 Can certain users be blocked/exempted from certain routes or types of calls (i.e. international)? 5.2.8.3 Does the solution offer basic call distribution or hunt groups?
5.3 5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.3.6 5.3.7
UNIFIED COMMUNICATIONS
Can the UC solution be added at a later date in order to reduce upfront costs? What interfaces are available for managing a user's account? Describe any computer-telephony integration possible with the system. Can the proposed system be integrated with Active Directory? What are the desktop requirements for the UC client? Does the product integrate with Microsoft SharePoint Services (MOSS)? If so, how? Proposed solution should provide a single desktop interface to many or all communication functions, including communication modes and devices, collaboration. 5.3.8 Does the system provide the ability to broadcast voice messages to a list of phone numbers and how does system ensure voice broadcast message delivery and track and report on reception? 5.3.9 Does the system provide the ability to auto dial numbers and deliver a unique message (an appointment reminder for example)? How does the system ensure reception and report on delivery? 5.3.10 Does system allow users to block/disable messages/calls from certain individuals/numbers? 5.3.11 Does the solution support SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)? 5.3.12 Does the solution support Extensible Messaging and Presence Protocol (XMPP)? 5.3.13 Does the solution support Interactive Voice Response (IVR) both for the customer side and the user side? 5.3.14 Enhanced Voicemail 5.3.14.1 What capabilities exist for Voice to Text conversion and delivery via email or other text capabilities? 5.3.14.2 Pager notification 5.3.14.3 Is product able to broadcast voicemail notification to a list of contacts? 5.3.14.4 Does solution allow live monitoring of a voicemail being left and allow user to take call? 5.3.15 ACD 5.3.15.1 Describe the ACD features and limitations. 5.3.15.2 What factors/criteria can be used to control call routing (e.g. voice response, touch tone entry by caller, ANI, agent skill sets, DNIS, etc.)? 5.3.15.3 Does the ACD system support voice recognition as well as touch tone entry of information for call routing purposes? 5.3.15.4 What is the maximum number of ACD agents supported? 5.3.15.5 What is the maximum number of ACD queues/paths supported? 5.3.15.6 Can an agent belong to more than one ACD queue? 5.3.15.7 Can ACD agents be logged in remotely across the LAN/WAN/Internet (e.g. remote office, home office, disaster recovery bunker)? 5.3.15.8 Describe the ACD agent “modes” (e.g., available, work, etc.) defined within the system. 5.3.15.9 Describe how inbound and outbound calls can be recorded. 5.3.15.10 Describe how ACD agent calls from their phone device (station side) can be recorded. 5.3.15.11 Describe how ACD agent calls from the trunk (trunk side) can be recorded. 5.3.15.12 Describe how the ACD agents’ PC screen captures can be combined with the recorded customer conversation. 5.3.15.13 Describe how supervisors can monitor agent calls for quality and training purposes. 5.3.15.14 Describe how and when the system can provide recorded announcements to callers. What is the maximum number of recorded announcements available within any queue? 5.3.15.15 After a configurable amount of time, can the caller transfer to a voice messaging system to leave a callback message? 5.3.15.16 Can the system provide a hold time estimate to a caller in a queue? 5.3.15.17 Describe how the solution provides unified queuing for all media types (e.g. e-mail, fax, Web chat, voice, SMS, EDI, and task). 5.3.16 Follow-Me 5.3.16.1 Describe the solution's follow-me feature 5.3.16.2 How many devices can be defined in the follow-me feature? 5.3.16.3 Does the follow-me feature support simultaneous ringing? 5.3.16.4 Does the follow-me feature support sequential ringing?
5.3.16.5 Does the follow-me feature allow a user to define what devices to ring based on the time of day? 5.3.16.6 Does the system provide a means for transferring a live call between a user’s devices? 5.3.16.7 Does the product support call-screening? 5.3.17 Audio, Video and Web Conferencing 5.3.17.1 Describe the solution’s audio, video and web conferencing features 5.3.17.2 What is the maximum number of simultaneous conferences supported by the Respondent’s system? 5.3.17.3 What is the maximum number of participants per conference? 5.3.17.4 Describe how an authorized user would hold an ad-hoc audio conference. 5.3.17.5 Describe how an authorized user would schedule an audio conference. 5.3.17.6 Describe how the system, though scheduling, or otherwise, will prevent a user, or group of users from over utilizing the system and blocking regular system functions and calling. 5.3.17.7 Is the system able to automatically generate an email invitation that a recipient can easily put on their calendar, with clear instructions on how to join the conference? 5.3.17.8 Can a conference have multiple moderators? 5.3.17.9 Describe how an authorized user would hold an ad-hoc conference. 5.3.17.10 Describe how an authorized user would schedule a conference. 5.3.17.11 Describe how a conference could be recorded, how participants would be made aware that the conference was being recorded, and how it can be made available for replay. 5.3.17.12 Does the system offer video conferencing in a web conference? 5.3.17.13 Are there any additional hardware and software requirements for video conferencing? 5.3.17.14 What are the video conferencing bandwidth requirements? 5.3.17.15 Are there any unique environmental requirements for each conference? 5.3.17.16 Are hardware video conferencing units like the Polycom HDX-7000 compatible? 5.3.17.17 Does the web conferencing feature allow other users to control the host's desktop? 5.3.17.18 Does the web conferencing feature allow other users (not the host) to share their desktop and give control to other users? 5.3.17.19 When sharing a desktop is the user sharing clearly prompted for confirmation before allowing another person to control their desktop? 5.3.17.20 When another user has been given control of someone's desktop is there a failsafe that allows the local user sharing their desktop to immediately and easily regain control of their desktop and prevent the remote user from continuing to control their desktop? 5.3.18 Instant Messaging 5.3.18.1 Describe the solution's instant messaging (IM) features 5.3.18.2 Does the solution provide multi-user chat? 5.3.18.3 Does the IM feature allow sharing of files? 5.3.18.4 Is the IM feature integrated with the other features allowing a chat session to easily be turned into a phone call or web conference for example? 5.3.18.5 Does system support personal and enterprise organized groups for use in Instant Messaging 5.3.19 Outlook 5.3.19.1 Is the system integrated with Outlook/Exchange? 5.3.19.2 Can contact (IM, video, voice, etc.) with another user be initiated through Outlook? 5.3.19.3 Are voicemails available in Outlook (Unified Messaging)? 5.3.19.4 Can users manage their UC preferences though Outlook? 5.3.19.5 Does the product integrate with Outlook's calendar? 5.3.20 Fax 5.3.20.1 Describe the solution's fax features 5.3.20.2 Can a user receive a fax directly? 5.3.20.3 Can a user send a fax? 5.3.20.4 Can a user broadcast a fax to a list of recipients? 5.3.20.5 Can a fax be received in email? 5.3.20.6 Can a group receive a fax? 5.3.21 Presence 5.3.21.1 Describe the presence features the system provides
5.3.21.2 5.3.21.3
Is the presence solution integrated with Outlook/Exchange? Does presence change automatically when user is on the phone or when their PC has been idle for a set period of time? 5.3.21.4 Can another user change someone’s presence status? For instance, can a manager change an employee’s presence status if the employee calls in sick? 5.3.21.5 Can a user manually change or customize their presence status? Describe how this can be done when the user is in the office and when the user is off-site. 5.3.21.6 Does a user’s presence indicate he is on a call even if he answered the call with a secondary or “twinned” device (i.e. cell phone)? 5.3.21.7 Describe how a user can change call routing based upon presence status changes (for any reason). 5.3.21.8 Does the presence engine integrate with automatic call distribution (ACD)? 5.3.21.9 Can the presence solution define presence based on a user’s physical location? If yes, describe how this works. 5.3.22 Mobile/Remote 5.3.22.1 Describe how the solution originates calls from an external device, such as a mobile phone, through the solution to present a single number to external customers. 5.3.22.2 Define the mobile operating systems supported (e.g. BlackBerry, Android, Apple iOS) and the level of functionality provided with each. 5.3.22.3 Describe the architecture for teleworking across the Internet, including all hardware and software components. 5.3.22.4 How does the solution securely extend corporate voice services to a teleworker who might be working from home or a remote location? 5.3.22.5 What additional hardware, software and network services (e.g. VPN) are required to enable a remote worker’s phone to connect to the office telephony system? 5.3.22.6 How does the teleworking solution guarantee voice quality on calls made across the Internet? 5.3.22.7 Describe E-911 support for remote/mobile devices. 5.3.22.8 Are mobile UC clients supported? If so, which mobile operating systems are supported? Explain any differences in functionality between your mobile UC client and your desktop UC client.
5.4
PSTN ORIGINATION AND TERMINATION
5.4.1 5.4.2 5.4.3
Does your solution include PSTN termination? Are their circuit costs or other monthly recurring charges associated with your solution? Provide detail on your outbound pricing plan. Include information regarding local, intra-LATA, inter-LATA, international, international mobile, etc. If you provide a local rate, how is it defined? Does your service have pricing exceptions we should be aware of, such as an 80/20 rule regarding LATA termination? Does your solution provide DIDs? Is there a recurring and/or non-recurring charge for a DID? What NXXs (Exchanges) in the 802 NPA are you able to provide DIDs? Are you able to LNP (Local Number Portability) the State's existing DIDs? Is there a charge for LNP? Are you able to terminate all DIDs in the LATA on one trunk? Are you able to load balance traffic across trunks at each of the State's two datacenters? Are you able to fail traffic over between the two trunks if one drops and are live calls dropped? Are you able to provide toll-free service? Are you able to port the State's existing toll-free numbers? Is there a charge to port a toll-free number? Is there a recurring or non-recurring charge for a toll-free number? What is your toll-free origination pricing plan? Are you able to offer geographically restricted toll-free numbers? How does your call quality compare to traditional TDM/POTS service?
5.4.4 5.4.5 5.4.6 5.4.7 5.4.8 5.4.9 5.4.10 5.4.11 5.4.12 5.4.13 5.4.14 5.4.15 5.4.16 5.4.17 5.4.18 5.4.19 5.4.20
5.4.21 Do you offer reciprocal compensation sharing? 5.4.22 Does the solution support the FCC’s Telecommunications Service Priority (TSP)? 5.4.23 Does the solution support the FCC’s Government Emergency Telecommunications Service (GETS)?
6 REQUESTED INFORMATION The Department encourages, but does not require, inclusion of the elements listed below in each response to the RFI. The vendor, when presenting the response, may use the following outline: • • • •
Cover Page Vendor Information Cost Estimates Business and Technical Requirements
6.1 COVER PAGE The first page of the vendor’s RFI Response must be a cover page displaying at least the following: • • • • • • •
Response of RFI Title Vendor’s Name Contact Person Telephone Number Address Fax Number Email Address
All subsequent pages of the RFI Response must be numbered.
6.2 VENDOR QUESTIONNAIRE Please provide your answers to the stated questions related to the project. Additional information may supplement your answers and must be attached to the RFI response.
6.3 CONTACT INFORMATION All communications concerning the process for this Request for Information (RFI) are to be addressed in writing to the attention of: John McIntyre Purchasing Agent, State of Vermont, Purchasing and Contract Administration Division, 10 Baldwin St, Montpelier VT 05633. John McIntyre, Purchasing Agent is the sole contact for this RFI Response. Attempts by RFI Responders to contact any other party could result in the rejection of their RFI Response.
6.4 RFI RESPONSE SUBMISSION CLOSING DATE: The closing date for the receipt of RFI Responses is 3:00 PM March 05, 2014. Responses must be delivered To: John McIntyre, State of Vermont, Purchasing and Contracting Department, 10 Baldwin St, Montpelier, VT 05633 prior to that time. RFI Responses or unsolicited amendments submitted after that time will not be accepted and will be returned to the vendor. The responses will be received by purchasing at 10 Baldwin St, Montpelier, VT 05633 and will be passed on to Vermont Department of Information and Innovation for review.
RFI responses must include one (1) electronic copy on Compact Disc (CD) and Two (2) Paper (hard copy) responses must also be submitted. Paper copies must be bound with a staple, binder or other appropriate means such that pages are not submitted loosely. Two (2) copies of the RFI must be delivered to the Purchase Agent. The electronic response made to the narrative portion of this RFI must be in Microsoft Word version 2007 compatible format. At least one copy of the Cost Table and Business and Technical Requirements must be made in Microsoft Excel Version 2007 or higher.
6.5 EXPLANATION OF EVENTS 1. Issuance of RFI This RFI is being issued by the Office of Purchasing and Contracting of the Department of Buildings and General Services. Additional copies of the RFI can be obtained from the State Purchasing Division web site http://bgs.vermont.gov/purchasing/bids or directly from the State Purchasing Agent. 2. Deadline for Written Questions Potential respondents may submit questions regarding this RFI. Questions must be submitted in writing, by e-mail, to the Purchasing Agent John McIntyre at
[email protected] and must be received by 4:30 PM Eastern Time on February 13, 2014. 3. Response to Written Questions Any vendor requiring clarification of any section of this request for information or wishing to comment or take exception to any requirements or other portion of the RFI is encouraged to submit specific questions in writing no later than February 13, 2014 at 4:30PM. Questions may be e-mailed to
[email protected]. Any objection to the RFI or to any provision of the RFI, that is not raised in writing on or before the last day of the question period is waived. At the close of the question period a copy of all questions or comments and the State's responses will be posted on the State’s web site http://bgs.vermont.gov/purchasing/bids. Every effort will be made to have these available as soon after the question period ends, contingent on the number and complexity of the questions. 4. Submission of Responses Two (2) paper copies of the RFI response and one (1) electronic copy on CD should be delivered to the Purchasing Agent no later than 3:00 PM Eastern Time on March 05, 2014 Responses received after the due date and time may not be considered. Responses should be labeled, "Response to RFI “Vermont Telephony Services”. 5. Review and Evaluation of Responses The review and evaluation of responses to the RFI will be performed by Vermont Department of Information and Innovation and their designees. The evaluation process will take place the week following the response due date. During this time, the RFI Manager or other Vermont Department of Information and Innovation representatives may, at their option, initiate discussion with respondents for the purpose of clarifying aspects of their responses. 6. Vendor Demonstration of Their Proposal Vendors chosen from the review process may be called on to demonstrate or provide more information about their proposals. The Vermont Department of Information and Innovation shall not be liable for any costs incurred by the vendor in preparation of its demonstration. All costs occurred are the vendor’s sole responsibility. All such demonstrations are for planning purposes only and do not constitute a legal bid. 7. Vendor Proposal Test Trial
Certain Vendor proposals may be selected after review process to be trialed by Vermont Department of Information and Innovation if this is an option allowable by the vendor. The selection of vendor proposals for a test trial does not commit the Vermont Department of Information and Innovation or the State of Vermont to award a contract.
7.0 ADDITIONAL MATERIALS Please provide any other materials, suggestions, cost, and discussion you deem appropriate.
