Rev. 4-16-15 Page 1 of 13 SOLICITATION QUESTIONS & ANSWERS Project Name: Fare Collection System Solicitation #: 4018000226 Contract Administrator: Alan Scanio 8 Fare Media Distribution, page 118: "8.1.1-3 Fare sales and value loads may also be completed through METRO’s third-party mobile application, which may provide a barcode for scanning at the retailer to collect Q660: payment. Additional details of integration with METRO’s mobile application will be determined during design review." Is the expectation that the barcode scanning at the retailers would be used to buy a fare product? If not, what is the intended purpose of these features? The intended purpose is to allow mobile application users to load tickets and value to their accounts using A660: cash at a retailer. [We are] requesting a 90 day extension to the current proposal submission date of October 29, 2018, to Q661: January 29, 2019. A661: Please reference Addendum 1 for deadlines. On pages 3, 11, and 14 of the RFP and in the SIOP spreadsheet for items 0.1.2.3, 1.1.1.2, 2.1.1.2 Q662: regarding Retail Network Transaction Fees there is an asterisk (*) but no note referring to such. What is the intended note? A662: The asterisk was added in error and has been removed in Addendum 2. Section 15.1.1-6. Please provide details regarding typical time and transaction volume associated with one Q663: full day of active use. For example: how many validations/inspections are performed per day with the current handheld devices? How long are the fare enforcement shifts? Transaction volume should account for 1,000 transactions a day. Shifts are currently 8 hours but handheld A663: devices may be swapped without returning to a depot to meet operational needs. Q664: Section 15.1.4-4. Define what a day of fare payment transactions means. How many transactions? A664: The HIT device must support a minimum of 1,000 transactions a day. Q665: Section 15.1.4-5. Same as previous question. How many transactions are we talking about? A665: The HIT device must support a minimum of 1,000 transactions a day. 6.3.2-3 Stipulates support of distance based fare. Previous requirement indicates no tap-off - is Metro Q666: considering introducing tap off in the future? METRO reserves the right to change fare policy at any time, including during the useful life of the future A666: system. The FCS should be flexible enough to hande all types of fare products described in section 6 of the Technical Specifications, Fare Policies. 21.2-2 stipulates Active - Active load balancing, in the context of high availability. Given cloud computing Q667: architectures and distributed nature of account-based fare collection systems, would Metro consider defining SLAs in lieu of defining computing environment architecture? Bidders should propose based on the functional requirements in the specification. If a proposer would like A667: to include additional products, services, or functionality, this should be submitted along with the base Proposal but under separate cover. Q668: How does METRO want the data stored? A668: See Section 19.7 for data retention requirements pg. 74. Regarding requirement 2.4.8, who pays today for the dedicated analog lines that connect 297 Q669: RPOS devices in retail to the Conduent backend? The retailers?Metro? Conduent? And at what cost/month? Legacy RPOS devices will not be part of the future FCS, and the costs of the current system will not be A669: provided. Bidders should propose anticipated fees for their proposed approach. pg. 117. Regarding requirement 8-7: Please confirm that RPOS units will not be a part of the legacy Q670: system that must be maintained by the new retail network provider for any amount of time during the transition or afterwards. A670: The SI will not support the existing RPOS units. Rev. 4-16-15 Page 2 of 13 pg. 125Requirement: Deployment of a retail network and associated distribution services relating to media will be managed initially by the SI initially, with transfer of contract ownership to METRO after Revenue Service Acceptance. Question: We recommend that you accept direct bids from retail network providers. Our recommendation Q671: offers Metro the highest degree of transparency and flexibility to select the best retail network solution without compromising the best SI solution. The selected retail network provider can agree to be managed initially by the SI with transfer of contract ownership to METRO after Revenue Service Acceptance. Please confirm if this is acceptable. A671: METRO appreciates the recommendation but maintains the retail requirements as specified in the RFP. pg. 126Regarding requirement 10.1.1-1, please provide a copy of the detailed modeling that resulted in the Q672: determination that you will need a minimum of 1,300 retailers. A672: The data will be made available to the successful bidder during design review. pg. 126Regarding requirement 10.1.1-2, please provide a list of every light rail and bus stop (with geo Q673: coordinates for each stop). All publicly available METRO GIS data may be found at A673: https://www.ridemetro.org/Pages/NewsDownloads.aspx pg. 115Regarding requirement 7.5, is there an expectation that retail will be able to load fare products to Q674: Third Party Media? Requirement 7.5 is for the SI to ensure devices can process third party media as an account credential in A674: the FCS. Fare products would exist in the account. pg. 125. Regarding requirement 10.1-4: Although there is no requirement to load fare products to EU Q675: Media in retail, is there a minimum number of fare products that you would ideally want to be available for sale/load at any given retail location? A675: Fare products required are referenced in specification section 6.3.1. pg. 117Regarding requirement 8-6: What consumer fee do you have in mind for issuance of the EU Media Q676: in retail? (next gen Q Card)? A676: Fees associated with this requirement will be decided during design review. Q677: What is your intended minimum/maximum load value for EU Media (next gen Q Card)? This should be configurable based on METRO's fare policy. Current minimum load is $3 and maximum is A677: $500, but the system must be flexible enough to accommodate any limits. pg. 4. Regarding the Pricing Schedule and Section 17.1: It appears that you are expecting to issue a total of 300,000 EU Media cards in retail in the first seven (7) years of the agreement. Perhaps this is for pricing Q678: comparison only. If for comparison only, please provide an estimate (by year) of what you expect 1,300 retailers to sell each year during the initial seven (7) year term of the agreement? Please provide the same level of detail for each of the optional years. METRO does not have the data to provide expected sales or reload by vendor. METRO is relying on the SI A678: and Retail Network provider to determine best retail solution through the design process. pg. 168. FCS Tech Spec, Section 17.1.1-1: Provided that you will accept bids from the retail network Q679: providers directly, would you accept a bid from the retail network provider for EU media only? No, respondents are to reply to the RFP in its current form and in its entirety. The SI response must include A679: a Retail Network Provider. pg. 200. How will the proposer's website developers be provided access to the Houston Web Hosting Q680: environment for deployment, testing, and support? A680: Access to systems and any relevant details will be provided during design review. RFP/Req. Section No. 0.1.2, page 3. There is an "*" associated with Retail Network Transaction Fees with Q681: no associated reference. Please provide a description of what is expected for this line item. A681: The asterisk was added in error and has been removed in Addendum 2. RFP/Req. Section No. 0.4.1A.5, page 7. Please provide a detailed description of what METRO is expecting Q682: these fees to cover. A682: Transaction fees are inclusive of all fees related to processing of any payment cards. RFP/Req. Section No. 0.4.1B.2, page 8. Please provide a detailed description of what METRO is expecting Q683: these fees to cover. A683: Transaction fees are inclusive of all fees related to processing of any payment cards. RFP/Req. Section No. 4.4-1, page 83. Who is the merchant acquirer that the new system will be interfacing Q684: with? The current Merchant Acquirers are Chase PaymentTech and First Data but METRO reserves the right to A684: change the Merchant Acquirer during the term of the contract. RFP/Req. Section No. 4.7-10, page 86. Please state if the back office/FCS management interface requires Q685: 15 languages. Rev. 4-16-15 Page 3 of 13 A685: The back office system shall be in English. Q686: RFP/Req. Section No. 4.9-1, page 88. Please define the thresholds or parameters of the word “optimal”. A686: "Optimal" is considered the best. RFP/Req. Section No. 7.2.2-3, page 144. The magnetic stripe data and barcode are proprietary to the Q687: Retail Network Provider (e.g. Incomm, Blackhawk, ePay, Clover). Is it the intention of METRO to have the SI contract with only one of these providers? This specification section does not restrict the SI from utilization of multiple retail providers but describes A687: intent of EU processing via barcode or mag stripe at retailers. RFP/Req. Section No. 8.1.1-1, page 117.