Loading...
HomeMy WebLinkAboutRFP - P917 PARKING TICKETING MANAGEMENT SYSTEM1 REQUEST FOR PROPOSAL CITY OF FORT COLLINS Proposal Number P917 The City of Fort Collins is seeking proposals from qualified firms for a new parking ticketing management system. Written proposals, eight (8) will be received at the City of Fort Collins' Purchasing Division, 215 North Mason St., 2nd floor, Fort Collins, Colorado 80524. Proposals will be received before 3:00 p.m. (our clock), December 1, 2003. Proposal No. P-917. If delivered, they are to be sent to 215 North Mason Street, 2nd Floor, Fort Collins, Colorado 80524. If mailed, the address is P.O. Box 580, Fort Collins, 80522-0580. Questions concerning the scope of the project should be directed to Project Manager Randy Hensley (970) 416-2058. Questions regarding proposals submittal or process should be directed to Buyer, James B. O’Neill II, CPPO, FNIGP (970) 221-6775. A copy of the Proposal may be obtained as follows: 1. Call the Purchasing Fax-line, 970-416-2033 and follow the verbal instruction to request document #30917. 2. Download the Proposal/Bid from the Purchasing Webpage, www.fcgov.com/purchasing. 3. Come by Purchasing at 215 North Mason St., 2nd floor, Fort Collins, and request a copy of the Bid. Sales Prohibited/Conflict of Interest: No officer, employee, or member of City Council, shall have a financial interest in the sale to the City of any real or personal property, equipment, material, supplies or services where such officer or employee exercises directly or indirectly any decision-making authority concerning such sale or any supervisory authority over the services to be rendered. This rule also applies to subcontracts with the City. Soliciting or accepting any gift, gratuity favor, entertainment, kickback or any items of monetary value from any person who has or is seeking to do business with the City of Fort Collins is prohibited. Collusive or sham proposals: Any proposal deemed to be collusive or a sham proposal will be rejected and reported to authorities as such. Your authorized signature of this proposal assures that such proposal is genuine and is not a collusive or sham proposal. The City of Fort Collins reserves the right to reject any and all proposals and to waive any irregularities or informalities. Sincerely, James B. O'Neill II, CPPO, FNIGP Director of Purchasing & Risk Management 2 Vendors: The City of Fort Collins Purchasing Division has implemented an on-line vendor registration system. This system allows vendors to register, view and update their business information and commodities. In the future, vendors will also be able to receive Requests for Proposals (RFP’s) through the on-line system. All vendors doing business with the City of Fort Collins are requested to register. The vendor registration system is accessible through the City of Fort Collins Purchasing Department internet webpage at www.fcgov.com/purchasing. The vendor registration form is located by clicking https://secure2.fcgov.com/bso/login.jsp Note the printable instruction pages link. If you have any difficulty completing the registration process, please call the Purchasing Division at (970)221-6775 for assistance. 3 CITY OF FORT COLLINS PARKING SERVICES REQUEST FOR PROPOSAL PARKING TICKETING MANAGEMENT SYSTEM SECTION I. BACKGROUND The City of Fort Collins has recently completed a Downtown Strategic Plan, including policy recommendations for Parking Operations in the downtown area. One major finding of this study is that parking turnover is a critical element for sustained economic vitality in the retail and entertainment sector of Downtown. A major conclusion of the study is that the City needs to increase the amount of parking turnover through the employment of enhanced enforcement measures, including an escalating fine structure, and through the use of updated technology. The purpose of this RFP is to solicit proposals for a new parking management system that will facilitate enhanced enforcement, including ticketing (citations), front office management, permit sales, inventory management, and possibly facility maintenance (as an optional requirement). At a minimum, the new system must be capable of three things: 1) facilitating the current existing parking business operations, 2) incorporating an escalating fine structure into the ticketing/citation process for overtime violations, and 3) a technology or method that would replace the manual chalking of vehicles currently practiced by the City’s parking enforcement officers. The City is also considering a separate vehicle- mounted system that employs license plate recognition and optical character recognition technology to replace manual chalking. The new parking management system being sought in this RFP must be capable of interfacing with any such license plate recognition system (LPRS) through standard data exchange technology. The City currently employs timed parking in the Downtown core to encourage parking turnover, backed up by enforcement in the form of parking tickets for overtime violations. Currently, enforcement is performed by an enforcement staff of six parking enforcement officers and one enforcement supervisor using a “walk and chalk” method. Parking tickets are written using Intermec Norand 6100 handheld computers and Intermec Norand 6806 printers. The computers are interfaced with Spectrum2000, a parking and citation management system provided by Spectra Corporation. The City’s existing parking management system is not capable of supporting an escalating fine structure, and has only limited capability to provide an alternative to manual chalking. It is also unsupported (the vendor has gone out of business.) The City will need extensive assistance from a successful new vendor to provide a transition from the existing system to a new system, including an analysis of business practices and systems, and how those practices and systems would be incorporated into a new system. Vendors should note that many of the requirements shown below are based on our current business practices and operations. If a vendor is not able to provide the same function we currently use, but is able 4 to provide a replacement function based on a modification of business practices, the vendor should explain this in the response to the RFP. The City will need training, implementation assistance, help translating existing data, and extensive follow-up to insure that the new system fulfills all the city’s operational requirements. SECTION II. SCHEDULE Please respond as to availability to have a system available to “go-live” on February 1, 2004. The City of Fort Collins intends to hold interviews of the top ranked firms on Thursday December 18, 2003. SECTION III. METHOD AND FORMAT OF RESPONSE The vendor’s response to this RFP must be in writing in the form of eight (8) bound copies. All materials submitted to the City will become the property of the City and will not be returned. The City of Fort Collins is subject to public information laws, which permit access to most records and documents. Proprietary information in your response must be clearly identified and will be protected to the extent legally permissible. Proposals may not be marked 'Proprietary' in their entirety. Information considered proprietary is limited to material treated as confidential in the normal conduct of business, trade secrets, discount information, and individual product or service pricing. Summary price information may not be designated as proprietary as such information may be carried forward into other public documents. All provisions of any contract resulting from this request for proposal will be public information. The format of the response should follow the order and format of the RFP. The numbering scheme and outline used in the RFP should be used in the vendor’s response so that it is easy to match the City’s requirements with the vendor’s response. Each item in the RFP should have a corresponding item in the vendor’s response. For each item in Section V of the RFP (Technical specifications and Requirements), the vendor should indicate one of the three following responses: 1) the vendor’s system meets the City’s requirements without reservation and with no modification required to the vendor’s system; 2) the vendor’s system meets the City’s requirements with modification to the vendor’s system – the vendor should describe how its system will be modified to meet the City’s requirements; 3) the vendor’s system is unable to meet the City’s requirements. The vendor may provide a generalized response (such as an introduction) that describes the vendor’s system and capability, but generalized responses should not be included in the vendor’s response to the specific itemized requirements in the RFP. Instead, the responses to the specific itemized requirements should be as described at the beginning of this paragraph. The vendor should provide a detailed, itemized cost bid including all aspects of a complete 5 bid (i.e. software, hardware, training, implementation, warranty, transition and data translation, follow-up, etc.) If the vendor provides certain modules or combinations of services that can be mixed and matched (allowing the City to pick or chose from a menu of items) the cost bid should indicate this as well. If there are certain parts of the cost bid which comprise mandatory, minimum-purchase-level (“must-have”) elements of the vendor’s package, that should also be indicated in the bid. Some of the requirements below are labeled as optional. No response is required for the optional requirements, and vendors will not be penalized in the grading of the RFP if no response for optional items is provided. In other words, the selection of a Parking Management System will not be based on information in the optional section of the RFP. However, if the vendor chooses to respond to the optional items, a cost bid for those items should be included. Some services which may be needed to implement this RFP are not called out explicitly in the requirements below, such as the business practice analysis. The reason for this is that the City cannot determine the extent that such an analysis may be required, since it is dependent on the functions of the vendor’s system, and how similar or dis-similar that system may be to the City’s existing system. If a vendor feels that a business practice analysis, or other items not called for specifically in this RFP, are needed for a successful transition to and implementation of the vendor’s system, those items should be noted by the vendor with a cost estimate. SECTION IV. PARKING MANAGEMENT SYSTEM General Requirements. The City of Fort Collins is seeking a new Parking Management System to replace the current software and associated hardware. The new Parking Management System must support the writing of parking tickets/citations; parking ticket tracking, billing, and collections; and parking permit sales, tracking, and renewal. As optional requirements, if the vendor’s system also provides a facility/equipment maintenance module or an e-commerce/internet module, that information may be included in the vendor’s response and cost estimate in the appropriate place below. Vendors who do not provide a maintenance module or e-commerce/internet module will not be penalized in the RFP evaluation process. Our goal is to purchase and implement a system that will do the following: 1. Issue citations as designed by the City of Fort Collins. 2. Have the ability to implement an escalating fine structure based on a rolling time period. 3. Increase collections through accurate and efficient data reporting. 4. Reduce workload by reducing data management overhead. 5. Identify repeat offenders and make this information available to Parking Officers in the field. 6. Improve and enhance the permit sales process. 6 7. Allow customers to apply for and purchase permits, access account information and pay or appeal citations via the Internet. 8. Provide a system for tracking vehicles that have been booted/towed or have been approved for boot/tow, and the status/location of booted/towed vehicles. 9. Help obtain reports for system analysis, problem resolution and overall management efficiency. 10. Help in the planning and management of special events, allocation of staff resources, financial transactions, and invoices associated with special events. 11. Save time by incorporating a relational database that contains permits, citations, vehicles, and customers. 12. Be compatible with adopted City technical standards, including but not limited to, operating systems, hardware systems, databases, wireless communications, and others. A copy of the City’s standards is included with this RFP for reference. SECTION V. TECHNICAL SPECIFICATIONS AND REQUIREMENTS A. SOFTWARE REQUIREMENTS The software should help in providing an effective and efficient tool to better use time and resources of office staff and field personnel, and to provide new and effective resources for customer access. The software provided should be simple for a novice computer user to access information. 1. General requirements: The system should contain, but not be limited to, the following modules: a. Various security levels that can be assigned by a system administrator on a “need to access” basis, by user. b. Citation / Customer Module – This should be the first screen that comes up when any inquiry is performed. The system should show all transactions associated with a citation, including who, when and how payments were entered. If duplicate customer records are ever created in the system, it should have the ability to identify those duplicate customer records with the option to merge the duplicate records into one record. The system should be able to record and report the status of citations, including but not limited to the following status conditions: paid, unpaid, overdue, pending collections, sent to collects, etc. c. Citation Appeals / Hearing Module, with the ability to schedule and track the status of court hearings for multiple hearing officers. d. Parking Permit Module, with the ability to sell, track and report on the status of permits with varying prices, privileges, functions, and locations. The permit module must link to customer, account and vehicle information, as well as the cash management system. The system should record the status of a 7 permit, including but not limited to the following status conditions: active, lost, stolen and returned. e. Cash Management / Payment Module – This should be a password- protected module, with the ability to track and report on receivables as well as daily transactions. The system should provide a cashier system for walk- in customers, as well as processing mail-in payments. f. Automated procedures that will provide for user-defined fine escalation for parking citations. The system must automatically calculate the fine amount that is added to the citation after 8 days. g. Automated procedures that will provide for the ability to identify and report on valid and expired permits. The system should be able to tell us which permits have expired or have been renewed so we do not have to do this manually. h. Batch Payment Module that will allow us to enter citations as a batch payment (such as mailed-in citations, and citations retrieved from drop boxes), rather than as cash transactions. i. Letter Module, with the ability to select accounts by automated query (accounts for which letters need to be generated for various purposes), including but not limited to overdue citations, unpaid accounts, permit renewal, accounts pending collections, etc. The letters in the letter module should be able to be customized to include information from any field in the citation, permit, customer, or vehicle databases. The “name” fields in these databases should be capable of splitting the first name, last name, and middle initial into separate fields. j. Report Module, including standard pre-made reports as well as customized or individualized ad-hoc reports. The system should have an easy to use report generator. k. Data Import/Export Module, including the ability to export standard text files with delimited fields, as well as the ability to interface with McGann Parker Database Parking Structure Software and AutoVu License Plate Recognition System databases. l. The database supplied by the vendor should be an “ODBC” compliant database. m. Vehicle Module, including the ability to send vehicle information to a third party information source that can return customer information such as name and address. Such customer information must be automatically populated into the customer module of the system, and properly linked to the permit, citation, and vehicle modules. n. Repeat Offender Module, including the ability to customize the criteria that define a repeat offender, and the ability to report on the citation history and permit status (if any) of repeat offenders. o. Tow Module, including the ability to track and report on towed vehicles by date, location, towing officer, vehicle information, or customer information. 2. Security Requirements 8 a. The system must allow for a wide range of user access control and security that can vary by module and security level from read-only access to complete insert, edit, delete capability anywhere in the software system. b. The system must allow the creation of a profile for each individual user. This profile must specifically detail the access rights and security privileges as defined by the system administrator. c. The system must also provide an audit trail of modifications and/or transactions executed by a particular user. 3. Parking Citation Capabilities The parking citation module must allow the user to enter, view, and print citations by means of either a query or batch basis. In addition, information should be displayed on one screen whenever possible, or should be displayed in overlaying windows that can be selected when necessary. In our current system, screen space is wasted, and multiple layers of information must be used to see things like comments, permits, customer account info, etc. (In other words, we have to “drill down” too deeply to retrieve information.) The new system should minimize the need to “drill down” to get related information. We would like a comment from the vendor in their response about how their system addresses the concerns expressed in this paragraph. The following information should be provided in this module: a. Detailed violation information, including fine structure (base amount, escalations, accumulations, late fees, etc.) b. Provide for user-defined parameters for fine escalation for parking citations, including the amount of the escalation, and the time period that drives the escalation. In other words, we would like to be able to look at a user-defined period of time, such as the most recent 6-months, and have the citation amount be based on the number of citations an account has incurred during that time period. c. Extensive scrollable comment fields. d. If fines are not paid within a certain time period (such as an 8-day limit) the amount of the fine should be increased (this is the equivalent of a late-pay penalty.) All of the parameters dealing with the late-pay penalty should be user-defined (amount of penalty, length of time before the increase occurs, etc.) Detail status information regarding balance due, whether late fees have been added, and the amount of the late fees which have been added should be available for viewing and/or reporting. e. A list of all prior citations for an account and ability to display any previous citation(s). f. Complete history of transactions associated with the citation. g. A complete history of paid citations. h. A complete history of dismissed citations by user ID (staff member). 9 i. A complete history of unpaid citations. This module must also: j. Provide some method to prevent duplicate or overlapping citation numbers. k. Provide a mechanism for rapid and convenient entry of hand-written citations utilizing defaults from the previously entered citation such as date, officer number, location, etc. l. Provide a mechanism that allows the input of citation numbers of hand- written citations that have their own unique number, without causing conflict with citations issued through the handheld computer system using automatically generated numbers. m. Be able to reassign citations to a different customer individually or in batch (such as from a vehicle leasing company to a vehicle lessee.) n. Have the ability to track and report repeat offenders, and download this information to handheld citation units based on user-defined criteria. o. Provide direct access to customer and vehicle information. p. Print notification letters (first notices, partial paid letter, refund letter, “Failure To Appear” letter, and collection letters) in Microsoft Word or Office XP format, while maintaining an audit trail within the application. q. Expediently find and access citations from virtually anywhere in the program including the cash register module. The system must also be able to find a citation using one or more of the following criteria: customer’s name, customer account number, customer ID number, license plate number, issuance date of the citation, citation number, permit number, ticket status, customer group, or violation. r. The ability to change the status of a citation, including a “void” status, while maintaining an audit trail. This feature should be one of the features that can be limited to certain users using security levels. s. Have the ability to make and track changes and adjustments made to a citation by a specific individual, date and time. t. Support the attachment of scanned documentation, digital images ([pictures) or other electronic items, to the citation. u. Must allow for the processing of numerous status codes including the following; Awaiting payment, Partial Payment Received, Paid in Full, Appeal Pending, Administrative Hold, NSF Check Hold, Court Proceeding Pending, Pending Collections, In Collections Status, Uncollectible. v. The system should allow the user to set up the account number according to a user-defined format. 4. Citation Appeals Capabilities The software must track the citation appeal process. When an Appeal is created, the information relating to a citation must be automatically copied into the appeal record as the citation number is entered. The appeals and hearing module must allow the ability to: 10 a. Ability manage a Court Docket and print it out. b. Ability to schedule appellants for specific time slots to the Court Docket. c. Ability to enter an appeal status code to indicate the results of an appeal (i.e., “the decision”). d. Ability for staff to fill out the Notice of Hearing form in electronic format, and print a copy to be signed by appellant and by the issuer of notice (staff). e. Document extensive information in the comment field. f. Attach digital pictures, files or documents to the appeal record. g. Adjust the citation’s final amount due by an authorized person and keep track of all adjustments made to the record. h. Link to, and simultaneously update, related information in citation files. i. Set revised due dates. j. Put citations on hold while appeal is in process. k. Assign multiple user-defined appeal note codes. l. Generate and print appeal decision letters on demand for a single hearing or in a batch for multiple hearings. m. Allow access to a user-defined appeal note code that allows users to read why an appeal was upheld or denied. n. Generate a message to alert the user if a citation has already been appealed. o. The system should be able to find a citation using one or more the following criteria: the customer’s name, customer account number, customer ID number, a license plate number, the issuance date of the citation, the citation number, permit number, ticket status, customer group, or violation. 5. Customer Tracking Capabilities The software must track customer activity, including, but not limited to, the following features: a. One unique account number issued to a customer b. Ability to view the balance due with details c. Access to all vehicles registered to the customer d. Complete list of invoices and access to details of each invoice including City assigned revenue account numbers e. Minimum of one address per individual f. Minimum of one phone number per individual g. Minimum of one e-mail address per individual h. Ability to generate invoices for permits to send to existing customers for various time periods (monthly, quarterly, annually, etc.) i. Ability to send user-defined customer statements in a variety of formats to inform customers of outstanding invoices on accounts (citations, permits, tow, etc.) j. Scrollable notes field. 11 k. Ability to compile and manage multiple “wait lists” based on permit type or lot, while linking this information with the permit inventories at point of sale. l. Ability to identify potential duplicate customer records with option to merge the duplicate records into one. m. Ability to find a citation from within the customer module using one or more of the following criteria: the customer’s name, customer account number, customer ID number, a license plate number, the issuance date of the citation, the citation number, permit number, ticket status, customer group or violation. 6. Parking Permit Capabilities The system must provide the capability to set up, issue, sell, track and manage permits. A permit may be a proximity card, sticker, hangtag or any other method determined by the City of Fort Collins Parking Division. The Permit module capabilities must allow for the processing of payment status codes including the following: Awaiting Payment, Awaiting Payment-Partial Payment Received, Paid in full, No Fees Due, NSF check hold, Unsold. The Permit module should be able to export/import permit information into and out of the McGann Parker Database Parking Structure Software. The capabilities of this module should provide for the complete control of the parking permit issuance process including: a. Ability to manage permit inventory and track uniquely numbered permits as they are being used. b. Ability to record the commencement, issuance and expiration dates for a permit. c. Ability to distinguish between valid and expired permits. d. Ability to scan a permit’s bar code at point of sale. e. Ability to register one or more vehicles to a permit. A minimum of two vehicles should be able to be registered to a single permit. f. Ability to display permit account balance. g. Ability to download permit records to handheld ticket-writers. h. Ability to associate multiple customers to a permit i. Ability to make monetary adjustments to a customer’s account, such as for a reduction in a fine, adding of an administrative fee if they miss a court appearance, etc. This process must include an audit trail that can be viewed or printed. j. Ability to view a detailed monetary transaction history for each permit. k. Ability to track permits for inventory management. l. Ability to prorate permit sales or returns and automatically calculate value based on user-defined rules (i.e. weekly, monthly, daily, etc.) 12 m. Ability to reset the permit fee for monthly billing. For example, if a person comes in mid-month to purchase a permit, they are charged a pro-rated fee, but the next month, they would be charged the full fee. n. Ability to use customer-defined permit possession status indicators including, but not limited to, “active, lost, stolen, and returned”.) o. Ability to issue and track temporary permits. p. Ability to list all citations related to a customer/vehicles assigned to a permit. q. Ability to print a permit at time of sale (such as a temporary hang-tag) or dash-board placard. r. Ability to print a permit receipt to give to a customer showing that a permit has been purchased. s. The ability to search for all permits that are associated with a particular account, address or license plate. t. Ability to document and/or store permit-related information, such as if the account holds multiple permits, if a permit was stolen, if a permit is a shared permit, or if the customer is abusing the permit. u. Ability to define lot/department allocations within the permit inventory. v. Allow for multiple user-defined permit payment status codes, such as “paid, unpaid, balance due”, etc. w. Allow the user to issue a batch of permits to an individual, agency, or department, and bill for the amount due. x. Ability to facilitate the renewal of permit purchases by having the purchase charged automatically to a credit card on a periodic basis. 7. Payment and Cash Management Capabilities The new system must be able to interface with an existing cash drawer, or the vendor should supply and support a new electronic cash drawer and workstations, including any parking management software, peripherals, cash drawer hardware, bar code reading devices, and receipt printers, which are fully integrated with the PC-based parking management system. The software must allow for separate financial accounts and account categories for activities such as Citations, Boot Fees, Encroachment Permits, Lot Permits, Structure Permits, Misc. Fees, etc. and for direct posting to these and any other accounts the user may choose to set up. The system should provide complete access to virtually any information in the system without having to leave the cash management module. The system must provide a complete audit trail for all transactions. The cash management module must include, but is not limited to the following: a. Ability to track all transactions by cashier regardless of cash drawer used. b. Access to citation lookups (single ticket or customer/vehicle’s complete listing of citations, and total balance due) without leaving the cash management module. It must also be possible to find a citation with as little information as customer name, license plate, the issuance date of the citation or the citation number. 13 c. Ability to display the results of a citation search to the screen, printer, or a file and to easily access the cash register screen for payment processing. d. Ability to accept and post both payments-in-full and partial payments as well as apply credits from an existing customer balance to any outstanding balance that might be owed by that customer. e. Ability to post payments for citations (should be able to apply payment to the oldest ticket first and every other ticket in succeeding date order, as well as having the ability to apply payment to citations out of order) permit invoices, NSF penalty fees. f. Ability to write-off balance of citation during acceptance of payment. This function must be restricted to authorized users and the maximum authorized write-off amount must be variable based on an individual user’s access profile. g. Ability for quick and easy batch application of mail-in citation payments. h. Ability to add outstanding payment information to a vehicle tow. i. Ability to refund citation payments. Provide a report summarizing all refunds. j. Ability to void receipts. k. Ability to void a citation. l. Ability to enter payments before citation information has been imported from handheld ticket-writers (skeleton tickets). m. Ability to have the skeleton ticket information automatically updated later when the citation is uploaded from the handheld ticket-writer. n. Ability to notify the cashier if checks are not accepted from a specific customer. o. Ability to print a receipt if necessary that clearly identifies individual transactions and/or items purchased, including paid citations, permit receipts, encroachment permits, citation payments, or payments for other services. p. Ability to print each receipt to a variety of printers in a variety of formats, including point of sale receipt printers. q. Ability to identify and select from several payment methods and to use multiple revenue types in one transaction. r. Ability to set up user defined tender types, such as cash, check, money order, credit card (Visa, Mastercard, Discover, American Express), etc. s. Ability to mark NSF check receipts, add associated fees and send user- defined standard NSF check notifications in one easy process. t. Complete drawer close-out process with detailed cashier report including but not limited to a summary report of all transactions, by all payment types from all cashiers over a user-defined time period, a write-off report, and an item summary. u. Transaction total given at close of cash drawer. The drawer cannot be closed until all open receipts are reconciled. v. Ability to access and import (for purpose of sale) a permit record from populated inventory via the cash register screen with automatic calculation of the prorated (if applicable) permit purchase price. 14 w. Ability to easily add customers and vehicles when selling permit without leaving the cash register module. x. User-defined register accounts that identify the person processing the transactions and the person responsible for the cash drawer, especially if there is more than one cash drawer. y. Ability to scan a bar code printed on items (citations, permits) into various fields to facilitate rapid data entry and lookup at point of sale. z. Ability to identify a cash drawer as multi-user. aa. Ability to provide password protection for all cash register functions and supervisory override. bb. Ability to track and print complete customer history including wait list assignments cc. Ability for customers to pay an amount due utilizing multiple payment types. dd. Ability to display customer or vehicle balance from the receipt and the ability to add outstanding invoices to a receipt ee. Ability to restrict the sale of a permit to an account until all citations for that account are paid ff. Ability to identify any credit owed to a customer. Currently, if a customer sends in an overpayment, we have to input the entire amount received. We do refund the over payment if we have a name and address to send the money back too, but until we actually refund the money, it shows as a credit on the customer’s account history. 8. Notice and Letter Generation Capabilities The software must also provide a module to allow for the notification of overdue citations, partial payments, first overdue notification, pre-collection notifications, failure to appear notices, refunds and “wait list” updates. Each letter must be printed based on user-defined criteria. The software should have the ability to export the data to Microsoft Word or Office XP for custom letter generation or have the ability to generate the letters directly without going through Word or Office. The user- defined criteria may include, but are not limited to, “days past citation issuance” or “number of unpaid citations” for a given license number. Notices and letters must be capable of being generated for either a single letter, or in a batch mode for multiple individuals and notices. Requirements for Letter Module: a. Allow the user to define/create multiple types of standard letters. The standard letters would include Overdue Notices, Collection and Pre- collection letters, Partial Payment, Failure to Appear, Appeals, and Account Statements. b. The system should include the ability to store letters sent to customers in electronic format, so that individual hard copies of letters sent do not need to be stored. 15 c. Allow the user to delineate the specific combination of conditions that must exist in order to trigger the printing of each standard letter type for a particular citation, vehicle or registered owner. d. Allow certain defined fields in each standard letter type to be automatically filled in by accessing data in the database file at the time of printing (i.e. customer name, address, etc) Such defined blank fields for automatic data entry should include but not necessarily be limited to individual listing of each unpaid citation, total dollar amount due, specific details for each outstanding citation, vehicle description information, registered owner information and customer authority name and address information. e. Allow the user to print standard letters on both an individual and batch basis. f. Allow overdue notices to be printed on three-section, pre-perforated paper. Currently, we order this paper through Lewis Paper Cooperation. It is 81/2 x 11 2/3 pre-perforated paper. It prints on a laser jet printer. g. Allow letters to be printed on a standard printer that can be accessed via the Microsoft Windows XP operating system. h. Provide for user-defined letter headings to be selected by letter type. The user-defined letter headings should contain name, address, city, state, zip code, and phone number. i. Provide for user-defined letters that can be used for general purpose. 9. Report Generation The software must be capable of producing pre-defined reports including the follow: a. Citation activity b. Permit sales activity c. Parking citation appeals activity d. Daily cashier transactions listed by account number/type These reports should contain a variety of sorting options including: e. Data range(s) f. Ticket number range(s) g. Outstanding tickets h. Tickets issued, by officer ID i. Tickets issued, by location j. Tickets issued, by violation k. Tickets issued, by date and time periods l. Tickets issued, by license plate number In addition: m. The software should be capable of producing accounts receivable reports and write-off reports which contain those citations which are uncollectible, as well as a tool to designate accounts as write-offs. 16 n. The system must also provide an easy to use report writer and query tool. This tool must allow reports to be created and run by any authorized user based on security level. The query tool must allow data to be sent to a printer, file, or screen. 10. Examples of reports. As part of the response to this RFP, each vendor should provide examples of reports that are generated by the system. These examples should either be screen prints or printouts of the reports. The following list includes reports that should be submitted. If the system does not include these reports, please indicate that in the response. a. Daily transaction report b. Cash drawer closeout c. Deposit summary sheets. d. Summary reports by tickets written, dollar amount, officer; with the ability to specify dates (daily, monthly, quarterly, yearly). e. Repeat offender (scofflaw) report. f. Collection report (by specified dates). 11. Data Translation a. The successful vendor should include a cost estimate to translate data from the City’s existing parking management system into the new system provided by the vendor so that historical data are not lost. Approximately three years of data, consisting of 400,000 records, would need to be translated and imported into the new system. 12. Optional: Web-Based Interface a. Proposals must include costs for an E-commerce module(s). The E- commerce module(s) should include, but not be limited to, the ability of customers to file for and track appeals for citations, permit applications, make payments for a variety of products and services, and account inquiries. The E-commerce modules must be able to provide access through the City’s current website or the vendor must be able to provide website development. b. Please include information concerning web portals to an e-commerce module for use with your application. Please include any current customers using the e-commerce modules and their websites. If this is a future enhancement, please include a timeline and product specifications and features. c. Describe in detail the software program that will be used to develop the web- based interface and how it will interface with the office system. 17 d. Outline how the proposed software will track credit card transactions and bank electronic funds transfers (ACH) and note how it will enable tracking from origin through accounting, reporting and auditing. e. Verify that the proposed software can interact directly with the City’s designated bank and how daily transaction reports can be produced and linked with the cash management system. f. List the payment types supported and certified such as credit card types, debit cards, electronic bank transfers (ACH), electronic checks, etc. g. Demonstrate how a typical transaction would proceed from the user’s access to authorization to bank settlement. 13. Optional: Lot / Facility Maintenance Requirements The City recognizes that some parking management systems include a module to facilitate maintenance activities and preventive maintenance programs. The City views this features as an “optional” requirement. If the system that you (the vendor) are proposing includes a maintenance module, please describe it’s capabilities and functions. If you respond to this section, the City would be interested in knowing the following: a. Is the maintenance module an integral part of the overall parking management system, or is it a stand alone system? b. Does the maintenance module have the capability of interfacing with the handheld computers used by enforcement officers in the field (so that if a maintenance item is noticed by an officer, it can be recorded in the field and the information can be reported back to the appropriate person in the office.) c. Does the maintenance module use the inventory information from the permitting module (lots, stall numbers, locations, etc.) to facilitate the tracking of maintenance activities? d. The cost of the maintenance module should be included as a separate item. 14. Optional: Bar-code capabilities If the vendor’s system includes the capability to process citations and/or permits using a bar-code technology, that capability should be described. A separate cost estimate should be included, including all the hardware and software needed to deliver a functional bar-code capability. B. HANDHELD TICKETWRITERS The handheld device for writing tickets while the officer is in the field will need the following capabilities. 18 1. The preferred handheld device will have capabilities most similar to the Symbol PDT 046 or better. Please specify which device you are recommending for use with your proposed system. 2. Please satisfy the requirement of having enough on board memory to hold the information concerning previous ticket holders based on the current rules of enforcement. For example, the ability to hold six months of lookup information about citations. This will allow the escalating fine structure to be implemented at the enforcement officer level. 3. Please include cost options for the 802.11 a/b/g Bluetooth or other wireless technology capabilities, and other accessories such as cases, extra batteries, etc. 4. The printing device must be able to be activated by wireless technology for communication to the handheld device. The printing device preferred should be most similar to the Zebra QL 320 or Cameo 3 Printer or better. 5. Specifications for Symbol PDT 8046 a. Microsoft Pocket PC operating system b. 128 MB RAM/64 MB ROM c. Size: 7.25” x 3.6” x 1.75”, 23 ounces d. Operating temperatures: 14° to 122° F e. Withstands drops up to 5 feet onto concrete f. Wireless IEEE 802.11 b peer to peer printing g. 3.9 diagonal, ¼ VGA color display h. Integrated bar code scanner 6. Specifications for ZEBRA QL320 Printer a. Communicates with hand held ticket writes by peer to peer wireless 802.11 b connection. b. Weight: 1.65 lbs c. 3” ticket stock, with 2.9” print area d. Maximum print speed 4” per second e. Rubber infused plastic over-mold design for tough conditions f. Operating temperatures: 5° to 122° F g. Rechargeable lithium ion battery 7. Specifications for Cameo 3 Printer a. Communicate with handheld ticketwriter by Bluetooth infrared, or wireless connection. b. Weight: 1.4 lbs without paper c. 3” ticket stock, with 2.8” print area d. Maximum print speed 3” per second 19 e. Withstands drops up to 6 feet f. Operating temperatures 5° to 122° F C. HARDWARE AND SOFTWARE MAINTENANCE AND SUPPORT 1. The vendor must offer an annual maintenance agreement that will cover all aspects of the Parking Management System, including handheld computers and printers, other hardware, and software support. The agreement should specify the length of the vendor’s contact response time and on-site response time, if needed for repair or maintenance of the system. 2. As part of the support agreement, the Vendor must provide cost information for new releases and upgrades to the main system software and handheld software as they become available for public distribution. 3. The vendor must offer 800 number telephone support Monday through Friday. Please specify the hours of operation of the support center, whether after-hours support is available, and the additional costs (if any) of after-hours support. D. TRAINING AND IMPLEMENTATION REQUIREMENTS 1. The vendor should offer an on-site pre-installation analysis of site requirements to ensure that the solution is sufficient for the City’s requirements. This pre-installation visit should also be used to determine requirements for implementation, training, and database conversion. The results of this visit should be used to provide an accurate timetable for total implementation in terms of time, cost, and other variables. 2. The vendor must provide a training course for line staff, management, and system administrator employees, for the changes associated with the implementation of a new system. 3. The vendor must provide on-site training for employees, both is the workplace setting and in a classroom environment, at the time of implementation (both prior to and after “going live” with the new system.) 4. The vendor should provide onsite follow-up training 10-12 weeks after “going live” with the new system. 5. The vendor should offer a web-based training program to train personnel on software for initial use and continuing education for current and new staff. 6. The vendor should provide training materials, including user manuals and system administration manuals. 20 7. The vendor should provide recommended system maintenance procedures and manuals for the delivered system. The system administration manuals should provide detailed descriptions and diagrams of the entire system as installed at the Fort Collins site, including connectivity diagrams, flow diagrams, contact information, troubleshooting techniques, and any other pertinent information. Information Technology Standards Revision Date: April 2002 Rev. 07 Print Date: November 6, 2003 21 City of Fort Collins Information Technology Policies and Standards Introduction 1.1. Purpose 1.1.1. The City of Fort Collins recognizes the need to share data, information, and resources in order to meet organizational goals and objectives relating to customer service. The adoption of standards allows the City to efficiently and effectively meet these goals. 1.1.2. Adopting standards will enhance the effectiveness of both internal and enterprise systems, maintain interrelationships between systems, and provide long range planning benefits for future upgrades and replacements. Enterprise wide systems include Electronic Mail; Intranet and Internet Services; Financial System, including Payroll and Personnel, Document Management; Geographic Information System 1.2. Goal 1.2.1. The overall goal is to provide a foundation for collaborative planning and support efforts for Information Technology that will result in improved customer service. 1.3. Objectives - The following objectives have been identified: 1.3.1. Business needs of the City organization will drive standards that will support City departments’ ability to provide services to their customers. Standards will balance the organizational and departmental needs to the greatest extent possible 1.3.2. Adoption and implementation of standards will minimize differences in technology, thereby creating easier integration of systems, organizational efficiencies and expertise in support and use of technology. Common technologies will support increased inter-departmental communications among technical staff to maximize their effectiveness. 1.3.3. Provide guidance for future information technology purchases in order to maximize return on future investments and ensure compatibility, integration and compliance with millennium date change requirements. 1.3.4. Address current electronic document and data exchange problems and avoid the potential for additional problems in the future. Information Technology Standards Revision Date: April 2002 Rev. 07 Print Date: November 6, 2003 22 1.3.5. Phase implementation of certain standards to protect current investment in technology and the ability of the organization to maintain critical operations. 1.4. Implementation 1.4.1. Standards are effective for all new purchases. 1.5. Assumptions 1.5.1. Standards for the City of Fort Collins information technology will continue to evolve over time in response to emerging industry standards, technology advances, and changing business requirements. This will require periodic review and updating. 1.5.2. Additional technology areas may be addressed in future standards. SECTION 2. RESPONSIBILITIES 2.1. Individual Departments 2.1.1. The responsibility for implementation of and compliance with standards lies with individual departments, divisions and service areas. The City Manager’s office will be kept apprised of progress and problems related to the implementation of these standards. Departments will work with Information Technology Department (ITD) to bring forward any concerns, proposed changes or additions to these standards, including representation on committees or a task force related to changes and additions. 2.2. Information Technology Department 2.2.1. The Information Technology Department (IT) is charged with the responsibility for monitoring industry trends to ensure necessary review and revision of standards are made in a timely manner. The Information Technology Department (ITD) Director or designate has responsibility to identify areas of needed standardization, solicit input from departmental technical staff and IT Liaisons , and take recommendations to the City Manager regarding changes or additions to existing information technology standards. 2.3. Purchasing 2.3.1. The purchasing process will include checkpoints for compliance, and assist with procurement of standard hardware, software and related equipment. 2.4. Information technology Liaison Committee Information Technology Standards Revision Date: April 2002 Rev. 07 Print Date: November 6, 2003 23 2.4.1. Initiates review of, additions or changes in standards and makes recommendations to City Manager. 2.5. City Manager 2.5.1. Approves standards, reviews exception appeals SECTION 3. STANDARDS 3.1. Office Productivity and PC Software and Operating System 3.1.1. These tools provide connectivity, security, and common formats for the access to, exchange of and integration of documents, systems and data. Category Product Office Productivity SW Suite1 Office XP Electronic Mail Novell GroupWise 6.1 effective Jan, 2002 MAPI (Mail Application Programming Interface for applications using e-mail) Web Browser Internet Explorer 5.1x or Netscape Communicator 4.7X or higher Graphics Software2 Layout Programs: In-Design 1.5 and PageMaker 6.5 Illustration Programs – Illustrator 8 or above Photo programs – Photoshop w/ Image Ready 5.5 Web graphics – Fireworks 3 Desktop/Server Virus Scan McAfee PC Operating System Windows NT Version 4 , with Service Pack 5 for legacy systems, ; Windows 2000 for new purchases 3.2. Local Area Networks 3.2.1. Local Area Networks (LANs) link computers together and thus support working relationships among individuals, groups and departments. Category Product Information Technology Standards Revision Date: April 2002 Rev. 07 Print Date: November 6, 2003 24 Network Operating System, Local Area Network, File and Print servers, and application servers. • Windows 2000 ADS implemented in existing Domain. Novell 5.x for new purchases. • HP-UX for application servers (see section 3.5) • Linux – ONLY with pre-approval from IT Liaison Committee or designates. Information Technology Standards Revision Date: April 2002 Rev. 07 Print Date: November 6, 2003 25 3.3. Desktop PC, Server, and Work Station Hardware 3.3.1. PC (Client) and Unix based Workstations are the basic equipment by which staff shares information and data and performs collaborative work. Similarities in this area support organizational efficiencies. Category Product Standard Desktop PC Hardware1 Dell Optiplex. Server Hardware2 HP, Dell . Workstation Hardware • Risc: Sun or HP • Intel: HP or Dell 3.4. Web Server and Development Software Tools Category Product Web Graphics Fireworks version 4 Web Browser Internet Explorer 5.1x or Netscape Communicator 4.7x or higher Web Server Software Workgroup level: MS Internet Information Server (IIS) EEnntteerr pprriissee lleevvee ll:: AAppaacc hhee Web Server HW and OS HP Server with HP-UX 11.0 or greater or NT 4.x Service Pack 6a Web Server-side Scripting Technology (development tool) Workgroup Level: Active Server Pages (ASP), PHP4 Enterprise Level: PHP4 and Server-side JavaScript (JSP) HTML Layout Tools Allaire Homesite 4.5, Macromedia Dreamweaver 3 or Dreamweaver 3/Fireworks 4 Studio Web Application Development Software MS Visual InterDev, Macromedia Dreamweaver UltraDev Information Technology Standards Revision Date: April 2002 Rev. 07 Print Date: November 6, 2003 26 3.5. Application Hardware, Software and Operating Systems 3.5.1. The data needed for informed decision making often resides in more than one location. Database management systems organize data for storage and retrieval, and make it possible to retrieve, extract, and manipulate data to provide decision support information. Category Product Operating System HPUX 11.0 or greater or Windows 2000 in NT Domain. Hardware (Server) HP or Dell Database Interoperability1 Oracle 8I or above for new systems or MS SQL with pre-approval Application Development Tool Visual Basic MS DotNet, Help Desk Software Heat (Bendata) Database Management - PC based MS Access Same version as current MS Office Professional version. Prepare to convert old databases to avoid multiple versions of MS Access on the desktop GIS Development Tools MapObjects 2.x, ArcIMS Web Development Tools See section 3.4 Server and Development Software Tools. 3.6. Geographic Information System (GIS) 3.6.1. Geographic Information System (GIS) provides mapping, location reference and spatial analysis tools. It enables departments to share access to common, spatially referenced data and produce maps, reports, graphs, charts and other displays. Category Product Workstation Intel Based: HP or Dell RISC Based: HP or SUN GIS Professional Desktop GIS Internet Mapping GIS ESRI ArcGIS 8.X ArcView 8.1 ESRI MapObjects IMS 2.x or ARCIMS 3.x GIS Spatial DataBase ESRI ArcSDE 8.x GIS Development Tools MapObjects 2.x, ArcIMS See Application Development Tools, Section3.4 Information Technology Standards Revision Date: April 2002 Rev. 07 Print Date: November 6, 2003 27 3.7. Computer Aided Drafting (CAD) 3.7.1. Computer Aided Drafting (CAD) is used for multiple drafting purposes in the City. Category Product CAD1 AutoCad 2000and 2002 AutoDesk Modules for use with AutoCAD 3.8. Document Management and Electronic Imaging Category Product Application Software1 Sire Solution Suite Capture or Scanning Workstation HW and SW Kofax Tool Kit, Kofax Adrenalin 32 bit compression card and/or Kofax Imaging Engine SW; 21”: colored monitor End user HW See section 3.3 Desktop PC HW; contact Document Management Administer for scanner recommendations. 3.9. Network Protocol, Components and Wiring 3.9.1. A common network protocol allows communication between and among the various local area networks. Components and wiring standards help maintain the highest level of performance available from the installed infrastructure. Category Product Network Protocol1 TCP/IP 10 MbpsHubs2 3Com Routers3 Cisco Enterasys (SSR); Switches Enterasys (previously Cabletron), Cisco, HP HHoorriizz oonnttaall WWiirrii nngg Siemon Cat5e or better Network Management System Spectrum Element Manager (SPEL), HP Openview Wireless LAN Enterays RoamAbout 28 SERVICES AGREEMENT THIS AGREEMENT made and entered into the day and year set forth below by and between THE CITY OF FORT COLLINS, COLORADO, a Municipal Corporation, hereinafter referred to as the "City" and ____________________________, hereinafter referred to as "Service Provider". WITNESSETH: In consideration of the mutual covenants and obligations herein expressed, it is agreed by and between the parties hereto as follows: 1. Scope of Services. The Service Provider agrees to provide services in accordance with the scope of services attached hereto as Exhibit "A", consisting of ____ (____) page[s], and incorporated herein by this reference. 2. The Work Schedule. [Optional] The services to be performed pursuant to this Agreement shall be performed in accordance with the Work Schedule attached hereto as Exhibit "B", consisting of ____ (____) page[s], and incorporated herein by this reference. 3. Time of Commencement and Completion of Services. The services to be performed pursuant to this Agreement shall be initiated within ______________ (____) days following execution of this Agreement. Services shall be completed no later than _______________. Time is of the essence. Any extensions of the time limit set forth above must be agreed upon in a writing signed by the parties. 4. Contract Period. [Option 1] This Agreement shall commence upon the date of execution shown on the signature page of this Agreement and shall continue in full force and effect for one (1) year, unless sooner terminated as herein provided. In addition, at the option of the City, the Agreement may be extended for an additional period of one (1) year at the rates provided with written notice to the Professional mailed no later than ninety (90) days prior to contract end. 29 4. Contract Period. [Option 2] This Agreement shall commence ________, 200_, and shall continue in full force and effect until ________, 200_, unless sooner terminated as herein provided. In addition, at the option of the City, the Agreement may be extended for additional one year periods not to exceed ___ (_) additional one year periods. Pricing changes shall be negotiated by and agreed to by both parties and may not exceed the Denver - Boulder CPI-U as published by the Colorado State Planning and Budget Office. Written notice of renewal shall be provided to the Service Provider and mailed no later than ninety (90) days prior to contract end. 5. Delay. If either party is prevented in whole or in part from performing its obligations by unforeseeable causes beyond its reasonable control and without its fault or negligence, then the party so prevented shall be excused from whatever performance is prevented by such cause. To the extent that the performance is actually prevented, the Service Provider must provide written notice to the City of such condition within fifteen (15) days from the onset of such condition. [Early Termination clause here as an option. 6. Early Termination by City/Notice. Notwithstanding the time periods contained herein, the City may terminate this Agreement at any time without cause by providing written notice of termination to the Service Provider. Such notice shall be delivered at least fifteen (15) days prior to the termination date contained in said notice unless otherwise agreed in writing by the parties. All notices provided under this Agreement shall be effective when mailed, postage prepaid and sent to the following addresses: City: Service Provider: __________________________ ______________________________ __________________________ ______________________________ __________________________ ______________________________ 30 In the event of early termination by the City, the Service Provider shall be paid for services rendered to the date of termination, subject only to the satisfactory performance of the Service Provider's obligations under this Agreement. Such payment shall be the Service Provider's sole right and remedy for such termination. 7. Contract Sum. The City shall pay the Service provider for the performance of this Contract, subject to additions and deletions provided herein, the sum of Dollars ($_________) [Option Cost Breakdown is attached Exhibit "C"] 8. City Representative. The City will designate, prior to commencement of the work, its representative who shall make, within the scope of his or her authority, all necessary and proper decisions with reference to the services provided under this agreement. All requests concerning this agreement shall be directed to the City Representative. 9. Independent Service provider. The services to be performed by Service Provider are those of an independent service provider and not of an employee of the City of Fort Collins. The City shall not be responsible for withholding any portion of Service Provider's compensation hereunder for the payment of FICA, Workmen's Compensation or other taxes or benefits or for any other purpose. 10. Personal Services. It is understood that the City enters into the Agreement based on the special abilities of the Service Provider and that this Agreement shall be considered as an agreement for personal services. Accordingly, the Service Provider shall neither assign any responsibilities nor delegate any duties arising under the Agreement without the prior written consent of the City. 11. Acceptance Not Waiver. The City's approval or acceptance of, or payment for any of the services shall not be construed to operate as a waiver of any rights or benefits provided to the City under this Agreement or cause of action arising out of performance of this Agreement. 31 12. Warranty. (a) Service Provider warrants that all work performed hereunder shall be performed with the highest degree of competence and care in accordance with accepted standards for work of a similar nature. (b) Unless otherwise provided in the Agreement, all materials and equipment incorporated into any work shall be new and, where not specified, of the most suitable grade of their respective kinds for their intended use, and all workmanship shall be acceptable to City. (c) Service Provider warrants all equipment, materials, labor and other work, provided under this Agreement, except City-furnished materials, equipment and labor, against defects and nonconformances in design, materials and workmanship/workwomanship for a period beginning with the start of the work and ending twelve (12) months from and after final acceptance under the Agreement, regardless whether the same were furnished or performed by Service Provider or by any of its subcontractors of any tier. Upon receipt of written notice from City of any such defect or nonconformances, the affected item or part thereof shall be redesigned, repaired or replaced by Service Provider in a manner and at a time acceptable to City. 13. Default. Each and every term and condition hereof shall be deemed to be a material element of this Agreement. In the event either party should fail or refuse to perform according to the terms of this agreement, such party may be declared in default thereof. 14. Remedies. In the event a party has been declared in default, such defaulting party shall be allowed a period of ten (10) days within which to cure said default. In the event the default remains uncorrected, the party declaring default may elect to (a) terminate the Agreement and seek damages; (b) treat the Agreement as continuing and require specific performance; or (c) avail himself of any other remedy at law or equity. If the non-defaulting party commences legal or equitable actions against the defaulting party, the defaulting party shall be liable to the non-defaulting party for the non- defaulting party's reasonable attorney fees and costs incurred because of the default. 15. Binding Effect. This writing, together with the exhibits hereto, constitutes the entire agreement between the parties and shall be binding upon said parties, their officers, employees, agents and assigns and shall inure to the benefit of the respective survivors, heirs, personal representatives, successors and assigns of said parties. 16. Indemnity/Insurance. a. The Service Provider agrees to indemnify and save harmless the City, its officers, agents and employees against and from any and all actions, suits, claims, 32 demands or liability of any character whatsoever brought or asserted for injuries to or death of any person or persons, or damages to property arising out of, result from or occurring in connection with the performance of any service hereunder. b. The Service Provider shall take all necessary precautions in performing the work hereunder to prevent injury to persons and property. c. Without limiting any of the Service Provider's obligations hereunder, the Service Provider shall provide and maintain insurance coverage naming the City as an additional insured under this Agreement of the type and with the limits specified within Exhibit ___, consisting of ______ (___) pages[s], attached hereto and incorporated herein by this reference. The Service Provider before commencing services hereunder, shall deliver to the City's Director of Purchasing and Risk Management, P. O. Box 580 Fort Collins, Colorado 80522 one copy of a certificate evidencing the insurance coverage required from an insurance company acceptable to the City. 17. Entire Agreement. This Agreement, along with all Exhibits and other documents incorporated herein, shall constitute the entire Agreement of the parties. Covenants or representations not contained in this Agreement shall not be binding on the parties. 18. Law/Severability. The laws of the State of Colorado shall govern the construction interpretation, execution and enforcement of this Agreement. In the event any provision of this Agreement shall be held invalid or unenforceable by any court of competent jurisdiction, such holding shall not invalidate or render unenforceable any other provision of this Agreement. 33 19. Special Provisions. [Optional] Special provisions or conditions relating to the services to be performed pursuant to this Agreement are set forth in Exhibit ___, consisting of _____ (____) page[s], attached hereto and incorporated herein by this reference. CITY OF FORT COLLINS, COLORADO a municipal corporation By: _________________________________ John F. Fischbach City Manager By:_______________________________ James B. O'Neill II, CPPO, FNIGP Director of Purchasing and Risk Management Date:_____________________________ ATTEST: _________________________________ City Clerk APPROVED AS TO FORM: ________________________________ Assistant City Attorney [Insert Corporation's name] or [Insert Partnership name] or [Insert individual's name] Doing business as ____[insert name of business] By:_______________________________ __________________________________ PRINT NAME __________________________________ CORPORATE PRESIDENT OR VICE PRESIDENT Date:_____________________________ ATTEST: (Corporate Seal) _____________________________ CORPORATE SECRETARY 0033 EXHIBIT B INSURANCE REQUIREMENTS 1. The Service Provider will provide, from insurance companies acceptable to the City, the insurance coverage designated hereinafter and pay all costs. Before commencing work under this bid, the Service Provider shall furnish the City with certificates of insurance showing the type, amount, class of operations covered, effective dates and date of expiration of policies, and containing substantially the following statement: "The insurance evidenced by this Certificate will not be cancelled or materially altered, except after ten (10) days written notice has been received by the City of Fort Collins." In case of the breach of any provision of the Insurance Requirements, the City, at its option, may take out and maintain, at the expense of the Service Provider, such insurance as the City may deem proper and may deduct the cost of such insurance from any monies which may be due or become due the Service Provider under this Agreement. The City, its officers, agents and employees shall be named as additional insureds on the Service Provider's general liability and automobile liability insurance policies for any claims arising out of work performed under this Agreement. 2. Insurance coverages shall be as follows: A. Workers' Compensation & Employer's Liability. The Service Provider shall maintain during the life of this Agreement for all of the Service Provider's employees engaged in work performed under this agreement: 1. Workers' Compensation insurance with statutory limits as required by Colorado law. 2. Employer's Liability insurance with limits of $100,000 per accident, $500,000 disease aggregate, and $100,000 disease each employee. B. Commercial General & Vehicle Liability. The Service Provider shall maintain during the life of this Agreement such commercial general liability and automobile liability insurance as will provide coverage for damage claims of personal injury, including accidental death, as well as for claims for property damage, which may arise directly or indirectly from the performance of work under this Agreement. Coverage for property damage shall be on a "broad form" basis. The amount of insurance for each coverage, Commercial General and Vehicle, shall not be less than $500,000 combined single limits for bodily injury and property damage. In the event any work is performed by a subcontractor, the Service Provider shall be responsible for any liability directly or indirectly arising out of the work performed under this Agreement by a subcontractor, which liability is not covered by the subcontractor's insurance. CITY OF FORT COLLINS ADDENDUM No. 1 SPECIFICATIONS AND CONTRACT DOCUMENTS Description of Bid : P917 PARKING TICKETING MANAGEMENT SYSTEM OPENING DATE: 3:00 p.m. (our clock) December 1, 2003 To all prospective bidders under the specifications and contract documents described above, the following changes are hereby made. Questions 1. Is the volume of Handhelds and printers to be 6 (six), as corresponds with paragraph 3 of page 3? This is important as the cost of the hardware varies significantly depending on the volumes required. Answer: The City intends to buy ten (10) handheld units and ten (10) printers. 2. Some figures have been provided. (400,000 records over a three year period, 6 staff) Does that mean each member of staff issues around 100 citations each day? Answer: On average, the City’s parking enforcement officers write 50 - 75 tickets per day. The number of records cited above is an estimate and includes slightly more than 3 years of information. 3. Do you have a copy of the current citation and what are the dimensions? Answer: The current citations used by the City measure 8 centimeters by 18.5 centimeters. The background of the citation is a pre-printed form in red ink, on thermal paper. The citation information is printed in black ink. The City is not requiring that vendors provide this same citation. The City is open to suggestions for different types or sizes of citations, depending on the hardware that is eventually selected. 4. How many concurrent “back office” operators will be using the system and how many in total may require to be registered users? Answer: The system should allow access for up to five users concurrently. The City needs up to ten registered users. 5. Page 5 first paragraph – Please clarify in what format data to be transferred will be provided in and also on what media will be shipped to us. Answer: The first paragraph on page 5 does not reference “data exchange”, so the City assumes the question comes from one of the other references in the document to “data exchange”. In all cases where data exchange is reference, it is the City’s expectation that the exchange will occur in some industry standard, uniformly accepted format such as comma delimited text files. The City is capable of exchanging data over the Internet, on CD ROM, on 3.5” floppy diskette, or as email attachments. The City can also set up and participate in internet-based FTP sites. If a vendor has a proprietary data exchange method, the vendor should plan to share whatever hardware or software the City may need to exchange data with the vendor. 6. Item M Page 7 – How is this currently carried out? Which Third Parties are catered for? Answer: This item refers to the collection of name and address information that corresponds to license plate information. Currently, the City generates a list of license plates for which it needs name and address information. Some additional (but very brief) information is also provided with the license plate, such as the make of the vehicle, and the state of issue for the license plate. This information is generated automatically at periodic intervals by the City’s existing ticketing management system, and is sent via the Internet to a data processing firm which returns to us the name and address information associated with the license plate. The name and address information is then loaded automatically into the customer record of the citation data base. It is the City’s expectation that a similar or better capability be provide by the vendor, is response to this RFP, in order to provide the City with name and address information, particularly for those citations that are not paid. The City needs the name and address information in order to send overdue notices, or to forward accounts to a collection agency (assuming the account is not paid within a certain time period.) There is no requirement in this RFP that the vendor’s ticketing management system interfaces with the City’s existing provider of name and address information. The City assumes that in order for a vendor to satisfy the requirement of Item V.A.1.m. on page 7, that a relationship of some kind must exist between the vendor’s system and an information provider. The specifications of that relationship are up to the vendor and should be disclosed in the response to this RFP. 7. Item 3 Page 8 – When was the Spectrum system installed and which company (if not Spectrum) supplied it? Answer: The City’s existing ticketing management system is called Spectrum2000. It was provided by and installed by Spectra Corporation (now defunct) in late 1999. 8. Item 7 Page 12 – Please define the current cash system? Is it a Cash register of a PC till? Are there check readers, bar code scanners, credit card swipes…etc? Answer: The City’s current cash system is elementary and unsatisfactory. The cash drawer is a stand-alone, manual storage bin. It is not connected to a cash register or a computer. We do not have check readers or bar code scanners. We do accept credit card payments, and we have a credit card reader, but it is not connected to the cash drawer. All funds that are received during the day are entered into a funds management screen on a computer which is adjacent to (but not connect to) the cash register. At the end of the day, the drawer is balanced by counting the actual funds received and comparing the total to the total in the cash management screen on the computer. 9. Item 3 Page 18 – Please outline what the status of 802.11 coverage is within the City. Answer: Currently, 802.11 coverage exists inside two City office buildings, including the office building where the Parking Services division is housed. The other building with coverage is City Hall. There is no 802.11 coverage outside of these two buildings. 10. Item 5 Page 18 – Which suppliers have demonstrated their systems to you and what companies demonstrated the Symbol device? Answer: The City examined products and software from all the vendors that were present at the International Parking Institute exposition in Long Beach California in late May of this year. A list of the specific attendees can be obtained from IPI. Some, but not all, of those firms demonstrated the Symbol device. In addition, representatives from T2 Systems Inc. and Cardinal Tracking Inc. came to Fort Collins in early 2003. Both of those firms demonstrated the Symbol device. Finally, representatives from Fort Collins Parking Services went to Los Angeles, California to view a demonstration of the AutoVu technology in October of 2003. That firm did not demonstrate the Symbol device. 11. Item D 2 Page 19 – How many staff will be requiring training? Answer: Six (6) Parking Enforcement Officers One (1) Parking Enforcement Supervisor Three (3) Customer Service Representatives One (1) Customer Service Supervisor One (1) Parking Operations Coordinator One (1) Parking Services manager 12. Exhibit B Item 2, A, 1 – Please confirm value required under Colorado Law. Answer: Unlimited for workers compensation injuries covered by state statute. RECEIPT OF THIS ADDENDUM MUST BE ACKNOWLEDGED BY A WRITTEN STATEMENT ENCLOSED WITH THE BID/QUOTE STATING THAT THIS ADDENDUM HAS BEEN RECEIVED. CITY OF FORT COLLINS ADDENDUM No. 2 P-917 PARKING TICKETING MANAGEMENT SYSTEM SPECIFICATIONS AND CONTRACT DOCUMENTS Description of RFP P-917 Parking Ticketing Management System OPENING DATE: December 1, 2003, 3:00p.m. (Our Clock) To all prospective bidders under the specifications and contract documents described above, the following changes are hereby made. Addendum #2 information Q1. Is the McGann software used by the City some form of "Revenue and Facilities Management" system for running your barrier controlled off street parking garages? A1. Yes. The McGann system is a Revenue and Facilities Management Package. We use it to control two parking structures with 6 entrance lanes, 6 exit lanes, and two reversing lanes. We also use it to keep track of our permit sales, and the occupancy of the structures. Q2. Is the McGann system using an Access/SQL database back end? A2. The McGann system runs and SQL back-end. Q3. Does the McGann system run off a central server at your offices or is the system distinct, in that it is located at each parking garage? A3. The system runs off a central workstation located in our office. Q4. If it is the former, would there be a problem doing a data exchange from trusted folders on a networked drive, either in real time or at a frequency to be specified by the City Council? A4. There should be no problem doing the data exchange as you described it using the trusted folders, network drive, and either real time or scheduled. The City Council would not play a role in this decision. It is purely an administrative and operational decision. Q5. If it is the latter, do you take multiple feed from each parking structure into one finance / management system which we could get the data from? Alternatively, would we have to consolidate the data from each location on an individual dial-up basis? A5. Part of your last question is moot (the part about the multiple feeds) since the multiple feeds are already aggregated into the office workstation database. As for consolidating data, that also would not be necessary. The data from both structures all reside in a single relational database. The data transfer that may be required in response to our RFP specification would be a matter of identifying relevant fields, extracting the data based on a query, and transporting that data to a handheld computer where it could be used by an application on the handheld to accomplish a specific purpose. In any event, no dial-up connection would be required as we anticipate that any data exchanges that may be required to meet our needs would happen locally. If you have any questions please contact James B. O’Neill II, CPPO, FNIGP, Director of Purchasing and Risk Management, at 970-221-6779. RECEIPT OF THIS ADDENDUM MUST BE ACKNOWLEDGED BY A WRITTEN STATEMENT ENCLOSED WITH THE BID/QUOTE STATING THAT THIS ADDENDUM HAS BEEN RECEIVED.