request for proposal (rfp) - calabasas · request for proposal (rfp) upgrade existing . ......

Request For Proposal (RFP)

UPGRADE EXISTING TELECOMMUNICATION SYSTEM FOR THE CITY OF CALABASAS

Issued on May 13, 2014

COMPLETED PROPOSALS SHALL BE DELIVERED TO:

City Clerk’s Office City of Calabasas 100 Civic Center Way Calabasas, CA 91302

CITY OF CALABASAS IP-BASED TELECOMMUNICATIONS RFP

REQUEST FOR PROPOSAL Purpose The City of Calabasas (The City) currently has a Cisco Call Manager VoIP Telecommunications system that was installed in 2008. The City has determined that the existing system provides many of the features and functions that it needs, but the core software and hardware for the telephone and voicemail system is at end of life and no longer supported. This situation can cause repair delays in the event of an outage. To address this issue, The City has decided to obtain proposals from qualified Cisco dealers to provide the needed software, hardware and labor to upgrade the core of the existing communications system and voicemail system and retain the existing telephone handsets. Specific Cisco software, hardware and labor required shall be determined by the Certified Cisco Partner. The City requires the Cisco Partner to be a Gold Certified Cisco Partner. This Request for Proposal (RFP) document describes the requirements of The City for an IP-based telecommunication system. All features/functions discussed in this RFP shall be provided in the proposed solution unless specifically noted. The proposed IP telecommunications system shall support all the required call processing, voice and unified messaging, system services, management and administrative feature requirements stated in the RFP. In addition, the proposed IP communication system must be capable of meeting a 20% growth in users without major hardware and/or software upgrades. This Request for Proposal (RFP) is intended to provide a standard base from which to evaluate alternatives for the telecommunications system and to allow the Respondent flexibility in proposing the most appropriate and cost-effective system. It is the responsibility of the responding Respondents to address all aspects of this RFP. As indicated, each page of the RFP response shall be initialed and dated by the Respondent. This document contains the system specifications and the requested format for vendor proposals. If additional features or equipment are believed to be appropriate for The City’s operations, please quote them as options and include supporting justification and cost detail. The City reserves the right to the following:

• Accept the Proposal that is, in its judgment, the best and most favorable to the interests of The City,

• To reject the low price Proposal, • To accept any item of any Proposal, • To reject any and all Proposals, • To waive irregularities and informalities in any Proposal submitted or in the Request for Proposals

process.


Price of hardware, software, installation and maintenance shall not constitute the primary, central, or overriding reason for award of contract. All equipment and software shall be new and of current production. Reconditioned, remanufactured, demo models shall not be accepted. Respondents should possess and use their extensive knowledge and experience in designing, implementing, and maintaining Cisco IP-based telecommunication solutions that will meet or exceed The City’s requirements as stated in this RFP. Preference will be afforded to the Respondent that provides the most comprehensive, cost-effective solution for the needs as it relates to the specifications, future capacity requirements, and ongoing service and support.

1. RFP RESPONSE SCHEDULE AND FORMAT

1.1 Schedule of events: The established schedule for the RFP process follows.

Request for Proposal Issued: May 13, 2014 Pre-Proposal Meeting: May 19, 2014 at Calabasas City Hall, at 1:30pm Last Day for Questions/Clarifications: May 20, 2014 RFP Response Due: May 27, 2014 System Delivery Date: June 19, 2014 System In Service Date: June 30, 2014

The Pre-Proposal Vendor Conference will be held at the City Hall facility:

City of Calabasas 100 Civic Center Way Calabasas, CA 91302

1.2 Proposal Outline: Respondent proposals shall contain three components. The first being the

technical response to the RFP, the second being a detailed spreadsheet detailing costs for all included components, and recommended optional equipment, and all associated labor costs as well as the pricing tables completed.

The proposal shall follow the following organization:

• Letter of Introduction – Include a recent Financial Statement signed by the

authorized Respondent’s representative and Proof of Insurance. • Include five reference projects of similar scope, using the proposed equipment and

software, completed within the last two (2) years. • Describe the proposed System. • Provide detailed responses to all questions on RFP indicating either compliance or

exception. • List specific equipment included in the proposed system, and a schematic diagram of the

complete system. • Describe the installation and installation process. • List the installation team’s technicians and engineers. Include their manufacturer’s

certifications and related project qualifications.


• Confirm the installation timeframe and identify any anticipated deviations from RFP

implementation timeline. • Describe the initial training provided (user and system administration), and provide

training course descriptions and associated costs for additional training. • Describe the Maintenance and Warranty information.

Each section/item starting at the beginning should have an appropriate response such as “read and understood and included” or the pertinent information requested.

The proposer should address each point listed in the document directly below the numbered point. In this way, The City will be able to discuss the specific information requested and review the specific response without a cumbersome matching process. This includes all sections and points in this RFP.

2. RFP EVALUATION CRITERIA

RFP submissions shall be evaluated on the following general criteria. It should be noted that The City reserves the right to disqualify any bid that is not complete, or fails in any evaluation category:

Complied with Format Complete Proposal and Letter of Introduction

PASS/FAIL

Overall system design and adherence to RFP

15

Installation procedures and personnel Installation timeframe System Testing/Turn-up

15

System training After Sale Support – Warranty, Maintenance, Upgrades

20

Similar Projects – References – Company Experience

20

Pricing (Provide Pricing in Separate Envelope)

30

Total Points Available 100


3. SELECTION, NOTIFICATION, AND AWARD OF CONTRACT

• The City reserves the right to clarify any of the terms and conditions of the RFP • The City reserves the right to request clarifications of any response submitted. • A designated committee will evaluate all proposals submitted in response to this RFP. • The recommendation of award will be made to the Respondent who best meets the needs

of The City. • The City will notify the successful Respondent in writing, should a contract be awarded. • A contract shall be developed which will incorporate in its provisions this RFP, and the

successful response. • All respondents will be notified whether their response has been accepted or not.

3.1 Duration of Quotations

The base price of the proposed solution will be in effect for a minimum period of 120 days after the submission of the response to the RFP. Unit prices quoted shall be in effect for 12 months.

3.2 Contractual Relationship

The contents of the proposal and this RFP are to be considered part of the Contract between The City and the selected contractor.

3.3 Any material submitted by the Respondent considered confidential in nature must be

clearly marked as “CONFIDENTIAL”. • Even if the Respondent completes the notification as noted above, they are not

relieved of responsibility. • If the Respondent fails to notify as noted above, this will become a basis for determining

whether the Respondent is negligent or not. • If the Respondent is found to be negligent by causing delays in the completion of the

project, penalties will be assessed as described in the final contract.

3.4 Delay of Schedule

When the selected Respondent knows of problems that can possibly delay the completion of the project, the Respondent will notify the authorized person(s) as defined in the final contract, providing reasons why the delay will occur, the new completion date and options.

3.5 Laws, Ordinances, and Codes

All applicable federal and state laws and the rules, regulations, codes, and ordinances of all local authorities having jurisdiction will apply to the Contract throughout. They will be deemed to be incorporated in the Contract.

3.6 Exceptions and RFP Substitutions

Any Respondent who finds a more cost-effective/elegant solution to complete the required design performance of this RFP may take exception, and/or make a recommendation for a


substitution, to any portion of this RFP prior to the RFP’s close of questions date.

An exception/substitution can only be made after all requirements of this RFP are met. These exceptions/substitutions will be fully documented showing any changes that are recommended, and the cost savings or technical benefit created.

The City shall provide written authority prior to any Respondent requesting to make any such changes. The evaluation of any exceptions/substitutions will be based on the RFP evaluation criteria described herein.

3.7 Other Terms and Conditions

Respondent should make every attempt to use terminology in their response that is defined in the RFP. If other words, phrases, or descriptions are used, definitions should be included. In case of conflicts, those definitions noted in this RFP will apply.

3.8 Reliance and Certification

The City requires the proposing vendor to be a Gold Certified Cisco Partner and relies upon the Respondent as an expert, fully competent in all phases involved in producing, testing, developing, installing, modifying, altering, servicing, and integrating the equipment and or systems furnished as part of their proposal. In this context, the Respondent agrees that it will not deny any responsibility or obligation to The City on any grounds.

More specifically, and without limiting the above, The City in originating, furnishing, or approving any specifications, drawing, plan, change, schedule or other document or part thereof, or any test report or in accepting any networks, neither accepts responsibility for nor relieves the Respondent from the performance of all terms and conditions of this RFP and contract that may be awarded.

4. Telecommunications System Features and Function Requirements

The following is a listing of features/functions/performance requirements.

4.1 IP-based Voice capabilities and Intelligent Network Infrastructure: The system shall

provide the integration of voice applications with an existing converged Internet Protocol (IP) solution. It shall be highly reliable and readily available switching system, support a wide variety of interfaces to the PSTN and legacy TDM equipment at remote locations, and shall include all hardware and software to support analog and IP phones for all user locations (local and remote) including end-users, modems, fax machines, conference rooms, etc.

4.2 Reliability: The system shall not have a single point of failure, and shall provide a local and

SRST remote back-up mode in which outbound and inbound calls can be made in a WAN data network failure. The system shall demonstrate a minimum of five-9’s reliability.

4.3 Existing Data Network - The existing network equipment includes all Cisco data switches. These switches are fully operational and provide the needed network throughput for the existing Cisco telecommunications system. The City anticipates retaining these


same data switches.

4.4 Existing Telephone Handsets – The City intends to retain all of the existing telephones and use them with the new updated Cisco software and hardware proposed.

4.5 Remote Locations - System attached phones in remote locations must maintain all features in the event of WAN outage. The Proposed system should be configured to have all phones operational in event of a power outage. While the system will be supported by UPS power, emergency operation in the event of power outage shall also be described and included in the response.

4.6 Under this procurement The City will accept proposals for a Cisco Call Manager, Unity Connections and appropriate software VoIP solution from any Cisco Gold Certified Partner capable of meeting both the voice and data communications requirements detailed in this proposal.

Location Street Address Survivable

City Hall

100 Civic Center Way

Library

200 Civic Center Way

4.7 Current Software Release: All system software components shall be maintained by the Respondent at the latest release level for a minimum of 1 year following acceptance of the system (2 years preferred).

4.8 Voice Quality: The system shall provide “toll quality” voice.

4.9 Cable Infrastructure - The cabling infrastructure of the facility is a Panduit certified

Category 6 copper/fiber optic based system, and the LAN hardware infrastructure is a VOIP certified, “Level 3”, POE switching network.

4.10 Respondent Experience and Vision: The City prefers to engage a Gold Certified

Cisco Partner. The City will evaluate the Respondent's experience in the engineering, implementation, and support of IP-based telephony systems and networks.

4.10.1. Company and technician certifications and experience shall be documented as required.

4.11 Voice Messaging: Scalable, cost-effective voice messaging solution that supports industry standards for both analog and VOIP handsets and desktop access, and supports unified messaging with desktop email solutions.


4.12 Unified Messaging: The proposed system should provide the ability for The City to integrate

voicemail and email, outlook contacts and calendaring tools into the proposed system’s features and services. It is the responsibility of the Respondent to define their offering, and to provide a solution that addresses the convergence of voicemail, e-mail, fax, and other messaging systems. Systems to be addressed will include those provided under this RFP and messaging systems maintained by The City. The City currently has Microsoft Outlook 2010 and Exchange Server 2010 implemented.

4.13 Paging System Interface: A Bogen multi-zone paging system is installed in the facility and is

operational in the Library. The VOIP system shall provide a level of connectivity to the paging system that will allow any user, on any type of handset (analog or VOIP), to access the Bogen system dial-tone, and place intercom calls to any zone in the facility.

4.14 Telephone System Paging System – The proposed system should also provide the ability for users with the appropriate rights to perform paging through the speakers on the telephones. The System should provide the ability for a user to dial a code and page through all phone speakers or a zoned subset of speakers.

4.15 System Administration: A single point of management from any point on the network for all

components including the IP-PBX, voicemail, auto attendant, ACD and unified messaging system, and other ancillary systems is preferred. The management interface shall provide the capability and flexibility for rapid, efficient, and cost-effective configuration changes to user profiles and IP telephone equipment through a standard browser-based interface. System “Self Diagnostics” and trouble reporting shall also be described.

4.16 Respondent Support/Service Capabilities: Demonstrated capabilities in Trouble Desk operations, trouble reporting, dispatch, and tracking. Qualified/certified technician support of all IP-PBX systems, networks, and applications. Describe and cost all support options.

5. EVALUATION TEAM AND PROCESS

5.1 Project Team: A City lead evaluation team will review all submitted proposals. Any RFP

addenda will be issued by the City Clerk’s Office. All questions shall be directed to:

Ms. Rachel Biety Executive Assistant Media Operations Department City of Calabasas 100 Civic Center Way Calabasas, CA 91302 P: (818) 224-1630, ext. 636 F: (818) 225-7363 [email protected] www.cityofcalabasas.com

Any contact or attempt to contact any other employees of The City that could be interpreted as being made for the purpose of securing privileged information or advantages in the bid process

http://www.cityofcalabasas.com/


will result in the immediate disqualification of the Respondent.

5.2 Submittal: Three (3) hard copies of the proposal and one (1) soft copy of the proposal on a thumb-drive shall be submitted for consideration to The City by 5:00 p.m., Tuesday, May 27, 2014. Proposals shall be submitted using the format previously described and sealed in a package with “Calabasas Civic Center IP-Based Telecommunications RFP” and the Respondent’s name and address clearly indicated on the front of the package.

PLEASE NOTE: After each item in this RFP, vendors should respond with any details to describe the information requested, and READ, UNDERSTOOD AND INCLUDED. Should the Respondent wish to clarify/comment on any section of this RFP; the comment shall be inserted into the response below the section, and highlighted. Additionally, any modifications to the questions in this RFP by the vendor may result in immediate rejection of that proposal.

5.3 Completeness of Response: All vendors must respond on compliance to all required features,

functions, and/or performance issues. Incomplete submissions will not be accepted.

5.4 Award: The selected firm’s proposal will be submitted to the City Council for consideration of award. The decision of the City Council is final.

5.5 Respondent/Equipment Questionnaire: All requested information shall be provided as

indicated. Additional background information shall be provided as an attachment to the RFP response:

Company Name: Address: Sales Representative Name: Telephone Number: E-mail address:

5.5.1. System Information

5.5.1.1. Who manufactures the proposed system/sub-systems? 5.5.1.2. Does the proposer install the product or use business partners? (If “YES”, please

provide all contact information described above) 5.5.1.3. Who will provide maintenance services 5.5.1.4. Is there a call-in “Trouble Desk” operation? Describe function and process. 5.5.1.5. What options are there for on-site support? 5.5.1.6. The Respondent must submit five reference customers. Reference information

must include company name, contact, telephone number and approximate size of installed system at each reference site.

6. SYSTEM REQUIREMENTS

All vendors shall respond to all listed features/functions/performance issues. Compliance/non- compliance shall be indicated, and additional information/explanations can be cross-referenced in an attachment to the response. Incomplete submissions will not be accepted.


6.1 System Features:

6.1.1. A network enabled UPS shall be provided to provide battery backup for the system and ancillary systems included in this RFP. The UPS shall operate for a minimum of 4 hours in the event of a power interruption.

6.1.2. Ability to function as a part of a network with a centralized voice mail system, and call accounting system, including the ability to light message waiting lights at each handset.

6.1.3. Three or Four-digit dialing to all sites on the network. 6.1.4. Audible Reminder of calls on hold. Provides an audible tone as a reminder that calls are on

hold on a user’s station. 6.1.5. Authorization Codes. Allows selected users to temporarily override the access restrictions

assigned to any station or trunk by dialing an authorization code. 6.1.6. Autodial. Allows users to dial a number by pressing a single key. 6.1.7. Automatic Answerback. Allows an incoming call to be answered automatically via the

hands free option on the digital telephone. 6.1.8. Automatic Call Distribution. Distributes incoming calls among a designated group of

telephone sets on a “most available station” basis. State any and all limitations of your system’s basic package with regard to:

6.1.8.1. Number of ACDs available 6.1.8.2. Number of agents or stations per ACD 6.1.8.3. Queue size and duration

6.1.9. Automatic Line Selection. Allows the user to automatically answer a predetermined line by lifting the handset.

6.1.10. Automatic Number Identification. Define the system’s capabilities to provide ANI to the station user as well as provide station user information to the Central Office.

6.1.11. Automatic Route Selection. Allows an outgoing call to be automatically completed by the least expensive route available. The system shall allow, by time of day, the automatic routing of outgoing calls over the most economical facility available. The system shall be fully compatible with the North American Numbering Plan and allow at least 20-digit screening/routing capability. Access to and administration of the routing plan shall be from the System Administration Terminal/workstation.

6.1.12. Bridging. Allows station numbers to appear and work simultaneously on another telephone within the system (1A-key emulation). State any system limitations.

6.1.13. Call Coverage. Allows calls to be forwarded to internal or external numbers. If any call is not answered at preselected destination, the call will be returned to voice mail. Discuss the impact on port utilization.

6.1.14. Call Accounting System and Call Detail Reporting – Please provide a proposal for a call accounting system. Please itemize the cost of the system in the Optional Equipment table later in the RFP. Please provide the following information regarding the proposed Call Accounting System:

Describe the specific relationship with the manufacturer.

Include the cost of the recommended product in the detailed pricing.


Reports for the proposed call accounting system should provide the ability for The City to obtain reports providing calling activities for all stations, allocate calling expenses to various departments, length of calls, frequency of calls to a specific number, internal station to station calling, etc. Please describe the functions of both the proposed system(s).

The proposed telecommunications system and Call Accounting System should provide the ability for The City to obtain call accounting information for both outgoing and incoming calls. Please provide a description regarding how the system can provide this function.

The City would also like to be able to gather information regarding internal station-to-station calling. Please describe the proposed system’s capabilities to provide this capability.

Please define if the proposed system is hosted and if so the specific operation, location and method of connectivity.

Your description should also include any monthly costs. Please provide details.

6.1.15. Provide pertinent information regarding the system’s CDR port. Information shall include: 6.1.15.1. Data Stream Layout 6.1.15.2. Port Speed Options 6.1.15.3. Type of Call -in/out/out toll/internal 6.1.15.4. Number Of Digits Allowed Per Field

6.1.16. Call Forward All Calls/Busy/No Answer. Allows a station’s incoming calls to be

automatically forwarded to a preselected destination. This will allow forwarding to internal and external numbers.

6.1.17. Call Forward Reminder Tone. Provides analog telephone users an audible tone to remind the user that their station is in the call forward mode.

6.1.18. Call Routing by Time of Day and/or Access Code or Designated Button. The system shall allow The City to program times where outside calls can be directed to individuals, and/or departments by the Automated Attendant. At other designated times; outside calls shall be directed from the Automated Attendant to the voice mailbox of the called party. This feature will not affect internal calls.

6.1.19. Call ID. System allows a reference number or tag associated with each call during its entire lifetime on the system (not to be confused with Caller ID).

6.1.20. Call Join. Allows calls already existing on separate lines on a digital telephone to be conferenced together.

6.1.21. Call Park. Places a call in a parked state, similar to hold, where it can be retrieved by any attendant console or by another telephone. State any system limitations.

6.1.22. Call Party Name Display. Identifies the calling or called party by name. The capability to block this feature shall be available on a station-by-station basis.

6.1.23. Call Back Queuing. Allows callers to hang up upon receiving a busy condition when attempting to access a trunk resource in the system. The system automatically calls back the station when the trunk becomes available.

6.1.24. Call Pickup. Allows a group of telephones to answer a ringing station in its group through the use of either an access code or a programmed pickup button.


6.1.25. Call Recording – The City would like to allow some users throughout the system to

record calls on an ad hoc basis. 6.1.25.1. Record button placed on specific phones allowing the user to press the button at

any time on a call and record the balance of the call. However, the portion of the call that occurred before the button was pressed is not recorded.

6.1.26. Call Transfer. Allows a telephone user to transfer a call to a third party. That transfer should be allowed to an external number as well.

6.1.27. Calling Line ID in CDR. CLID number is included in Call Detail Recording (CDR) records. 6.1.28. Centralized Attendant Service. Allows customers with multiple locations to centralize

their attendant services at a single location. 6.1.29. Class of Service. Each station must be capable of variable assignment of features and calling

privileges. The variable class of services shall be easily administered from the on premise system administration terminal. Discuss the process of administering and changing the parameters associated with each class of service. Describe the system’s capability to establish line restrictions through the use of multiple classes of services. The classes of services allowed would include restriction to trunk access. A minimum of 25 classes of services shall be allowed.

6.1.30. Conferencing – The City would like the vendors to propose two types of conferencing capabilities.

6.1.30.1. Ad hoc conference capabilities allowing individuals to establish conference calls including any combination of internal and external users up to a total of 10.

6.1.30.2. Conference Bridge Tool – Allows The City to schedule conference calls with any combination of internal or external users up to 20. This system should also interact with Outlook allowing City employees to schedule a meeting and the system will populate the meeting notice with the call in number as well as the participant pass code.

6.1.31. Computer Telephone Interface (CTI). Allows for the transfer between a computer and the system of call record information. Must be compatible with Lightweight Directory Access Protocol (LDAP). What other standards does the proposed system support? (See list in following section.)

6.1.32. Controlled Class of Service. Alters the Class of Service restriction levels on telephones. 6.1.33. Direct Inward Dialing (DID). The system must support direct dialing of extensions from

outside parties. 6.1.34. Directed Call Pickup. Allows a caller from one Call Pickup group to pick up a specific

ringing call by dialing that station’s extension number. 6.1.35. Distinctive Ringing. Provides a difference in the cadence of the set ringing to distinguish

internal calls from outside trunk calls. The system shall provide this feature. 6.1.36. Do Not Disturb. Allows the station user to place their station in the “Do Not Disturb”

mode. Discuss the ability to restrict this feature by class of service, and any executive override feature.

6.1.37. Forced Account Codes. Temporarily overrides Class of Service restrictions for toll-denied users and provides the account code as part of the CDR data stream. State digit minimum and maximum.

6.1.38. Group Call. Allows a user to place a call to multiple system users simultaneously through single key or dial access code activation. State system limitations.

6.1.39. History File. System shall automatically keep a record of maintenance problems it uncovers


during its diagnostic process. The records should be maintained a minimum of 24 months. How long is the history file maintained? Describe the record process.

6.1.40. Hold in Queue for IVR. Allows the redirection of a call to an Interactive Voice Response Unit, Voice Mail or Automated Attendant service and retain control of the call.

6.1.41. Hot Line. Allows designated analog stations to place calls to a predetermined destination simply by going off-hook.

6.1.42. Intercom Groups. This allows dialing other stations in a pre-designated group with a one- or-two digit number. Describe limitations, system features and restrictions that can be set up for intercom groups.

6.1.43. Last Number Redial. Allows the last number dialed by a user to be automatically stored. 6.1.44. Make Set Busy. Allows a telephone to appear busy to all incoming calls. 6.1.45. Malicious Call Trace. Allows users to activate a call trace that results in a printed report of

the calling and called parties. State procedure to activate and provide information on any system limitations.

6.1.46. Unified Communications. Please define this term for your proposed solution, and detail the levels of integration available, and associated costs.

6.1.47. Message Waiting Indications. Provides for Message Waiting Indication to be activated within the system, across a private network or across the public switched network. State the system’s limitations.

6.1.48. Mobility Tools 6.1.48.1. Please include the ability for all system users to use Twinning. Allows users to

move calls seamlessly from mobile device to desk phone and back. 6.1.48.2. Advanced Mobility Application – Allows users to load a Cisco app on their smart

phones allowing them to have call control and system features provided by the Cisco Call Manager on their mobile device.

6.1.49. Multiple Appearance Directory Number. A telephone number appears on more than one telephone. This can allow a single-line telephone to have more than one telephone number. Discuss the operation of this feature if the telephone is in use during the period an incoming call is made. What other alternatives are available to insure all calls are answered appropriately.

6.1.50. Multi-Language. List the languages supported by the system for digital telephone displays. 6.1.51. Music on hold. Describe. Are multiple music sources supported? 6.1.52. Night Service. Permits incoming calls normally directed to the attendant to be routed to a

defined destination. The system shall provide the ability to route in the following ways - selected trunks to selected stations, all trunks to one station, or all incoming calls to one common alerting device (ringer). Additionally, different patterns shall be allowed to be established by the administrator / attendant to satisfy different night, holiday or weekend night service answering needs automatically.

6.1.53. Override. Allows a user to enter into an established connection. A warning tone is sent to the established connection.

6.1.54. Phantom Extension Operation. Gives users the ability to configure phantom extension numbers (e.g. “roll over” numbers) without purchasing any associated hardware (line cards, shelves etc.). This capability shall also be incorporated into the unified messaging system.

6.1.55. Priority Queuing. Allows users on a class of service basis to have priority when placed in queue for busy trunk facility and feature activation.

6.1.56. Private Line Service. Enables the customer to assign private Central Office lines to selected digital telephones.


6.1.57. Recorded Announcements for night answer and night greeting. 6.1.58. Recorded Overflow Announcement. Allows delayed calls to the attendant to be connected

to a recorded announcement notifying the calling party of the delay. 6.1.59. Recovery of uncompleted Call Transfers. Prevents external calls from being dropped due

to a station user’s incorrect operation of transfer feature. 6.1.60. Ring Again (Busy Redial). Provides the station user the opportunity, after encountering a

busy station, to have the system monitor the station and ring the station again when it becomes free.

6.1.61. Secretarial Coverage Forwarding. Allows a station user to forward all external incoming calls to a second telephone. If the user at the second telephone cannot address the caller’s needs, the call can be internally transferred back to the forwarding telephone, or to another number at the user’s discretion.

6.1.62. System Administration Terminal Access. The SAT shall be LAN-based MS Windows equipped personal computer, loaded with appropriate administration, maintenance, traffic and service change software programs for the system as well as any other system application programs such as Voicemail, Automated Attendant, Call Accounting, Unified Messaging, and the like. The vendor shall include costs for providing the hardware and software, or just the software alone.

6.1.63. Speed Dialing. Allows a station user to place calls by dialing a one-two-or three-digit code or a programmed digital set button. State the system’s total capacity and individual capabilities to provide Personal, Group or Department, and System lists. All three speed call lists shall be available on all handsets.

6.1.64. Station Camp-On. Allows the attendant and/or a station user to transfer a call to an active station. Caller shall hear ringing while the station to which a call is placed hears an audible tone indicating the call waiting.

6.1.65. Station Priority Indication. Allows an attendant to selectively answer internal attendant calls on a priority basis.

6.1.66. Station Specific Authorization Codes. Allows a telephone user to override normal restrictions by using an authorization code for special access. Station Specific Authorization Codes enable the system administrator to control the level of authorization code access on a per-telephone basis.

6.1.67. Stored Number Redial. Allows telephones and attendant consoles to store one previously dialed number for automatic redialing. Is the same as “Last Number Redial?”

6.1.68. System Message Lookup Alarms. Allows customer to perform on-line look-ups of system alarm messages while providing a description/explanation of same.

6.1.69. Three-Party Service. Allows a user of an analog telephone to toggle between an active party and a held party, form a conference between them, or release the active party and reconnect to the held party.

6.1.70. Time and Date. Must be displayed on all display telephones and should be able to be administered from the attendant console as well as the system administration terminal.

6.1.71. Time and Date Routing. System shall have the ability to, on a class of service basis; automatically change the routing of calls and/or the Class of Service of a station on a time and/or date basis. Describe the feature.

6.1.72. Trunk Verification from a Station Telephone should be able to seize a particular trunk within a trunk group, receive a dial tone and outpulse digits for test purposes.

6.1.73. Voice Activated Call. Permits automatic speaker activation to the called party when making an internal call. Provide details on the operation of this feature if the called party is on


another call. 6.1.74. World Routing. Dialing plan should meet the requirements of global numbering plans. The

system shall be national and international dialing plan compliant. How many area codes can the system accept? Is there a restriction on the number of digits the system can process? The vendor is to provide updates to the proposed systems routing plan whenever area codes and prefixes are added.

6.2 Disaster Recovery

6.2.1. Describe how the system addresses reliability, resiliency, and/or redundancy for the overall system, and ancillary systems?

6.2.2. Describe the sequence of operations if there should be a failure of a call processor. 6.2.3. Describe the sequence of operations if there should be a failure of a WAN connection. 6.2.4. Describe the sequence of operations if there should be a failure of an edge router/call

processor.

6.3 System Configuration -

The City’s Current VoIP Setup

CISCO

7945 IP Phone

CISCO 7965 IP Phone

CISCO 7913

sidecard

CISCO 7921

Wireless IP Phone

Attendant Console

PRI Analog Trunks

City Hall 98 17 3 4 1 1 4

Library 15 0 0 1 0 0 4

Total 113 17 3 5 1 1 8

Table 3.3.1

6.4 Unified Messaging System

The proposed system must include a Unified Messaging System (UMS) to support all users at The City and provide the ability to network to other locations via the WAN, to provide services to another site, or network to a UMS located at that site. Define your solution and describe the functionality that includes the following:

6.4.1. The UMS will record speech to text as well as text to speech for distribution. 6.4.2. Detail any options for Fax Management. 6.4.3. The UMS will include provision for accessing voicemail messages locally and remotely

through a standard DTMF phone. 6.4.4. Describe in detail your voice messaging product offering. Include an overview of the

hardware, software, architecture and all components. Include information on


recommended storage, message management options for users (features, distribution lists, alternate greetings, etc.), auto attendant features, IVR capabilities (if any), number of ports needed to support the system, etc.

6.4.5. Describe how the System Administrator accesses the UMS administration application. What specific information does the administrator have available, such as passwords, class of service, adds, deletes, modifications, backing-up the system, etc. for ease of administration.

6.5 Automated Attendant

6.5.1. Provide functional descriptions and illustrations of the automated attendant system. 6.5.2. The system shall provide dedicated services to City Hall, Library and to remote sites. 6.5.3. The system shall be sized based on the configurations provided.

6.6 System Software/Administration

6.6.1. Administer multiple remote sites through a centralized workstation. 6.6.2. Multiple level password protected access. 6.6.3. Multiple levels of administrators with each having different capabilities of system access and

each with a unique password. 6.6.4. Ability to track administrator activity in detail. 6.6.5. The system administration application accessible from any workstation on the LAN. 6.6.6. Multiple levels of security. How many levels of security can be defined? Can some

administrative users be defined with “view-only” permissions? 6.6.7. Define the support that is provided with this system (Help Desk, after hours availability,

costs etc.). 6.6.8. How does your company provide future software releases? How are software upgrades

performed? What costs are associated with future upgrades? As per the RFP, all upgrades for a minimum of 1 year (and preferred 2 years) following acceptance of the system shall be included.

6.6.9. When system or station software updates are performed, must the system be shut down, or can these types of activities take place in an on-line environment?

6.6.10. How frequently does the manufacturer recommend that the operating system software, which includes up-to-date moves and changes, be backed up? How is the backup scheduled, and can the backup be done from a remote site?

6.6.11. What changes can the telephone user make as opposed to requiring the system administrator?

6.6.12. Can a single installation command from the administration tool be used to manage all local and remote system locations within an enterprise simultaneously?

6.7 Voice Mail

Required System Features:

• Ability to support multiple system prompts to greet callers with a ring no answer message or a busy message.

• System must support a “zero out” to the attendant to another user defined station. • Users must be required to enter a password to access their voice mailbox.


• Provide notification that the limits have almost been reached in regard to the maximum total number of minutes of messages than can be stored in a single voice mailbox.

• Require a system administrator password. • Ability to Stamp each new message with a time/date. • Ability to access voice mail remotely. • Ability to allow remote change of greetings and passwords. • Ability to easily transfer a caller directly to an internal voicemail. • Ability to easily access and manage voice mail from a mobile device.

Required User Features: • Obtain user instruction through system prompts. • Record messages; send and mark “urgent”, “private”, etc. • Transfer messages to other users and append them with their own comments. • Modify own passwords. • Ability to record multiple greetings for internal and external callers, out-of-office

greetings, etc.

Required System Administration Features: • Add or modify a class of service. • Assign default passwords for users, and reset passwords for users that have been

locked out of their mailboxes. • Add, delete, or modify a user. • Ability to run detailed reports on system utilization by dates, times, extensions, etc.

Additional Questions: • What user permissions or characteristics within a class of service can be created or

modified? • How would the system administrator perform a backup and restore on the voice

messaging system? • What would be involved to install unified messaging to your proposed system at a

later date? • Are voice messages stored in an industry standard format? • How does your system handle a full mailbox? • What types of reports does your system provide? Please include examples.

6.8 911/ E-911 Support

6.8.1. Provide quote for Cisco Emergency Responder. 6.8.2. Define the capabilities of the proposed Cisco system related to 911 and E911 support.

6.8.2.1. Is the proposed system in compliance today? 6.8.2.2. Is the proposed system able to direct emergency workers to the building and room

originating a 911 call? 6.8.2.3. Identify the system’s ability to redirect callers who dial “911” or “9,911” to a

predetermined location; i.e., security desk, operators console, etc. 6.8.2.4. Describe the method used by the system for providing station information and

updating the 911 PSAP database for additions, moves and changes.


6.8.2.5. Allow users to call either 911 or 9+911 to reach emergency services. 6.8.2.6. Provide an option to allow each and every site on the network to be able to place a

911 call that will send the correct address for the site. This feature is critical for the networking of remote sites.

6.9 Music or Messaging on Hold

6.9.1. Ability to provide music or prerecorded messages through the VOIP system. 6.9.2. What are the requirements to provide music or pre-recorded messages on hold to each of

The City locations? 6.9.3. Provide the ability of providing a minimum of 15 pre-recorded messages, totaling a

minimum of 45 minutes of messages.

6.10 System Monitoring and Diagnostics 6.10.1. Provide system monitoring reports. 6.10.2. Shall be scalable to support from 100 to 300 users. 6.10.3. Shall support a minimum of 4 remote locations with transparent feature access. 6.10.4. What remote diagnostics are available? Can administrators see and access any alarms or

alerts from remote terminals? 6.10.5. What information is included in your system monitoring reports? If they are not currently

supported, are there any plans in a future release to include them? Any foreseen limitations from these reports?

6.10.6. Does the system provide system alarms and alarm notification? 6.10.7. Describe the IP call processing hardware platform in detail. Is it based on industry standard

hardware, or is it proprietary? 6.10.8. What standard components are included in the call-processing platform? What components

are optional?

6.11 System Reliability and Availability

While The City is not a 24 hours/7 days per week operation at this time, should problems occur within one of the buildings in the network, they can have only a minimal effect on call processing on any of the other locations. The two primary buildings (City Hall and Library) must be able to handle incoming and outgoing traffic regardless of the state of the wide area network. The ability to add this level of reliability to additional locations is also be desired and should be clearly identified.

The City does not expect that all communications will remain as normal in a major outage. It would be acceptable for peripheral functions such as voice mail to be less functional, for a limited time. Identify each component that is duplicated in your proposal. In the pricing section, provide one price for the redundancy proposed with your system.

• Redundancy to primary sites that also allows for growth. • Ability to keep basic telephone services operable for all phones should the

building-to-building network be down. • Describe the redundancy provided by your system solution. • How are databases synchronized? • How does a switchover occur in a redundant system? • Should an entire site become completely uninhabitable, due to any disaster, how long


would it take for complete restoration of voice service to all stations at another location in the network? How long for the peripherals?

• Does any virus and intrusion protection come with your product or is it priced as an option?

• Please include SRST for all locations.

6.12 Training

User training will be needed for the proposed phone and voice mail system. In addition, training will be needed for 2-3 VOIP system administrators. The Respondent shall provide all of the training for the system administrators and a plan to “train the trainer” in regard to user training. It is not known at this time how many user “trainers” will need training.

A minimum of two 4 hour System Administrator classes shall be provided, a minimum of three 1 hour user training classes shall be provided, and a 1 hour class for Console Attendants shall be provided. The City will video record the training sessions.

Any costs associated with providing additional Respondent-provided training classes shall be provided.

Features of the training program shall include:

• Review proposed training with the designated City project manager and other

assigned personnel prior to first class to possibly fine tune the material to specifically meet the needs of The City.

• Conduct end-user training on The City premises prior to cutover. • For every product application proposed, provide a detailed description of the training

the Respondent will provide along with pricing.

6.13 System Reporting and Call Detail Reporting (CDR)

The Respondent shall provide one centralized call accounting system to track calls out of all locations on the network. The call accounting system must be able to distinguish which phone originated the call, no matter where the phone exists on the network. The system needs to track an outside call through its destination, including any internal transfers. We need to be able to track all extensions involved.

The configuration of the system shall provide the retention of 2 years of usage. Additionally:

• What is the format of the CDR records? Can they be exported to an external application for analysis?

• Provide usage reports for all types of inbound, outbound and intercom calls. A minimum of 8 standard reports shall be available, and the users shall receive training on establishing ad-hoc reports.

• Provide call pricing and bill-back for usage by station, group, department or building. • Provide any additional software and training for creating specific reports for the above

requirements. • Be equipped to be networked to other locations to provide call accounting services,


and/or network with other similar systems to address the call accounting needs of multiple locations.

• Can we do custom grouping? • Does the system have the capability to report by extension number or by location? • What standard reports are included with the system? • How are customized reports generated? • Can detailed activity reports be generated when needed, or must this feature be

enabled on specific extensions before the detailed reporting data is captured? • Is this feature in the base price? If not, please show pricing as a separate line item.

6.14 Maintenance and Warranty

A complete maintenance and warranty contract must be included as part of the proposal, including all options available for extended coverage, service contracts and full pricing details for each level of support coverage for a minimum of 12 and a preferred 24 months.

6.14.1. Warranty – The system and all associated equipment in the proposal must be warranted by

the Respondent and by the manufacturer to be free of defects in equipment, software and workmanship for a period of at least one year from system cutover.

6.14.2. Extended Warranty – Respondent must provide a schedule of any future labor cost increases for engineering, programming, service and maintenance of the proposed system.

7. INSTALLATION, TEST, AND ACCEPTANCE

7.1 Prior to the start of installation, the Respondent shall:

7.1.1. After the contract is awarded by The City to the successful vendor, the selected vendor must conduct a thorough and complete on-site station review. This station review process will identify the following:

7.1.1.1. The type and quantity of all telephone stations, by City location, to be installed for City users during the implementation process.

7.1.1.2. The telephone station programming, by user, including, but not limited to, telephone numbering, programmed features, call flow, recordings, detailed automated attendant operation, and voice mail capability.

7.1.1.3. Detailed voice system security plan that addresses the liabilities of the proposed system. Each system may require different protection measures; it is our expectation that the selected vendor will provide recommendations regarding protection of this system in The City’s environment.

7.1.1.4. The PSTN network interface information by customer location to provide for local, long distance, E911, and intra-organization calling.

7.1.1.5. The information developed through the station review process will be provided to The City both electronically and in hard copy. The selected vendor will detail the design to The City and gain The City’s acceptance before proceeding. Phased implementation will follow.

7.1.1.6. The City will not be responsible for any equipment order placed by the vendor prior to the completion and acceptance of the station review process.


7.1.2. The Respondent shall coordinate the ordering and installation of all trunking with AT&T.

The Respondent shall participate with The City staff in configuring trunking quantities and types for the voice and data systems.

7.1.3. Provide the same primary installation crew for each building site in the facility. 7.1.4. Assign a Project Manager to this installation to work with the assigned City Project

Manager. 7.1.5. Be required to supply a complete description of the key activities and responsibilities

required for the installation of the proposed system. 7.1.6. Coordination of a master project development schedule must be included, along with a

work responsibility matrix, identifying the tasks the Respondent will perform and the tasks The City is expected to perform to successfully implement the new system.

7.2 Responsibilities for installation are shared between The City and the Respondent.

At minimum, The City will:

7.2.1. Provide the Respondent’s employees access to the premises and facilities at all reasonable hours during the installation.

7.2.2. Take actions as necessary to ensure that the premises are dry and free from dust and in hazardous conditions to the installation personnel or the material to be installed.

7.2.3. Provide climate control and general illumination in rooms in which the work is to be performed or materials stored. The City expressly waives any responsibility for any material, tools, or equipment left on the premises after the end of the normal workday.

7.2.4. Provide free and clear access to existing conduit or the placement of new conduit if necessary to all work locations, floors, buildings, etc. to support the cable and equipment installation and provide Respondent access to adjacent areas where and when required.

7.2.5. Make inspections when notified by the Respondent that the equipment or any part thereof is ready for acceptance.

7.3 Respondent Responsibilities will include:

7.3.1. Provide all supervision, labor construction, tools, equipment, materials, transportation,

erection, storage, construction, unloading, inspection, inventory keeping, and returning spare material. Whenever in this RFP the terms provide, furnish, install, etc. are used, it shall be interpreted as requiring the Respondent to both furnish and install materials, unless specific provisions and/or installing of materials by The City is denoted.

7.3.2. Obtain City permission before proceeding with any work necessitating cutting into or through any part of the building structure.

7.3.3. Exercise reasonable care to avoid any damage to the building. 7.3.4. Be responsible for and promptly repair all damage to the building due to carelessness of its

workmen and report to The City any damage to the building, which may exist or may occur during the occupancy of the quarters.

7.3.5. Take necessary steps to ensure that flammable materials will be kept in suitable places outside the building(s).

7.3.6. Install all hardware in accordance with manufacturer's specifications or local codes and ordinances, whichever is more stringent.

7.3.7. Conduct all manufacturer’s and RFP recommended/required testing, and record the results. These are more fully explained below.


7.3.8. Provide weekly status reports to The City that includes, at minimum, a list of all activities currently in process, the level of completion for each process and estimated completion dates.

7.3.9. Promptly notify The City of completion of the project, or portions ready for inspection. 7.3.10. Promptly correct all defects for which the Respondent is responsible, as determined by

The City. 7.3.11. Coordinate all work with Respondent staff and/or their designated representative(s). 7.3.12. Maintain insurance on equipment until such time as it is accepted by The City. 7.3.13. Remove all tools, equipment, rubbish, and debris from the premises and leave the premises

broom clean and neat upon completion of the work. 7.3.14. The Respondent may use subcontractors to perform work with the written authorization

of The City. The Respondent accepts full responsibility for any subcontractors, and must furnish the complete list of such subcontractors. Subcontractors are required to carry the same insurance protection as required by the Respondent for the purpose of this RFP.

7.3.15. The Respondent must abide by the safety and security rules in force on the work site.

7.4 Test/ Acceptance Criteria 7.4.1. Acceptance - The City requires an acceptance period of at least 30 days subsequent to

the completion of the Cutover. During this 30-day period the system must perform without interruption of services and in compliance with all representations offered in the vendor’s proposal. Should the system or other associated devices fail to perform satisfactorily, the 30-day time frame for acceptance will start over until such time as the system performance is satisfactory for a period of 30 consecutive days. Final payment (including change orders) will be withheld, and the warranty period will not begin until system acceptance.

7.4.2. Test and document all equipment and features of installed equipment. Testing period will begin after completed installation and continue for 30 days before acceptance.

7.4.3. Testing/Acceptance shall demonstrate a full functionality of hybrid, TDM, and VOIP wired/wireless. All system features and functions listed above. Unified messaging, call accounting, fax management, and the like, shall also be verified as being fully functional.

7.4.4. All training shall also have been completed prior to acceptance of the installation. 7.4.5. Acceptance of any phasing of the installation will require approval by The City shall be

defined in the final contract. 7.4.6. A complete maintenance and warranty agreement must be included as part of the vendor’s

proposal, including all options available for extended coverage and full pricing details for each level of coverage.

7.4.7. The VOIP system, and all associated equipment in the vendor’s proposal must be warrantied by the vendor and the manufacturer to be free of defects in equipment, software, and workmanship for a period of at least one year following system acceptance.

7.4.8. During the warranty period and any subsequent maintenance agreement, any defective components shall be repaired or replaced at no cost to The City.

7.4.9. All system maintenance during the warranty period and under any maintenance agreements shall be performed by the successful bidding organization using personnel employed full time by the vendor and at no additional cost to The City other than those charges stipulated to maintain the warranty.


8. FINANCIAL CONSIDERATIONS

8.1 Pricing Detail

8.1.1. The Respondent will deliver in (1) envelope the pricing detail for the proposed system. 8.1.2. The Respondent's response must include complete pricing for the described System, call

accounting, fax management, and Unified Messaging. Pricing will be for a turn-key installation.

8.1.3. The total will include cost for materials, labor, taxes, transportation, maintenance, and miscellaneous charges, which must be separately identified.

8.1.4. Complete material lists and a Unit Price Matrix must be included. The UPM will list all components and sub-systems associated with increasing and decreasing the configuration of the system, and the number of users served. Along with equipment costs, typical labor rates will also be provided.

8.1.5. Should certain additional work be required, or should the quantities of certain classes of work be increased or decreased from those upon which the Respondent's response is based, only by order of approval by The City, the Respondent agrees that Unit Price shall be the basis of payment to the Respondent or credit to The City for such additional work or increase or decrease in the work. Unit prices shall represent the exact net amount per unit to be paid to the Respondent (in case of additions), or credited to The City (in case of decreases). Overhead and profit are included in unit prices and no additional adjustments will be allowed for overhead, profit, insurance, compensation insurance, or other direct or indirect expenses to the Respondent, subcontractor, or other supplying parties.

8.1.6. The Respondent shall include a guaranteed hourly rate for a minimum of 12 months on the following services:

8.1.6.1. Installation Labor 8.1.6.2. Call Manager Programming Labor 8.1.6.3. Additional Training Labor 8.1.6.4. Response should include prices for maintenance, upgrades and support for 24, 36,

and 48 months following completed installation. 8.1.6.5. Pricing detail should be in a separate sealed envelope.


8.2 Pricing - Expand the following tables as required to provide itemized, component pricing for

the proposed system to meet the requirements. The component name should be clear and understandable, not a code or stock number. The Discounted Price must be the actual cost The City will pay for the component, not a list price with a summary discount at the end. Total Price equals the Quantity times the Discounted Price.

8.2.1. Telecommunications system as defined. Include all required components.

Component - Name

Qty

Price

Install

Total

(List all component parts of the system)

City Hall Library Voicemail System Unified Messaging Call Accounting System Sub-total – Hardware / Software

Shipping General Install & Training Taxes Total Purchase Price


8.2.2. E-911 Station Locator Capability

Component - Name Qty Discounted Unit Price

Total Price

Install Unit Price

Total Install

(List all component parts of the system)

Sub-total – Hardware / Software

Shipping General Install & Training Taxes Total Purchase Price

8.2.3. Optional Equipment

Facility Qty

Discounted Unit Price

Total Price Install Unit Price

Total Install

(List all component parts of the system) Call Accounting System 1 Conference Bridge 1 Recording Device/System 1

8.2.4. Maintenance Pricing – Using the following table, please provide a detailed description of

the following: 8.2.4.1. Software Upgrade Costs 8.2.4.2. Software Update Costs 8.2.4.3. Software Assurance

Component - Name Qty First Year Maintenance Costs

Total Annual Second Year Maintenance

Cost (List all component parts of the system)

Total Maintenance Price

END OF REQUEST FOR PROPOSAL

request for proposal (rfp) - calabasas · request for proposal (rfp) upgrade existing . ......

Documents