Montclair, NJ ADDENDUM NO. 2. Request for Proposal # 987 Access and Revenue Control System

Transcription

1 Montclair, NJ ADDENDUM NO. 2 Request for Proposal # 987 Access and Revenue Control System Date of Original Bidding Documents: November 4, 2011 Date of Addendum No. 1: November 28, 2011 Date of Addendum No. 2: December 6, 2011 INTENT: This Addendum forms a part of the Contract Documents and modifies the Original Bidding Documents and Prior Addenda, if any, as identified above. Acknowledge receipt of this Addendum in the space provided on the Bid Form. Failure to do so may subject Bidder to disqualification. I. Points of Information: 1. Question: Can the University please provide details as to how the facility operates today and what major functional and operational changes they would like to see in the facility with this new system. Response: The Facility today operates as a transient and permitted parking facility. It services students, visitors, faculty, staff and conference center guests. The Facility has AVI device technology, as well as ticket splitters, exit verifiers and six (6) pay stations for transient parking. The University wishes to keep the same model, however, with a few upgrades. The University is looking for faster response times to both AVI devices and at pay stations. The University is looking for patrons to be able to use their credit cards at the entrance and exit gates instead of waiting in long lines at pay stations. Further, the University is looking to allow students to pay for transient parking with their student cards. 2. Question: Will the awarded vendor be required to remove the existing equipment in the facility and if so will they be required to dispose of it or will it remain with the University? If this is required where can this be accounted for in the 'pricing sheet', Attachment #5? Response: The awarded vendor will be required to remove the existing equipment in the facility, however, it will remain at the University. 3. Question: Section 3.1.1, Page 9. This section states that 'awarded vendor must furnish the equipment specified in Section 3.2' but it appears that there is equipment listed in Section 3.3 that is not listed in Section 3.2 can the University please provide clarification on the exact equipment that is being requested as this is a 'must' request? Response: The awarded vendor will supply all equipment listed in both sections 3.2 and 3.3. Access and Revenue Control system Page 1 of 6

2 4. Question: Section 3.12, page #37. Where in the submittal documents would a vendor outline any exceptions regarding their bid and the functionality that is requested by the University or is a vendor not permitted to respond if they do not meet all of the qualifications and specifications that are outlined in the bid documents? This section, 3.12, only discusses vendor qualifications and not specifics related to the solution that the vendor is proposing Response: For each section requiring a response, vendors are allowed to say that while they do not meet a must according to the bid specs, they do propose an alternative solution. Then, the vendor can outline the solution they are proposing if it is different than what is outlined in the bid document. These alternative proposals will be accepted by the University if they are found fit to be equivalent or better. 5. Question: Section 3.2.1, page 10. 'AVI Readers' - does the University have a preference for these readers (i.e. A preferred vendor)? To confirm, the University is asking for 1,500 tags per Attachment 5? Response: The University does not have a preference of vendor for AVI readers. The University is asking for 1500 AVI tags to start. 6. Question: Section 3.3.1, page 11. It states 'system must also have the capability for the transient patron to insert a credit card into the TD to be used as their ID in lieu of taking a ticket', this appears to indicate that the University would like the system to have credit card in/credit card out capabilities is this a mandatory requirement and if so what are implications if a vendor submits a bid but cannot meet this requirement? Response: This is a mandatory requirement. If the vendor cannot provide this functionality nor an equivalent, they will not be eligible to bid. The vendor must submit proof that it is an equivalent. 7. Question: Section 3.3.1, page 11 Can you please provide some clarification regarding the last paragraph on this page and the 'attended operation' for exit? You state 'Fee Computer Ticket Validator' which would indicate that a Fee Computer would be in the exit lanes but you only ask for one 'Fee Computer' in Section and there is no mention of booths or other enclosures for the exit lanes where a Fee Computer might reside. Additional details on the 'attended operation' would be greatly appreciated as this is a 'must' requirement. Response: While the University does not have standard cashier booths or lane cashiering, there are instances where customers do park their vehicles and go into the main office to have their parking verified and paid for by the fee computer. So while cashier booths will not be installed in lanes, the system still does have a need for attended options. 8. Question: Section 3.3.3, page 14/15. You state that the Ticket Dispenser 'must also be capable of accepting credit cards to gain access into the facility' - we have the same question here as we did above in Section 3.3.1, page #11 regarding cc in-out functionality. Is this a mandatory requirement? Response: This is a mandatory requirement. If the vendor cannot perform this functionality, nor provide an equivalent, they will not be eligible to bid. The vendor must provide proof that it is an equivalent. 9. Question: Section 3.3.3, page 15. You state 'TD parameters must be locally programmable at the TD' - is this a requirement that it be programmable only at the device or can it be programmed via more advanced technology means, I.e. Via the FMS system that will be proposed. Same question applies in the next paragraph - 'each controller must contain an integrated keypad and LCD display' - is this a requirement as this sounds very vendor specific? Response: The Ticket Dispenser parameters can be programmed at either the TD or via more advanced technology through the FMS. You may disregard the sentence on the controllers. Access and Revenue Control system Page 2 of 6

3 10. Question: Section 3.3.4, page 18. Can you please provide additional detail as to how a Fee Computer would serve as the central point for payment for unattended locations'? In addition, you note that the 'fee computer must be a revenue control device that process non-parking related transactions' - as this is a 'must' can you please provide details as to what these non-parking related transactions would be? Response: Please see answer to number 7. In this case, the Fee Computer will be used to do parking transactions for lost tickets, or for customers who misunderstand pay station locations or did not use credit card entry or exit. The Fee Computer will not be doing non-parking related business. 11. Question: Section 3.3.5, page 22. Can you please provide additional details regarding 'Proprietary Debit Cards' as you mention one specific vendor in this section? Response: The Blackboard Transact application does not feature an SDK. Third party vendors are required to enter into a business agreement with Blackboard Transact with the requisite non-disclosure clauses to develop a Transaction Interface Agent (TIA) between the products. The 3rd party vendor becomes a Blackboard Building Block Partner. Here is the link for the Blackboard web site with some additional details about this business model: Transact Interface agents become part of our annual license and maintenance as managed by the University's Card Services office and the System/Application Administrators. The University is currently not responsible for hosting credit card information. Further, the University needs a PCI compliant hosting environment for customer credit card information. 12. Question: Section 3.3.5, page #22. You mentioned that the PIL 'should also, if applicable, operate as a Prepay Entry Device' - is this applicable here? Response: This is not a must. 13. Question: Section 3.3.5, page #23. You state 'a Programming Interface must provide the ability to locally programming hardware and software features of the PIL device' - is this a 'must' requirement if our solution is programmed via the FMS system that will be proposed and not done locally at the equipment level? Response: Please see the response to question Question: Section 3.3.8, page #28. Can you please provide additional information regarding 'the optional Variable Message Sign application' - is this a requirement of the bid, what exactly is the University looking for, are you looking for a Variable Message Sign, etc? Or are you only looking for OPEN/CLOSED signage for the facility based on the total capacity of the facility? Response: The University needs the count system to count vehicles on each floor for its own reporting and data analysis purposes. The University is no longer asking for a VMS as part of this project. Access and Revenue Control system Page 3 of 6

4 15. Question: Section 3.3.9, page 29. Can the University please provide additional details regarding the statement 'tags should have the ability to add and subtract funds for a set number of variable uses such as monthly parking, semester and annual parking' - what is the intention here with respect to this functionality and how would it be used in lieu of the traditional tag usage? Response: This is a part of the University s ideal system. In this system model, like an EZPass, customers could prepay a certain dollar amount onto a mag strip card or AVI device and a fee could be taken from the balance after each use. While the University is not asking for this to be done currently through an AVI device, the University wishes to use this model with the student ID card. 16. Question: Section 3.4.1, page 30. You state 'the FMS must be designed specifically to operate under the Windows Operating System' - is a web based solution acceptable to the University? Response: Yes 17. Question: Section 3.4.1, page 30. You further state in this section that the FMS must be able to 'inventory license plates' - can you please provide some additional detail regarding this requirement. Response: The University does not require License Plate Inventory. 18. Question: Section 3.4.1, page 31. Can you please provide additional information regarding the 'Event Control System' that is mentioned in this section, this term is not defined in the RFP? Response: Please disregard the information pertaining to the event control system. 19. Question: Section 3.4.1, page 31. You mention 'Count System Configuration window' - this appears to be a very vendor specific term, can you please clarify what you are looking for with this functionality. Same for the 'Count System Monitor' listed in the next paragraph and the 'System Activity Monitor' noted on page #32. Response: The University needs a count system to monitor that will display up to date and accurate facility counts of transient parkers, permit holders and combined overall numbers present in the facility at each second during the day. Vendors may choose to do this in various ways due to the types of software involved. 20. Question: Section 3.4.4, page 34. Blackboard Interface is this a 'must' requirement? Is this functionality in place today with the current Access & Revenue Control System? Response: This is a must. It is not in place with the current PARCS model, however, the University is requesting it as part of the updated system requirements. 21. Question: Section , page 38. Can you please provide Attachment A, we do not see where that is provided as part of this bid? Response: The attachment was provided in Addendum 1. Access and Revenue Control system Page 4 of 6

5 22. Question: Attachment #5, page 65 Can we provide additional pricing information on our own proposal format if desired? This could provide additional information and detail on the items that are being proposed, the detail behind the pricing of those items, any exceptions, and any additional information that we feel might be helpful to the University Response: In order to evaluate all candidates equally, all pricing must be submitted as per Attachment 5. We cannot accept an alternative format. 23. Question: Attachment #5, page 65. Per the question proposed above, is 'cc swipe in' and 'cc swipe out' a mandatory requirement for this bid? Response: Yes it is mandatory. II. Special Notice of Bid Extension: The Bid Opening date has been extended to 12/15/2011 at 3:00 pm. The opening location is 855 Valley Rd., Suite 112. III. Changes to Prior Addenda: IV. Changes to Bidding Requirements: V. Changes to Agreement and Other Contract Forms: VI. Changes to Conditions of the Contract: VII. Changes to Specifications: VIII. Changes to Drawings Access and Revenue Control system Page 5 of 6

6 Please acknowledge receipt of this Addendum No. 1 via fax. The fax number is Company Name (please print) Date Signature Title Contact Name (please print) Distribution: All Bidders FILE A. DEO Access and Revenue Control system Page 6 of 6