Best Practices for Preparing a Request for Proposalby Be.docx

Best Practices for Preparing a Request
for Proposal
by Betsy Walli
Copyright 2010, Faulkner Information Services. All Rights
Reserved.
Docid: 00018560
Publication Date: 1012
Report Type: TUTORIAL
Preview
A well-crafted, thoroughly defined RFP is the principal
instrument for successful procurement of enterprise
systems and software. The RFP should focus on the business
needs to be addressed by the acquisition,
and be designed to elicit vendor responses that are specific,
complete, and of a consistent format to allow
cross-vendor comparisons. The winning vendor's RFP response
can be automatically incorporated into
an organized, detailed contract. RFP preparation tools that
allow electronic distribution and results
processing greatly reduce data entry and analysis time, as well
as printing and distribution costs.
Report Contents:
● Executive Summary

● Description
● Current View
● Recommendations
● Web Links
Executive Summary
[return to top of this report]
A well-crafted, thoroughly defined request for proposal (RFP) is
the principal instrument for successful
procurement of enterprise systems and software. An RFP should
focus on the business needs to be
addressed by the acquisition, and be designed to elicit vendor
responses that are specific, complete, and
of a consistent format, to allow cross-vendor comparisons. The
winning vendor's RFP response can be
automatically incorporated into an organized, detailed contract.
RFP preparation tools that allow electronic
distribution and results processing greatly reduce data entry and
analysis time, as well as printing and
distribution costs.
Effective contract management comprises a series of steps.
The first step is to determine the business needs that the
technology procurement will address. Next a
company must prepare and distribute a request for proposal
(RFP) that articulates those needs. After
evaluating the proposals it receives in response to the RFP and
choosing a supplier, the company is
ready to negotiate and write a contract with the supplier. The
company must then be prepared to ensure
contract performance, and to re-negotiate the contract when
circumstances change. Each step builds on

all the preceding ones. Contract management is most successful
when a company approaches each step
with this entire process in mind.
The procurement of enterprise systems and software is a
complex process that must be carefully planned
and executed. A well-crafted, thoroughly defined RFP is the
principal instrument for success. Those
buyers that develop an effective RFP can reap a significant
return on investment (ROI) due to having
meticulously described business requirements for a select group
of vendors. The RFP is a critical link
between the buyer and the seller that enables both to work from
the same set of requirements, schedules,
and information. The winning vendor is awarded the contract
after effectively responding to the RFP’s
stringent list of questions and criteria.
Successful RFPs are clear and complete. Many RFPs fail
because they neglect to include some basic
technical requirements. To enable suppliers to provide the best
solution, an RFP must present a clear
understanding of all technical issues, as well as providing a
method for implementing and managing those
issues. RFPs should also be articulate in describing acceptable
business practices to suppliers, and they
should be designed to elicit a vendor response that can be
converted easily into a contractual agreement
that retains much of its original form.
Preparing an RFP and reviewing subsequent proposals is a
labor- and time-intensive activity, but
enterprises that prepare RFPs properly will reap rewards from
solid, mutually beneficial partnerships as a
result. The time and effort spent reviewing and comparing
vendor responses to a detailed RFP can be

minimized if a company first narrows the field of potential
suppliers to a short list of the most promising
prospects and sends the full RFP only to them. RFP preparation
tools can reduce the time and work
involved in preparing an RFP while still creating customized
results. RFP tools that allow electronic
distribution and results processing greatly reduce data entry and
analysis time, as well as printing and
distribution costs. Once a vendor is chosen, that vendor's
electronic RFP response can be automatically
incorporated into an organized, detailed contract. Another
option is to hire an outside consultant with
detailed business process knowledge to help with the RFP
process and to ensure that all pertinent issues
are addressed.
Description
An RFP is used to detail the solution an enterprise wants to
implement and to evaluate vendor proposals
in a systematic and consistent manner. It accurately
communicates an organization’s needs, and it
enables a company to determine the suitability of a proposed
system. An RFP is not used to learn about a
vendor’s technology. For that purpose, an enterprise should
write an request for information (RFI), which
is discussed later in this report.
An effective RFP requires vendors to make concrete and
detailed commitments when submitting
competitive bids on products and services, which leads to
proposals that are easier to evaluate and
contracts that are easier to enforce. With a careful RFP process,

a company can also reduce the chance
of large cost overruns; software that is missing mission-critical
features; slow or hard-to-use software; and
expensive, unplanned data conversions.
RFPs do not necessarily follow a particular format or outline.
They typically provide a list of essential
business requirements, with each business process addressed in
a separate section. Within each section,
the vendor is asked to address how it can meet each
requirement. RFPs should be highly detailed. They
thus tend to be lengthy.
According to On-Line Consultant Software (OLC), the provider
of an automated RFP development tool, a
well designed RFP provides the following benefits:
● Requires buyers to define and prioritize their needs.
● Adds structure to the procurement process.
● Allows for "apples to apples" vendor comparisons.
● Provides objective data that support informed decision-
making.
● Increases price competition among vendors (which saves
the company money).
● Increases vendor participation by showing serious customer
interest.
● Minimizes risks in vendor and system selection.
● Involves users in the decision-making process, increasing
the likelihood of "buy-in" during
implementation.
● Helps ensure project funding by demonstrating a rigorous,
no-nonsense approach to capital
spending.
● Helps in the interpretation of vendor contracts and dispute

resolution.
While the details may differ, most RFPs for enterprise systems
and software address the same
fundamental issues. For hardware acquisitions, these factors
include (but are not limited to):
● Performance - What are the minimum acceptable
performance characteristics? Response time?
Turnaround time?
● Peripheral Equipment - What speed is required? What
capacity?
● System Backup - How are backups performed? Is the
system configured to conduct full
backups?
● Connectivity - How will the system be integrated into the
customer's existing local or wide area
network?
● Compatibility - Is the system compatible with industry
standards and the customer's existing
equipment?
● Fault Tolerance - What are the "single points of failure"?
Can the system be configured to
minimize or eliminate these exposures? This is particularly
important for mission-critical
applications that demand very high system availability.
● Maintenance - How does the vendor handle maintenance?
In many cases, hardware support is
outsourced to a third-party firm. Where is the nearest spare
parts depot?

● Upgrade Path - Is the system expandable or upgradable?
What is the process and what are the
limits on growth?
● Future Product Plans - What are the vendor's plans for new
or enhanced systems?
● Price - What is the cost? Are any volume discounts
available?
For software procurements, the factors include (but are not
limited to):
● Ease of Use - What impact will the software have on
productivity? How can this effect be
measured?
● License Fees - Is the software licensed by user or is a site
license available?
● Compatibility - Will the software run on the customer's
current systems, or is additional hardware
required?
● Documentation and Support - What documentation and help
are available, and in what form?
Manuals? Online "help" systems? Toll-free customer service
phone numbers?
● Installation and Training - How much training and
installation support does the vendor provide?
At what cost?
● Upgrade Path - Is the software expandable or upgradable?

What is the process and what are the
limits on growth?
● Future Product Plans - What are the vendor's plans for new
or enhanced versions?
● Price - What is the cost? Are any volume discounts
available?
Current View
RFP preparation can be a laborious and daunting process due to
the size and highly technical orientation
of the document. It can therefore be tempting to buy and use a
generic RFP or to reuse an RFP that was
developed for a past procurement. The procurement process,
however, will be far more successful if the
RFP is tailored to a particular organization’s present needs,
priorities, and business environment, which
requires careful planning and execution. The investment in
preparing a well-written RFP will pay off over
time as the enterprise benefits from systems and software that
best suit its requirements.
Short List Selection. Reviewing and comparing vendor
responses to a detailed RFP can be time-
consuming. This effort can be minimized if a company first
narrows the field of potential suppliers to a
short list of the most promising prospects, and then sends the
full RFP only to the short list. To narrow the
field of suppliers, a company distributes a brief document that
covers only its "must-have" major
requirements. The best three to five responses to this request for
information (RFI) become the short list.
RFP Preparation Tools. Some companies, including Infotivity,

OLC, and SupplierSelect, offer RFP
preparation tools that reduce the time and work involved in
preparing an RFP while still creating
customized results. These packages include project domain
checklists, sample questions, and RFP
templates that a company can fit to a particular procurement
situation by adding, deleting, modifying, and
prioritizing questions. For example, Infotivity offers sample
RFP questions and layouts for a variety of
applications, including accounting, electronic document
management software, manufacturing, order
processing/inventory, web site development, and workflow
processing. EC Sourcing Group reports that
implementing their sourcing and vendor management software
can cut negotiation time and
administrative costs by about 50 percent, and that the increased
competition it facilitates can result in
savings of 18 percent on an average contract.
Electronic Distribution and Processing. RFP tools with
electronic distribution and processing greatly
reduce data entry and analysis time, as well as printing and
distribution costs. Some RFP software
includes an electronic user requirements survey whose results
can be incorporated into an electronic RFI
or RFP, with automated short list preparation based on the
vendor responses. An electronic RFP can also
validate vendor input and provide on-line help for the vendor.
An interactive, electronic RFP can be distributed via CD or
email attachment, or uploaded to a company’s
web site for vendors to download and respond to offline. A web-
based document that must be responded
to on-line can be used for a small request for quote (RFQ) or

RFI (less than five pages). Some programs
require the vendor to download special software to read and
respond to the RFP; others require only a
browser.
The electronic RFP is not just a word-processing document. It is
linked to a database to enable automatic
correlation of vendor responses with RFP questions. Vendor
responses can be automatically merged,
tabulated, and reported, without the time and errors that would
be involved with manual data entry. The
electronic vendor comparisons thus obtained can then be
analyzed to help select the most suitable
proposal. Once a vendor is chosen, that vendor's electronic RFP
response can be automatically
incorporated into an organized, detailed contract.
Consultants
Another option is to hire an outside consultant with detailed
business process knowledge to help with the
RFP process and to ensure that all pertinent issues are
addressed. Infotivity, for example, provides
consultants who can develop vendor and product short lists, and
prepare RFIs and RFPs.
Recommendations
The success of the RFP is dependent on a comprehensive listing
of business-related user requirements.
The tedium of the needs determination and RFP preparation
process, however, often results in the
enterprise omitting some important supplier requirements.
Workflow checklists and user survey tools can
help speed this process, and they can organize, prioritize, and

summarize the information that is
collected, to reduce the chance of important needs being left out
or overlooked. Automatically converting
the list of user requirements to the RFP will ensure that all the
user requirements are addressed in the
RFP.
Some companies fail to find the best solution for their business
needs because they cast their nets too
narrowly when assembling a list of potential suppliers.
Although RFPs are rarely sent to more than five
vendors, RFIs can be sent to a larger number of vendors to
gather information about vendors before
selecting a short list. For the best chance of finding the optimal
solution to its needs, an enterprise should
diversify its list of potential suppliers by sending RFIs to both
well established large vendors and small
enterprise system and software providers.
Importantly, for smaller or less well-established vendors, the
RFI vehicle can help provide a "level playing
field." Remember, larger vendors have advantages over their
smaller competitors. A large vendor will:
● Have more experience in responding to an RPF; and
● Maintain a library of existing proposals from which a new
RFP response can be assembled - at
least in part - through "cutting and pasting."
In addition, a large vendor may have a seasoned technical
writing staff skilled in interpreting RFP
language, and crafting RFP responses. Since the RFI offers a
simpler mechanism for promoting a

vendor's solutions, it gives smaller providers a "fighting
chance" against their larger counterparts.
How to Prepare and Submit an RPF
The following steps outline a best practice process for preparing
- and submitting - a request for
proposal.
Step 1. Determine the Business Needs to Be Addressed
Prior to writing an RFP, a company should carefully determine
the business needs that the RFP will
address. This step is described in the Faulkner report,
Identifying Acquisition Needs. How well acquisition
needs are determined has the potential to affect the success of
the entire RFP and contract process.
Ultimately, an RFP and contract cannot be considered
successful if the goals they achieve are not
meaningful to the company. Therefore, it is important for an
RFP to focus on business needs, to avoid the
mistake of acquiring unneeded technology just because it is
available. On the other hand, a company
should continue to learn about new technology in order to make
informed decisions about whether that
technology answers a business need for the company. If an
electronic needs survey is used, the survey
results can be incorporated automatically into the requirements
section of the RFP.
Step 2. Describe the Project Domain
The project domain is the total environment in which the system
will be used. Making this information
explicit can help the company avoid data incompatibility
problems, manual data entry, large error rates,

and unexpected ongoing costs. The project domain also
describes what parts of the business will be
affected by the new system, such as sales prospects, the sales
force, customers, inventory levels, project
completion time, and business procedure efficiency. This
information can help vendors plan configuration,
installation, and user training. It can also affect the project
schedule by identifying which improvements
will have the best ROI and should be completed first.
The project domain covers topics such as
● Current networking environment.
● Space and power available for hardware.
● Staffing, user demographics, and skill sets.
● Current data formats and conversions; data interfaces
required with other company and third-party
data bases.
● Boundaries of the new system; where and how it will
integrate with other systems, procedures,
and departments; how and where information flows into and out
of the proposed system.
● Overview of the business procedures targeted by the new
system, the business problems to be
solved, and the goals to be achieved.
● Workflow of the affected procedures.
Some vendors of RFP tools offer a project domain checklist to
help identify environmental issues and set
the scope of the project. An asset management system can also

aid in providing a comprehensive,
accurate picture of a company's IT environment.
Step 3. Create a Short List of Suppliers
Before the formal RFP development process starts, an enterprise
can use some alternative documents to
query vendors about their products and services and to narrow
the list of potential suppliers. Among these
documents are the request for quotation (RFQ) and request for
information (RFI).
Request for Quotation. Enterprises can prepare an RFQ to
receive quoted or confirmed prices from
prospective suppliers for budget planning or for subsequent
purchase orders. The RFQ is used as a
shopping tool to secure the best price among a group of
suppliers selling similar products and services.
Enterprises write brief RFQs for routine procurements regarding
open or upgraded technology, such as
larger hard disk storage capacity. For larger procurements, a
more detailed RFQ explains the basic terms
of the acquisition, and provides an evaluation structure designed
to be fair for all competing vendors.
Request for Information. Enterprises that need to better
understand the products and services offered
by a multitude of potential suppliers should consider developing
an RFI document before committing to
the RFP process. An RFI is used to quickly gather information
and obtain an overview of different
vendors' technologies and approaches, in order to narrow the
pool of suppliers to a short list of the three
to five most promising companies. RFIs are concise, high-level
documents that emphasize the
enterprise’s business objectives and "must have" requirements,

not specific processes. Once the
enterprise collects enough information, it produces an RFP to
evaluate the short list of suppliers and
determine which one is best suited for the job.
Step 4. Follow a Basic RFP Template
A basic RFP template is shown in Table 1 below. Of course, a
company may decide that its procurement
situation requires different names or categories from those
shown in this template. The category names
are less important than the fact that questions and statements
are grouped logically to make it easier to
evaluate vendor responses. Nevertheless, it is good to start with
a basic RFP template to reduce the
chance of leaving out important information or questions.
Table 1. Basic RFP Template
Category Content Description
Executive
Summary
An administrative information section that provides an overview
or
summary statement of the project. This one-page synopsis of the
RFP's purpose is often the most widely read section of the RFP.
Background Background on the corporation or business
division; background on
the project; statement of confidentiality. Company history; key
executives; sales force environment; technology environment.
Current

operating environment and business situation. (See the project
domain
description above.)
Project Schedule Administrative rules and deadlines, including
the deadline and location
for proposal delivery, the option date for vendor demonstration,
the
proposed date of final decision on awarding the contract, and
the
proposed date of project implementation. Also provides contact
data
for the person at the firm managing the project.
Business
Objectives Description of the business problem, its scope and
objectives.
Requirements Detailed business and technical requirements for
managing and
implementing the project, organized by business procedure.
Enables
suppliers to understand the issues and respond to the RFP
coherently.
Includes topics such as implementation and training; technical
and
human resource requirements; customer support and service
availability; upgrade and maintenance policies; compliance with
government regulations; integration and interfacing; data
formats and
conversions; and system expansion options and methods. The
list of
requirements should be comprehensive, including even what
may
seem like obvious, basic features, because the buyer and the
vendor

may not be making the same assumptions.
Vendor Profile Helps to assess a vendor’s stability, reliability,
and qualifications. Asks
for vendor's background, experience, customer references, key
executive profiles, and financials (annual reports). Allows
vendor to
describe in its own words its qualifications for the job. Some
RFPs ask
vendors for a complete list of customer installations, or for the
five
most recent installations, so the vendor cannot stack the deck by
picking and choosing favorable references.
Pricing Description of all purchase prices, licensing fees,
upgrades, and
associated guarantees. Initial and ongoing costs associated with
the
proposed system.
Legal Documents A contract and license agreement section with
the purchase contract,
non-disclosure agreements, and other legal documents.
Appendices Related white papers, technical diagrams, and any
other information
the vendor will require to complete its proposal, such as
addresses and
telephone numbers.
Step 5. Organize and Frame Requirements by Business
Procedure
The requirements section of the RFP describes the business

problems to be solved and the particular
goals or requirements to be met. In this section, companies
should focus on simplifying or improving
business procedures, on accomplishing tasks faster and more
efficiently, and on saving money or
generating more revenue, not on the technology itself. For
example, a company might state a need for
software that is easily modified and expanded, rather than
specifying a technique for creating such
software, such as Object Oriented Programming. Another
company might state a need for more efficient
order processing or better inventory control, breaking it down
into the components that make up the
business procedures, and letting the vendors' proposals translate
that into technological features and
functions.
For easier budgeting, evaluation, and decision making,
questions should be organized by business
function category, not by type of technology. All features
should be referenced back to the business
process they affect, and to the financial impact each business
process has on the company.
Step 6. Use Effective Question Formats
The question formats in an RFP affect the usefulness of the
information returned, and the quality of the
decision that is based on it. Poor question formats can make it
hard to compare and evaluate responses,
whereas good formats elicit responses that are focused, concise,
and consistent.
RFP questions should be written with the evaluation process in
mind, in formats that let the company
quantitatively evaluate the responses to each question. They

should elicit detailed, specific supplier
responses that can form the basis of an explicit, enforceable
contract. All vendors must be asked the
same set of questions, and the RFP should provide a structure
and framework that ensures that vendors’
responses are consistent and constrained. Some electronic RFPs
validate vendor inputs to ensure the
format is adhered to. Each question should address a single
concept. If a lot of functionality is bundled
into one question, the vendor response can be more difficult to
interpret.
Questions should be objective and quantitative whenever
possible, and avoid using subjective, general, or
vague terms or statements. Terms should be defined if there is
any possibility that vendors may have
different definitions of the same term. If the RFP is unclear and
vendors must call for clarification, it is
difficult to make sure that each vendor receives the same
information and instructions.
Different topics and questions will be suited to different
question formats, so the RFP should use a variety
of formats. Some topics will be expressed as statements of
requirements, not questions. For example, the
RFP can state that the vendor must provide source code; the
vendor either accepts the stipulation or is
disqualified. Other topics are suited to the multiple answer
format, which lets vendors check off multiple
answers to a single question.
Feature Support Matrix. Yes/no questions can be tricky. While
it may seem that there are only two
possible answers to a question about whether a certain feature is

supported, vendors will often answer
yes when that capability is partially supported, could be added
through custom programming, or will be
available in a future release. A better question format that
distinguishes among the ways that a feature will
be made available is the feature support matrix, which asks
whether a capability is
● Standard and fully supported.
● Standard and partially supported.
● A free enhancement (added through custom programming).
● A paid enhancement (added through custom programming).
● Available in a future release.
● Not available.
This information can help determine both the suitability of a
product and the risks involved in its
implementation. For example, a feature provided through
custom programming has a greater risk of being
delayed or unreliable. A separate follow-up question can allow
the vendor to explain its answer, and to
commit to a cost for custom programming or configuration.
Freeform Questions. Freeform questions give vendors the
opportunity to fully express what is distinctive
about their capabilities and can include room for explanations
and details. It can also be productive to ask
vendors about possible alternative solutions that were not
addressed in the RFP. Freeform answers,
however, must be interpreted and compared manually and
subjectively (not quantitatively). They are
difficult and labor-intensive to compare because vendors'
answers can differ in length, form, and level of
detail. Therefore, the number of freeform questions should be
minimized; they should be used only when
other formats are not suitable.

Step 7. Assign Weights to Questions
To ensure that the most important requirements are given proper
weight when evaluating a proposed
system, questions should be assigned priorities and ranked by
importance. Mandatory, or "must have,"
features can then carry more weight in the decision than merely
important features, which in turn should
carry more weight than desirable, or "nice to have," features.
The mandatory list will include system
constraints (such as the need to use an existing database or to
interface with a legacy system), as well as
key features. This ranking makes it possible to perform
weighted grade point scoring when evaluating
RFP responses.
Step 8. Send the RFP Electronically to a Short List of Suppliers
Electronic distribution and processing greatly reduce data entry
and analysis time, as well as printing and
distribution costs. An electronic RFP can automatically
correlate vendor responses with RFP questions,
so vendor responses can be automatically merged, tabulated,
and reported, without the time and errors
that would be involved with manual data entry. Moreover, once
a vendor is chosen, that vendor's
electronic RFP response can be automatically incorporated into
an organized, detailed contract.
The enterprise should include a statement informing bidders
that it will screen out all non-responsive and
incomplete proposals to focus on acceptable proposals.
Likewise, suppliers are not obligated to respond
to the RFP if they find it poorly written. Suppliers will likely be
selective in responding to multiple RFPs

with similar requirements and will opt to respond to the ones
that are professionally packaged.
The buyer is not the only one shopping around for the best deal.
The supplier, too, often perceives the
buyer as a potential business partner, and the RFP is likely to be
the first step to developing a successful
business relationship.
Step 9. Schedule a Vendor Q&A Session
Even the best-written RFPs will prompt questions from the
responding vendors. Also, many of the
questions will be similar in nature. To avoid answering the
same question twice, or worse, to avoid giving
two different answers to the same question, schedule one vendor
question-and-answer session, usually
about a week after the RFP is transmitted. The best forum is a
limited-duration joint teleconference, in
which each vendor is asked to submit their questions - in
writing - about two days in advance. The
enterprise submitting the RFP will collate the questions -
eliminating any duplicates - and prepare
appropriate responses. On the occasion of the teleconference,
an enterprise moderator will read the
questions and answers, leaving perhaps fifteen (15) minutes at
the end of the session for spontaneous
vendor queries.
Web Links
EC Sourcing Group: http://ecsourcinggroup.com/

Infotivity: http://www.infotivity.com/
On-Line Consultant Software: http://www.olcsoft.com/
SupplierSelect: http://www.supplierselect.com/
About the Author
Betsy Walli is a graduate of the Massachusetts Institute of
Technology with a Ph.D. in linguistics. Ms.
Walli is an independent writer and editor with experience in
academic, technical, and marketing writing.
http://ecsourcinggroup.com/
http://www.infotivity.com/
http://www.olcsoft.com/
http://www.supplierselect.com/
Class,
This is a set of information comparing IP Contact Call Centers
in side-by-side analysis that was created by Faulkner’s FACCTs
several years ago. You can see that they do cover information
on each company, the features that are in each product, and
even some basic pricing information.
You are going to use this as if it is the compiled responses from
a real RFP. This information will help you assign vendor scores
in your table, and help you decide which vendor to use.
IP Contact Call Centers: Side-by-Side
The right IP contact call center can make potential new
customers go away happy. A conventional “Your call is
important to us…” call center—in today’s age of Internet

gratification—will likely just make them go away.
Take a conventional call center, put it over an IP-telephony
infrastructure, plug in a multimedia server or two and upgrade
the agent PC client software, and presto—you’ve got all the
makings of an IP contact center. It’s not quite that easy, of
course. Contact centers—so called because they add customer-
interaction channels beyond just voice—represent considerable
added complexity, and cost, over voice-only call centers.
After listening to years of vendor claims about their nouveau
contact centers—ROI, ease of use, functional one-upmanship—
BCR and Miercom decided to see for themselves. Invitations
were issued to all vendors known to us in the contact-center
marketplace for a hands-on comparative evaluation.
Six leading vendors quickly responded, welcoming us with open
arms:
(Note: Nortel has been removed from the table since they no
longer are in business, however, references to Nortel within the
analysis was left in for completeness.)
Avaya, which showed off its high-end Interaction Center, along
with its mid-sized offering, a Microsoft-based package with
equally rich multimedia support, the Contact Center Express.
Genesys Telecommunications Laboratories, which offered its
flexible Genesys 7 Suite.
Interactive Intelligence, which presented its Customer
Interaction Center.
Mitel Networks, which offered its 6100 Contact Center
Solution

s package, a set of contact-center building blocks.
Siemens’ subsidiary, Trango Software, which showed its HiPath
ProCenter Standard. The “Standard” is in addition to the lower-
end “Agile” version, which has smaller agent capacity but
otherwise the same architecture and code base.

Table 1 provides a thumbnail, side-by-side comparison of the
key aspects of the contact-center packages reviewed. These
participating vendors, especially Avaya, dominate the contact-
center marketplace today.
TABLE 1. IP Contact Call Centers Reviewed
Avaya
Genesys
Interactive Intelligence
Mitel
Siemens
Total contact center seats shipped(all products), per vendor
6 to 8 million (25,000 contact centers globally)
1.25 million (3,000 contact centers)
100,000 (“100’s of contact centers”)
500,000 (2,100 contact centers)
1 million (shipping 2,000 cont ctrs/mo)
Contact center package, version reviewed
Interaction Center 7.0
Contact Center Express 2.1
Genesys 7 Suite

Customer Interaction Center v2.3.1
6100 Contact Center

Best Practices for Preparing a Request for Proposalby Be.docx

More Related Content

Similar to Best Practices for Preparing a Request for Proposalby Be.docx (20)

More from ikirkton (20)

Recently uploaded (20)

Best Practices for Preparing a Request for Proposalby Be.docx