THE CITY OF SIDNEY

REQUEST FOR PROPOSALSto provide

TELEPHONE SYSTEM REPLACEMENT

PROPOSALS DUE BY 5:00 P.M.FRIDAY, JULY 7, 2017

TO

CITY OF SIDNEYMUNICIPAL BUILDINGPURCHASING OFFICE

201 WEST POPLAR STREETSIDNEY, OH 45365

1.0 INTRODUCTION AND GENERAL INFORMATION

The City of Sidney is issuing a Request for Proposal (RFP) to replace the City’s phone system.

1.1 Point of Contact

Direct all communication concerning this RFP to:

Joel GlassCity of Sidney IT DepartmentAddress: 201 West Poplar Street, Sidney Ohio 45365 Voice: 937-498-8161Email: ITPROJECTS@sidneyoh.com

OR

Jenny Wagner 201 West PoplarSidney, Ohio 45365 Voice: 937-498-8749

1.2 Clarification Questions

Companies in doubt as to the meaning of any part of this document may submit a request for clarification no later than June 23, 2017. No response will be provided for questions after that date. Responses to questions will be provided to all known Companies by June 30, 2017.

2.0 PROPOSAL GUIDELINES

2.1 Submission

Sealed quotations must be submitted to the City of Sidney no later than July 7, 2017 at 5:00 pm. One (1) original and three (3) copies of the quotation must be sealed in one envelope or other container and plainly marked. Address package to:

Jenny Wagner 201 West PoplarSidney, Ohio 45365Email: jwagner@sidneyoh.com

Proposals submitted by e-mail will be accepted. Proposals received after the date and time set forth above will not be accepted. The City of Sidney will not accept responsibilities for delays in delivery regardless of the reason.

2.2 Evaluation Criteria

Special attention will be directed to the qualifications of the respondents when awarding this proposal, including past successful installation/upgrades of similar systems.

Technical Expertise (40%) Knowledge/Past Experience in Similar Projects (40%) Project Schedule (10%) Cost (10%)

The City of Sidney reserves the right to reject any or all quotations and proposals or parts thereof and to waive minor irregularities in response.

2.3 Cost Proposal

Include the following items in this proposal section:a) Companies Quotationb) Terms and Conditions

2.4 Companies’ Price Guarantees

Submission of a proposal signifies that Companies proposed services are to be completed within 6 months after the initial award and that quotes are genuine and not the result of collusion.

2.5 Project Schedule

Date of RFP June 7, 2017Proposals due July 7, 2017Proposal review July 10 – 15, 2017Interviews if necessary, and award

July 17 – 21, 2017

2.6 Contract Award

Following acceptance of the quotation by the City of Sidney, a RFP will be selected for the award. All Companies will be notified of the decision.

TABLE OF CONTENTS

1.0 IntroductionThis Request for Proposals (RFP) is intended to solicit proposals from bidders capable of satisfying the City of Sidney's (City) needs for an enterprise telephony system. This project is intended to replace the existing legacy Nortel voice technology currently used in the specified City facilities included in this RFP.Vendors responding to this request are expected to use the basic requirements outlined in this document as a guideline for the proposed solution. We are relying on you, the vendor, to use your knowledge and experience within the communications industry to provide the best and most fiscally responsible, scalable, reliable, and maintainable solution possible.Bidders shall provide a response outlining the design and implementation of an On-Premise Voice over IP (VoIP) Shoretel telephone system. Bidders' responses will be evaluated and ranked based on the criteria described in this RFP. In addition to soliciting written responses, this document provides information to assist bidders in preparing their responses and facilitates the subsequent evaluation and comparison process.

2.0 Current EnvironmentIt is vitally important that Bidders understand the size, scope, strengths, and challenges of the City's current telecommunications environment in order to engineer a new system that both meets the City's current needs, and is scalable well into the future.

2.1 Phone Systems

For the scope of this project, the City intends to replace approximately 244 business lines in 11 facilities located throughout the City of Sidney. (see Appendix: Facility Inventory)All 244 lines are serviced by a Nortel Option 11 CS1000 PBX located at the City Hall facility. Approximately 54 of these lines remain analog and are used for devices such as fax machines, modems, elevators, and fire alarm panels. The remaining 190 lines are converted to digital or IP via on-premise City-owned Nortel Option 11 CS1000 PBX. (see Appendix: Facility Inventory).All analog lines throughout the system are copper leased lines, and all support basic analog features. All users at all facilities have the ability of internal 4-digit dialing and access to voicemail. All current IP based phones at remote locations are serviced over City owned fiber.

2.2 Voicemail

The City utilizes Call Pilot, a Nortel voicemail system integrated with the Nortel Option 11 PBX located at the City Hall facility. This system currently provides access to approximately 287 voicemail boxes.

2.3 Handsets

The City currently uses approximately 244 handsets across all facilities. Handsets are a mix of multi-line Nortel M3904, M3903, and others. Cabling to these handsets is currently a mix of Category 3 and Category 5. Note: Replacement Cabling is out of scope for this RFP.

2.4 Network Infrastructure

The City's municipal data network is currently servicing IP telephony equipment at certain remote locations. It consists of multiple facilities that are connected to the main City Hall network via a variety of private fiber, and leased fiber. The speeds of these connections measure from 1GB to 10 Gigabit. The City maintains a standard Cisco network of layer 2 and layer 3 switches to support and manage the environment. Many, but not all switches are POE and are providing IP based phone service to current facilities.Internet access for all facilities is provided through each facility's connection back to the City Hall Datacenter. The City Hall Datacenter hosts a 40 MB Internet connection that is shared amongst all facilities. The facility is climate controlled and monitored, protected by UPS, and has a power generator.Servers are a mix of physical and virtual Windows 2008r2/Windows 2012 running on Dell PowerEdge Servers. Desktop computers are a mix of physical and virtual PC’s, running the Windows 7 Professional operating system.

3.0 General RequirementsThe proposed solution should provide for integration of voice applications utilizing a converged IP solution. The solution should provide: a highly reliable and available system; a choice of a variety of devices, analog, or IP phones for endpoints, and support modems, fax machines, conference rooms, etc., and include a rich, flexible set of features available for every user.

3.1 Quality/Stability/Failover

Implementation of the proposed solution should cause minimal telephone service interruptions and no perceived degradation in the sound quality of calls. Larger facilities and Public Safety facilities should be capable of full survivability should their connection to the main site be lost.

3.2 Portability

The City desires to retain its existing blocks of phone numbers. The awarded Bidder will be tasked with coordinating and executing the porting of the City's lines, as well as ensuring that its Public Safety lines retain their status as Emergency Priority Numbers.

3.3 Robust set of features

It is desired that the proposed system include a variety of features, in addition to full support for the City's most commonly used basic features, namely 4-digit dialing, call park/pickup, call transfer, caller ID, overhead P.A., auto-attendant and ACD Groups.

3.4 Cost Savings

The City is interested in all opportunities for cost savings that the Vendor may suggest. This might include: combining resources, proposing alternatives to analog fax/modem/alarm lines.

3.5 Detailed Usage Reporting capabilities

It is desired that the proposed system be capable of providing easy access to accurate and up-to-date usage reports, such as incoming and outgoing calls on all lines, capacity per facility, etc., and that it provide some mechanism for building custom queries and data analysis of various metrics throughout the overall telephone system.

3.6 One-stop Administration

It is desired that the proposed system be fully administrable through a single GUI portal. It is also desired that the system include the ability to batch changes to multiple devices via both the GUI and a command line interface.

3.7 Audio Conferencing capabilities

The proposed solution should include the ability to audio conference with others on the same phone system, as well as inviting outside guests.

3.8 P.A. System capabilities

The proposed solution should be capable of making voice announcements through all or a subset of phones, as well as capable of integration with external PA system loudspeakers.

3.9 Email Integration

The City utilizes Microsoft Exchange for email. It is desired that the proposed system be capable of some level of email integration for unified messaging.

3.10 Call recording capabilities

The City currently uses a Dynamic Instruments analog solution for call recording. Call recording is not in the scope of this RFP.

3.11 Choice of long distance providers

The proposed system should facilitate use of the City's choice for long distance providers.

3.12 Handsets

The proposed solution should include IP handsets, and should generally include four basic "types":1. IP480G with Communicator- Quantity 202. P480 with Communicator- Quantity 343. IP420G with Communicator – Quantity 110 4. IP420G with Communicator - Quantity 26Please include individual pricing per handset type for potential quantity modifications. (See Apendix: Shoretel Configuration Worksheet)

It is desired that the proposed system be capable of supporting the full range of phone types including:· Basic analog phone· IP Phone· Soft phones· Expansion ports for administrative assistants· Wireless phones

3.13 Network Infrastructure

The proposed solution should NOT include any network infrastructure. The City of Sidney’s network infrastructure is capable of handling the IP telephony.

3.14 Service Provider Integration

The current Nortel Option 11 PBX interfaces with a PRI as well as a 6 analog emergency trunks. The trunks are used for emergency purposes in the event the PRI and or phone system fails. The proposed solution will need to accommodate the PRI as well as the 6 trunks.

QUESTIONNAIRE4.0 Proposed SolutionPlease provide a response to each item below. Proposal responses should address each statement individually and shall align with the questions.4.1 Executive Overview

4.1.1 Provide a brief background and overview of your company.4.1.2 Describe your experience in designing and building voice over IP solutions.4.1.3 Is the proposed system Hosted, Managed, On-Premise, or some

combination thereof?4.1.4 Describe your experience in implementation of Shoretel IP Telephony

systems.4.1.5 Does the bidder install the product or use business partners?

4.1.6 Does the bidder maintain the product or use business partners?4.1.7 Does the bidder maintain a support call-in center for problems?4.1.8 Does the bidder provide on-site assistance if it is required?4.1.9 Describe your experience in Nortel phone system migrations to a Shoretel

solution. Also include you experience in the Nortel to Shoretel phased migration approach.

4.2 Proposed System4.2.1 Provide a brief description of the overall proposed system. Include

diagrams if desired.4.2.2 Describe how the system integrates voice services with the converged

Internet Protocol network including the use of standards and the support for analog and IP endpoints for users, modems, fax machines, etc.

4.2.3 Describe how the Solution delivers reliability for voice services including maintaining dial tone during WAN outages, failure of switches or servers, and power outages.

4.2.4 Explain how the system will scale to add additional user capacity and how additional sites are added to the system.

4.2.5 Explain the network requirements for supporting the proposed system.4.3 Hardware Configuration

4.3.1 What hardware is being proposed? Please provide the model names and numbers.

4.3.2 Describe the IP call processing hardware platform in detail. Is it based on industry standard hardware, or is it proprietary?

4.3.3 Describe the operating system used for the proposed system providing "call control".

4.3.4 What is the maximum user capacity of the proposed IP communications system? Provide a description of how scalability is achieved.

4.3.5 What is the maximum number of simultaneous conversations supported by the proposed system? What happens when this maximum is reached?

4.4 System Software4.4.1 Which software package is being proposed? Please provide the release

and version.4.4.2 Describe all the system software components for call process and identify

the platforms where they are hosted in the proposed architecture.4.4.3 When dealing with multiple sites and multiple call processors are they all

running the same database? If they are not running from the same database how is information synchronized?

4.5 Network Infrastructure4.5.1 Describe requirements to the data network to support the system

including necessary infrastructure features and capabilities.4.5.2 What capabilities (example: QoS (DSCP/802.1p), Rate Shaping, VLANS

etc...) are required inside the LAN?4.5.3 What speeds are the LAN interfaces on the IP Phones (PC Port)?

4.5.4 What speeds and capabilities are required across the network?4.5.5 Explain how IP phones that are installed on the IP network are identified

and added to the system.4.6 PSTN and Legacy Integration Interfaces

4.6.1 Identify all types of PSTN interfaces or trunks supported by the system.4.6.2 If PRI is supported, identify supported protocols and PRI services such as

ANI, DNIS, Caller ID Name and Number.4.6.3 Identify all supported interfaces for integration with existing telephone

equipment such as Nortel Option 11 PBX.4.6.4 How does the proposed solution handle devices which require straight

analog lines, e.g. Emergency lines on elevators.4.6.5 Can smaller facilities with only 1 to 3 analog POTS lines and no Internet

connection be integrated into the proposed solution?4.7 Proposed System Cabling

4.7.1 Describe the system cabling requirements, including the number of wire pairs ofwires or network connections required to support the specific hardware configuration, telephones, PSTN interfaces, and connections to legacy equipment. Note: Actual station cabling is out of scope and excluded from this RFP.

4.8 Station Hardware4.8.1 Does the system support the following types of user equipment?

Equipment Yes No Optional

Analog Telephones (2500 Type)IP TelephonesProprietary Digital PhonesModemsFax Machines

4.9 IP Phones4.9.1 Provide a description of each type of IP telephone in the proposed system4.9.2 Is the maximum speed of the proposed IP Phones 1 Gigabit or 100

Megabit?4.9.3 Specify the power requirements for each IP telephone and if they require

local or closet power. On power failure is the telephone disabled?4.9.4 Are headsets available for all IP telephones?4.9.5 Are A/C adapters available for all IP telephones? Are they included?

Include itemized Pricing.4.9.6 What per-user configuration is required for each IP phone deployed or

re-deployed in the system?4.9.7 Can IP phones from third parties also be used with the proposed system?

State the types of third party telephones that are supported.4.10 Handset/Phone Features

4.10.1 For the following features, use the table to indicate their availability on the proposed IP Phone hardware. Note if any of these features are optional or result in additional charges. For definitions of features, see Appendix: Phone Features Definitions.

Feature Yes No Optional

Message Waiting LED

Audio Volume Adjust

Auto Off-hook Preference

Bluetooth

Bridged Call Appearances

Call Forward All Calls

Call Forward Busy

Call Forward No Answer

Call History

Call Hold / Release

Call Park / Pickup

Call Redirect

Call Transfer

Call Waiting

Call Waiting Caller ID Name and NumberCalling Line ID Name and NumberDial by Name Directory

Group Paging

Headset Compatibility

Hot Key Pad

Intercom

Feature Yes No Optional

Last Number Redial

Make / Drop Conference

Missed Call Indicator

Multiple Calls Per Line AppearancePrime Line Select

Privacy

Programmable Buttons w/ paperless labelsRinger Pitch Adjust

Ringer Volume Adjust

Shared Extensions on Multiple PhonesSingle Button Retrieve

Speaker Phone Full Duplex

Speaker phone Mute

Speed Dial (Auto-Dial)

Time & Date

Voice Mail Login Button

Wireless headset on/off hook (without lifter)

4.11 System/User Features4.11.1 For the following features, use the table to indicate their availability

within the phone system. Note if any of these features are optional or result in additional charges. For definitions of features, see Appendix: Phone Features Definitions.

Feature Yes No Optional

Answer/Answer Release

Attendant or Operator Console

Feature Yes No Optional

Account Codes

ACD

Admission Control

AMIS

Audio Volume Adjust

Automated Attendant

Auto Echo Cancellation

Auto Silence Suppression

Automated Call-by-call Bandwidth SelectionAutomated Phone Installation ConfigurationAutomatic Phone Moves

Admission Control On WAN UsageBackup Auto-attendant

Call Barge In

Call forwarding (Off Premise)

Call forwarding (Ring and/or No Answer)Call forwarding (Self Directed)

Call Hold / Release

Call History

Call Join

Call Park / Unpark

Call Permissions

Call Pickup

Call Recording

Feature Yes No Optional

Call Redirect

Call Transfer

Call Waiting

Calling Line ID Name and NumberCall waiting Caller ID Name and NumberConference Calling

Dial by Name Directory

Direct Inward Dialing

Direct Outward Dialing (DOD)

Distinctive Ringing (internal vs. external call)Distinctive Station Ringing Pitch

Extension Dialing Between LocationsExtension Reassignment (On-net or Off-net)Emergency Notification Integration (CESID)Fax Redirection

Feature Permissions

Group Paging

Hot Key Pad

Hunt Groups

IP-based Integrated Messaging

IP Phone Failover

Intercom

Last Number Redial

Lowest Cost Trunk Selection

Feature Yes No Optional

Centrex Trunk Flash

Tandem Trunking

Message Waiting Indicator

Media Encryption

Missed Call Indicator

Multi-Station Hunt Groups Spanning LocationsMultiple Calls Per Line AppearanceMultiple Line Appearances

Music On Hold

Night Bell

On Hold Reminder Ring

On-net Dialing (1-7 digits)

Operator ("0")

Overhead Paging

Power Fail Transfer

PRI Protocol Support

PSTN Failover

Redial

Ringer Pitch Adjust

Ringer Volume Adjust

Shared Extensions on Multiple PhonesSilent Monitoring

SMDI

SNMP

Speaker Phone Mute

Feature Yes No Optional

Speed Dial (Auto-Dial)

Station Monitoring or Busy Lamp Field Across all LocationsTAPI 2.1

Temporary Set Re-Assignment for Traveling WorkersToll and Nuisance Number (900,976,970,550,540 exchanges) RestrictionTone On Hold

Visual Message Displays (All digital telephones) (name, extension, etc.)Voice Mail Login Options

Whisper Page

4.12 System Administration4.12.1 Describe the system administration tools available to provide integrated

administration of the system across all locations.4.12.2 Can administration of all remote sites be done through a centralized

workstation? Is there any limit to how many workstations are supported? 4.12.3 Is the system administration application accessed through a standard

web browser?4.12.4 Can moves and changes be "batched", that is can block copy changes

can be made to a number of subscribers or class of service simultaneously?

4.12.5 How is security provided to prevent unauthorized access to the administration application?

4.13 System Reliability4.13.1 How does the system provide reliability? Explain how it avoids any single

point of failure.4.13.2 Is the system guaranteed to provide a certain amount of uptime? 4.13.3 Explain how the system reacts if the main site's routers or switches fail.

Can reliable dial tone and call routing be achieved?4.13.4 Describe the sequence of events that occur if a remote site loses its WAN

connectivity.4.13.5 Does the proposed system include any swappable spare equipment for

rapid replacement in an emergency?

4.14 System Maintenance and Upgrades4.14.1 Explain the back-up procedures for the system configuration and

information and how the administrator would restore the data to a previous configuration.

4.14.2 How are customers provided future software releases? How are software upgrades performed?

4.14.3 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?

4.15 System Monitoring/Diagnostics/Reporting4.15.1 Describe the diagnostic tools available for monitoring and maintaining

the system's performance.4.15.2 Can the system be configured to notify the administrator of diagnostic

events when they are remote or away from the system?4.15.3 Describe the types of Reports that are available from the proposed

system, such as incoming and outgoing calls on all lines, capacity per facility, etc.

4.15.4 Does the proposed system include some mechanism for building custom queries and data analysis of various metrics throughout the overall telephone system?

4.16 Emergency Dialing and Emergency Notification Services4.16.1 Does the proposed system always provide at least one way to dial 911

from every facility? Under what circumstances would a facility lose the ability to dial 911?

4.16.2 If a VoIP user at a remote site dials 911, what ensures that 911 Dispatchers will see the correct name and address for that user's facility?

4.16.3 Is the proposed system capable of receiving and routing Emergency Alert Notifications to all stations?

4.16.4 When dealing with multiple sites, what is needed in order to support the Emergency Alert Notification requirements, even during a WAN outage?

5.0 Applications5.1 Desktop Call Management

5.1.1 Describe the system's desktop call manager and the call features supported from the user's desktop computer. Include hardware and software requirements.

5.1.2 Describe how operators are supported. Can an operator answer calls and route calls from other sites?

5.1.3 Does the desktop call manager application provide directory dialing across all locations in the system?

5.1.4 Does the desktop call manager provide caller history or call log to archive the user's telephone use?

5.1.5 Does the desktop call manager provide call routing information to identify how the caller reached the user though the proposed system?

5.2 Voice Mail System5.2.1 Describe your voice messaging product offering. Include an overview of

the hardware, software, architecture, and components of the equipment proposed to meet City requirements.

5.3 Voice Mail System - Specifications5.3.1 How many users are supported by the proposed voice mail system? How

are additional users added to the system?5.3.2 How many ports are proposed to support the voice mail system? If

additional ports are required in the future, how are these added? Explain how the system scales beyond the number of proposed ports.

5.3.3 Can the voice mail application be distributed across the different locations in the system?

5.3.4 How many classes of service can be defined for voice mail permission levels?

5.3.5 What types of user permissions or characteristics within a class of service can be created or modified?

5.3.6 Are message capacity limits configurable by class of service?5.3.7 What is the length of the longest message that can be recorded by a

caller?5.3.8 How many messages can be stored in a subscriber's mailbox?5.3.9 What is the maximum total number of minutes of messages that can be

stored in a single voice mailbox?5.4 Voice Mail System - System Features

5.4.1 Is the voice mail system remotely accessible? Can the system be accessed from a standard touch-tone phone?

5.4.2 Does the voice mail system provide an interface to deliver voice mail messages into email to provide unified messaging?

5.4.3 Describe the impact on the existing email infrastructure (Exchange) of providing unified messaging.

5.4.4 Is a desktop application included that provides visual access to view and manage user's messages from their PC?

5.4.5 Can system prompts be interrupted by experienced users? In other words, is there a "fast path" for users?

5.4.6 Does the voice mail system support a "zero out" to the attendant feature? Is this feature configurable by class of service?

5.4.7 Can the "zero out" destination be a station rather than the attendant? 5.4.8 If the "zero out" destination is busy, or rings unanswered, will the call be

re-directed?5.4.9 Does the voice mail system support multiple greetings? If yes, describe all

available greetings.5.4.10 Does the system support automatic remote notification and delivery of

voice mail messages to users?5.4.11 Can the voice mail system identify callers that leave voice mail

messages and display their name based on Caller ID information?5.5 Voice Mail System - System Administration

5.5.1 Is system administration done through a standard web-based GUI? If so, which web browsers does the administrative application support?

5.5.2 Is voice mail administration integrated with the actual phone system administration or is it a separate program?

5.5.3 Explain how a system administrator would perform a backup and restore on the voice messaging system.

5.6 Mobility5.6.1 Summarize the proposed Mobility solution.5.6.2 Does the Mobility solution have the ability to allow users to login as their

designated extension from any telephone?5.6.3 Does the Mobility solution support remote users using IP Phones? How is

this done, what hardware is required? What protocols are used to secure the communication?

5.7 Audio Conferencing5.7.1 Does the proposed solution support Audio Conferencing?5.7.2 What hardware and software are required for audio conferencing?5.7.3 How many people can attend a single conference call?

6.0 Implementation6.1 Project Management

6.1.1 Project Plan - Bidders are required to supply a complete description of the key activities required for the installation of the proposed system.

6.1.2 Responsibility Matrix and Project Schedule - A master project schedule must be included, along with a work responsibility matrix, identifying the tasks the vendor will perform and the tasks the City is expected to perform to successfully implement the new system.

6.2 Installation RequirementsThe selected vendor is responsible for the complete turn-key engineering of the new telecommunications system and all interconnecting facilities. Vendor will perform an initial network assessment, station reviews, and determine any additional requirements.It is essential that the installation of the new system be as non-disruptive as possible to users at each facility. There should be minimal telephone service interruptions, no interim changes in dialing procedures, and no perceived degradation in the quality of service. Where possible, intrusive work that is likely to cause interruptions in service should take place in off hours.

6.3 Facility RequirementsBidders must furnish all space, power, and environmental requirements for the proposed telephone system and optional voice messaging equipment.6.3.1 Space - Provide the physical dimensions of the proposed equipment. 6.3.2 Power - All power requirements, including any special conditioning or

grounding requirements.

6.3.3 Heat - Provide recommended safe temperature operating range for the proposed system.

7.0 TrainingThe successful Bidder is required to conduct end-user training on City premises, tailored specifically to the City's particular requirements (e.g. admin, message center operator, administrative assistant, normal user).7.1 Training Plan

The successful Bidder will develop and manage a detailed plan for training. This Training Plan must include the information described below.7.1.1 The role and responsibility of the vendor in the design and implementation

of the training plan.7.1.2 The role and responsibility of City staff in the design and implementation

of the training plan.7.1.3 Overview of proposed training plan/strategy, including options for on-site

and/or off-site training services, for the core project team, end-users, and technology personnel.

7.1.4 A proposed training schedule for City personnel of various user and interaction levels.

7.1.5 Descriptions of classes/courses proposed in the training plan. (The vendor should specify the unit of measure for its training, e.g., units, classes, days, etc., and define the hours associated with these units of measure.)

7.1.6 The knowledge transfer strategy proposed by the vendor to prepare City staff to maintain the system after it is placed into production.

7.1.7 Detailed description of resources that will be included as part of the training by the vendor including, but not limited to: system user manuals, "Quick Reference" guides, online support, help desk support, user group community resources, and others as available.

8.0 DocumentationThroughout the course of the project, the selected vendor will develop and provide accurate AS-BUILT documentation that describes the features and functions of the installed hardware and software.Appropriate documentation shall be provided for both end users and the technical personnel who will administer and maintain the system.The selected vendor shall provide documentation in Microsoft Word/Excel or Microsoft Visio formats, as appropriate.

9.0 Service9.1 Maintenance and Warranty

A complete maintenance and warranty agreement should be included as part of the bidder's proposal.Bidders should specify a support proposal for service between 8a.m.and 5p.m. Monday through Friday. An additional "Optional" agreement should be provided for emergency support 24x7.The telephone system and all associated equipment in the bidder's proposal must be warranted by the bidder and by the manufacturer to be free of defects

in equipment, software, and workmanship for a period of at least 3 years following system cutover.All system maintenance during the warranty period and under any maintenance agreements shall be performed by the successful bidding organization and at no additional cost to the City other than those charges stipulated to maintain the warranty.

9.2 Logistical SupportBidder should identify the address of the vendor's local service centers and the number of service personnel trained on the proposed system.

9.3 Repair ResponseThe bidder must include a description of the bidder's repair commitment from time of trouble discovery through the time the trouble is cleared.Bidder should guarantee a response time of no more than 4 hours for all major system problems and a maximum of 24 hours response to other system problems.Bidders must describe their definitions of "major" and "minor" problems.Disaster Recovery - Bidders should explain the amount of time required for full replacement of the central operating hardware/software of the system.

10.0 ReferencesThe vendor must submit a minimum of three reference customers of Nortel migrations. Reference information must include company name, contact, telephone number and approximate size of system.