Sample RFP Template

REQUEST FOR PROPOSAL
FOR A NEXT GENERATION IP-BASED VOICE,

DATA and VIDEO COMMUNICATIONS SYSTEM
FOR
<Customer Name (please do not include a logo)

and Project/Deliverable Name>
REQUEST FOR PROPOSAL
Version <x.y>
Sample RFP – Template
March 11, 2003 2 of 59

TABLE OF CONTENTS
1 (CUSTOMER NAME’S) REQUEST FOR PROPOSAL........................................................5
1.1 RFP OVERVIEW............................................................................................................................5

1.2 CUSTOMER CONTACTS AND CONTRACT REQUIREMENTS....................................................................6
1.3 PROPOSAL FILING DATE.................................................................................................................6
1.4 NUMBER OF COPIES.......................................................................................................................6
1.5 SCHEDULE OF EVENTS....................................................................................................................6
1.6 PROPOSAL RESPONSE FORMAT........................................................................................................7
1.7 VENDOR QUESTIONNAIRE................................................................................................................7
1.8 OVERVIEW OF CURRENT ENVIRONMENT...........................................................................................9
1.9 REQUIREMENTS FOR (CUSTOMER NAME’S) IP COMMUNICATIONS SYSTEM.......................................10
2 EXECUTIVE OVERVIEW....................................................................................................11
3 VENDOR PROFILE...............................................................................................................12
3.1 PROPOSED IP COMMUNICATIONS SYSTEM......................................................................................12

3.2 IP COMMUNICATIONS SYSTEM ARCHITECTURE...............................................................................12
3.3 SYSTEM RELIABILITY AND AVAILABILITY.......................................................................................15
3.4 ADVANCED ROUTING FEATURES....................................................................................................17
3.5 EMERGENCY SERVICES.................................................................................................................17
3.6 PROPOSED SYSTEM CABLING.........................................................................................................18
3.7 SYSTEM ADMINISTRATION REQUIREMENTS.....................................................................................19
3.8 SYSTEM MONITORING AND DIAGNOSTICS.......................................................................................20
4 IP TELEPHONY SYSTEM SOFTWARE AND HARDWARE ..........................................22
4.1 HARDWARE CONFIGURATION.........................................................................................................22

4.2 SYSTEM SOFTWARE......................................................................................................................24
4.3 CONFERENCING............................................................................................................................25
4.4 SYSTEM FEATURES.......................................................................................................................25
4.5 STATION HARDWARE AND IP SOFTPHONE......................................................................................27
4.6 IP MANAGER-ASSISTANT.............................................................................................................30
4.7 ATTENDANT CONSOLE..................................................................................................................32
4.8 SYSTEM REPORTING AND CALL DETAIL REPORTING.......................................................................33
5 VOICE MAIL AND UNIFIED MESSAGING SYSTEM SPECIFICATIONS...................35
5.1 VOICE /UNIFIED MESSAGING SYSTEM DESCRIPTION AND SUPPORT OPTIONS.....................................35

5.2 VOICE /UNIFIED MESSAGING SYSTEM SPECIFICATIONS....................................................................35
March 11, 2003 3 of 59

5.3 VOICE MAIL SYSTEM – SYSTEM FEATURES...................................................................................37

5.4 VOICE MAIL SYSTEM – USER FEATURES ......................................................................................39
5.5 VOICE MAIL SYSTEM – SYSTEM ADMINISTRATION ........................................................................40
6 IP CONTACT CENTER SYSTEM SPECIFICATIONS .....................................................42
6.1 HARDWARE CONFIGURATION.........................................................................................................42

6.2 SYSTEM SOFTWARE......................................................................................................................42
6.3 AGENT STATION HARDWARE AND SOFTWARE.................................................................................43
6.4 CALL ROUTING AND REPORTING SOFTWARE FUNCTIONALITY..........................................................44
6.5 COMPUTER TELEPHONY INTEGRATION (CTI)................................................................................46
6.6 WEB COLLABORATION FUNCTIONALITY.........................................................................................46
6.7 EMAIL RESPONSE MANAGEMENT..................................................................................................47
6.8 FAX MANAGEMENT......................................................................................................................47
7 IMPLEMENTATION.............................................................................................................48
7.1 PROJECT MANAGEMENT...............................................................................................................48

7.2 INSTALLATION REQUIREMENTS......................................................................................................49
7.3 FACILITY REQUIREMENTS ............................................................................................................50
7.4 TRAINING....................................................................................................................................50
8 VENDOR SERVICE...............................................................................................................52
8.1 MAINTENANCE AND WARRANTY ..................................................................................................52

8.2 LOGISTICAL SUPPORT .................................................................................................................52
8.3 REPAIR RESPONSE........................................................................................................................53
9 CONFIGURATION/PRICING...............................................................................................55
10 FINANCIAL REQUIREMENTS.........................................................................................56
10.1 PAYMENT OPTIONS ....................................................................................................................56

10.2 PAYMENT SCHEDULE ................................................................................................................56
11 TERMS AND CONDITIONS...............................................................................................57
March 11, 2003 4 of 59

1 (CUSTOMER NAME’S) REQUEST FOR PROPOSAL
1.1 RFP Overview

This Request for Proposal (RFP) documents (Customer Name’s) requirements for a native IP-
based voice, data and video communications system. This IP communications system will
replace the current system. The proposed IP communications system must be able to support all
the required call processing, voice messaging, contact center, management and administrative
features of this RFP. In addition, the proposed IP communication system must be capable of
meeting anticipated growth. Since this RFP calls for a converged system, it is expected that
vendors will propose some combination of gatekeeper(s), gateway(s), client and conference
devices as well as an intelligent network infrastructure to meet these capabilities.
This Request for Proposal (RFP) is intended to provide a standard base from which to evaluate
alternatives for communications systems and to allow the vendor flexibility in proposing the most
appropriate and cost-effective system. The acceptance of a proposal does not obligate
(Customer Name) to purchase a system from any vendor. (Customer Name’s) reserves the right
to reject all proposals and not make a decision. All costs for proposal preparation are the
responsibility of the bidder. After receipt of the proposal, and prior to signing the contract,
(Customer Name) reserves the right to modify the system requirements by adding or deleting
specific equipment or optional features.
(Customer Name) is looking for a converged IP voice/video/data solution. Bidders should use
their vast knowledge and experience within the communications industry to recommend a
creative solution that will meet or exceed (Customer Name’s) requirements.
Preference will be given to the vendor that provides a comprehensive, cost-effective, single-
vendor solution for current specifications, future capacity requirements, and ongoing service and
support.
Key Decision Criteria
• IP-based Voice/Data/Video capabilities and Intelligent Network

Infrastructure: Integration of voice, data and video applications with a
converged Internet Protocol (IP) solution. Ability to provide highly reliable and
available switching systems, a wide variety of gateways to the PSTN and legacy
TDM equipment, and a strong selection of IP phones.
• Vendor Experience and Vision: Evaluation of the vendor's experience

in building intelligent network infrastructures and implementing Internet
technologies. (Customer Name) is looking to partner with a vendor that has
vision and leadership in the Internet industry.
• Vendor support for Open System Standards: The vendor

should be committed to supporting open system industry standards, such as
H.323, 802.1p and 802.1q, MGCP, TAPI, JTAPI, etc.
• Voice Messaging: Scalable, cost-effective voice messaging

solution that supports industry standards, such as AMIS-A, VPIM, LDAP and
IMAP.
• Contact Center: The vendor should offer solutions from entry-level, informal
contact centers to large, multi-site, multi-channel enterprise contact centers. The
March 11, 2003 5 of 59

solution should have native integration to IP call processing, and may be required
to bridge legacy TDM and IP contact centers.
• System Administration: Maximum flexibility for rapid, efficient, and cost-

effective configuration changes, affecting personnel and associated IP telephone
equipment through a standard browser-based interface.
• Vendor Support/Service Capabilities: Remote serviceability, technical support

of the entire PBX system and applications, and vendor reputation. Ability to
provide global support.
• Scalability: Modular, cost-effective growth in both IP phones and applications

over the next five years. Asset protection moving forward is critical.
• Leading Edge Technology: The ability to incorporate future requirements and

technological advances.
1.2 Customer Contacts and Contract Requirements
For questions about the Request for Proposal or (Customer Name)'s system
requirements, contact:
Contact Name: ________________________________

Address: ___________________________________
Phone Number: __________________________________
Fax number: __________________________________
e-mail address: __________________________________
Requests for clarifications should be e-mailed. Clarifications will be sent to all

bidders.
1.3 Proposal Filing Date
All proposals must be received by (Name), (Customer Name), (Address) by

( _______ ) p.m., on (Day),(Date).
Bids received after that time will not be accepted.
1.4 Number of Copies
# copies of the proposal are to be delivered to (Customer Name).
1.5 Schedule of Events

Event Date
Request for Proposal Issued Mm/dd/yy
Bidder's Conference Mm/dd/yy
Site Visit Mm/dd/yy
Last Day for Questions/Clarifications Mm/dd/yy
RFPs Due to Purchaser Mm/dd/yy
March 11, 2003 6 of 59

Purchasing Decision Mm/dd/yy

System Cut Date Mm/dd/yy
1.6 Proposal Response Format
This RFP has been provided in soft copy for the bidders convenience. Responses to
(Customer Name)’s RFP must be in the same format as the original request. All
responses should be stated in the body of the document following the specific
questions. As requested please place additional information in the Appendix.
Please note that any modifications to the questions in this RFP by the bidder will
result in immediate rejection of that proposal.
1.7 Vendor Questionnaire
Bidding Company Name:

Address:
Sales Representative Name:

Telephone Number:
e-mail address:
Technical Advisor:
Telephone Number:
e-mail address:
1.7.1 Who manufactures the proposed system?
If not Proposing Vendor, Manufacturer Name:
Manufacturer Address:
1.7.2 Does the bidder install the product or use business partners?
Response:
1.7.3 Does the bidder maintain the product or use business partners?
Response:
1.7.4 Does the bidder maintain a support call-in center for problems?
Response:
1.7.5 Does the bidder provide on-site assistance if it is required?
Response:
March 11, 2003 7 of 59

1.7.6 Does the bidder maintain a web site for customers to access technical support and
documentation?
Response:
March 11, 2003 8 of 59

1.8 Overview of Current Environment
(Customer Name) has the following current environment……
EXAMPLE - from a fictional company:

(delete from actual RFP and add one specific to this customer)
GetReady is an emerging software development company that is located at Rapid City, South
Dakota. Facing dramatic new demands for service, the owners are planning an immediate
expansion in the sales, marketing, and engineering force. The owners have decided to use this
opportunity to completely replace their traditional telephone system and data connections with an
integrated enterprise network that will support IP telephony and collaborative communication
among PC-based workstations. (See Figure 1).
Each GetReady employee has a desktop Pentium-class PC running Windows 95 and Office 97 or
Windows NT Workstation and Office 97. Currently there are 70 employees with 20 new hires
soon to join. Each desktop is provisioned with four RJ-45 jacks. Today, one jack is utilized for
the PC and the other is used for the telephone.
Each digital telephone is connected to a separate jack and separate infrastructure which
ultimately connects to a PBX system and a Voice Mail. The long distance telephone carrier is
LDCC1 with a negotiated price of $.04 per minute within the continental US. (Most GetReady
activity will continue to be targeted to USA calls. Projects requiring calls outside the continental
US are quoted on a case-by-case basis).
Currently, the technical assistance center for (Customer Name’s) products is outsourced to
another vendor. The eventual goal is the build a 7X24 call center within the headquarters
building.
Note: Both GetReady and LDCC are fictitious companies and are not modeled after any known
organization.
Figure 1: (Customer Name’s) Current Data and Voice Networks
DATA VOICE
Server farm
Voice Mail PBX System
PSTN
User
segments
March 11, 2003 9 of 59

1.9 Requirements for (Customer Name’s) IP Communications System
(Customer Name) requires the following……..
In this section the customer should state their requirements in detail, including required or desired
features and applications, number of users to be supported by various voice/video/data
applications, growth requirements, or desired network infrastructure changes. There should also
be a discussion of any particular business problems that the customer wishes to solve.
EXAMPLE from a fictional company:

(delete from actual RFP and replace with a customer-specific description)
GetReady seeks a solution that will replace the current system in Figure 1 with a unified
voice/data network that will seamlessly serve headquarters and future branch offices in year
2000. All existing telephones should be replaced with equivalent new IP telephones that
support basic telephony features. An employee should be able to plug in their IP phone
anywhere on the network and automatically receive calls without administrative intervention.
GetReady also requires voice mail for all users, and will consider unified messaging as an
option.
While video is not a requirement of this RFP, the IP Communications System should be
capable of handling future IP video applications without major modification to the network
infrastructure.
GetReady’ backbone network, IP PBXs and gateways must be sized and configured for
automatic load shifting. GetReady requires a cost-effective level of network security that is
adequate to prevent outside monitoring of telephone calls, file transfers, passwords, etc.
March 11, 2003 10 of 59

2 EXECUTIVE OVERVIEW
This section is an introduction to and summary of the system being proposed by the
vendor. This should be structured so anyone reading only this section has a clear
understanding of the proposed system.
Response:
March 11, 2003 11 of 59

3 VENDOR PROFILE
This section is to provide an overview of the vendor's proposal and its architecture, and
experience in the manufacturing, installation, and support of the type of system proposed. It also
covers how the vendor will provide an intelligent network infrastructure to support the IP
Communications system.
3.1 Proposed IP Communications System
3.1.1 Provide a brief description of the proposed system. Include diagrams if desired.
Response:
3.1.2 What are the model names and version numbers of all relevant components of the
proposed system?
Response:
3.1.3 Describe how your solution can be used to decrease time to market, improve customer
responsiveness, or increase end-user productivity
Response:
3.2 IP Communications System Architecture
3.2.1 Provide a brief description and discussion of your system architecture. Describe your
philosophy on open architecture and your ability to support other vendors’ equipment.
Response:
3.2.2 Provide a diagram of the system architecture.
Response:
3.2.3 Describe your company’s experience with building intelligent network infrastructures.
Response:
3.2.4 How does your proposed intelligent network infrastructure support end-to-end QoS? In a
converged network supporting voice, broadcast video, H.323 video, and data, how are
QoS issues resolved?
Response:
March 11, 2003 12 of 59

3.2.5 How do LAN switches recognize voice traffic to guarantee QoS?
Response:
3.2.6 How does the intelligent network infrastructure recognize voice traffic at the WAN edge
and guarantee QoS across WAN links?
Response:
3.2.7 How does your system provide for Call Admission Control to guarantee that LAN/WAN
links are not oversubscribed?
Response:
3.2.8 Explain how the intelligent network architecture provides power to IP phones over the
Ethernet. Can the network automatically detect the presence of the IP phones? If so,
how is this done, and what are the benefits of this feature?
Response:
Survivable Remote Site Telephony
3.2.9 Does your solution support remote office phones from a centralized phone system? If so,
how does this work and what equipment is required at the remote site?
Response:
3.2.10 Are applications also available to users at remote sites?
Response:
3.2.11 Describe what local survivability capabilities are provided for remote sites during a WAN
outage (for remote sites hosted off of a central server).
Response:
IP Addressing and VLAN Support
3.2.12 Explain how you can provide easy addressing of the IP phones without having to change
the addressing scheme of the existing IP data network.
March 11, 2003 13 of 59

Response:.
3.2.13 Can IP phones share existing Ethernet ports with data devices, or do the IP phones
require additional Ethernet ports to be added by the customer to support voice?
Response:
3.2.14 Do your phones have a built-in switch to support automatic VLAN? Please comment in
detail about your VLAN support.
Response:
3.2.15 Under what circumstances would a phone outage affect the PC communicating to the
network?
Response:
3.2.16 In terms of support for open industry standards, which of the following standards do you
support in your proposed solution? If the standard is not currently supported, indicate in
the “Availability Date” column when you expect to support it.
RECOMMENDATION STATUS AVAILABILITY DATE

1. G.711
2. G.726
3. G.728
4. G.729
5. G.729a
6. H.323 V2
7. T.120
8. Q.931
9. 802.1d
10. 802.1p
11. 802.1q
12. 802.3
13. SNMP
14. FAX - Group 3
15. FAX - Group 4
16. T.37
17. T.38
18. IP Precedence
19. Differentiated Services
20. RSVP
21. Weighted Fair Queuing
22. CBWFQ
23. PQWFQ
24. RED
25. Weighted RED
26. RTP
27. CRTP
28. RTCP
29. RTSP
30. Policy Based Routing
March 11, 2003 14 of 59

31. Committed Access Rate

32. IPv6
33. MGCP
34. H.225
35. H.245
36. TCP/IP
37. UDP/IP
38. DHCP
39. DCL
40. DNS
3.3 System Reliability and Availability
3.3.1 Does the system support clustering? If so, across how many systems?
Response:
3.3.2 What is the highest number of IP devices currently supported under a single instance of
the software? How many IP devices are supported by a cluster?
Response:
3.3.3 Does the system have a web-based or GUI-based administration tool? Is this included in
the base price?
Response:
3.3.4 Can a single instance of the administration tool be used to manage all systems within an
enterprise simultaneously?
Response:
3.3.5 How does the system provide for fault tolerance? Identify the components that can be
duplicated in your system. Fully describe the systems redundancy capability. Is it “hot
standby redundancy”, “shared redundancy”, etc.
Response:
3.3.6 Explain in detail how a switchover occurs in a redundant system.
Response:
3.3.7 In redundant systems, how are databases synchronized?
Response:
March 11, 2003 15 of 59

3.3.8 Identify each component that is duplicated in your proposal. In the pricing section,
provide one price for the redundancy proposed here.
Response:
3.3.9 What is the anticipated mean time between failures (MTBF) of the components quoted in
this RFP?
Response:
3.3.10 How would you provide redundancy and disaster recovery ensuring no single point of
failure for our entire voice network? Please detail recovery methodology including
recovery times and outages.
Response:
3.3.11 In consideration of a full-scale rollout of voice over IP, which would include our regional
offices, please describe how voice services are maintained at these remote sites if there
is an outage at the remote site.
Response:
3.3.12 What virus and intrusion protection comes with your product?
Response:
3.3.13 How often is it maintained and enhanced?
Response:
3.3.14 What is your response time to the identification of new viruses and attacks?
Response:
3.3.15 How do you monitor new viruses and intrusions?
Response:
3.3.16 What toll fraud protection is available? How is it monitored?
Response:
3.3.17 Describe any UPS or “battery” back-up capabilities for the proposed system. Can these
capabilities benefit a redundant system? Please explain.
Response:
March 11, 2003 16 of 59

3.4 Advanced Routing Features
3.4.1 Fully describe your advanced routing features. Please be sure to include a discussion of
the following applications:
• Amount and type of routing plans.

• Types of trunks supported in routing scheme
• Queuing and overflow capabilities.
• Use of authorization codes on individual routes.
• Describe how your system handles digit deletion and insertion regarding
the North American Dialing Plan. Include system limitations.
• Describe the route filtering method
Response:
3.4.2 Describe the Dial Plan structure.
Response:
3.4.3 Describe the Dial Plan configuration options.
Response:
3.4.4 Is the system compliant with the North American Numbering Plan (NANP)?
Response:
3.5 Emergency Services
3.5.1 If emergency-911 municipal services are mandated for commercial systems, is your
proposed system in compliance today?
Response:
3.5.2 Identify the systems ability to redirect callers who dial “911” or “9+911” to a
predetermined location; i.e., security desk, operator’s console, etc.
Response:
3.5.3 Describe how the system identifies location information of the IP phone and makes a 9-1-
1 call.
Response:
3.5.4 How often does the PS-ALI database need to be updated after new phones are added to
the system, or phones move?
March 11, 2003 17 of 59

Response:
3.6 Proposed System Cabling
3.6.1 Provide information on the cable type (fiber, copper, other) number of pairs / strands
required between buildings.
Response:
3.6.2 Does your cabling requirement take into account redundancy, disaster recover, single
points of failure? Please explain.
Response:
3.6.3 Is there a preferred manufacturer for your proposed system required cabling?
Response:
3.6.4 How many pairs of wires are needed to support the specified instruments, terminals and
consoles?
Response:
3.6.5 Identify and describe the distance limitations and wire gauge limitations to your station
equipment, consoles, administrative terminals, etc.
Response:
March 11, 2003 18 of 59

3.7 System Administration Requirements
Describe the system administration tool(s) available to meet the following requirements.
3.7.1 Is the system administration application accessible from any workstation on the LAN
/WAN?
Response:
3.7.2 Is the system administration application accessed through a standard web browser? Can
it run on any Windows 95/98 client?
Response:
3.7.3 Can moves and changes be “batched”; that is, can block copy changes be made to a
number of subscribers or class of service simultaneously?
Response:
3.7.4 Can administration of multiple remote sites be done through a centralized workstation?
Is there any limit to how many workstations are supported?
Response:
3.7.5 How is security provided to prevent unauthorized access to the administration

application? How many levels of security can be defined? Is there any limit to the
number of administrative users that can be given access passwords? Can some
administrative users be defined with “view-only” permissions? Can different individuals
be given individualized permission levels?
Response:
3.7.6 Explain how the administrator would reload the database if they needed to restore a
previous configuration.
Response:
3.7.7 Is there a limit to the number of administrators that can be logged on to the system at one
time?
Response:
March 11, 2003 19 of 59

3.7.8 Does the administrative application system have an alternate form of access if the
primary access is unavailable?
Response:
3.7.9 Does the administrative application have on-line help? If yes, describe.
Response:
the base price?
Response:
Response:
3.7.12 Describe the database used to administer the IP PBX and populate telephone tables.
Describe how this database might be integrated with (Customer Name’s) current email,
NT, and HR databases.
Response:
3.8 System Monitoring and Diagnostics
3.8.1 What diagnostic tools are available? Does the system support the Windows 2000 Event
Log? What diagnostic reports are available to aid in isolating faults? Can diagnostics be
remotely accessed? Are the system ‘s diagnostic tools SNMP compliant?
Response:
3.8.2 What remote diagnostics are available? Can administrators see and access any alarms
or alerts on the system from remote terminals?
Response:
3.8.3 Describe the system monitoring report(s) available from the IP PBX. If monitoring reports
are not supported with the current proposed product, state when they will be available in
a released product, and what the expected limitations of these reports will be at that time.
Response:
March 11, 2003 20 of 59

3.8.4 For each of the following system monitoring items listed below, respond with a “Yes” if
the proposed IP PBX monitoring reports can support this feature. If the answer is “Partly
Yes”, then define exactly what is supported and what is not supported, and when you
expect the IP PBX to be able to support this feature. If the answer is “No”, then state
when you expect the IP PBX to be able to support this feature.
Feature YES NO Availability Date

Status Trunking
Real-time traffic
Status of all routing components
Status of all remote components
Status of individual stations
Status of all gateway ports
Provide call trace capability
3.8.5 Describe the system alarms and alarm notification available from the IP PBX.
Response:
March 11, 2003 21 of 59

4 IP TELEPHONY SYSTEM SOFTWARE AND HARDWARE
4.1 Hardware Configuration
4.1.1 Describe in detail the hardware platform supporting the solutions in the small, medium,
and large deployment scenarios. Include whether the solution uses open-market industry
standards–based hardware (with specifications) or is a closed (proprietary) platform.
Response:
4.1.2 What equipment will have to be purchased to support the proposed solution?
Response:
4.1.3 Can the solution work on a customer-specified platform, or is a specific vendor platform
required?
Response:
4.1.4 What is the model name and number of the proposed IP call processing system
(gatekeeper)?
Response:
4.1.5 Describe the IP call processing hardware platform in detail. Is it based on industry
standard hardware, or is it proprietary?
Response:
4.1.6 What standard components are included on the call-processing platform? What
components are optional?
Response:
4.1.7 What is the maximum user capacity of the proposed IP communications system? Provide
a description of how scalability is achieved. For example, describe what is required to
scale from 100 users to over 25,000 users
Response:
4.1.8 What is the maximum number of simultaneous conversations supported by the proposed
system? Is the system non-blocking for voice calls?
Response:
March 11, 2003 22 of 59

4.1.9 What is the maximum number of busy hour call attempts supported by the proposed
system?
Response:
4.1.10 Describe all the gateways the vendor can provide to support connectivity to legacy TDM
equipment and the Public Switched Telephone Network (PSTN). Be sure to include a
description of the gateway options available for analog station and trunk and digital trunk
connectivity.
Response:
4.1.11 Identify all PRI services that you support: ANI, call-by-call, DNIS.
Response:
4.1.12 Identify all PRI feature and signaling options.
Response:
4.1.13 Identify all the PRI features that the proposed system has supported at working customer
sites.
Response:
4.1.14 Please provide a list of PBXs and Central Office switches to which your PRI trunk has
been successfully connected.
Response:
4.1.15 Does the bidder support H.323-compliant gateways from other manufacturers?
Response:
the base price?
Response:
Response:
March 11, 2003 23 of 59

4.2 System Software
4.2.1 Which software package is being proposed? Please provide the release and version?
Response:
4.2.2 Is this the most recent release of this software? When is the next software release due?
Response:
4.2.3 Does the system main memory utilize RAM and/or ROM, or other?
Response:
4.2.4 How does your company provide future software releases? How are software upgrades
performed?
Response:
4.2.5 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?
Response:
4.2.6 How frequently do you back-up the operating software, which includes up-to-date moves
and changes? Is a copy secured off-site, and how frequently is that copy updated?
Response:
4.2.7 What non-proprietary open systems computer telephony (CTI) applications are available
with the proposed system?
Response:
4.2.8 What is your plan of record for developing CTI applications?
Response:
4.2.9 What Telephony Application Programming Interface (TAPI) applications do you support
or currently offer?
Response:
4.2.10 What Java Telephony Application Programming Interface (JTAPI) applications do you
support or currently offer?
March 11, 2003 24 of 59

Response:
4.2.11 Do you have a partner program for third-party applications development?
Response:
4.2.12 If so, list certified example offerings.
Response:
4.2.13 Describe how the system supports workers who may perform their job from more than one location
Response:
4.3 Conferencing
4.3.1 If your system supports Meet-Me conferencing, how many parties to a conference and
how many simultaneous conferences to a resource? Describe the resources and their
limitations.
Response:
4.3.2 Is there password protection and entry and exit tones?
Response:
4.3.3 Is there a scheduling package for managing defined capacities?
Response:
4.3.4 What hardware and software resources are required?
Response:
4.3.5 How many simultaneous conference calls can be scheduled? How many participants are
supported per conference?
Response:
4.3.6 Describe how (Customer Name) employees from non-company telecommuting locations
can (a) gain authorized access to the IP PBX to make calls to (b) local or (c) long
distance calls.
Response:
4.4 System Features
March 11, 2003 25 of 59

For the following features, use the table to indicate their availability. Note if any of these
features are optional or result in additional charges.
FEATURE YES NO OPTIONAL
Answer/Answer Release
Application Sharing
Attendant Console
Audio Volume Adjust
Auto Echo Cancellation
Automated Call-by-call Bandwidth Selection
Automated Phone Installation Configuration
Automatic Phone Moves
Call Detail Records
Call forwarding (Off Premise)
Call forwarding (Ring and/or No Answer)
Call forwarding (Self Directed)
Call Hold / Release
Call Park / Pickup
Call Transfer
Call Waiting
Calling Line ID Line and Name
Chat
Conference (unicast)
Conference (multicast)
Direct Inward Dialing
Direct Outward Dialing (DOD)
Distinctive Ringing (internal vs. external call)
Distinctive Station Ringing Pitch
Event Logging and Reports
Event Viewer Interface
External SMDI Interface
File Transfer
H.323 V2 RAS Support
IP Phones set IP Precedence Bit
IP Routable
IP-based Integrated Messaging
JTAPI
Last Number Redial
License Management
Multiple Calls Per Line Appearance
Multiple Line Appearances
Number Portability
Performance Monitor Interface
PRI Protocol Support (NI-2 and EuroISDN)
Privacy (prevent barge in on bridged extension)
Redundant Call Managers
Remote Process Control
Ringer Pitch Adjust
Ringer Volume Adjust
Shared Extensions on Multiple Phones
March 11, 2003 26 of 59

Single Button Collaborative Computing / Virtual

Meetings
Speakerphone Mute
Speed Dial (Auto-Dial)
System Events on Windows NT Event Viewer
TAPI 2.1
Toll and Nuisance Number (900,976,970,550,540
exchanges) Restriction
Tone On Hold
Video
Visual Message Displays (All digital telephones)
(name, extension, etc.)
Web Administration
Web Documentation
Web-based Speed Dial (Auto-Dial) Directory
Whiteboard
4.5 Station Hardware and IP Softphone
4.5.1 What methods are available to for disposition of blocked calls (announcements, reorder,
queuing, others)?
Response:
4.5.2 Provide a description of each IP telephone available with the proposed system
Response:
4.5.3 Do you offer an IP softphone? If yes, please respond in detail to questions 4.5.3.1
through 4.5.3.10.
Response:
4.5.3.1 Provide a general description of the IP softphone and its features and capabilities.
Response:
4.5.3.2 What PC operating system is required for the IP softphone?
Response:
4.5.3.3 What are the PC requirements for the IP softphone?
Response:
4.5.3.4 What standards are supported by the IP softphone?
Response:
March 11, 2003 27 of 59

4.5.3.5 Does the IP softphone support Microsoft NetMeeting?
Response:
4.5.3.6 Is a physical IP phone required in addition to the IP softphone?
Response:
4.5.3.7 Can the user set up conference calls by dragging and dropping the participants from a
list on their display or from a directory? Can the user place a call by dragging and
dropping the party to be called from a directory?
Response:
4.5.3.8 Is the graphical user interface configurable by the user? Describe which features can
be customized.
Response:
4.5.3.9 Does the IP softphone include an integrated help function?
Response:
4.5.3.10 Does the IP softphone maintain a call history log (separate from the system CDR)?
Response:
4.5.4 Are shared extensions supported on the IP phones? Explain how these work in a call
coverage application.
Response:
4.5.5 Do the phones require manual labeling of features or lines?
Response:
4.5.6 Do the phones support pushing of URL content?
Response:
4.5.7 Can the phones be configured to point to a primary and backup server for redundancy?
Response:
4.5.8 If yes, is failover automatic and how long does it typically take to connect to the backup
server?
Response:
March 11, 2003 28 of 59

4.5.9 If yes, how many servers can the phone be configured to point to?
Response:
4.5.10 How are software/firmware upgrades applied to the phones?
Response:
4.5.11 Do phones support “log in” to use another person’s phone and have your calls directed to
that phone?
Response:
4.5.12 Describe all methods for forwarding calls to cover positions, Voice Mail and the Operator.
Identify how many cover points can be included in the call forwarding, hunting or cover
path.
Response:
4.5.13 Please describe the proposed system’s speed dialing capabilities.
Response:
4.5.14 Identify any of your system’s telephone sets that require local power. Is power required
locally at the station? Please specify the power requirements for each type of set and if
they require local or closet power. If power is lost (for any telephone type), is the
telephone set completely disabled or, is support services such as LCD/LED devices
disabled?
Response:
4.5.15 Are headsets available for all IP phones?
Response:
4.5.16 Does your station equipment provide the following features?

Application Sharing
Audio Volume Adjust
Call Forward Busy
Call Forward No Answer
Call Forward All Calls
Call Hold / Release
Call Park / Pickup
Call Transfer
March 11, 2003 29 of 59

Call Waiting
Calling Line ID Line and Name
Chat
File Transfer
Last Number Redial
Meet Me Conference (multicast)
Multiple Calls Per Line Appearance
Multiple Line Appearances
Prime Line Select
Privacy
Ringer Pitch Adjust
Shared Extensions on Multiple Phones
Single Button Collaborative Computing / Virtual
Meetings
Single Button Retrieve
Speakerphone Mute
Video
Whiteboard
4.5.17 Are 802.3 ports autosensing and autonegotiable?
Response:
4.5.18 Can your solution be configured for VLANs?
Response:
4.5.19 Can your solution be configured for secondary VLANs? If so, describe how the
configuration is accomplished.
Response:
4.5.20 Is VLAN trunking supported, or multiple VLANs on a single interface?
Response:
4.5.21 How does your system support power fail transfer?
Response:
4.6 IP Manager-Assistant
4.6.1 Are there special features or configurations associated with Manager/Boss and
Admin/Secretary telephones?
Response:
March 11, 2003 30 of 59

4.6.2 Is additional hardware or software required?
Response:
Managers
4.6.3 Does the manager have a GUI application for setup or configuration?
Response:
4.6.4 Do managers have access to select assistants that will support their calls?
Response:
4.6.5 Are they accessible from Telephone, Application or both?
Response:
4.6.6 Can a manager select whether or not all calls will ring only on assistant’s telephone?
Response:
Response:
4.6.8 If all calls are ringing only on assistant’s telephone, does a manager have the ability to
see who is calling for them?
Response:
4.6.9 If so, can a manager intercept or take call from assistant’s phone?
Response:
4.6.10 Can the manager manually re-route an incoming call from his/her phone to the assistant?
Response:
4.6.11 Can managers configure filters to allow or disallow certain calls to be answered directly
by the manager?
Response:
Response:
March 11, 2003 31 of 59

Assistants
4.6.13 Does the assistant have a GUI application to support managers?
Response:
4.6.14 Can the assistant send an active call directly to manager’s voicemail?
Response:
4.6.15 If yes, how many steps are involved?
Response:
4.6.16 Can the assistant send an active call directly to a manager?
Response:
4.6.17 If yes, how many steps are involved?
Response:
4.6.18 Can assistant view the manager's status?
Response:
4.6.19 Can assistant change or update manager's configuration?
Response:
4.7 Attendant Console
(Customer Name) prefers a PC-based attendant console application rather than a traditional
hardware console. Does your system offer a PC-based attendant console application? If so,
please respond in detail to this section:
4.7.1 Provide a description of the general capabilities and features of your PC-based attendant
console application.
Response:
4.7.2 Is the PC-based attendant console application browser-based? What PC operating

systems are supported?
Response:
March 11, 2003 32 of 59

4.7.3 Provide an illustration of the PC-based attendant console application GUI and describe
its key features.
Response:
4.7.4 Does the PC-based attendant console have loop keys? How many loop keys are
supported?
Response:
4.7.5 Does the PC-based attendant console application have a busy lamp field (or equivalent)?
Response:
4.7.6 Can the PC-based attendant console application access the corporate (LDAP) directory?
Can the operator search the directory? Can the operator use the directory list to drag
and drop incoming calls to the destination extension?
Response:
4.7.7 Is the PC-based attendant console application a separately priced option? If so, what is
the price?
Response:
4.7.8 Do all of the PC-based attendant console applications that are running share the same
information?
Response:
4.7.9 How many PC-based attendant console applications can be supported by the system?
Response:
4.7.10 What is the maximum number of simultaneous calls that can be handled by the PC-
based attendant console application?
Response:
4.8 System Reporting and Call Detail Reporting
4.8.1 Describe how system CDR reporting is configured. How are these records accessed?
Response:
March 11, 2003 33 of 59

4.8.2 What is the format of the CDR records? Can they be exported to an external application
for analysis?
Response:
4.8.3 Do you recommend any third-party CDR billing vendors?
Response:
4.8.4 Does the system have the capability to report by location and on a consolidated
enterprise level? Provide examples.
Response:
4.8.5 What standard reports are included with the system?
Response:
4.8.6 How are customized reports generated?
Response:
March 11, 2003 34 of 59

5 VOICE MAIL AND UNIFIED MESSAGING SYSTEM SPECIFICATIONS

In this section the customer should state their voice mail/unified messaging requirements in
detail, including required or desired features and applications, number of users to be supported,
growth requirements, or desired network infrastructure changes. There should also be a
discussion of any particular business problems that the customer wishes to solve.
EXAMPLE: (delete from actual RFP)

Replace with information specific to your customer.
This section details the specific technical requirements which GetReady Company's Voice Mail
System must satisfy, and documents the principal applications to be supported by the system. A
single system solution must support a minimum of 100 users with growth to 500 users, and
provide voice mail functionality. Users should be able to access their voice mail messages locally
and remotely through a standard DTMF phone.
5.1 Voice /Unified Messaging System Description and Support Options
5.1.1 Describe in detail your voice/unified messaging product offering. Include an overview of
the hardware, software, architecture, and components of the equipment proposed to
meet (Customer Name’s) requirements.
Response:
5.1.2 What is the typical method of support for future software updates, and how are licensing
upgrades handled?
Response:
5.1.3 What hardware level support is available? Can the appropriate hardware for our design
be purchased directly from Cisco or only from a third party?
Response:
5.2 Voice /Unified Messaging System Specifications
5.2.1 How many ports are proposed to support (Customer Name’s) 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.
Response:
March 11, 2003 35 of 59

5.2.2 Are voice messages stored in an industry standard format? How many Mbytes of disk
space are required for each hour of voice storage?
Response:
5.2.3 What operating system does the voice mail/unified messaging system use?
Response:
5.2.4 Does the voice mail/unified messaging system support AMIS-A and/or VPIM for
networking?
Response:
5.2.5 Does the voice mail/unified messaging system support connectivity to Avaya/Octel
networked voice mail? If so, please explain how this functionality is supported.
Response:
5.2.6 What database is used for the message store?
Response:
5.2.7 Once a voice mail is left, can it be forwarded to another user? Can the user append
comments before forwarding the message to another user? Explain how this works.
Response:
5.2.8 Is the voice mail/unified messaging system remotely accessible for both subscribers and
administrators? Can the system be accessed from a standard touch-tone phone? What
other types of clients and points of access are supported?
Response:
5.2.9 Specify if the ports on the proposed system are used in one direction or used for both
incoming and outgoing call activities such as message notifications and voice application
call handling. Can this be programmed under administrative control?
Response:
5.2.10 Does the proposed system use analog or digital interface ports? If analog, include in
your proposal the specific interface card required for the IP Communication system. If
proposed ports are digital, provide all specifications that the telephone system must meet
for proper operation. Is your offering truly an “IP/voice converged system”? Please
explain, and use architectural diagrams if possible.
Response:
March 11, 2003 36 of 59

5.3 Voice Mail System – System Features
5.3.1 Describe in detail the voice digitization technique and voice digitization rate used for
recording users' speech.
Response:
5.3.2 Indicate the capacity limits that can be defined for a particular voice mailbox. Indicate
whether or not this is configurable by class of service.
5.3.2.1 What is the length of the longest message that can be recorded by a caller?
Response:
5.3.2.2 How many messages can be stored in a subscriber's mailbox?
Response:
5.3.2.3 What is the maximum total number of minutes of messages that can be stored in a
single voice mailbox? How is this controlled with your system?
Response:
5.3.2.4 Are users given any notification that these limits have almost been reached?
Response:
5.3.2.5 Does the system provide an "end of recording" warning?
Response:
5.3.3 Does the system provide user adjustable playback speed control (with full pitch
preservation)?
Response:
5.3.4 Does the system provide alternate system wide conversations? Please explain.
Response:
5.3.5 Does the unified messaging system provide any text to speech capabilities? If so,
please explain how a typical subscriber would take advantage of this feature.
Response:
5.3.6 Does the unified messaging system provide ASR and speech recognition features?
Response:
March 11, 2003 37 of 59

5.3.7 Can system prompts be interrupted by experienced users? In other words, is there a "fast
path" for users? Can system prompts be repeated?
Response:
5.3.8 If a caller does not know a particular subscriber's extension number, can they "look up"
the subscriber by "spelling" the name via touch tone input? Explain how the system
would resolve the situation where one name has multiple entries (e.g., "Jones")?
Response:
5.3.9 Does the voice mail system support multiple greeting? If yes, describe all available
greetings.
Response:
5.3.10 Are touch-tone keys dedicated to a specific function, or are they context-sensitive?
Response:
5.3.11 Does the voice mail system support a "zero out" to the attendant feature? Is this feature
configurable by class of service? Can the "zero out" destination be a station rather than
the attendant? If the "zero out" destination is busy, or rings unanswered, will the call be
re-directed?
Response:
5.3.12 Describe the voice mail systems capabilities with regard to the following security
features?
5.3.12.1 Users should be required to enter a password to access their voice mailbox. What is
the minimum and maximum password length? How is this configured? Can it be
different for different classes of users?
Response:
5.3.12.2 Does the system track failed password entries in a single session? Does the system
automatically disconnect the caller after a configurable number of failed attempts?
Response:
5.3.12.3 Does the system track failed password entries across multiple sessions? Does the
system automatically lock out the user after a configurable number of failed attempts?
Response:
5.3.12.4 Does the system log information about failed password attempts?
March 11, 2003 38 of 59

Response:
5.3.12.5 Does the system require a system administrator password?
Response:
5.4 Voice Mail System – User Features
5.4.1 Can system subscribers conduct the following actions:
5.4.1.1 Pause and replay messages
Response:
5.4.1.2 Record messages; send and mark "urgent", "private", etc.
Response:
5.4.1.3 Transfer messages to other users and append them with their own comments
Response:
5.4.1.4 Create their own distribution lists
Response:
5.4.1.5 Edit / Modify their own distribution lists
Response:
5.4.1.6 Dial internally by name / company directory
Response:
5.4.1.7 Obtain user instruction through system prompts
Response:
5.4.1.8 Record personal greetings. How many different greetings can they have?
Response:
5.4.1.9 Modify own passwords.
Response:
5.4.1.10 Set business days and hours for alternate greetings.
Response:
March 11, 2003 39 of 59

5.5 Voice Mail System – System Administration
5.5.1 Is system administration done through a standard web-enabled GUI? If so, please
explain the advantages of this type of administration over other methods?
Response:
5.5.2 The system administrator should be able to perform the following actions:
5.5.2.1 Add or modify a class of service. State what user permissions or characteristics within a
class of service can be created or modified.
Response:
5.5.2.2 Set the minimum and maximum password length for a user.
Response:
5.5.2.3 Set the maximum length of voice messages.
Response:
5.5.2.4 Set the maximum failed login attempts before a user lockout from the mailbox.
Response:
5.5.2.5 Assign default passwords for users, and reset passwords for users that have been
locked out of their mailboxes.
Response:
5.5.2.6 Set the "disk space remaining" warning level.
Response:
5.5.2.7 Add, delete, or modify a user.
Response:
5.5.3 Explain how the system administrator would perform a backup and restore on the voice
messaging system.
Response:
5.5.4 Please explain the major features provided by your system that directly support
administration of remote branch office users.
Response:
March 11, 2003 40 of 59

March 11, 2003 41 of 59

6 IP CONTACT CENTER SYSTEM SPECIFICATIONS

This section is to provide an overview of the vendor's proposal and it’s architecture, and
experience in the manufacturing, installation, and support of the type of system
proposed. It also covers how the vendor will provide an intelligent network infrastructure
to support the IP Contact Center system.
6.1 Hardware Configuration
6.1.1 What is the model name and number of the proposed IP Contact Center Solution?
Response:
6.1.2 Describe your integrated IVR functionalities, as well as “media” on hold capabilities.
Response:
6.1.3 What is the maximum number of agents supported in a single group?
Response:
6.1.4 What is the maximum number of simultaneous conversations supported by the proposed
system? Is the system non-blocking for voice calls?
Response:
6.1.5 What email integration does your system support? Is email an integrated component of
your system? If so, please describe.
Response:
6.1.6 What web collaboration (co-browse, text chat, web callback) does your system support?
Is Web-based support an integrated component of your system? If so, please describe.
Response:
6.1.7 What voice mail integration does your system support?
Response:
6.2 System Software
6.2.1 Which software package is being proposed? Please provide the release and version?
Response:
6.2.2 Is this the most recent release of this software? When is the next software release due?
Response:
March 11, 2003 42 of 59

6.2.3 How does your company provide future software releases? How are software upgrades
performed?
Response:
6.2.4 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?
Response:
6.2.5 How frequently do you back-up the operating software, which includes up-to-date moves
and changes? Is a copy secured off-site, and how frequently is that copy updated?
Response:
6.2.6 What non-proprietary open systems computer telephony (CTI) applications are available
with the proposed system?
Response:
6.2.7 What Telephony Application Programming Interface (TAPI) applications do you support
or currently offer?
Response:
6.2.8 What Java Telephony Application Programming Interface (JTAPI) applications do you
support or currently offer?
Response:
6.3 Agent Station Hardware and Software
6.3.1 Do IP agent phones work on standard Ethernet port? Provide details on all models
supported with specific mention of the models that have a built-in switch to connect agent
desktop.
Response:
6.3.2 Does the IP phone use a single directory that is common for the data network and allow
display of name, extension browsing and dialing by press of a button?
Response:
6.3.3 Please describe the agent desktop interface to manage and process agent
incoming/outgoing contacts.
Response:
6.3.4 Does your solution require a “hard phone” for the agent desktop to be VoIP enabled?
Response:
March 11, 2003 43 of 59

6.3.5 Do the agent IP phones support the following features?

Audio Volume Adjust
Call Forward Busy
Call Forward No Answer
Call Forward All Calls
Call Hold / Release
Call Park / Pickup
Call Transfer
Call Waiting
Calling Line ID Line and
Name
Chat
Last Number Redial
Ringer Pitch Adjust
Speakerphone Mute
6.3.6 Can callers be presented with the option of leaving a message, and can this message be
routed accordingly?
Response:
6.3.7 Are pre-defined responses available as an agent tool in your solution? Please describe.
Response:
6.3.8 Does your solution support remote agents or satellite offices? Please describe.
Response:
6.3.9 Please describe the supervisor capabilities of your solution, barge-in, silent monitoring,
etc.
Response:
6.4 Call Routing and Reporting Software Functionality
6.4.1 Does your system manage call routing from a single application for all Contact Center
locations?
Response:
6.4.2 Can the following routing strategies be used with your proposed system?
ROUTING Yes or No
March 11, 2003 44 of 59

1 Application Based Routing and Reporting

2 Automatic Call Distribution
3 Call By Call Routing
4 Call Re-Routing Based on Wait Time
5 Call Re-Routing Based on Non-Answer
Conditional Routing based on Time of Day,
6
Day of Week and Holidays
Conditional Routing based on Calls in
7
Queue
8 Conditional Routing based on Caller Origin
Conditional Routing based on Dialed
9
Number
Conditional Routing based on Caller
10
Entered Digits (CED)
Directed Agent Routing (single agent
11
selection)
12 Database Call Handling
14 Look Ahead Queuing
15 Look Back Queuing
17 Overflow (retains queue position)
18 Priorities
19 Skill-Based Routing
20 Build your own Strategy Routing
6.4.3 Describe with detail your skills based routing algorithm? Does this apply to all media
channels?
Response:
6.4.4 Does your system provide agent proficiency setup?
Response:
6.4.5 Are all contacts “queued” in the same fashion regardless of media type?
Response:
6.4.6 Are routing priorities available with your solution and if so, how are they assigned to
different media contacts?
Response:
6.4.7 How is the IVR functionality reflected in the reporting? Does it cause double pegging?
Response:
6.4.8 Does your software provide reports for all agents across all locations?
Response:
March 11, 2003 45 of 59

6.4.9 Does your software collect information through the entire life of the complete customer
interaction and provide not only real time, but also historical reporting? Please provide
detailed descriptions of all reporting capability.
Response:
6.4.10 Does your application support a web-view monitoring tool for read-only access to real
time contact center performance reports and call routing scripts? Explain the features,
functionality and reports that can be viewed through the web-view feature.
Response:
6.4.11 Does your system offer the ability for an agent to record a conversation with a customer
(for instance if a customer was being abusive)? Please describe how this feature would
be activated.
Response:
6.5 Computer Telephony Integration (CTI)
The (Customer Name) is interested in implementing CTI on a limited basis.
6.5.1 Do you have screen-pop integration capability?
Response:
6.5.2 Is CTI integration handled “out of the box,” via toolkits, or integrated with CRM
applications? Or does your system offer multiple options? If so, please describe.
Response:
6.5.3 Explain how your system can access database information for call routing decisions or
screen pop data.
Response:
6.5.4 Explain how your system delivers third party call control from a CTI-enabled desktop.
Response:
6.6 Web Collaboration Functionality
6.6.1 The (Customer Name) is considering adding web collaboration functionality at some
future time. Please describe your current web collaboration capabilities.
Response:
March 11, 2003 46 of 59

6.7 eMail Response Management
6.7.1 Please describe your current email management capabilities. Include specific details on
how your system interfaces with email and with which systems it can interface.
Response:
6.8 Fax Management
6.8.1 Please describe your current fax management capabilities. Include specific details on
how your system interfaces with fax contacts and with which systems it can interface.
Response:
March 11, 2003 47 of 59

7 IMPLEMENTATION
7.1 Project Management
7.1.1 Project Plan - Bidders are required to supply a complete description of the key activities
required for the installation of the proposed system.
Response:
7.1.2 Project Organization Chart - In the project plan, the bidder will include a project
organization chart with the reporting relationships of project team members and other key
personnel. An escalation matrix should also be included.
Response:
7.1.3 Transparency - It is essential that the installation of the new system be as transparent
as possible to the users. There should be no telephone service interruptions, no interim
changes in dialing procedures, and no perceived degradation in the quality of service.
Response:
7.1.4 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 (Customer Name) is expected to perform to successfully
implement the new system.
Response:
__________________________________________________________________
EXAMPLE: This sample implementation plan is included to provide a suggested
format. Actual activities and dates are always customer-specific.
(CUSTOMER NAME)
SAMPLE IMPLEMENTATION PLAN
All necessary tasks related to your installation are tracked to ensure a trouble-free
cutover. The project manager uses an implementation plan similar to this enclosed
sample.
ACTIVITY START END
Preimplementation
Proposal submitted
Contract awarded to vendor
Initial customer meeting
Site Preparation
Secure storage for equipment
Required structural modifications
Electrical Modifications and Inspection
System Design
Letter of agency
March 11, 2003 48 of 59

Telco planning meeting

Order telco services
System design meetings
New Telco Requirements

Test new telco
Data entry
Test software applications
Software freeze date
Cable Plant
Tone and test cable
Install station cable
Install house cable (if required)
Install outside plant (if required)
IP Communication System Installation

Deliver equipment to site
Power up and test
Install servers
Install gateways
Install MDF and IDF
Install UPS systems
Run cross-connects
Set phones
Training
Identify training room
Schedule users for class
User training classes
Cutover
Install trunks to PSTN
IP Communication System ready for full
utilization
Post-Cutover Activities
In-service coverage
System Acceptance
Service turnover meeting
7.2 Installation Requirements
7.2.1 Responsibility - The selected vendor is solely responsible for the complete turn-key
engineering of the new telecommunications system and all interconnecting facilities.
Response:
7.2.2 Initial Work - Vendor will perform station reviews, data base preparation, and original
program initializations.
March 11, 2003 49 of 59

Response:
7.2.3 Telco Coordination - Vendor will coordinate the ordering of all long-distance and local
communications facilities as deemed necessary by (Customer Name). Ensure that WAN
circuits are in place as required.
Response:
7.3 Facility Requirements
7.3.1 Bidders must furnish all space, power, and environmental requirements for the proposed
telephone system and optional voice messaging equipment.
Space – Provide the physical dimensions of the proposed equipment.
Power - All power requirements, including any special conditioning or grounding

requirements.
Heat - Vendor must provide heat dissipation for proposed switchroom and the
recommended safe temperature operating range for the proposed system.
Floor Loading - Vendor must provide complete floor loading requirements.
ADD A TABLE HERE FOR ENVIRONMENTALS:
7.4 Training
7.4.1 Requirements - The successful bidder is required to conduct end-user training on

(Customer Name) premises, tailored specifically to (Customer Name)’s particular
requirements (e.g., console operator, message center operator, secretary, and
professional).
Training class sizes will not exceed more than _____ station users at a time.
_____ users will require training on the new telephone system.
_____ users will require data communications training.
_____ users will require ACD agent training.
Response:
7.4.2 Training Plan - Vendor will also provide a training program and training materials for
designated (Customer Name) personnel who will train future employees.
Response:
March 11, 2003 50 of 59

7.4.3 Description - For each product application proposed, provide a detailed description of
the training the vendor will provide. Specify the cost of this training.
Response:
7.4.4 Materials - Reference copies of the training materials should be included as part of the
bidder's response to this RFP.
Response:
March 11, 2003 51 of 59

8 VENDOR SERVICE
8.1 Maintenance and Warranty
8.1.1 A complete maintenance and warranty agreement must be included as part of the
bidder's proposal, including all options available for extended coverage and full pricing
details for each level of coverage.
Response:
8.1.2 One Year Warranty - 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 one year following
system cutover.
Response:
8.1.3 Defective Parts - During the warranty period and any subsequent maintenance
agreement, any defective components shall be repaired or replaced at no cost to
(Customer Name).
Response:
8.1.4 Maintenance Personnel - 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 bidder and at no additional cost to (Customer
Name) other than those charges stipulated to maintain the warranty.
Response:
8.1.5 Ten Year Support - As part of the response to this specification, the bidder must
guarantee to continue to provide system maintenance for a period of not less than ten
years following the expiration of the original warranty period.
Response:
8.2 Logistical Support
8.2.1 Bidder should identify the address of the vendor's local service centers and the number
of service personnel trained on the proposed system.
Response:
March 11, 2003 52 of 59

8.2.2 Include in this section any other support levels in the local area available to (Customer
Name) for the maintenance of the proposed system.
Response:
8.3 Repair Response
8.3.1 The successful bidder will provide routine system monitoring to assure the continued
operation of all system components.
Response:
8.3.2 Repair Commitment - The bidder must include a description of the bidder's repair
commitment from time of trouble discovery through the time the trouble is cleared.
Response:
8.3.3 Response Time - (Customer Name) is guaranteed a response time of no more than #
hours for all major system problems and a maximum of # hours response to other
system problems.
Response:
8.3.4 4 Hour Response - During the warranty period, the bidder must supply no more than a
4-hour response to major problems, 24 hours a day, 7 days a week.
Response:
8.3.5 Major/Minor Problems - Bidders must describe their definitions of major and minor
problems.
Response:
8.3.6 Preventative Maintenance - Explain any services the vendor offers that would assist in
disaster avoidance and recovery planning for the proposed system.
Response:
8.3.7 Spare Parts Availability - Describe the availability of spare parts maintained in the area
for the critical hardware and software.
Response:
March 11, 2003 53 of 59

8.3.8 Replacement Time - Explain the amount of time required for full replacement of the
central operating hardware/software of the system, assuming a suitable site exists for
locating the replacement components.
Response:
8.3.9 Emergency Installation - How long does it take trained personnel to install and load
operating system software and database software, if a major disaster destroys the call
processing component (gatekeeper) of the system.
Response:
8.3.10 Plan - Explain the available services provided by the vendor to allow for a high level of
recovery from disasters [e.g., within two (2) hours, four (4) hours].
Response:
8.3.11 Back-up Procedures - Describe standard database back-up procedures.
Response:
8.3.12 Replacement Options - Describe the options available to (Customer Name) if a system
component is destroyed (e.g., replacement with the next machine on the assembly line,
replacement systems available locally, customer spares on site, etc.).
Response:
March 11, 2003 54 of 59

9 CONFIGURATION/PRICING
9.1.1 Bidder must itemize all charges for individually identifiable components of the proposed
IP Communication system, including all associated installation, programming, and
cabling. Bidder must include charges for all components required to connect all
applications, all design charges, telco interface charges, and training charges.
Response:
March 11, 2003 55 of 59

10 FINANCIAL REQUIREMENTS
10.1 Payment Options
10.1.1 Bidder shall offer methods of payment to include leasing options.
Response
10.2 Payment Schedule
10.2.1 Bidder must include payment schedules available with the proposed leasing options.
Response:
March 11, 2003 56 of 59

11 TERMS AND CONDITIONS

THESE QUESTIONS ARE SAMPLES OF WHAT COULD BE ON A REQUEST
FOR PROPOSAL. PLEASE CONTACT YOUR BRANCH CONTRACTS
ADMINISTRATOR AND/OR FIELD CONTRACTS PRACTICES PERSONNEL FOR
THE PROPER RESPONSES TO THESE QUESTIONS.
11.1.1 Damage Liability - The successful vendor is liable and responsible for any damage to
the premises (e.g., floor, walls, etc.) caused by vendor personnel or equipment during
installation and is responsible for the removal of all project-related debris.
Response:
11.1.2 Permits - The vendor shall obtain and pay for any permits and licenses required for the
performance of the work, post all notices required by law, and comply with all laws,
ordinances and regulations bearing on the conduct of the work, as specified herein. On
any work which requires an inspection certificate issued by local authorities, National
Board of Fire Underwriters, or any other governing body, such inspection certificate(s)
shall be obtained by and paid for by the vendor. The chosen vendor shall procure all
required certificates of acceptance or of completions issued by the state, municipal or
other authorities and must deliver these to (Customer Name).
Response:
11.1.3 Insurance - The vendor shall, at vendor expense, procure and maintain satisfactory
public liability and casualty insurance to adequately protect the vendor's personnel and
(Customer Name) against damages for bodily injury, including death, that may arise from
operations under this contract, whether such operations are by the vendor or by the
vendor's subcontractor, or anyone directly or indirectly employed by the vendor.
Response:
11.1.4 Vendor Responsibility - Unless otherwise stipulated, vendor shall provide, and pay for,
all materials, labor, tools, equipment, transportation, and other facilities necessary for the
performance and completion of the work. Vendor shall verify conditions at the building,
particularly door openings and passages. Any pieces too bulky for existing facilities shall
be hoisted and otherwise handled with apparatus as required.
Response:
11.1.5 Terms and Conditions - The vendor shall include a copy of standard terms and
conditions as part of the system proposal.
Response:
March 11, 2003 57 of 59

11.1.6 RFP Responses - All materials submitted by the vendor in response to this RFP
become the sole property of (Customer Name) upon receipt of the proposal. The
material contained in these responses will be appended to the final contract, further
defining the contractual responsibilities of the vendor.
Response:
March 11, 2003 58 of 59

APPENDIX
Product literature
References
Sample Reports
Traffic Reports – Samples
Drawings
March 11, 2003 59 of 59

Sample RFP Template

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sample RFP Template

Uploaded by

Copyright:

Available Formats

REQUEST FOR PROPOSAL

FOR A NEXT GENERATION IP-BASED VOICE,

<Customer Name (please do not include a logo)

March 11, 2003 2 of 59

1 (CUSTOMER NAME’S) REQUEST FOR PROPOSAL........................................................5

1.1 RFP OVERVIEW............................................................................................................................5

3.1 PROPOSED IP COMMUNICATIONS SYSTEM......................................................................................12

4 IP TELEPHONY SYSTEM SOFTWARE AND HARDWARE ..........................................22

4.1 HARDWARE CONFIGURATION.........................................................................................................22

5 VOICE MAIL AND UNIFIED MESSAGING SYSTEM SPECIFICATIONS...................35

5.1 VOICE /UNIFIED MESSAGING SYSTEM DESCRIPTION AND SUPPORT OPTIONS.....................................35

March 11, 2003 3 of 59

5.3 VOICE MAIL SYSTEM – SYSTEM FEATURES...................................................................................37

6 IP CONTACT CENTER SYSTEM SPECIFICATIONS .....................................................42

6.1 HARDWARE CONFIGURATION.........................................................................................................42

7.1 PROJECT MANAGEMENT...............................................................................................................48

8.1 MAINTENANCE AND WARRANTY ..................................................................................................52

10.1 PAYMENT OPTIONS ....................................................................................................................56

11 TERMS AND CONDITIONS...............................................................................................57

March 11, 2003 4 of 59

1 (CUSTOMER NAME’S) REQUEST FOR PROPOSAL

1.1 RFP Overview

Key Decision Criteria

• IP-based Voice/Data/Video capabilities and Intelligent Network

• Vendor Experience and Vision: Evaluation of the vendor's experience

• Vendor support for Open System Standards: The vendor

• Voice Messaging: Scalable, cost-effective voice messaging

March 11, 2003 5 of 59

• System Administration: Maximum flexibility for rapid, efficient, and cost-

• Vendor Support/Service Capabilities: Remote serviceability, technical support

• Scalability: Modular, cost-effective growth in both IP phones and applications

• Leading Edge Technology: The ability to incorporate future requirements and

1.2 Customer Contacts and Contract Requirements

Contact Name: ________________________________

Requests for clarifications should be e-mailed. Clarifications will be sent to all

1.3 Proposal Filing Date

All proposals must be received by (Name), (Customer Name), (Address) by

Bids received after that time will not be accepted.

1.4 Number of Copies

# copies of the proposal are to be delivered to (Customer Name).

1.5 Schedule of Events

March 11, 2003 6 of 59

Purchasing Decision Mm/dd/yy

1.6 Proposal Response Format

1.7 Vendor Questionnaire

Bidding Company Name:

Sales Representative Name:

1.7.1 Who manufactures the proposed system?

If not Proposing Vendor, Manufacturer Name:

1.7.5 Does the bidder provide on-site assistance if it is required?

March 11, 2003 7 of 59

March 11, 2003 8 of 59

1.8 Overview of Current Environment

(Customer Name) has the following current environment……

EXAMPLE - from a fictional company:

Figure 1: (Customer Name’s) Current Data and Voice Networks

March 11, 2003 9 of 59

1.9 Requirements for (Customer Name’s) IP Communications System

(Customer Name) requires the following……..

EXAMPLE from a fictional company:

March 11, 2003 10 of 59

March 11, 2003 11 of 59