[College/University Name] - [Issuing Department]

REQUEST FOR PROPOSAL
for a 
CampusWide ID Card and Access Management System

Table of Contents

											Page No.
I.	General Information
	A.	Purpose
	B.	Issuing Office
	C.	No Obligation to Purchaser
	D.	Event Dates
	E.	Proposal Format

II.	Vendor Information and Partnership Capabilities
	A.	Company History
	B.	Vendor Contacts
	C.	System Reference Accounts
	D.	CampusWide Products and Services Partnership

III.	System Requirements
	A.	ID Cards 
	B.	Hardware
		1.	Applications Processor
		2.	Network Processor
		3.	Communication
		4.	Card Readers
	C.	Software
		1.	System Administration Software
		2.	ID System Software
		3.	Point-of-Sale (POS) Software
		4.	Mandatory Reporting Capabilities
	D.	System Security

IV.	System Support
	A.	Implementation and Installation
	B.	Training
	C.	Customer Service and Support
	D.	System Users Group
	
V.	System Warranty and Maintenance
VI.	System Acceptance
VII.	Award Criteria
VIII.	Quotation Information and Format

[College/University Name]
[Issuing Department]

REQUEST FOR PROPOSAL
for a 
CampusWide ID Card and Access Management System


I.	General Information

A.	PURPOSE

[College/University] is requesting qualified Vendors to submit proposals for a complete online 
one-card CampusWide ID Card and Access Management System that will include point-of-sale, 
food services and meal plans, prepaid services and credit accounts, activity access and 
monitoring capabilities, and door/building access control and alarm monitoring. This system 
must also be able to support video imaging ID card production; vending; laundry; merchant-on-
points; bookstore; as well as time and attendance applications.

[Add any additional background/overview information here, such as pertinent information about 
the College/University, prior history/activities to date leading up to CampusWide system 
implementation, specific CampusWide applications desired, etc.]

B.	ISSUING OFFICE

The [name] department is the issuing office for this Request for Proposal (RFP) and all 
subsequent addenda relating to it. The [name] department is the sole point of contact regarding 
all procurement and contractual matters relating to the requirements described in this RFP. The 
[name] department is the only office authorized to change, modify, clarify, etc., the 
specifications, terms, and conditions of this RFP and any contract(s) awarded as a result of this 
RFP.

Address all communications in writing concerning this RFP to:

[name]
[address]
[telephone number]
[fax number]

C.	NO OBLIGATION TO PURCHASER [College/University]

Neither the purchaser nor any agent thereof on behalf of the purchaser will be obligated in any 
way by any Vendor response to this RFP. The selection of a Vendor and the accompanying 
award of a contract is to be based on evaluation criteria established by the [College/University] 
and described in the Award Criteria Section.  The selection is at the sole discretion of the 
[College/University].

D.	EVENT DATES

1.	Required (or suggested) pre-proposal conference to be held at:
	[address]	
	on [date] 
	at [time]

2.	Deadline for questions: 	[date and time].
	Submit questions in writing to: 	[name and address of contact].

3.	Deadline for receipt of proposal:		[date and time].

4.	Award Date

5.	Installation Date

	Mail or deliver [number] sealed copies to:	[name of department]
								[name of institution or company]
								[address]


E.	PROPOSAL FORMAT

Proposals must be organized in the order presented in this RFP, and include a Quotation which is 
based on the System information provided by [College/University] in Section VIII. Proposals not 
organized in the prescribed manner may be eliminated from consideration. The Vendor must 
respond, in order, to all of the items listed in the RFP: use the numbering system of this RFP; and 
be complete and comprehensive in a concise manner.
The Vendor must provide written, point-by-point narrative responses to each Proposal 
requirement; simply stating "agreed" or "complies" is not acceptable. Supplemental technical 
information, product literature and other supporting materials that further explain or demonstrate 
the proposed System capabilities may also be included within the proposal response. 
All Vendors who provide a proposal in response to this RFP are responsible for all costs 
associated with preparing that proposal, answering all questions, providing the 
[College/University] with requested information, and making a Vendor presentation to the 
[College/University].  The [College/University] is under no obligation to incur or reimburse any 
Vendor for any proposal costs. 

II.	Vendor Information and Partnership Capabilities

A.	VENDOR EXPERIENCE

Please provide information about the Vendor's background and experience in developing, 
supplying and maintaining online, real-time CampusWide ID and Access Management Systems 
to colleges and universities.


B.	VENDOR CONTACTS

Please identify the following individuals who will act as contacts for the [College/University]:

	-	The sales representative/account manager responsible for the sale.

-	The corporate executive who has the authority to negotiate for and bind the 
company if the contract is awarded.


C.	CampusWide System Reference Accounts

The Vendor must be able to demonstrate an established, successful track record of past 
performance in providing products and services closely related to the requirements specified in 
this RFP.  [College/University] reserves the right to visit the Vendor site, at the 
[College/University]'s expense, to witness a functional demonstration of the proposed system and 
peripheral devices. If the proposed functions cannot be properly demonstrated, the Vendor will 
be liable for the entire cost of [College/University]'s visit.
Please provide six reference accounts/installations, showing company experience in receiving 
contracts for the delivery of CampusWide ID and Access Management Systems similar to the 
one proposed, to other college and/or university clients.  At a minimum, the reference accounts 
must be using the Vendor's proposed System as the primary CampusWide System supporting the 
following applications:
	1.	CampusWide ID
	2.	Food Service/Meal Plans
	3.	Point of Sale, Prepaid Services/Credit
	4.	Activity Access and Monitoring
	5.	Door/Building Security
	6.	Online Snack/Beverage Vending

Information should include the college/university name, address, and telephone number, and the 
name and title of the person to contact.  Three of the installations should have been completed in 
the last 18 months; the remaining three installations should have been completed three or more 
years ago.

D.	CampusWide Products and Services Partnership

Through the implementation of the CampusWide ID and Access Management System, 
[College/University] desires to establish an effective and mutually-beneficial business 
partnership with a Vendor that can be the comprehensive source for all products, services and 
components for a complete and comprehensive CampusWide One-Card System.  This 
partnership will provide ongoing opportunities to expand and enhance the CampusWide ID and 
Access Management System.  Please describe your capabilities for providing each of the 
following CampusWide products and services:


1.	Campus Carding Services
	-	Manufacture of customized ID cardstock for [College/University]
	-	Carding/Recarding program development and assistance

2.	Off-Campus Applications and Related Revenue Generation Opportunities:
	-	Long-Distance Telephone Services Program
	-	Off-Campus Merchants 

3.	System Interfaces with Third-Party Service Providers
	-	Banking/Electronic Funds Transfer
	-	Bookstore Systems
	-	Library Systems
	-	Inventory Management Systems

III.	System Requirements

This RFP anticipates a complete System that consists of an applications processor, a network 
processor, and an initial Card Reader Network of up to [number] card readers.  The System must 
be able to expand to accommodate 128 interactive user workstation/terminal connections with 16 
concurrent System operators.  All applications supported by the System will use the same single, 
central database, the same software and the same card reader family.  Multiple integrated systems 
and/or systems that utilize multiple integrated databases are not acceptable.  The System will be 
supported with peripherals as required.
The System must be designed to operate online, in real time, 24 hours a day, 7 days a week under 
normal operating conditions, to ensure accurate cardholder and transaction data for effective 
System information management, reporting and auditing activities. Specific hardware, software, 
and other requirements follow.


A.	ID CARDS

	1.	Card Specifications: ID cards must:

a.	Be nonproprietary.

b.	Use a standard American Banking Association (ABA) Track II 3,600-
oersted high-energy magnetic stripe and encoding.

c.	Be American National Standards Institute (ANSI) CR-80 size (2.125" X 
3.375").


B.	HARDWARE

	1.	Applications Processor

The applications processor (or Central Processing Unit [CPU]) manages the 
online central database, ancillary cardholder information, product information, 
and network configuration.  The CPU must:

a.	Use an industry-standard UNIX multitasking, multiuser operating system.

b.	Be nonproprietary with an open architecture capable of interfacing with 
other computer systems.

c.	Be a commercially available Reduced Instruction Set Computing (RISC)-
based processor of sufficient size to support desired performance with 
upgrade paths for future expansion.

d.	Be capable of performing updates online in real-time.

e.	Utilize a commercially available database management system.

f.	Have data backup via Digital Audio Tape (DAT) with a 4.0 gigabyte 
capacity or equivalent.

g.	Be protected by an AC power line conditioner and an Uninterruptable 
Power Source (UPS) capable of maintaining full CPU and network 
processor operation for a minimum of 20 minutes.

h.	Be supported by a 9600-baud modem for remote diagnostics.

i.	Under no circumstances, should it be necessary to shut the system down 
while performing any other functions such as system backup, report 
generation, etc.


	2.	Network Processor

The network processor performs online authorization of a transaction based on 
privilege, account balance, time, and location restrictions, and maintains the 
reader network. In addition, it must:

a.	Handle real-time communications with the network of card readers. 

b.	Support a minimum of 8 communications lines and 60 card readers, with 
the ability to expand to 60 communications lines and 1,000 card readers.

c.	Record and automatically upload, without operator intervention, 
transactions stored during offline operations.

d.	Respond to online reader authorization requests in two seconds or less. 
Response time should be subsecond under normal operating conditions.


	3.	Communication

a.	It is desired that reader communications occur over a multidrop, RS-485, 
9600-baud, asynchronous network.  Reader communications may occur 
over any facility (hardwired telephone lines, fiber, cable TV, leased lines, 
or radio) that will support clear-channel, full-duplex, 9600-baud, 
asynchronous communications. Please provide a diagram below detailing 
your System's typical communication topology.

b.	The Individual communications lines must be capable of supporting up to 
16 card readers (mix or match) on a single line.


c.	To ensure maximum flexibility and cost-effective communication options, 
the readers must not require a direct connection into a campus network in 
order to communicate with the network processor.  No intermediate 
controller or communication devices (such as a PC or other Network 
Manager computer) between readers and the network processor are 
acceptable.  Please describe how the readers communicate with the 
network processor, and provide a diagram below identifying all 
components required to convey data between the readers and the network 
processor.

d.	The applications processor (CPU), CRT workstations, and printers must 
communicate via standard RS-232 circuits at up to 19,200 baud.

e.	The System must communicate with other computers via Ethernet 802.3 
with TCP/IP protocols.

	4.	Card Readers

		General Specifications

The following are the general requirements for all Card Readers.  Additional 
specific requirements for each type of reader follows.

a.	All card readers must be specifically designed for the college/university 
environment, and be made of rugged, rustproof metal.  Reader must not 
have plastic casings or moving parts which are subject to frequent 
replacement due to shattering and/or breakage.

b.	All card readers must feature a continuous swipe-through style card slot 
with a floating read head, which reads the encoded information on Track II 
of the ABA magnetic stripe on the ID card.

c.	All card readers must be programmable at System CRT workstations by 
authorized operators only. No programming shall be done at the reader.

d.	In the event of a communication disruption between the reader and the 
network processor, each reader must be able to store cardholder 
transactions in an offline condition for automatic uploading to the network 
processor when communication is restored.

		Access Control Card Reader

Access control card readers are used to control access at doors, elevators, parking 
lot gates, etc. The readers must:

a.	Provide three Light-Emitting Diodes (LEDs) to indicate if card entry is 
valid, denied, or the card must be reinserted. (For security reasons, access 
control card readers must not visually indicate an offline condition.)

b.	Have control electronics mounted remotely within the interior of the 
secured area.

c.	Be protected against power line disturbances (i.e., have power line filter 
and watchdog timer circuitry).

d.	Be able to store up to 4,000 transactions while offline, and automatically 
upload stored transactions upon going online.

e.	Be able to support a high-security option that allows use of a downloaded 
cardholder privilege database for offline authorization.

f.	Be able to support an optional Personal Identification Number (PIN) pad.

g.	Be capable of interfacing with proximity card recognition devices and 
other types of door-opening systems and hardware.

h.	Be able to support multiple alarm inputs/outputs that will activate other 
types of peripheral equipment (lights, video camera, sirens, etc.).

		Point-of-Sale (POS) Card Reader

The Point-of-Sale (POS) card readers are used for food services, athletic 
concessions, bookstores, convenience stores, etc. The readers must:

a.	All POS card readers must be a single, countertop device, featuring a 
continuous swipe-through style card slot, and be made of rugged, 
rustproof metal with no moving parts (i.e., disk drives).  Personal 
computer workstations consisting of a PC terminal, CPU and keyboard 
components are not acceptable as POS readers.

b.	Provide a programmable and spill-resistant flush keyboard.

c.	Support user-definable keyboards for multiple periods each day.

d.	Permit easy replacement of user-designed keyboard overlays.

e.	Provide a 2-line, 20-character alpha/numeric fluorescent display.

f.	Provide a visual indication of an offline condition.

g.	Provide a time-of-day clock to allow network downloaded keyboards to 
automatically switch over based on time of day and day of week (seven 
switches per day, seven days per week).

h.	Provide full product control, full cash accountability, full payment method 
flexibility, and full reporting capabilities.

i.	Protect against power loss by providing sufficient memory to store up to 
10,000 transactions, menus, configurations, and programs in a powered-
down state for a period exceeding one year.  Memory must be battery-
backed nonvolatile solid-state.

j.	Become fully operational in less than 30 seconds after power is restored 
with no operator intervention without the use of low-reliability devices 
such as disks or other external media. 

k.	Be able to support a patron display, an electronic scale, a cash drawer, a 
kitchen printer, a journal/receipt printer, a Personal Identification Number 
(PIN) pad, a remote printer and a bar code scanner.

l.	Have a reader validation response time of two seconds or less regardless of 
the number of online card readers or transaction volume level.

m.	Be able to operate in a degrade mode if the reader network is down.


		Activity Reader

The Activity Reader is used to enable and track cardholder access and 
participation in a wide variety of activities across campus.  The Activity Reader 
must:

a.	Be a portable, stand-alone device capable of operating both online and 
offline at indoor and outdoor locations across campus.

b.	Be be able to support a receipt printer.

c.	Provide a 2-line, 20-character alpha/numeric fluorescent display and 
continuous vertical swipe-through style card slot.

d.	Be capable of storing up to 2,500 transactions during offline operation for 
automatic uploading to the network processor upon communication 
restoration.


		Vending Reader

The Vending Reader is used to complete cardholder transactions at both single- 
and multiple-price snack and beverage vending machines.  The Vending Reader 
must:

a.	Be built with tamper-resistant, rugged metal construction with a 
continuous vertical swipe-through style card slot.

b.	Communicate directly with the network processor, online in real time 
continuously, without the use of intermediate controller devices.  Please 
provide a diagram below detailing how the Vending Reader communicates 
with the network processor.

c.	Provide a 2-line, 8-character alpha/numeric fluorescent display to display 
messages and the cardholder's balance after each valid vend.

d.	Be capable of storing up to 2,000 transactions during offline operation for 
automatic uploading to the network processor upon communication 
restoration.


		Laundry Center Reader

The Laundry Center Reader must:

a.	Be able to activate mechanical, computerized card ready- and ticket-
activated laundry machines.

b.	Be able to support up to 64 laundry machines at one location.

c.	Feature a 28-key flush keypad that provides characters and numbers to 
operate the laundry equipment, including a Problem key which allows 
cardholders to report machine malfunctions. 


		Copy Machine Reader

The Copy Machine Reader must:

a.	Be a space-saving, easily mountable reader with a horizontal-swipe card 
slot that retains the ID card while the copies are being made.

b.	Feature a one-line, 24-character Liquid Crystal Display (LCD) to inform 
the cardholder of current copy status and display account balance 
information after each copy session. 


C.	SOFTWARE

	1.	System Administration Software

The system administration software must be able to:

a.	Assign operator security codes to permit access to the designated software 
programs, functions, CRT workstations, printers, privileges, and privilege 
accounts.

b.	Add, change, and delete system operators; deny access to previously 
authorized operators; assign operator login phrases; and grant or deny the 
use of multiple updates to each operator.

c.	Create an events calendar that signals the system to automatically perform 
an action at a specified date and time (i.e., deny access during holidays or 
run an end of quarter report).

d.	Specify time period names for use in accounting and reporting, and 
describe locations and cardholder privileges (i.e., first shift, breakfast, 
etc.).

e.	Perform system backups automatically and on demand.


	2.	ID System Software

The ID system software must be able to:

a.	Support multiple identifier numbers, such as SSN and ISO numbers, for 
each cardholder.

b.	Add, change, and delete cardholder prepaid services accounts.

c.	Support up to 9,999 privileges with up to 999 different plans for each 
privilege, to provide full flexibility for the University.  The University's 
authorized operators must be able to define and configure these 
privilege/plan combinations at any time from any System workstation, 
without requiring software reprogramming from the vendor.

d.	Define activities or functions (privileges) that a cardholder is allowed to 
perform.  The system must support monetary (credit/debit), count/points, 
activity (yes/no), and access-type privileges that reference the central 
cardholder database.

e.	Segregate funds into multiple accounts for a cardholder, and provide 
automatic links between accounts, if desired, to provide the cardholder 
with a reserve.

f.	Send and cancel user-defined messages to cardholders.

g.	Add, change, and delete cardholders individually or by group (i.e., 
multiple updates).

h.	Assign and revoke cardholder privileges and suspend and reactivate the 
use of privileges.

i.	Review cardholder characteristics.

j.	Manage cardholder account funds (i.e., deposits, transfers, withdrawals, 
etc.) and perform exchanges.

k.	Designate damaged, forgotten, lost, and stolen cards immediately; activate 
expired cards; set personal credit limits; and activate and suspend card.

l.	Monitor the status of card readers (online, offline, or inactive) by location 
or by group.


	3.	Point-of-Sale (POS) Software

The POS software must be able to:

a.	Designate POS operators as cashiers or managers to determine the number 
of functions the operator can perform (i.e., operators designated as 
managers can use keys defined for manager use only; operators designated 
as cashiers cannot.)

b.	Restrict the use of any designated key to a manager.

c.	Assign each manager or cashier to a specific location or locations.

d.	Provide a minimum of 100 tax categories with a minimum of two tax rates 
per category.

e.	Add, change, and delete size categories for products sold in different sizes.  
The software must support a minimum of six sizes per size category and 
each category must have a default size.

f.	Define products sold individually and groups of products sold at one price 
(combos). The system must support a minimum of 999,999 products and 
combos.

g.	Provide for 999 different types of tenders to include check, cash, split, 
points/debit/credit, cash equivalency, etc.).

h.	Support up to 170 keys for a la carte cash operations requiring product 
accountability. Every key must be user-definable.

i.	Support up to 28 user-definable keys for board operations or bar-code 
scanner applications (i.e., convenience stores).

j.	Define activity keys to permit or deny an activity, supporting a minimum 
of 500 activities.

k.	Define separate keyboards for each time period in all locations and 
automatically download the information to the POS device from a single 
CRT.

l.	Define operating schedules for accounting and reporting. The software 
must support a minimum of seven time periods per location.

m.	Create Price Lookup (PLU) lists that identify the products and combos for 
which there may or may not be preset keys.

n.	Support up to 2,000 products or combos per location.

o.	Group card readers that have the same operating characteristics (i.e., 
operating schedules, keyboards, time periods, etc.) into locations.

p.	Program all card readers from a System CRT workstation.  (Programming 
at a POS reader is not acceptable.)


	4.	Mandatory Reporting Capabilities

The software must be able to support, at a minimum, the following mandatory 
reporting capabilities. Please include a sample of each report.

a.	Reconcile the balances of credit/debit accounts with the balance of all 
reader transactions for a specified date.

b.	Display information on one cardholder, all cardholders, or cardholders 
within a specified range of ID numbers for a specified date.

c.	Report the actions of a specified cardholder for a range of dates and times.

d.	Report all or some of the transactions performed by an authorized operator 
for a range of dates.

e.	Report the privilege use activity at a specified location for a range of dates 
and times. 

f.	Report the number of patron sales in detail (i.e., peak periods, highest 
sales per patron, etc.).

g.	Run a journal report from a CRT rather than from a POS reader for a 
specified date.

h.	Summarize information about cardholders and their privileges and 
accounts for the report date.

i.	Report the quantity of different products selling at a specified location 
during a specified period of time for a specified range of dates.

j.	Report sales and patron counts for all or selected locations for a range of 
dates and times.

k.	Schedule the date and time that reports will be run automatically (i.e., 
without operator attention).


D.	SYSTEM SECURITY

As described previously, the System administration software must be able to control 
access to the designated software programs, functions, CRTs, printers, privileges, and 
privilege accounts.  Specifically, it is required that the System security codes be able to:

	1.	Be department-specific to restrict access. 

	2.	Offer operator-defined password protection. 

	3.	Allow operators to select individual CRT workstation timeout values. 

	4.	Assign operators to specific CRTs and printers only.




IV.	System Support


A.	IMPLEMENTATION AND INSTALLATION

	1.	Delivery and Installation Schedule

		The System must be delivered and installed on campus by the following dates:

(date)		Site survey and needs assessment completed by Vendor.

(date)		Inspection of communication lines performed by Vendor.

(date)		Printed ID card blanks delivered.

(date)		Applications processor and software delivered.

(date)		Initial operator training completed.

(date)		Network processor and card readers installed and tested. 

(date)	All hardware and software installed and operational.  On-site final training 
and checkout.  Acceptance testing completed or underway.

The Vendor must provide [College/University] with System implementation and 
installation support and assistance.  Please describe the services you will provide.  
Associated costs for these services must be specified in the Quotation section of 
the Vendor's response. 


B.	ON-SITE TRAINING PROGRAM

The Vendor must provide on-site training for the proposed hardware and software.  
Please describe the training program provided for the proposed System.  Training costs 
must be specified in the Quotation section of the Vendor's response. 

C.	CUSTOMER SERVICE AND SUPPORT

Please describe your Customer Service and Support program. Associated costs for the 
program services must be specified in the Quotation section of the Vendor's response. 

D.	SYSTEM USER GROUP

Please indicate if there is an established System user group, what part the user group 
plays in System development, and how often the user group meets.


V.	System Warranty and Maintenance


A.	SYSTEM WARRANTY

The proposed System must be covered by a 365-day warranty from the date that the 
system is accepted.  During this period, any defects in the system will be corrected at no 
additional charge as described below:

1.	Failed card readers will be sent to depot repair.  The maximum turnaround time 
should be one week and a spare reader must be sent from the factory to replace the 
failed unit.

2.	Failed computer system components will be replaced at no charge and delivered 
within 24 hours of the reported failure.

3.	Failure of the entire computer system or any software to meet the requirements 
listed in this RFP will be corrected at no charge during the warranty period.  This 
includes any necessary software modifications.

At the option of [College/University], the Vendor must be willing to place software 
source code and documentation in a third-party escrow.  Please describe this program.


B.	SYSTEM MAINTENANCE


An ongoing annual service maintenance agreement must be provided.  This agreement 
must cover all System hardware and software, and must provide a toll-free telephone 
number (24 hours a day, seven days a week), and provide spare readers free of charge, 
based on an appropriate ratio for the University's System requirements.  Please describe 
the maintenance agreement and coverage proposed by the Vendor, including details of 
your spare reader policy.  Costs for this maintenance agreement must be specified in the 
Quotation section of the Vendor's response.

The applications processor and network processor are to be considered high-priority 
items.  When defective, a loaner part must be delivered within 24 hours of the reported 
failure.

At the option of [College/University], the Vendor must be willing to participate in a 
disaster recovery plan by agreeing to make available all hardware and software on a 
temporary, as-needed basis.  Please describe this program.



VI.	System Acceptance

Before final acceptance, the System must be demonstrated to meet all of the performance, 
installation, and training specifications in this document, to the satisfaction of the 
[College/University] representatives.  Successful completion of the following tests 
constitutes acceptable performance:

A.	CONTINUOUS OPERATION TEST

Each card reader, applications processor (CPU), and network processor must operate 
under normal load conditions for a 30-day period.

B.	POWER FAILURE TEST

Each card reader must pass a simulated AC power failure test.  When power is restored, 
each card reader must power up and return to online status.  Stored transactions must be 
automatically uploaded to the CPU.

The CPU and network processor must pass a simulated AC power failure test.  During 
this period, the system must function normally with all card readers online while the 
system runs on backup power.  Neither the removal nor the restoration of AC power may 
result in any loss of data.

C.	COMMUNICATIONS FAILURE TEST

Each card reader must pass a simulated communications failure test (i.e., interrupted 
communications between the card reader and the network processor).  All devices must 
continue to function normally and store transactions.  When communications are restored, 
the card readers must automatically upload stored transactions to the network processor.

D.	BACKUP TEST

The CPU must perform a full backup once a day for a consecutive 14-day 
period.

E.	DOWNLOAD/UPLOAD TEST

The CPU must be able to download or merge data from a remote computer, and upload 
data to a remote computer.

F.	The system will not be considered acceptable if:

	1.	Any transactions are lost or data integrity is destroyed.
	2	Any card reader fails to transition from online to offline operation, and vice versa.
	3.	The reader validation response time exceeds two seconds.

VII.	Award Criteria


	Systems will be evaluated on the following criteria:

-	Compliance with the RFP specifications

-	Base bid price

-	Vendor's experience in providing online, real-time CampusWide Systems to 
colleges and universities

-	Total cost for a minimum 5-year period

-	Quality and reliability

-	CampusWide applications and features offered, flexibility, and expandability

-	Vendor's capabilities as a comprehensive source for CampusWide System 
products and services in an ongoing business partnership relationship

-	Customer service and support services

-	System architecture, design, etc.

-	Training program

-	Utilization of industry standards

-	Type and manufacturer of hardware and software

-	Warranty and maintenance stipulations

-	Replacement of parts and equipment costs

-	Vendor's system performance, speed, user-friendliness, backup systems, network 
type, and ability to interface with existing campus database/information systems


VIII.	Quotation Information and Format


A.	QUOTATION INFORMATION

The Vendor is requested to provide a Quotation for the proposed CampusWide ID and 
Access Management System based on the following information:

1.	Identify the CampusWide applications desired, and provide additional information 
for specific locations on campus, if necessary:

a.	Food Service Application:
-	meal plans
-	points
-	prepaid services account (debit)
-	concessions

b.	Door/Building Access & Security Application:
-	which doors/buildings/facilities
-	alarm monitoring requirements

c.	Point-of-Sale Application:
-	locations and nature of POS transactions

d.	Other CampusWide Applications:
-	(list and describe)

2.	If this will be a progressive, phased System implementation, provide a 
breakdown, by phase, identifying which CampusWide applications will be 
implemented during each successive phase.

3.	Identify how many cardholders the proposed System must support.

4	Identify the building/location where the System applications processor/network 
processor will be located.

5.	Identify the buildings/locations on campus which will have readers, and provide a 
breakdown of reader types and quantity by building/location.

		Building/Location	Type of Reader	Reader Quantity


a.	Additional information for POS Readers: identify how many 
programmable product keys are required on each POS reader device, and 
the type and quantity of peripheral components, such as receipt printer, 
patron display, bar code scanner, etc., desired at each POS reader location.

b.	Additional information for Laundry Center Readers: identify how many 
washers and dryers are in each laundry room and type/brand of each 
washer/dryer (i.e., mechanical, computerized card-ready, etc.).

6.	Identify any third-party systems, such as Student Information System, Bookstore 
Management, Library, Inventory Management, that will interface with the 
CampusWide System.


B.	QUOTATION FORMAT

The Vendor is requested to organize its Quotation in the following format:

1.	Summary Sheet which provides a breakdown of:

a.	total cost for the proposed System

b.	the annual maintenance cost for the second year (System must be covered 
by a one-year hardware and software warranty)

c.	on-site installation and training program costs

2.	Detailed Breakdown of the proposed System Hardware and Software 
Components, including description and quantity of component, unit and extended 
pricing, and annual subsequent-year maintenance costs for Years 2 through 5:

a.	Applications Processor and Peripheral Equipment

b.	Network Processor

c.	Software (include ongoing annual licensing costs, if required)

d.	Reader Network Communication Equipment

e.	Card Readers and Related Peripheral Equipment and Components

f.	Third-Party System Interfaces (i.e., Bookstore Management System 
interface)

g.	On-Site Installation and Training

h.	Optional Items (provide unit pricing unless otherwise indicated)

The Vendor is requested to provide its standard Terms and Conditions within its proposal 
response.


Please note: If the System will be implemented in phases, include the following statement:

		Please provide a Summary Sheet and Detailed Breakdown for each Phase.