BOISE STATE UNIVERSITY

REQUEST FOR PROPOSAL

RFP #LF16-057

Parking Management Systemfor

Boise State University

Issue Date 02/23/2016

LF14-057 Page 1 of 68 5/7/2023

TABLE OF CONTENTS

Page

1. ADMINISTRATIVE AND BACKGROUND INFORMATION 32. SUBMISSION PROCESS 53. CONTRACT 124. BUSINESS INFORMATION 155. SPECIAL TERMS AND CONDITIONS 166. SCOPE OF WORK 197. PROPOSAL REVIEW AND EVALUATION 548. COST PROPOSAL 57

APPENDIX A--SCOPE OF WORK 59ATTACHMENT 1--SIGNATURE PAGE 60ATTACHMENT 2--OFFEROR QUESTIONS 61ATTACHMENT 3 REFERENCES 63ATTACHMENT 4 COST PROPOSAL 67ATTACHMENT 5 VENDOR SECURITY ASSESSMENT FORM

LF14-057 Page 2 of 68 5/7/2023

1. ADMINISTRATIVE AND BACKGROUND INFORMATION

1.1 RFP Administrative Information

RFP Title: RFP LF16-057, Parking Management System for Boise State University

RFP Project Description: The purpose of this Request for Proposal (RFP) is to purchase and successfully implement an integrated Parking Management System for Boise State University.

RFP Lead/Address to deliver response:

Lori Farris, Buyer1910 University, MS-1210Boise, ID 83725-1210lorifarris@boisestate.eduPhone: (208) 426-5449

University Purchasing Dept. (all RFP information and updates will be posted to this website):

http://vpfa.boisestate.edu/purchasing/, click on Bid Opportunities link and select appropriate solicitation

Optional Pre-Proposal Conference:

03/1/2016 Mountain Standard Time (Details will be provided upon RSVP)

Location: Teleconference (Details will be provided upon RSVP)

Deadline To Receive Questions: 3/2/2016, 11:59:59 AM Mountain Standard Time

Anticipated Release of Answers to Questions:

3/3/2016 at http://vpfa.boisestate.edu/purchasing/, click on Bid Opportunities link.

RFP Closing Date: 3/21/2016, 5:00:00 PM Mountain Daylight Time, Late responses will not be accepted.

RFP Opening Date: 10:30 AM Mountain Daylight Time in Purchasing Department on the first work day following the Closing Date.

Demonstration/Oral Presentations: If required, tentatively scheduled for, Week of 4/10/2016 for Offerors from whom a demonstration is requested.

Validity of Proposal: Proposals are to remain valid for one hundred twenty (120) calendar days after the scheduled RFP Closing Date. Proposals submitted with a validity period of less than this will be found non-responsive and will not be considered.

Initial Term of Contract and Renewals:

Initial term of the Contract will be for an implementation phase plus two (2) calendar years. The implementation phase shall commence upon signing of a contract and terminate upon System acceptance and Go Live. The two (2) year period shall commence immediately following Go-Live acceptance, and terminating two (2) years following the Go-Live date. Following the Initial Term, the parties may extend the Contract, under the same terms and conditions, on an

LF14-057 Page 3 of 68 5/7/2023

annual basis, upon mutual written consent. At the time of extension, the annual renewal pricing will not exceed five (5) percent over the previous year’s renewal term without nullifying the contract.

1.2 Scope of Purchase – Boise State University is soliciting proposals for a Parking Management System. Boise State University, Transportation and Parking Services strives to meet the growing needs of a Metropolitan Research University of Distinction. We will be expanding our current parking management software system to encompass a more robust system, combining current contracted systems and streamlining them into a centralized unit. In order to benefit our customers, we desire an extensive software management system for all parking operations, including event parking reservation and transaction processing, focusing on current needs and future growth, with the ability to enhance our system based on our student, employee and community’s wants and needs.

1.3 Boise State University Overview - Boise State University (“University”) is a public, higher-educational institution located in Boise, Idaho. Serving approximately 22,000 students and employing nearly 2,690 faculty and staff, the University offers undergraduate, graduate, and non-degree programs. More information is available at http://news.boisestate.edu/facts/

1.4 Current Environment - Boise State University is currently utilizing parking management software by iParq - Intelligent Parking. This software solution is used to manage our customer accounts, order information, permit inventory and permissions settings, enforcement module, and vehicle information. We are currently using an in-house created event reservation solution. Due to the expanse of our coverage, we also leveraging solutions from Genetec LPR hardware and software, Digital Iris for Luke pay station, and IPS meter management, and works regularly with the main campus PeopleSoft installation for campus personnel and financial management. The University is also in the midst of expanding our financial management piece to implement an expansion to Oracle Fusion Cloud in 2016.

The Boise State University Transportation and Parking Services Department offers these metrics to understand how we utilize current systems, and the scope of business we regularly process:

Student population of 22,259Faculty and staff population of 2,6897,851 vehicle parking spaces in structures and lots across campus 21,000 citations per year13,000 permits per year1,700 events managedReservation, Estimate, Quote, Setup, Parking Staff During Event, TeardownArrears billing for event personnel, equipment and spacesDigital codes for pay stationsApproximately 1,300 Pre-Paid permits for specific event categoriesIn the field payments for parking during events

LF14-057 Page 4 of 68 5/7/2023

1.5 Timeline (M) - Upon award of the RFP, signing of the contract and within ten (10) days of receipt of the University’s purchase order, the successful Contractor must provide a complete project timeline to the University’s Parking Services Department and the University’s Purchasing Department. The University’s preference is for the system to Go-Live in the month of July 2016.

2. SUBMISSION - PROCESS, FORMAT, & REQUIREMENTS

2.1 Pre-Proposal Conference and Questions and Answers

2.1.1 A non-mandatory pre-proposal conference will be held at the location and time as indicated in Section 1.1 of this RFP. This will be your opportunity to ask questions of the University staff. All interested parties are invited to participate, restricted to two (2) incoming phone lines from each prospective Offeror as the number of telephone lines is limited. Those choosing to participate must pre-register via email with the name and contact information of participants to the RFP Lead to receive meeting details. This conference will be used to explain, clarify, or identify areas of concern in the RFP. Those asking questions during the pre-proposal conference will be asked to submit those questions to the University in writing by the designated “Deadline to Receive Questions” period as indicated in Section 1.1 of this RFP. Any oral answers given by the University during the pre-proposal conference are to be considered unofficial. Conference attendance is at the Offeror’s own expense. For simplicity’s sake, Offerors are strongly encouraged to submit just one, final set of questions, after the pre-proposal conference but prior to the question deadline, rather than multiple sets of questions.

2.1.2 All questions regarding the proposed product or service must be submitted to the RFP Lead by the “Deadline to Receive Questions” noted in Section 1.1. Questions must be submitted using Attachment 2, “Offeror Questions,” via email to the RFP Lead at the address listed in Section 1.1 for the RFP Lead. Official answers to all questions will be posted on the University’s website as an amendment as indicated in Section 1.1, of this RFP.

2.1.3 All questions regarding the State of Idaho Standard Contract Terms and Conditions, State’s “Solicitation Instructions to Vendors” and State’s “Special Terms and Conditions for Customized Software and Related Services” (if applicable) found at http://purchasing.idaho.gov/terms_and_conditions.html or http://adm.idaho.gov/purchasing/purchasingrules.html, and as may be amended from time to time, and incorporated in this RFP by reference (collectively, the Terms and Conditions”) must also be submitted in the same form as provided in 2.1.2 and must be submitted by the deadline to receive questions as stated in Section 1.1. Questions regarding these requirements must contain the following:

2.1.3.1 The term or condition in question;

2.1.3.2 The rationale for the specific requirement being unacceptable to the Offeror (define the deficiency);

LF14-057 Page 5 of 68 5/7/2023

2.1.3.3 Recommended verbiage for the University’s consideration that is consistent in content, context, and form with the University’s requirement that is being questioned; and

2.1.3.4 Explanation of how the University’s acceptance of the recommended verbiage is fair and equitable to both the University and the Offeror.

2.1.4 In response to questions regarding the Terms and Conditions, the University will, in its sole discretion (i) accept the proposed modification or a proposed alternative as an amendment to the RFP, or (ii) reserve the question to be negotiated in accordance with Section 3.4 hereof.

2.1.5 Proposals received that qualify the offer based upon the University accepting other terms and conditions not found in the RFP or which take exception to the University’s terms and conditions may be found non-responsive, and no further consideration of the proposal will be given.

2.1.6 Any Offeror proposed modifications will be incorporated into the contract only if specifically accepted by University in an amendment to the RFP or otherwise as expressly accepted in writing by the University.

2.1.7 From the date of release of this RFP until an Intent to Award Letter is issued, all contact and requests for information shall be directed to the RFP Lead, only. Regarding this RFP, all contact with other personnel employed by or under contract with the University is restricted. During the same period, no prospective Offeror shall approach personnel employed by, or under Contract to the University, on any other related matters. An exception to this restriction will be made for Offerors who, in the normal course of work under a current and valid contract with the University, may need to discuss legitimate business matters concerning their work with the University. Violation of these conditions may be considered sufficient cause by the University to reject an Offeror’s proposal, irrespective of any other consideration.

2.1.8 Proposals should be submitted on the most favorable terms from both a price and technical standpoint as well as with regard to legal terms and conditions. The University reserves the right to accept any part of a proposal, or reject all or any part of any proposal received, without financial obligation, if the University determines it to be in the best interest of the University to do so.

2.1.9 No verbal proposals or verbal modifications will be considered. An Offeror may modify its proposal in writing prior to the RFP closing time. A written modification must include the date and signature of the Offeror or its authorized representative.

2.1.10 All data provided by the University in relation to this RFP represents the best and most accurate information available at the time of RFP preparation. Should any data later be discovered to be inaccurate, such inaccuracy will not constitute a basis for Contract rejection or Contract amendment by an Offeror.

LF14-057 Page 6 of 68 5/7/2023

2.1.11 All proposal concepts and material submitted becomes the property of the University and will not be returned to Offeror. Award or rejection of a proposal does not affect this right. Proposals and supporting documentation may be available for public inspection upon written request following the announcement of a Contract award, except for information specifically labeled on each separate page as a “trade secret” under the Idaho Public Records Act, Section Title 74, Chapter 1, Idaho Code (“the Act”). Alternatively, information may be specifically labeled “exempt” from public records under another exemption found in Act. Information specifically labeled as trade secret or otherwise exempt may be protected from disclosure, but only to the extent consistent with the Act or otherwise applicable federal or state law or regulation. Accordingly, the University cannot guarantee its confidentiality.

2.1.12 An appeal by an Offeror of a specification, a non-responsiveness determination, or the award is governed by the Boise State University Purchasing Appeals Process, and must be filed in accordance with that process, which can be found on the Internet at http://vpfa.boisestate.edu/purchasing/purchasing-procedures/

2.1.13 Proposal opening will be held at the location and time as indicated in Section 1.1 of this RFP. All Offerors, authorized representatives and the general public are invited, at their own expense, to be present at the opening of the proposals. During the proposal opening only the names of the Offerors will be provided.

2.2 Proposal Format

2.2.1 These instructions describe the format to be used when submitting a proposal. The format is designed to ensure a complete submission of information necessary for an equitable analysis and evaluation of submitted proposals. There is no intent to limit the content of proposals. Evaluation points may be deducted from the Offeror’s possible score if the following format is not followed.

2.2.2 Any qualified Offeror may submit a proposal. All Offerors are qualified unless disqualified. Those Offerors presently on the General Service Administration’s (GSA) “list of parties excluded from federal procurement and non-procurement programs” may be disqualified. Information is available on the Internet at: https://www.sam.gov/portal/SAM/##11

2.2.3 Offerors must adhere to all requirements of this RFP to be considered responsive. The determination of whether a proposal is responsive is a determination made solely by the University. The University reserves the right to waive any nonmaterial variation that does not violate the overall purpose of the RFP, frustrate the competitive bidding process, or afford any Offeror an advantage not otherwise available to all Offerors.

2.2.4 Proposals must demonstrate that Offerors have the ability to complete the described functions of this RFP.

2.2.5 Sections of the format may be listed with an Evaluated Requirement.

Evaluation Code - The codes and their meanings are as follows:

LF14-057 Page 7 of 68 5/7/2023

(M) Mandatory Specification or Requirement - failure to comply with any mandatory specification or requirement may at the sole discretion of the University render Offeror’s proposal non-responsive and no further evaluation will occur. Offeror must indicate whether their proposed system can perform the requirement listed.For any specifications or requirements listed as (M), your proposed system must have these functions currently in production.

(ME) Mandatory and Evaluated Specification - failure to comply/respond may render Offeror’s proposal non-responsive and no further evaluation will occur. Offeror is required to respond to this specification with a statement outlining its understanding and how it will comply. Points will be awarded based on predetermined criteria. For any specifications or requirements listed as (ME), your proposed system must have these functions currently in production.

NOTE: If any requirement listed as (M) or (ME) exists in your proposed system, but is accomplished in a manner other than described in that section, Offeror MUST identify the variation and provide a complete detailed explanation of the variation. Acceptance of a variance in method to accomplish mandatory requirements is at the sole discretion of Boise State University and the evaluation committee.

(E) Evaluated Specification - a response is desired and will be evaluated and scored. If not available, respond with “Not Available” or other response that identifies Offeror’s ability or inability to supply the item or service. Failure to respond will result in zero (no) points awarded for this item. For any requirement coded as (E), which require the Offeror to develop functionality to meet that requirement or specification, please list the estimated time and cost with your response to that specification. Do not include the cost of developing new functionality in your Cost Proposal. For specifications coded (E) for which the specification or requirement already exists, and is offered in your proposed system, those costs must be included in your Cost Proposal.

2.2.6 (M) In order to be considered for award, the sealed proposal must be delivered to the location and attention of the buyer specified in Section 1.1 of the RFP, no later than the date and time specified in Section 1.1 of the RFP. No late proposals will be accepted. A proposal received at the office designated in this RFP after the RFP closing date and time will not be accepted.

2.2.7 The proposals must be addressed to the RFP Lead and clearly marked “RFP LF16-057 Parking Management System”.

2.2.8 All costs incurred in the preparation and submission of a proposal in response to this RFP, including, but not limited to Offeror’s travel expenses to attend the pre-proposal conference, proposal opening and presentation or negotiation sessions, shall be the sole responsibility of Offerors and will not be reimbursed by the University.

2.3 Submission Requirements

2.3.1 (M) The proposal must be submitted with the University–supplied signature pages in the form provided, without modification. The Signature Page must contain an original, handwritten signature and be returned with the relevant RFP documents. PHOTOCOPIED SIGNATURES or FACSIMILE SIGNATURES are NOT

LF14-057 Page 8 of 68 5/7/2023

ACCEPTABLE. Failure to include a signed, complete, unmodified, original University Signature Page will result in a finding that the proposal is non-responsive, and no further consideration will be given to the proposal.

2.3.2 Each proposal must be submitted with one (1) original and six (6) copies of the Business

and Scope of Work Proposal and one (1) original and one (1) copy of the Cost Proposal.

2.3.3 In addition, Offerors must submit one (1) electronic copy of the proposal on USB device. Word or Excel format is required. The only exception will be for financials or brochures. The format and content must be the same as the manually submitted proposal. The electronic version must NOT be password protected or locked in any way. Please attach the USB device to the original version of the Business and Scope of Work Proposal. The USB device may contain the original electronic copy in Word or Excel format, as well as the redacted version as requested in Section 2.3.5 and 2.3.6 of the solicitation. The electronic file name of the redacted version should contain the word “redacted.”

2.3.4 The Idaho Public Records Law, Idaho Code Sections 74-101 through 74-126, allows the open inspection and copying of public records. Public records include any writing containing information relating to the conduct or administration of the public's business prepared, owned, used, or retained by a State Agency or a local agency (political subdivision of the state of Idaho) regardless of the physical form or character. All, or most, of the information contained in your response will be a public record subject to disclosure under the Public Records Law. The Public Records Law contains certain exemptions. One exemption potentially applicable to part of your response may be for trade secrets.

Trade secrets include a formula, pattern, compilation, program, computer program, device, method, technique or process that derives economic value, actual or potential, from not being generally known to, and not being readily ascertainable by proper means by other persons and is subject to the efforts that are reasonable under the circumstances to maintain its secrecy. If you consider any material that you provide in your Bid, Proposal or Quotation to be a trade secret, or otherwise protected from disclosure, you MUST so indicate by marking as “exempt” EACH PAGE containing such information. Marking your entire Bid, Proposal or Quotation as exempt is not acceptable or in accordance with the Solicitation or the Public Records Law and WILL NOT BE HONORED. In addition, a legend or statement on one (1) page that all or substantially all of the response is exempt from disclosure is not acceptable or in accordance with the Public Records Law and WILL NOT BE HONORED.

Prices that you provide in your Bid, Proposal or Quotation are not a trade secret. The State, to the extent allowed by law and in accordance with these Solicitation Instructions, will honor a designation of nondisclosure. Any questions regarding the applicability of the Public Records Law should be addressed to your own legal counsel PRIOR TO SUBMISSION of your Bid, Proposal or Quotation.

2.3.5 If your Bid, Proposal or Quotation contains information that you consider to be exempt, you must also submit an electronic redacted copy of the Proposal with all exempt information removed or blacked out. The State will provide this redacted Bid, Proposal or Quotation to requestors under the Public Records Law, if requested. Submitting Offerors must also:

LF14-057 Page 9 of 68 5/7/2023

2.3.5.1 Identify with particularity the precise text, illustration, or other information contained within each page marked “exempt” (it is not sufficient to simply mark the entire page). The specific information you deem “exempt” within each noted page must be highlighted, italicized, identified by asterisks, contained within a text border, or otherwise be clearly distinguished from other text or other information and be specifically identified as “exempt.”

2.3.5.2 Provide a separate document with your Bid, Proposal or Quotation entitled “List of Redacted Exempt Information,” which provides a succinct list of all exempt material noted in your Bid, Proposal or Quotation. The list must be in the order in which the material appears in your Bid, Proposal or Quotation, identified by Page#, Section#/Paragraph#, Title of Section/Paragraph, specific portions of text or other information; or in a manner otherwise sufficient to allow the University to determine the precise material subject to the notation. Additionally, this list must identify with each notation the specific basis for your position that the material be treated as exempt from disclosure.

2.3.5.3 Offeror shall indemnify and defend the University against all liability, claims, damages, losses, expenses, actions, attorney fees and suits whatsoever for honoring a designation of exempt or for the Offeror’s failure to designate individual documents as exempt. The Offeror’s failure to designate as exempt any document or portion of a document that is released by the University shall constitute a complete waiver of any and all claims for damages caused by any such release. If the University receives a request for materials claimed exempt by the Offeror, the Offeror shall provide the legal defense for such claim.

2.3.6 Alternately, if there is no redacted information in the proposal, please note that with the proposal.

2.3.7 The proposal must be separated into two (2) distinct sections: 1) Business and Scope of Work Proposal and 2) Cost Proposal.

2.3.7.1 The Business and Scope of Work Proposal must be sealed, identified “Business

and Scope of Work Portion of Proposal – RFP LF16-057 Parking Management System” and include a cover letter (see Section 2.3.10) and all other documentation related to this response, except the Cost Proposal.

2.3.7.2 The Cost Proposal must be sealed and identified “Cost Portion of Proposal – RFP LF16-057 Parking Management System.” The only document that should be included with this section is the Cost Proposal itself, Attachment 4.

2.3.8 Include in the Business and Scope of Work Proposal a Table of Contents; adequately identify the contents of each section, including page numbers of major subsections. The Table of Contents is not evaluated, and is for reference purposes only.

2.3.9 Include in the Business and Scope of Work Proposal an Executive Summary, which provides a condensed overview of the contents of the Business and Scope of Work Proposal submitted by the Offeror, which shows an understanding of the services to be performed. The Executive Summary is not evaluated, and is for summary purposes only.

LF14-057 Page 10 of 68 5/7/2023

2.3.10 (M) The Business and Scope of Work Proposal must include a cover letter on official letterhead of the Offeror, the Offeror’s name, mailing address, telephone number, facsimile number, and name of Offeror’s authorized agent including an email address. The cover letter must identify the RFP Title, RFP number and all materials and enclosures being forwarded collectively as the response to this RFP. The cover letter must be hand signed, in ink, by an individual authorized to commit the Offeror to the work proposed. In addition, the cover letter must include:

2.3.10.1 Identification of the Offeror’s corporate or other legal entity. Offerors must include their tax identification number. The Offeror must be a legal entity with the legal right to contract.

2.3.10.2 A statement indicating the Offeror’s acceptance of and willingness to comply with the requirements of the RFP and attachments, as may be amended.

2.3.10.3 A statement of the Offeror’s compliance with affirmative action and equal employment regulations.

2.3.10.4 A statement that the proposal was arrived at independently by the Offeror without collusion, consultation, communication, or agreement with any other Offeror as to any matter concerning pricing.

2.3.10.5 A statement that Offeror has not employed any company or person other than a bona fide employee working solely for the Offeror or a company regularly employed as its marketing agent, to solicit or secure this Contract, and that it has not paid or agreed to pay any company or person, other than a bona fide employee working solely for the Contractor or a company regularly employed by the Contractor as its marketing agent, any fee, commission, percentage, brokerage fee, gifts or any other consideration contingent upon or resulting from the award of this Contract. The Offeror must affirm its understanding and agreement that for breach or violation of this term, the University has the right to annul the Contract without liability or, in its discretion, to deduct from the Contract price the amount of any such fee, commission, percentage, brokerage fee, gifts or contingencies.

2.3.10.6 A statement naming the firms and/or staff responsible for writing the proposal.

2.3.10.7 A statement that Offeror is not currently suspended, debarred or otherwise excluded from federal or state procurement and non-procurement programs.

2.3.10.8 A statement affirming the proposal will be firm and binding for one hundred twenty (120) days from the proposal opening date.

2.3.11 (M) Offeror must submit with its response all documents and/or agreements that the Offeror proposes to have incorporated into any resulting Contract including any proposed modifications to the Terms and Conditions reserved for further negotiation, in accordance with Section 2.1.4. If Offeror expressly conditions its proposal upon the University’s acceptance of its additional documents and/or proposed agreements or modifications to the Terms and Conditions, its proposal may be deemed non-responsive. The terms of such additional documents and proposed agreement and modifications to the Terms and Conditions the University reserved for negotiation may be considered in

LF14-057 Page 11 of 68 5/7/2023

accordance with Section 3.4 of this RFP, but no additional or modified terms shall be binding on the University until expressly accepted in writing by the University.

Alternately, if the offeror has no additional documents or proposed agreements they wish to submit for consideration, please note that in response to this specification.

The University will not accept any documents and/or proposed agreements submitted after the Solicitation’s closing date. The University will not accept any additional proposed modifications to the Terms and Conditions or terms that conflict with the Terms and Conditins after the Solicitation’s closing date. If Offeror attempts to submit additional documents and/or proposed agreements after the Solicitation closing date, and conditions its Proposal upon the University’s acceptance of those additional documents and/or proposed agreements, its Proposal may be deemed non-responsive and given no further consideration.

The University will not accept terms that allow Offeror to make unilateral amendments to any resulting Contract or terms that require the University to indemnify another party.

2.3.12 (M) If the RFP is amended, including through the question and answer process, the Offeror must acknowledge each amendment with a signature on the acknowledgement form provided with each amendment. Failure to return a signed copy of each amendment acknowledgement form with the proposal may result in the proposal being found non-responsive. See the Boise State University Purchasing website (http://vpfa.boisestate.edu/purchasing/) and “Bidding Opportunities” for any amendments and the required amendment confirmation document.

3. CONTRACT

3.1 The RFP, all attachments, appendices, and amendments, the successful Offeror’s proposal submitted in response to the RFP and any negotiated changes to the same will become the Contract (hereinafter referred to as the “Contract”).

3.2 State of Idaho Standard Contract Terms and Conditions:      The State of Idaho’s “Standard Contract Terms and Conditions” and the State’s “Solicitation Instructions to Vendors” are incorporated by reference into and shall apply to this solicitation and any contract resulting from this solicitation. The State’s “Special Terms and Conditions for Customized Software and Related Services” may also apply, if customized software is proposed.  Offerors are encouraged to review these documents at the following website. 

http://purchasing.idaho.gov/terms_and_conditions.html

3.3 All terms should be reviewed carefully by each prospective Offeror as the successful Offeror is expected to comply with those terms and conditions, as may be amended in accordance with Sections 2.1.4 and 3.4 hereof.

3.4 The apparent successful Offeror will be asked to engage in discussions to finalize the agreement. Such discussions will include discussion of the legal terms and conditions, including any additional agreements submitted by the Offeror as required by Section 2.3.11 and any proposed modifications to the Terms and Conditions, submitted in accordance with Section 2.1.4 during the question and answer period. Should the

LF14-057 Page 12 of 68 5/7/2023

apparent successful Offeror and the University fail to reach an agreement within a reasonable timeframe, the University may elect to end the discussion with the top scoring Offeror and begin a discussion with the Offeror whose response ranked second.  Upon successful completion of the discussions, the winning Offeror will be required to execute a contract with the University, and immediately begin preparations to undertake its requirements. 

3.5 Where Offeror agreements and assumptions, specified in the Offeror’s response, differ from the Terms and Conditions, or the terms and conditions of this Solicitation, the Terms and Conditions and the terms and conditions of this Solicitation shall apply and supersede, unless such different terms are expressly agreed to by the University in writing.  Where Offeror agreements and assumptions supplement the Terms and Conditions and Related Services (if specifically identified as applicable to this solicitation), or the terms of this Solicitation, the supplemental terms and conditions shall apply only if specifically accepted by the University in writing.  Where unsolicited supplemental documents, including unsolicited pricing sheets, are submitted, the University reserves the right to deem the proposal non-responsive if the supplemental documents conflict with the specifications of this solicitation.  Supplemental documents shall be considered as reference materials only, and nothing contained within a supplemental document shall be deemed as accepted by the University, unless accepted by the University in writing.  Offerors are cautioned against the use of supplemental documents.  Conflicting supplemental documents may lead to the response being deemed non-responsive, and no consideration of the response given.  It is recommended that Offerors review the State’s Solicitation Instructions to Vendors, Clause 18 at the following website.

http://purchasing.idaho.gov/terms_and_conditions.html

To the extend the terms of such agreements, once accepted by the University, conflict with the State of Idaho Standard Terms and Conditions or other terms and conditions of this RFP, any conflict or inconsistency shall be resolved in accordance with Clause 18 of the State of Idaho Standard Terms and Conditions.

3.6 The Contract, in its incorporated composite form, represents the entire agreement

between the Contractor and University and supersedes all prior negotiations, representations, understandings, or agreements, either written or oral.

3.7 Finalization of the Contract documents may require additional time for review from the Office of Information Technology and Office of General Counsel. Additionally, the Office of General Counsel may review and negotiate agreements, prior to the finalization of a contract in accordance with Section 3.4.

3.8 The Contract is not effective until Purchasing has issued a purchase order specifying a commencement date (the “Effective Date”), and that date has arrived or passed. The Contractor will not provide or render services to the University under this Contract until the Effective Date. The University may determine, in its sole discretion, not to reimburse the Contractor for products provided or services rendered prior to the Effective Date.

3.9 Prior to the release of the Contract, University and the apparent successful Offeror will clarify expectations and develop a Project Management Plan for the implementation of the service.

LF14-057 Page 13 of 68 5/7/2023

3.9.1 The Project Management Plan shall include a project schedule/timeline, (tasks that require more than 20 hours of work), and major deliverables.

3.9.2 The Project Management Plan shall include a description for each task and a designation of whether Boise State or the Offeror is responsible for the task.

3.9.3 Additionally, the Project Management Plan will contain all points of clarification, an agreed upon Project Schedule for the implementation of the service, and other clarifying supporting documents. Examples of points of clarification are clarification of requirements and legal clarifications. Examples of other clarifying supporting documents are risk management plan, change management plan, configuration management plan, and project closure plan.

3.9.4 Upon a mutually agreed upon Project Management Plan, an award will be made, a Contract put in place, and implementation of the System can begin.

3.9.5 Once the Contract is in place, all modifications to the Project Management Plan must be reviewed and approved by the University in writing.

3.10 Acceptance: In addition to the acceptance terms detailed in the State of Idaho Standard Contract Terms and Conditions, acceptance from the University will be based upon the completion of tasks and deliverables as agreed upon by the University and Contractor in the Project Management Plan.

3.11 End of Strategic Life/Termination of Contract Processes. Termination shall be in accordance with Clause 2 of the State of Idaho Standard Contract Terms and Conditions, found at http://purchasing.idaho.gov/terms_and_conditions.html

3.12 Upon any termination of the Contract, Contractor shall return to the University all copies of the Confidential Information or other materials incorporating Confidential Information in the possession of Contractor or its employees. Contractor agrees to:

3.12.1 Return all data that is the property of the University in a reasonable format specified by the University;

3.12.2 Return all property in any form belonging to the University;

3.12.3 Return all confidential information that may have been received from the University. Provide the ability for University to electronically retrieve data and documents from Contractor’s system, as this data is owned by University.

3.12.4 Deliver to Boise State, within 6 weeks, all data and documents from Contractor’s system that pertain to Boise State. This data must be delivered in an electronic format.

3.12.5 The University will verify receipt of that data.

3.13 Notwithstanding termination, the restrictions on disclosure and use of Confidential Information arising under the Contract shall continue to be effective after the date of termination.

LF14-057 Page 14 of 68 5/7/2023

3.14 Upon expiration or termination of the Contract, the obligations of the parties to each other shall come to an end, except those provisions which are intended to survive and continue, which shall include, but shall not be limited to, provisions relating to confidentiality, indemnification, and insurance requirements contained in the Contract.

4. BUSINESS INFORMATION

4.1 (ME) Experience - Describe in detail your knowledge and experience in providing services similar to those required in this RFP. Include business history, description of current service area, and customer base. Specifically, include experience in other higher education institutes within the last three (3) years. Additionally, provide information about the number of system deployments that your company has implemented at higher education institutions, how long those systems have been in use, and what percentage of your business higher education constitutes. Include in this description where you have successfully implemented an Event Scheduling module to your system and how long this module has been in operation.

4.2 (ME) Qualifications - Describe your qualifications for successfully completing the requirements of the RFP. To demonstrate your respective qualifications, the following are required:

4.2.1 Staffing Plan - Offerors should provide a detailed staffing plan with a chart showing all technical and functional roles that will be provided by the respondent to carry out the work of the ensuing contract. Offerors should also provide a plan of technical and functional roles and an estimate of total hours that need to be provided by Boise State. Offerors should explain how the workflow will occur using the staffing plan based on the requirements of this RFP.

4.2.2 Escalation Plan - Offeror must provide an Escalation Plan describing the response time and escalation procedure. The Escalation Plan must provide the name(s) of the personnel who will handle the escalation process for the resulting Contract. Upon award, the University may require an Escalation plan including name, title/position, contact phone, fax and email.

4.3 (E) References

For evaluation purposes, using Attachment 3, “References,” provide three (3) completed, written professional references from universities (preferred) or companies where the proposed System has been in operational for a minimum of one (1) year.

Offeror s must follow the instructions in Attachment 3, “References,” to obtain those references.

4.4 (ME) Project ScheduleProvide a Project Schedule that includes criteria listed in Section 3.9, Project Management Plan, above. Ability to deliver and complete installation as requested will be a component of the award. See Section 6.27.1 for the University’s preferred Go-Live date.

LF14-057 Page 15 of 68 5/7/2023

5. SPECIAL TERMS AND CONDITIONS

5.1 Notwithstanding any other term in the State of Idaho Standard Contract Terms and Conditions, State of Idaho Solicitation Instructions To Vendors, State of Idaho Special Terms and Conditions for Customized Software and Related Services, (available at: http://purchasing.idaho.gov/terms_and_conditions.html and or the Offeror’s Proposal, the following warranties shall apply to the Contract. Offeror represents and warrants that:

5.1.1 Contractor has the full power and authority to enter into the Contract, grant the University any license offered in its proposal, and has the full power and authority to grant to the University access to the System, and to produce all required functionality as specified in the Contract.

5.1.2. The System and required services are fit for the particular purpose of providing the requirements specified within the Contract, and all amendments to the Contract as agreed to and accepted by both the University and the Contractor. Furthermore, the Contractor warrants that the System is merchantable.

5.1.3 The System is compatible with the software, hardware, and telecommunications environment specified within the Contract, and all amendments to the Contract as agreed to and accepted by both the University and the Contractor. Incompatibility will include but not be limited to, the creation of errors in data, the loss of data, the inability to access data, and delays and stoppages in performance of work by the Contractor or the University arising from the System.

5.1.4 The System, in whole and in part, will operate within the defined hardware and telecommunications environments of the Contract and in accordance with the specifications of the Contract established by the University, and be free from defects during the term of the Contract.

5.1.5 The System will perform without the creation of errors in University data, the loss of University data, the inability to access University data, the inability to input University data, and delays and stoppages in performance due to data collection, data corruption, or loss.

5.1.6 Contractor shall repair or replace, within a commercially reasonable time unless otherwise specified in this solicitation and at its sole cost and expense, any portion of the System failing to comply with the warranties granted in this section during the warranty period offered by Contractor. If the Contractor fails to repair or replace such portion of the System within the required time, the University may, in its sole discretion, act to repair or replace all or a portion of the System or re-perform the services and the Contractor shall reimburse the University for all costs incurred by the University to repair or replace the System or to re-perform the services.

5.1.7 Contractor will perform all services required pursuant to the Contract in a professional manner, and with high quality.

LF14-057 Page 16 of 68 5/7/2023

5.1.8 The System, in whole or in part, does not infringe upon an enforceable patent, copyright, trade secret, trademark or other proprietary right. The Contractor knows of no action or proceeding of any kind pending, or to its knowledge, threatened against, by or affecting it or the software used to provide the service or any documentation, which if decided, is adverse to the Contractor, and could adversely affect the Contractor’s ability to perform or complete its obligations under this Contract.

5.2 Boise State University’s registered trademarks, as well as other names, seals, logos, college colors and other indicia (“University Marks”) that are representative of the University may be used solely with permission of Boise State University. Notwithstanding the foregoing, the University logo may be used in the RFP response for illustrative purposes only. No use may be made of University Marks in any document which implies any association with or endorsement of the services of the Offeror or any other third party.

5.3 The University shall own and retain all rights to information, techniques, processes and data developed, documented, derived, stored, installed or furnished by the University under the Contract.

5.4 The Contractor and System must comply with all federal, state and local laws and regulations, statutes and codes. The System must comply with the federal, state and local laws and regulations governing the privacy and protection of educational records, including but not limited to the Family Education Rights and Privacy Act (FERPA).

5.5 The Contractor shall comply at all times with appropriate data security of information, as applicable, as defined by the Family Education Rights and Privacy Act (FERPA) and the Health Insurance Portability and Accountability Act (HIPAA).

5.6 The Contractor warrants that at all times for the term of the Contract, Contractor will comply with all posted and applicable, active Idaho Executive Orders as posted at http://gov.idaho.gov/mediacenter/execorders/.  Contractor further warrants that at all times for the term of the Contract, Contractor’s offered property as defined by Idaho Code will comply with all applicable Idaho Technology Authority Standards as posted at http://ita.idaho.gov/resources.html/.

5.7 If there is theft or misappropriation of the University’s confidential information which is due to the negligence or intentional misconduct of Contractor or due to the Contractor’s failure to comply with applicable provisions of HIPAA, FERPA or corresponding regulations, Offeror shall provide the University written notice of theft or misappropriation within 24 hours of when theft or misappropriation becomes known to Offeror. In the event of a breach of any of the Contractor’s data security obligations or other event requiring notification under applicable State and Federal law, the Contractor must assume total financial liability incurred by such breach and subsequent notifications. In addition the Contractor must assume responsibility to indemnify, hold harmless and defend Boise State University, its officials, and employees from and against any claims, damages, or other harm related to such theft or misappropriation. Boise State will have six (6) months from the date of receipt of written Notice from Offeror of the theft or misappropriation to provide written notice to the Offeror of its intent to terminate, and to terminate, this Contract. If the University elects to terminate this Contract pursuant to

LF14-057 Page 17 of 68 5/7/2023

this section, Offeror will have no right to cure the breach of this Contract in order to prevent Boise State from terminating the Contract.

5.8 Unless otherwise allowed by the University in this Contract, the Contractor shall not, without written approval from the University, enter into any subcontract relating to the performance of this Contract or any part thereof. Approval by the University of Contractor’s request to subcontract or acceptance of or payment for subcontracted work by the University shall not in any way relieve the Contractor of any responsibility under this Contract.  The Contractor shall be and remain liable for all damages to the University caused by negligent performance or non-performance of work under the Contract by Contractor’s sub-contractor or its sub-contractor.

5.9 The Contractor hereby agrees to be bound by the terms and conditions of Section 504 of the Rehabilitation Act of 1974 and to the applicable provisions and requirements of the Americans with Disabilities Act of 1990, as may be amended or modified from time to time, and as such provisions are applicable to the University. The Contractor shall comply with pertinent amendments to such laws made during the term of the Contract and with all federal and state rules and regulations implementing such laws. If applicable, the Contractor must include this provision in every sub-contract relating to this Contract. Specifically, Contractor hereby agrees to use good faith efforts to ensure that the System is fully accessible for individuals with disabilities and enables the University to fully comply with all applicable requirements of the aforementioned laws, regulations, and requirements.

In the event the System fails to meet the requirements of this section, the University shall provide written notice to Contractor detailing requirements to bring System into compliance. If Contractor fails to correct the deficiency and enable the University to fully comply with the laws, regulations and requirements set forth herein as detailed in such notice within thirty (30) days of receiving such notice, the University may elect to terminate this Contract without further notice and without penalty. In the event the University terminates the Contract under this section, Contractor agrees to compensate the University for all costs associated with securing a replacement that fully complies with the requirements set forth herein, payable upon receipt of an invoice from the University detailing such costs.

5.10 The Contractor and its sub-contractors are required to carry the types and limits of insurance shown at http://rmi.boisestate.edu/wp-content/uploads/2014/11/CertificateInsRqmts_3rdParty.pdf on the Boise State University Office of Risk Management & Insurance web page. Contractor is required to provide the University with a Certificate of Insurance within ten (10) days of contract signing.

5.11 (ME) Section 508 Amendment to the Rehabilitation Act of 1973 – Offeror must be in complete compliance with Section 508 Amendment to the Rehabilitation Act of 1973. Complete and return the Volunteer Product Accessibility Template (VPAT) located at http://www.state.gov/m/irm/impact/126343.htm with your completed response.

5.12 (M) Awarded Contractor must be in compliance with SSAE 16. A copy of last year’s Statement on Standards for Attestation Engagements (SSAE) No. 16 SOC Type II report will be required prior to contract signing for the winning Offeror (vendor).

LF14-057 Page 18 of 68 5/7/2023

5.13 The Software and any media used to distribute it contain no computer instructions, circuitry or other technological means (“Harmful Code”) whose purpose is to disrupt, damage or interfere with University’s use of its computer and telecommunications facilities for their commercial, test or research purposes. Harmful Code shall include, without limitation, Viruses, Worms, Trap Doors, Trojan Horses, bombs, and any other instrumentality that will cause the Software to cease to operate or to fail to conform to its specifications upon (i) use by more than the licensed number of users or (ii) termination or expiration of this Contract; unless otherwise expressly provided herein. Licensor shall indemnify Boise State and hold Boise State University harmless from all claims, losses, damages and expenses, including attorneys’ fees and allocated cost of internal counsel, arising from the presence of Harmful Code in or with the Software or contained on media delivered by Licensor.

5.14 The System and all software comprising the System must be operational in a verifiable customer live production environment, providing service for no less than ninety (90) production days (production days does not include training or testing), prior to the release date of the RFP.

5.14.1 The University may verify that the System meets these requirements, and any system found not to meet these requirements may result in the Offeror’s proposal being found non-responsive and no further consideration given.

5.14.2 Specifically, the University reserves the right on a Pass/Fail basis, to confirm and verify all software versioning, functionality, and requirements mandated in the RFP, and to do so in an Offeror’s customer’s live production site of the University’s own choosing. If the University verifies that the software version proposed is not the software version currently in production, or fails to meet the required time in production, the Offeror’s proposal may be found non-responsive and no further consideration given. PROPOSED SOFTWARE VERSION NUMBERS MUST BE INCLUDED IN RESPONSE.

5.14.3 Operational in a verifiable production environment will mean:

5.14.3.1 The version of the software proposed by the Offeror is being used;

5.14.3.2 The software is used by an organization other than the Offeror in the normal course of such organization’s business;

5.14.3.3 The software is not used in a testing or otherwise reduced capacity; and, 5.14.3.4 All the mandatory software operational functionality specified in the RFP

is in use by such organization. 

6. SCOPE OF WORK

Use this proposal outline as part of your response to the RFP, and identify it as Appendix A Scope of Work. Keep in mind, the evaluators will be evaluating on the methodologies proposed and the completeness of the response to each of the services listed below.

LF14-057 Page 19 of 68 5/7/2023

6.1 GENERAL REQUIREMENTS

6.1.1 (M) The Parking Management and Revenue Control System must include the following system options that will be capable of interfacing with existing University software systems and between each module of the system. It must be configured to meet the University’s business requirements for standard and event parking. 1. License Plate Recognition Camera System2. Online Parking Permit System (customer facing)

2.1 Parking Permit System 3. Event Parking Reservation4. Transaction Processing System (Accounting)5. Enforcement (Policy Enforcement)

6.2. HOSTING SPECIFICATIONS

The University’s Transportation and Parking Services Department operation and communication system functions are supported by the University’s Office of Information Technology (OIT). OIT provides support for applications, network, systems, desktops, and telephones. OIT provides the following platforms: Vmware, Windows and Linux server platforms and Oracle databases.

6.2.1. (M) Contractor cloud hosted system required. Cost of hosting must be included in proposer’s total cost in COST PROPOSAL, ATTACHMENT 4.

6.2.2. (M) For Contractor hosted software systems, Contractor will provide all servers, services, storage, security, access, backup/recovery for production and test environments.

6.2.3. (E) Please describe in your response: what cloud servers and services you use, what backup/recovery protocols are in place, what remote access levels to database system are available for system admins.

6.2.4. (M) For Contractor hosted solution the Contractor must install and manage software upgrades and perform routine application maintenance.

6.3.1.1. (ME) Describe the process of integrating the System with PeopleSoft.

6.3.1.2. (ME) Describe the technologies used to integrate the System with PeopleSoft.

6.2.5. (E) Boise State University prefers a Contractor who will provide a test system for Boise State to utilize in addition to the production system. If respondent provides a test system, please provide appropriate descriptions of usage and functionality.

6.2.6. (ME)SaaS System: Submit response in Attachment 5, “Externally Hosted Vendor Security Assessment Form.”

LF14-057 Page 20 of 68 5/7/2023

6.3. REDUNDANT SPECIFICATIONS

This section will cover specifications that Boise State University is requesting across multiple software modules. They will be described here in order to be scored only once and to ensure all are met, due to their importance to University functions. We require the functionalities listed in these specifications be present in the software modules indicated

6.3.1 (M) Offeror software must provide an audit trail, please describe your system’s audit trail within all included software modules.

6.3.1.1 (ME) University requires all audit trails include these items at minimum: user, date, time, associated account identifier where the change took place, and information relating to what was changed, this information will be specific to the module in which the change was made and where the audit trail is being viewed from:Such as tender type, amount, letter type, citation type, past due account notice type, vehicle information changed, address information changed, email type, access to letter type, and so on encompassing applicable fields to the respective module. Please describe your system’s capabilities.

6.3.1.2 (ME)This audit trail must have the ability to track payments by type (cash, check, money order, credit card, Bronco Bucks, etc.) in at least, but not limited to: the customer, permit, and financial modules of the Offeror’s software. Please describe your system’s capabilities.

6.3.1.3 (ME) All changes, adjustments, credits, and payments made to any account must create a record in audit trail with the University user’s identifier, date, time stamp and reason code for the adjustment and the audit trail record must not be user-alterable. The record must be included in an associated Offeror software report for transactions completed within parameters of the search criteria. Please describe your system’s capabilities.

6.3.1.4 (ME) This audit trail also needs to include functionality that will track changes to customer, permit, and vehicle modules. Any time a University user or customer within the software completes a change to any customer, permit, or vehicle related information (contact address, email address, phone number, and any other associated similar information in the customer module, and any permit attachments to vehicles based on addition of new vehicle descriptor information such as a new license plate) the software audit trail must include the above applicable defined terms in (6.3.1. and subsections ) in this specific module audit trail. Please describe your system’s capabilities.

product purchase date valid dates

any changes to permit valid dates by user university user processing transaction (when in office)

separately defines when customer purchases through website vehicle connections to permit

LF14-057 Page 21 of 68 5/7/2023

added (by specification of data logged defined in 6.3.1. and subsectionsdropped (by specification of data logged defined in 6.3.1 and subsections.

6.3.2 (E) The University would like the additional specification if Offeror’s system has the capability to have an audit trail system that will allow the entry of data to document when the customer picks up their permit including standard audit trail posting of date/time/user. This will be used when the purchase and pick up dates are different, I.e. during early renewals or if customer purchases online and wants to pick up the permit instead of having it mailed. Or being able to document when an office worker puts a customer’s permit in the mail. Please describe your system’s capabilities.

6.3.2.1 (E)The Audit trail needs to contain any information applicable to contact made to a customer including but not limited to: any letters or emails of correspondence to individual customers, mass communications from the department to multiple users, notifications of citations, notifications of past due balance, notifications of scofflaw on account, parking advisories sent via mass-email in system shown in individual customer account, any other communications sent to customer’s account with or without permit, and including any other correspondence sent by Offeror system must be included in the audit trail with defined terms in 6.3.1. and subsections. Please describe your system’s capabilities.

6.3.2.2 (E)Direct access to letter history/communication audit trail from the applicable modules (examples: customer communication in customer account, invoice/receipt communications from order information screen) must be provided as well as storing a copy of the letter in the history. Please describe your system’s capabilities.

6.3.2.3 (E)This access must include the ability to view within the system the exact message/content of letter that was sent to any individual customer, date printed or emailed, system user, method of delivery (paper or email).(Storing means ability to access the letter content that was sent to the customer with original information at a later date after printing from the customer’s account) Please describe your system’s capabilities.

6.3.3 (ME) Ability to provide some form of comments or notes of explanation, and the ability to upload attachments. Please describe your system’s capabilities.

Notes sections need to be within the Offeror’s system software modules, at minimum. The ability to upload attachments must be included at least at the root level (meaning in association to a specific customer/permit/vehicle/order/etc) of each of these modules):

6.3.3.1. Customer Account6.3.3.2. Vehicle 6.3.3.3. Citations and Appeals6.3.3.4. Permit

LF14-057 Page 22 of 68 5/7/2023

Permit order Permit Permission

6.3.3.5. FinancialExtensive “notes” field on each cashier closeout report (e.g. to Indicate why there are discrepancies between the expected balance and the actual balances)Customer Order Transaction (entire transaction or line item within transaction). If Transaction and Customer Order notes sections overlap this will be accepted)

6.3.3.6. Refunds6.3.3.7 Payroll deduction plans on customer account

6.3.4 (E) University also prefers the ability to make notes at the transaction or receipt level The attachment of scanned documentation and digital images as well as other electronic items within listed (above) modules and ability to view attachments from the record itself is required. In response please include details of total amount of attachments per record allowed, and how they are held for long term data storage.

6.3.5 (M) System must both import and export files in tab delimited, LST, CSV, .PDF formats. This should be able to import and export files into or from the Customer, Financial, and Reporting modules. Software must be able to accept imports of updated customer account information and process these updates into the corresponding customer accounts. In the Financial module the software must be able to accept imports of files to process multiple payments to multiple accounts at one time, for example a payroll deduction register uploaded to post a single partial payment into the correct corresponding accounts. In the Reporting module, the software must be able to export any report created.

6.3.5.1. (ME) The system must be configurable for setting the download location of exports to any University storage location. Please describe how these parameters are set.

6.3.5.2. (ME) Please describe system functionality for creating and customizing queries and reports which can be exported to csv, tab delimited, LST and PDF formats.

6.3.5.3. (ME) Please describe system functionality for uploading manual imports from csv, tab delimited, and LST formats, and how the records will be dispersed into the system

6.3.5.4. (E) Please describe if and how your system checks to prevent incorrect associations from this upload process.

6.3.5.5 (E) If your system has the ability to ‘rollback’ or revert data from an incorrectly formatted upload document, please include the details of this process as well.

6.3.5.6. (E) University prefers system with automatic task controls which can control the automatic import and export of files in tab delimited, LST, CSV format. These files would be exported to or imported from a University shared storage location via SFTP. University prefers this specification have University controlled parameters and the ability to have multiple

LF14-057 Page 23 of 68 5/7/2023

tasks. Please detail the proposed system’s ability to use automatic task controls of this nature.

6.3.5.7 (E) Please indicate availability and describe software functionality to create a customized query and a preinstalled system report (individually respectively) for an automatically exported dataset which is run on University defined automatic settings of date, time, format, exported file format etc.

6.3.5.8. (E) Please describe software functionality which allows the ability to have an automatically scheduled report or custom query exported, in University defined format, and then emailed through proposed software (automatically) to a University defined list of recipients.

6.4 REQUIRED TECHNICAL CRITERIA

6.4.1. (M) Client access must be browser-based and must run on the most recent versions (at least N and N-1)

6.4.2 (E) Please describe if proposed software is required to be used in only a single one of: Microsoft Internet Explorer/Edge, Firefox, Safari, or Chrome

6.4.3 (M) Boise State University solution requires wifi (IEEE 802.11a/g/n) interfaces.

6.4.4 (M) The system must store all of its control and transactional information in an Oracle (11.2.X or higher) or SQL Server (MS SQL SERVER 2008 R2 or higher) database with a preference to Oracle.

6.4.5 (E) Database type, backup and recovery setup should be detailed by Offeror in response. Please describe your system’s capabilities.

6.4.6. (M) User interface and tracking ability for Transportation Services managers and staff that will allow access to all customer information. User Interface allows searches, information updates, queries, reporting and auditing capabilities.

6.4.7 (M) System to be configured to handle a minimum of fifteen (15) concurrent users for administrative staff with no significant degradation in performance.

6.4.8 (E) It is desired that the system proposed be able to work with current citation hardware and printers listed in Section 6.5.1. Indicate your ability to work with the University’s existing hardware. If University’s current hardware is not compatible with your proposed system, please list the hardware that would be required (quantity, brand, model, etc.) and the associated cost of this hardware. If the University must purchase new hardware for your proposed system, these costs MUST be listed in ATTACHMENT 4, COST PROPOSAL.

6.4.9 (M) Citations must be updated in the management software real time by cellular and/or wifi. This transfer must include both data and pictures.

LF14-057 Page 24 of 68 5/7/2023

6.4.10 (ME) System must include an online appeal system for users to submit through a website. The appeal process must allow the appellant to add evidence in forms of pictures, and/or documents supporting their appeal. Appeal settings must be customizable to University needs. Please describe your system’s capabilities.

6.4.11. (M) Ability to have multiple websites for different parts of the system. Separate or combined customer facing portals for yearly permit registration, permit ordering and customer account information management, appeals submissions.Any required websites for administrative facing functions to include all dimensions of the Offeror’s software modulesAdministrative management website for such things as customer accounts, permit settings, permit sales, inventory settings, location settings. This website must be the crux of the administrative side of the software and allow University employees to access all sections of Offeror’s software along University profile permission levels.

6.4.12. (E) The University prefers a system with customer-facing portal website which will be easily updateable by University Administrators. An example of this: system down banner or notification of the office being closed on title page; field definition manipulation to University needs on event form submissions pages, or appeal submission pages, or additional informational banners on permit selection website for ordering information. The site may also have the ability to be taken offline and online easily if needed. Explain the options for these functions that are included in your proposed system.

6.4.13. (E) The University understands the Offeror may not have the ability to control this situation when hardware and equipment is being discontinued, therefore: Describe your policies for refund, replacement, and/or discounting of equipment when the University purchases such equipment and that equipment is discontinued within one year or less. Also list your policy for equipment discontinued outside of one year from purchase.

6.4.14. (M) Offeror must make every effort to immediately notify Boise State of any discontinuation of hardware within Boise State’s inventory. Offeror’s response to include description of process for doing this.

6.5. EXISTING HARDWARE/EQUIPMENT/SOFTWARE

6.5.1. (ME)The University currently has the following hardware / equipment. Contractor should respond with compatibility with their system for each of the items listed below. Any hardware required in addition to, or in replacement of, the items listed below for a fully functional integrated system as outlined in this RFP, must be included in your cost proposal, Attachment 4.

Thirty (30) Verizon Samsung Galaxy note 3 handhelds Ten (10) Bluetooth receipt printers (Zebra Mz 220)Five (5) work station computers (Windows OS, Boise State University Image) Five (5) Cash drawers (MMF Printer Driven Cash Drawer Part# 2251516442E5)Five (5) Thermal receipt printers (Star TSP100)Three (3) Credit Card MachinesGenetec Server LPR car with four (4) Cameras set up with genetec LPR software.

LF14-057 Page 25 of 68 5/7/2023

Pay Stations25 Lukes7 Model 1 serial #100012 Model 2 serial #30006 Luke II's serial #5000IPS MetersApproximately 250 model MK 3 metersApproximately 40 in ground sensors.

6.6 INTERFACE

6.6.1 (E) University prefers software system which includes Peoplesoft integration. Please describe software integration capabilities with a Peoplesoft system. Boise State is currently running PeopleSoft 8.8 for Financials and PeopleSoft 9.0 for HCM and Campus Solutions. This refers to PeopleSoft integration that is not centered around the prior discussion of import and export via SFTP. Please describe your system’s capabilities.

6.6.2 (E) Please detail any interfacing the proposed software has with Oracle Fusion Cloud software (a future implemented solution by the University) and how this is completed.

6.6.3 (ME) Software must interface with the University’s current LPR system hardware through Genetec. How this interfacing is achieved by your specific software must be detailed in response, and will be evaluated based upon respondent’s information.

6.6.4 (ME) System must interface with current SSO (SAML 2.0 and Microsoft ADFS (Active Directory Federation Service)) system used by the University. Describe how your system accomplishes this.

6.7. AUTHENTICATION

6.7.1 (ME) Access to functions must be able to be limited by assigned user roles. Please describe how an administrator would control security and access controls within your system for lower level user roles.

6.7.2 (ME) User ID and password will be required to access the applications with lockout controls, optional auto log-off, and sign in using University Single Sign On (SSO) credentials via OIT integration. Please describe how your system will manage the functions of user account login credentials. Also whether or not your system, and via what processes, will be able to utilize the University SSO.

6.7.3 (ME) System must allow Lightweight Directory Access Protocol (LDAP) and Local account authentication. LDAP will be used for Students, Faculty & Staff. Local accounts will be used for Employees and Non Event permit requestors. Please describe your system’s capabilities.

LF14-057 Page 26 of 68 5/7/2023

6.8 SECURITY

6.8.1 (M)Segregation of duties must be an integral internal control, so that a single individual cannot have access to divert resources.

6.8.2 (ME) Shall provide essential security based on access levels. Functions and screens must not be displayed or accessible unless the user has the necessary level of security. For example: A cashier batch must only be accessible to the cashier that opened the batch and others based on security level. Shall allow for user configuration of role privileges and specific individual overrides of standard role security privilege. Security access to range from customer facing only access to full system administrator control (with respondent explanation for exceptions to this rule). Please describe your system’s capabilities.

6.9 MOBILE APPLICATIONS

6.9.1 (ME) Contractor must have a web optimized portal that users can use to access their accounts, purchase permits, and pay citations. Boise State prefers both on a desktop and a mobile version. State whether your system is capable of one or both and describe. Allows users to register and obtain parking permits online through customer facing portal by purchasing permit and registering their vehicles

6.9.2. (E) Offeror should indicate their own mobile applications for android and IOS for customer usage and any associated costs to customer for usage.

6.9.3. (E) If Offeror has mobile applications for IOS and Android available, Boise State requests SSO crossover using Boise State system credentials for login. Describe.

6.9.4 (E) Mobile application is preferred to include the ability for a user to update their account or parking permit. For example change license plate number and associated vehicle information, customer must also be able to update contact information. Describe.

6.9.5. (E) Integration with Boise State’s My Boise State mobile app is preferred. Describe your system’s ability to comply with this specification.

6.9.6 (E) Any system additional features such as: pay for parking stall or meter location through mobile app, check by gps if the customer’s permit is valid in that location, etc are requested for University understanding of available expansion features. Describe your system’s current capabilities in these mobile application areas.

6.10 FINANCIAL MANAGEMENT

The University is seeking an included financial management software module with the parking and revenue control system. This system will provide standard accounting functions including, but not limited to: payments, service fees, deposits, credits, adjustments and reversals for accounts with quick links and full detailed information displayed on screen for Parking staff and administrators with complete audit trail. Including the ability to use an account balance where money from an order can be refunded to the ‘account’ and then reapplied to a different order if needed or cashed out to the customer.

LF14-057 Page 27 of 68 5/7/2023

6.10.1 (ME) University requires direct access to financial information related to the customer. This must include, at a minimum, access to invoices, payments, adjustments, receipts, orders, within the proposed software system and shows proper relations to relevant permits, customer information, vehicle information for citations (list any items included in your system, but not included in this list). Please detail the ways in which these pieces of information are correlated between the different modules of the proposed software system

6.10.2 (ME) University requires the ability to restrict permit purchases if they do not include all University required criteria being entered during the sale. Also the ability to assign these settings specifically to a permit type, and global settings applied to all purchases.

Examples of required criteria specific to a permit type:6.10.2.1. University ID number6.10.2.2. State issued Accessibility Identifier for accessible parking permits

Examples of Global required settings6.10.2.3.System requires a license plate number and applicable vehicle registration

information be entered at time of purchase.

6.10.3.(M) Direct access to financial information related to the permit. This includes payments, adjustments, additional fees, citations, permitted vehicles. List any items included in your system, but not included in this list.

6.10.4. (ME) Ability to provide “shopping cart” style functionality. If Offeror uses a different style, please explain in response. “Shopping cart” style functionality means allowing the customer to pay for multiple product types (citation + permit, event charges + shuttle reservation, etc.) in a single transaction. Please describe your system’s capabilities.

6.10.5.(M) Ability to track all transactions by cashier regardless of cash drawer used, transaction tracking must have included, at minimum, for each transaction:

User Date Time Amount and tender type Cash drawer or terminal used Relevant permits, citations, or sold products on the transaction Any manual adjustments made during transaction Any refunded amount

6.10.6.(M) Allows posting combinations of payments, refunds, adjustments, or estimates for citations, permit sales, event invoices, NSF penalty fees, miscellaneous revenue: meter collections, pay station collections, and more as needed by University requirements.

6.10.7. (E) Capability to mark NSF check receipts, and add associated fees, with University defined standard NSF check notifications. An option to activate a “Do Not Accept Checks” feature in one easy process. Describe.

6.10.8 (M) Ability to accept and post both payments in full and partial payments

LF14-057 Page 28 of 68 5/7/2023

6.10.9. (ME)University prefers the system be able to apply credits from an existing customer balance tied to their customer account within proposed system. Including but not limited to partial payments from multiple tender types, as well as payroll deduction partial payments over defined parameters. Please describe the process your system uses for posting partial payment/adjustment back to a customer account for later use on another transaction.

6.10.9.1. Capacity to apply held monies (credits) to a customer account with complete audit trail.6.10.9.2. Ability to apply these credits to other transactions.

Example: If a customer overpays, software has the ability to post excess amount as a credit to customer account for later usage by: cashing out a refund or apply that credit to a different purchase made by customer. This process must allow the cash out refund option to occur via any established tender types the University has set up within the system.

6.10.10.(E) Ability to restrict employee’s write-off or adjustment amounts based on a user level access profile is preferred, but not required. Please describe your system’s ability to meet this specification.

6.10.11.(M) Ability to print receipts on demand and reprint receipts with any updated transaction information.

6.10.12.(ME) Print a receipt as necessary that clearly identifies individual transactions and/or items purchased, including but not limited to citations paid, permit receipts, event reservation payments. Please describe your system’s process for customizing or setting what parameters are printed on the receipt.

6.10.13.(M) University requires the software be capable of notating on a transaction specific amounts of information related to the transaction. These must include: last four digits of credit card number for credit card transactions, a check number for check transactions, and an Internal University accounting number on orders to other University departments

. 6.10.14.(E) Ability to specify number of digits saved based on payment method (i.e.: only 4

digits for credit card, unlimited char alphanumeric for interdepartmental charges). Please describe system functionality for implementing this.

6.10.15.(ME) Ability to restrict payment types based on customer classification or permit type, either in user classification module or in permit module. Please provide description for how the system allows customization of payment type based on University parameters. Example only department’s or groups may use Interdepartmental Charge as payment type. Please describe your system’s capabilities.

6.10.16.(E) Ability to restrict a permit sale until all citations are paid with optional override authorizations with approval is preferred, but not required. Please describe your system’s ability to meet this specification.

6.10.17.(M) University created payment types without limitation as needed

LF14-057 Page 29 of 68 5/7/2023

6.10.18.(M) The system must have the ability to print each receipt to a variety of printers in a variety of formats, including point of sale receipt printers.

6.10.19.(M) Decal or Permit purchases may be purchased by immediate payment, through payroll deduction or, spread out over several months as a payroll deduction or on a per paycheck basis throughout the fiscal or calendar year.

6.10.20.(ME) Ability to establish payment plans. Explain your system’s ability.University defined parameters including but not limited to: start and end times, number of payments, associated permit types; in system for global use across users.multiple payment plan types with different parameters

6.10.21.(ME) Reporting including but not limited to notice generation based on a delinquency report, users on payment plan with status of plan. Please describe your system’s capabilities.

6.10.22.(M) Capable of accepting and linking updated data in proper format from internet based payment systems linked to relevant transaction information. Example: customer website portal payments through Authorize.net or similar payment gateway will automatically link to customer order information in administrative side of software

6.10.23.(M) Real time updates between users when transactions or updates to financial information (like refunds or adjustments) occur.

6.10.24.(M) Shall display real time balance on each cashier’s screen of cash and check payments, or similar functionality. Software needs to have a balancing component; this will allow the cashier to compare funds in the drawer with amounts entered in the system’s cashiering function to ensure matching balances intake/output.

6.10.25.(E) Also includes a supervisor approval component for certain permission override functions related to tender balances as needed. Describe.

6.10.26.(ME) Software includes standard drawer close-out process with detailed reconciliation report. Describe this process.

6.10.27.(M) Must automatically and sequentially generate receipt/ transaction numbers for payments, refunds and adjustments.

6.10.28.(ME) Associate free-form financial transactions and adjustments to an individual or group customer. Please describe your system’s capabilities.

6.10.28.1 Posting an overpayment to customer account.

6.10.28.2 (E) Posting meter/pay station collections in general ledger accounting.

6.10.28.3. (ME) Ability to facilitate third party sales (i.e. an individual purchases a permit but the bill for the permit is directed to a third party). Posting charges, payments, refunds, adjustments for invoiced permits or services to a third party group. Please describe how your system facilitates invoicing third party, non-university customers.

LF14-057 Page 30 of 68 5/7/2023

6.10.28.4. (E) University prefers the ability to allow services or permit permissions to be placed on another user’s account with third party group being charged.

Example: Customer A has permit Group B is responsible for paying for permit, Customer A is responsible for citations and parking properly

6.10.29.(M) Ability to make adjustments for misapplied payments or reverse payments with a complete audit trail.

6.10.30.(E) Ability to return a permit to inventory if mistakenly applied to incorrect account. is preferred, but not required. Please describe your system’s ability to meet this specification.

6.10.31.(ME) Ability to manually apply and remove flags on an account based on University defined criteria. Describe your system’s ability. Must include, but not limited to:

Unpaid citations greater than a University defined amount Overall account balance owed greater than a University defined amount Payroll deduction status

6.10.31.1 (E) Please describe any additional options available not previously described in this list.

6.10.32.(ME) Ability for customers to view, print and pay all associated charges (permits and citations) via customer facing portal. Also to allow for transactions to be charged to, but not limited to, student accounts, payroll accounts for student/faculty/staff and standard credit/debit/cash payment types based on University discretion according to University parameters of payments accepted on certain charge types. These payment transaction types are specific to the customer portal abilities.

6.10.32.1. (E) If customer portal can also processes payment for event permits or reservations please indicate in response and how.

6.10.32.2. (E) If Offeror has customer mobile application for smartphones/tablets which has this functionality please indicate in response what functionality is included.

6.10.32.3. (E) Respondent related expansion or included features are requested in response.

6.10.33.(M) Provide approval capability on the administrative side including, but not limited to, financial overrides and permit sale price overrides. Admin users must have the ability to override/approve transactions that lower security users cannot complete without approval. Example price change at time of sale for pro-rated permits.

6.10.34.(M) Allow administrative staff to monitor and manage users, citations, invoices, payments, reports, user groups, parking lots

6.10.35.(E) Upcoming University expansion in financial software will include Oracle Fusion Cloud, please respond with any information that the respondent has for integration with this system.

LF14-057 Page 31 of 68 5/7/2023

6.11 CREDIT CARD PROCESSING

6.11.1 (M) For the processing of credit card payments, the University is required to use its existing merchants services centralized contract and one of the following:

6.11.1.1. (E) Authorize.net payment gateway and processing for online payments (already used by University)

6.11.1.2. (E) will consider another proprietary payment system such as Touchnet with proper PCI compliance verification dependent upon Offeror usage.

6.11.2. (E) Boise State University requests that handheld credit card readers be capable of reading as many as possible of mag stripe, NFC, Tap n Pay, secure chip products.

6.11.3. (M) Meet any and all current PCI compliance requirements based on industry standard, and maintain current PCI compliance as needed through lifetime of contract. The software shall be PCI compliant with no storage of customer credit card information. All credit card information shall be in Parking and Transportation Services’ approved payment gateway (last four digits accepted).

6.12 PARKING MANAGEMENT

6.12.1. (M) Vehicle Registration:The capabilities of this software module must provide for the complete control of the vehicle registration process including: Ability to view all activity associated with a vehicle on desktop application including permits, citations, handheld notifications (messages sent to the handheld), boot/tow information, and notes. Link multiple vehicles to a Customer.

6.12.1.1 (E)The University desires to have a system that allows multiple people assigned to the same vehicle. (5)(ME) Describe your ability to have the same vehicle assigned to multiple people as necessary and be able to see that relationship at all times when looking at the customer’s record.

6.12.2. (ME) Ability to assign VIP Status to a customer and vehicles (multiple) and see this VIP status on the enforcement handhelds while enforcing. The University desires that the enforcement Ambassadors are able to quickly ascertain when a vehicle is a VIP vehicle.

6.12.3. (ME) Ability to send custom vehicle notifications to the handhelds, notifications includes a start and end date, notification type and comments and view such comments quickly by enforcement officers. (Examples: do not ticket or tow, VIP, boot/tow, scofflaw, etc.)

6.12.4. (M) Define vehicle assignment categories, such as registered owner, driver, rental car, etc.

6.12.5. (E) Describe how this would tie into the ability to see multiple vehicles/people on the same account.

LF14-057 Page 32 of 68 5/7/2023

6.12.6. (ME) Describe the ability for the system to include primary liability for citations when set by customer relationship. University prefers to establish current liability for the vehicle and any associated citations as well as being able to reassign these to another vehicle if mistakes have been made.

6.12.7. (M) Assign a unique licence plate registration number that is identifiable by staff.

6.12.8. (M) Maintain Vehicle Ownership and Plate Type historical information with ability to view all data related to specific customer record or vehicle record being accessed from.

6.12.9. (M) System must be able to process special characters on license plates as necessary for LPR system capabilities

6.12.10.(ME) Ability to insert additional University defined fields, preferably up to an unlimited amount. Field definitions include data type (date, flag, character, etc.), field title, length of field, etc. Please describe your system’s capabilities.

6.12.11.(ME) Access to complete list of invoices (citations, permit order,event reservation, boot/tow, etc.) related to the vehicle and or customer and the ability to go directly to one of those listed record, once at the record be able to print it out if necessary.

6.13 CUSTOMER TRACKING

6.13.1. (M) One unique account number issued to a customer that is visible and usable to staff

6.13.1.1. (E) Would like the ability to link software account number with on campus ID number (numeric) or departmental charge account number (alphanumeric currently, but is changing to fully numeric in future University expansion to Oracle Fusion Cloud software) Please describe your software’s ability to meet this.

6.13.1.2. (M)Follows through all levels of account.

6.13.1.3. (M) Ability to prevent duplicates through this process

6.13.1.4. (M) For non-campus ID holders, software must automatically create a sequential unique account number meeting same visibility and usage requirements

6.13.2. (ME) Display of accurate account balance due with linked access to detail.Please describe how your system accomplishes this.

6.13.3. (ME) Assignment of customer “classification” (e.g. vendor, staff, visitor, etc.)These classifications will be used for such things as exclusions from certain permits. Your response needs to detail how these classifications are used within the proposed system

6.13.4. (E) Assignment of customer “sub-classification” (e.g. full-time, part-time, quarterly parker, etc.) It is intended that these classifications will be used for such things as exclusions from certain permits. Please describe your system’s capabilities.

LF14-057 Page 33 of 68 5/7/2023

6.13.5. (M) Unlimited number of addresses (physical and e-mail) per individual

University defined address types (home, work, school, etc.) Ability to prioritize multiple addresses i.e.: primary, secondary etc. Ability to remove addresses with audit trail of removal and memory of these

removed addresses for comparison Include ability to use on campus mail stop addresses

6.13.6. (M) Must have the ability to define E-mail address types (work, home, etc.)

Ability to define current Ability to remove addresses with audit trail of removal and memory of these

removed addresses for comparison

6.13.7. (M)Ability to insert additional University defined fields, preferably up to an unlimited amount. Field definitions include data type (date, flag, character, etc.), field title, length of field, etc.

6.13.8. (E) Ability for software to run a process which identifies potential duplicate customer records. Describe your system’s ability to accomplish this.

6.13.9. (M) Ability to merge manually identified duplicate records into one. (Administrative side only function).

6.13.10. (M) Direct access to additional modules associated with the customer including, but not limited to:

orders processed related to customer citations and appeals related to customer vehicles related to customer events related to customer

6.13.11. (M)Direct access to financial information related to the customer. Including, but not limited to:

invoices payment transactions adjustment and refund transactions

6.14 PARKING PERMIT CAPABILITIES

Currently, Boise State uses a static cling decal,however, Boise State is open to suggestion of other permit media. A permit may be a card, sticker hang tag, or virtual/digital permit and it may be issued to a person(s).

6.14.1 (M)The software must offer students, faculty, staff and contract vendors with an on-line permit purchase website that has the look and feel of BOISE STATE UNIVERSITY’s home web pages, or be able to be seamlessly embedded in existing pages.

6.14.2. (ME)When a permit is issued, a *customer centric relationship must be established between a customer, to vehicle(s) and the permit(s). Customer-centric data model

LF14-057 Page 34 of 68 5/7/2023

(Customer is “Primary Key”) that will allow the linking of multiple vehicles, permits, citations, addresses, booting/towing, event registrations, etc. to a single customer and or multiple customers. Definition: *Customer centric means the customer, not the vehicle, is the foundation of the data base, records point to customers first, thus a vehicle is attached to a customer(s), not customer attached to a vehicle. Describe.

6.14.3 (E) University prefers that the proposed software has the ability to define primary and secondary liability status to vehicles. This means when a vehicle is assigned to two different customer accounts (i.e. relatives), the system has the functionality to define which user has primary liability for citations and infractions, while the secondary liability user would not get the citations assigned to them. Describe.

6.14.4 (M) Must have the ability to view all activity associated with a permit including, but not limited to: customers, vehicles, properties/locations, receipts, and notes.

6.14.5. (E) Must have the ability to track all stages of permit fulfillment. Describe.

6.14.6. (ME) Must have the ability to create at least the following three (3) types of permits: Inventoried, Non-inventoried and non-tracked locally printed permits. Describe.

6.14.7. (M) Must have the ability to inventory and track uniquely numbered (alphanumeric and numeric) permits as they are being issued or refunded, the inventory module will update the number of permits available for that category.

6.14.8. (ME) Must have the ability to return, exchange, and re-sell a permit. Describe.

“re-sell” explanation: if a person returns a permit, ability to automatically or manually place the permit’s “space” back in inventory with same or new permit number attached, with tracking of returns and counts by permit type

Additional points will be awarded for automation in regards to physical permits

6.14.9. (M) Must have the ability to record a permit’s effective, issuance and expiration dates.ability to modify on demand with proper security authorization based on user’s profile

6.14.10.(M) Must have the ability to register one or more vehicles and/or customers and both as needed to a permit (carpooling). Carpool permits shared by multiple individuals.

6.14.11.(ME) Payroll/student financial deduction plan for University students, staff and faculty. Describe.

6.14.11.1 The system must allow multiple types of payment plans to be available for permit payments.

6.14.11.2. Meeting University defined start and end dates and number of payments

6.14.11.3. Includes a way to batch post payments to multiple accounts on the same payment plan type

LF14-057 Page 35 of 68 5/7/2023

6.14.11.4. The payroll deduction schedule must be customizable as to how many payments will be required to fulfill payment, or automatically calculate this based upon a starting date, end date, and length of time between pay periods.

6.14.11.5. Ability to define independent of specific customers (global settings), set-up for system based on university fiscal year

6.14.11.6 Ability to have multiple payment plan types with different parameters as needed.

6.14.12 (ME) Must have the ability to sell a permit to a customer and charge the transaction to an approved 3rd party or invoice tender type. Describe.

6.14.12.1 System management of third party vendors as individual customer or as a group customer.

6.14.12.2. see balance due by vendor.

6.14.12.3. link orders to vendor.

6.14.12.4. ability to send invoices, estimates, etc to vendor from vendor customer dashboard.

6.14.12.5. manage multiple account numbers for on campus departmentseach department has multiple account numbers for different types of payment types i.e. one for permits, one for events but both are linked to the same department.

6.14.13.(M) Must have the ability to display customer/permit total account balance due.

6.14.14.(M) Must have University defined permit possession status indicators minimum to include active, lost, stolen and returned.

6.14.15.(M) Must have the ability to download customer/permit records to handheld ticket writers.

live system, any change made on administrative side, once saved will update across the system and handhelds.

6.14.16(M) Must include complete tracking and issuance of temporary permits.

admin issuance of temporary permits customer ability to issue temporary permits based on Boise State criteria and

valid lengths of time

6.14.17.(M)Must include direct access to financial information related to the permit/customer. This includes, but is not limited to: payments, adjustments, additional fees, refunds, etc.

6.14.18.(ME) Must have the ability to populate permits for inventory management. Describe.

LF14-057 Page 36 of 68 5/7/2023

6.14.18.1. Dependent on virtual or physical permits active, adjusts for returned or lost/stolen replacement

6.14.18.2. Ability to set maximum lot sales

6.14.18.3. Running tally of active permits in the field by permit type and/or customer classification depending on reporting needs

6.14.18.4. Sales reports based upon student/employee and sub-classificationsability to have permits set up to sell at different prices for student or employee pricing

6.14.18.5. Reporting shows differentiation

6.14.18.6. Inventory management allows for the permits to tally totals across sub-classifications relating to total permit classification

Example: one of our permits has three sub-classifications: student, employee with benefits, employees without benefits. For the main permit category set inventory allowances which covers any sub-classifications

6.14.19.(ME) Must have the ability to prorate permit sales/returns and automatically calculate value based on user-defined rules (i.e. weekly, monthly, daily, etc.).Vendor specific application can be described in response for consideration.

6.14.20.(M) Must have extensive search capabilitiesMust include but not limited to the following:

search results return relevant items based on criteria search for customer ID number email address phone etc. search for vehicle license plate search for permit number search for order number search for citation number search for event details event name unique event ID number event date billable customer any additional searches as required

6.14.20.1. (5)(E)University prefers an included ability to use wildcard in search functionality. Please describe your system’s capabilities.

6.14.21.(M) Must provide the ability to assign permits and numbers at the time of a sale.

LF14-057 Page 37 of 68 5/7/2023

for physical or digital permits

6.14.22.(E) Ability to reserve permits to a specific customer for future sale. Describe.

6.14.22.1. (E)(preferred) Customer does not pay for place in line 6.14.22.2. (E)And/or link customer to a permit that will be purchased at a future date,

but able to be returned to open inventory if not purchased by a specific date by manual or automatic process

6.14.22.3. (E)With appropriate reporting functionality to identify relevant accounts.

6.14.23.(M) Must have the ability to insert additional University defined fields, preferably up to an unlimited amount. Field definitions include data type (date, flag, character, etc.), field title, length of field, etc.

6.14.24.(M) University requires an administrative review function for specific permit types

Handicap accessible permits go through administrative review to ensure proper documentation and allowance to purchase said permit category

Ability for software to provide fields for customer entry at point of sale State issued accessible decal identification University provided ID number others as needed, with university definition of needs dependent on specific

permits

6.15 (E) PERMIT FULFILLMENT SERVICES

In recent years Boise State has chosen to fulfill permits from our own location. Offererors may respond with a permit fulfillment service in which they (the offeror) process fulfillment on behalf of Boise State University from the Offeror’s facilities.

6.15.1 This service is desired to provide an option for the secure mailing of ordered permits to our patrons if chosen as an option by the University.Responses must include details for how the proposed system processes the permit fulfillment as well as return and shipping times to be expected by the customer receiving the permit from Offeror’s fulfillment facilities. Please describe your system’s capabilities.

6.15.2. The software is desired to produce reports, as needed, to provide the mailing status of a permit, the name of the patron, and other pertinent information as determined by the University, if Offeror fulfillment is chosen as an option. Please describe your system’s capabilities.

6.15.3. Certain Boise State customers will be fulfilled local permits printed on demand by Boise State customer interfacing employees. This process of on demand in house permit creation will still need to be an available option to meet these needs if Offeor fulfillment is chosen by Boise State. Please describe your system’s capabilities.

ability to add these permits to system inventory for reporting needs ability to connect these permits to customers in the respondent’s software system ability to use fulfillment functions locally

LF14-057 Page 38 of 68 5/7/2023

letters mailing status of permit payment status of permit etc. as needed

6.16 (E) WAIT LISTS

It is desired that the software would provide the ability to compile and manage multiple wait lists based on a permit category and/or permit control area (location/zone/lot) without impacting current inventory controls and counts.

The University is interested in understanding how the proposed system treats wait lists. While we want to employ wait lists in our our operation we are interested in idea’s/solutions. The capabilities of the wait list feature could provide for the complete control of the permit wait list management including:

6.16.1. System would have the ability to use Waiting Lists. If a user is unable to buy a permit due to lot space limits they are to be placed on a waiting list until space is available. The waiting list must not require the customer to purchase a permit in order to be placed on the waitlist, as well as not being impacted if person purchases a different permit until space is available on original permit. The wait list must be permit specific, allowing as many waitlists as permit types in the system. Please describe your system’s capabilities.

6.16.2. Wait lists that can be prioritized by classification: such as student, VIP, staff or faculty.

6.16.3. Prioritization based on an optional combination of a date field and custom fields.

6.16.4. Configuration options that either require a customer to be on a particular wait list to purchase a permit or do not require a customer to have a valid waitlist record to purchase a permit. The software must also provide an override feature.

6.16.5. Multiple choice permit options

6.16.6. Permit Category independent wait lists

6.16.6.1. Customer on wait list for Category A will not impact customer on wait list for Category B

6.16.6.2 Customer may purchase permit from Category C while waiting for spot on wait list in Category A

6.16.7. Automatic update of the wait list position number when records are inserted or edited.

6.16.7.1. When first in line purchases permit from designated wait list category, the wait list is automatically updated for remaining users on list

6.17 BULK PERMIT ISSUANCE AND INVOICING

6.17.1. (M) The software must have a module that enables the user to issue bulk permits or products to an individual, agency or department and bill for the total amount due.

LF14-057 Page 39 of 68 5/7/2023

6.17.2. (M) Must have the ability to view all activity associated with the batch permit including customers, permits, receipts, citations and notes.

6.17.3. (E) Ability to define a sub-customer liable for an individual permit within a bulk sale. Describe.

Example: Group Customer purchases X permits as a bulk sale as paying customer, each permit under the bulk sale is then linked to a university employee or student as liable for parking citations

6.17.4. (M) Must have the ability to make monetary adjustments to permit pricingat point of sale with proper administrative security roles.

6.17.5. (M) Must include direct access to financial information related to the batch permit record. This includes, but is not limited to payments, adjustments, additional fees, refunds, etc.

6.17.6. (M) Must have the ability to display bulk permit balance due with applicable payment transaction information.

6.17.7. (M) Must have the ability to assign a unique permit number from inventory to each permit within a bulk permit sale/order and use indicators to easily identify a bulk permit sale compared to a single permit sale

6.18 IN HOUSE NOTICE AND LETTER GENERATION MANAGER

6.18.1. (M)The following letter types must be available in the software module: Customer Account Statement.

for accounts with multiple overdue citations on demand

Citation Overdue Notice. on day of overdue status being reached letter prints out by batch function on 30, 60, 90… day statuses

Appeal Hearing Notification/Results Notices. on demand when appeal hearing is adjudicated by university staff

Permit Renewal Letter when a permit is purchased through online purchasing system, the staff can

run a process to print all pending permit renewal letters since last task run. 6.18.2. (ME) Must have the ability to send University defined customer statements in a variety of

formats to inform customer of all outstanding charges on account (citations, permits, boot/tow, event reservation, invoice, estimate, etc.). Describe.

6.18.2.1. Paper and digital formats

6.18.2.2. Ability to reprint or resend letter to customer with updated printing/emailing date included and documented

6.18.3. (ME)Must have the ability to generate and print permit renewal letters while maintaining an audit trail (previously defined) within the application. Describe.

LF14-057 Page 40 of 68 5/7/2023

6.18.3.1. Both physical and digital letters in standard digital formats (pdf, doc, html, etc.)

6.18.3.2. Permit renewal letter: means a letter that is printed in an automatic (preferred) or on demand daily task for identifying all permit purchases since the task was last run for stuffing envelopes for mailing or pickup with physical decals

6.18.4. (ME) Must allow the user to prioritize address types (address types must consist of both email and physical address types).Describe.

6.18.4.1. Ability to remove an address as current, but be held in customer audit record

6.18.5. (ME)Must allow the University to define/create different types of forms such as: standard letters, including letters specifically for Appeals, Permit Renewals, Account Statements, Citation Billing, Multiple Overdue Notices, delinquent Payment Plans, etc., for storage in the database file. Describe.

6.18.5.1. With the addition of University branding on all communication sent from software

6.18.5.2. Offeror working with university to build University approved templates and language inclusions

6.18.6. (ME)Must have the ability to produce University defined batch processes that print all letters meeting university defined criteria of that type of letter for all related citations, vehicles or customers when certain user-defined conditions are met for the process. Describe.

6.18.6.1. Process to print all 30 day unpaid citations

6.18.6.2. Process to print all 60 day unpaid citations

6.18.6.3. Process to print all 90+ day unpaid citations

6.18.6.4. Vehicles with more than X amount of citations

6.18.7.(ME)Must allow the user to go to a specific citation, vehicle or customer and print a related letter. Describe.

6.18.7.1. Appeal notice

6.18.7.2. Customer account statement

6.18.7.3 Citation payment due

6.18.7.4. All unpaid/paid citations for a given license plate/vehicle record

6.18.7.5. Chosen from a dropdown of options from previously defined letters input during implementation

LF14-057 Page 41 of 68 5/7/2023

6.18.8. Must 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 and address, etc.).

Standard Form letter processes

6.18.9. (M)Applicable letters must include table of information in readable format including:

Individual listing of each unpaid citation total dollar amount due specific details for each outstanding citation vehicle description information registered owner information and liable customer name and address information.

6.18.10.(E) Desired ability “roll back” letters, if they were generated in error or the ability to make a note on the record to indicate the error. Describe your system’s ability in this area.

6.18.11.(M)Must have the ability to add University Transportation and Parking Services department logo and contact information

6.18.12.(M) Must be able to generate and print notification letters from on University location.

6.18.13. (ME) E-mail communication. Please describe your system’s capabilities. :

6.18.13.1. Use of University defined address for sender and reply-to addresses

6.18.13.2. Permit purchase letters

6.18.13.3 Notification of citation written against account connected vehicle

6.18.13.3 Past due citation notices (30, 60, 90…)

6.18.13.4. Immediate notification of citation

6.18.13.5. Follow-up notification (24 hours, 15 days)

6.19 (E) MASS EMAIL

The University desires to have the capability within the system to send email notifications to permit holders notifying them of issues concerning parking areas their permit has access to, these would be event, maintenance, weather, or administrative, but not limited to these. Send emails within the system to any permit holder by individual, group or combination of groups. Please describe your system’s capabilities.

LF14-057 Page 42 of 68 5/7/2023

6.19.1. Send emails that are formatted to meet accessibility requirements.

6.19.2. Send emails that are formatted for mobile and desktop devices.

6.19.3. Send emails on an automatic and manual university defined schedule.

6.19.4. Send mass email function to large groups of users (1-10,000)

6.19.5. Html formatting preferred over rich text

6.19.6. Ability to add attachments in standard formats (.pdf, .doc, .xls, .jpg, etc.) to mass email

6.19.7. Ability to add University Transportation and Parking Services department logo and contact information

6.20 LPR AND ENFORCEMENT SYSTEM

6.20.1. (M) The capabilities of this policy enforcement module must allow for the issuance of citations to vehicles, BSU accounts, vins and serial numbers.

6.20.2. (M)Module must be able to be utilized via a mobile webpage or mobile application

6.20.3. (M) Module must also be accessible within a browser with an administrative side of handling enforcement

6.20.4. (M)Must have the ability to issue citations to bicycle or vehicle serial numbers, License plates,6.20.4.1. (5)(E) and BSU ID numbers

6.20.5. (ME)Module must allow user to identify difference between license plates,vin number, bicycle serial numbers and BSU account number when reviewing citation. Describe.

6.20.6. (E)Module desired to display different drop down boxes based on type of policy enforcement being performed based on License plate, BSU account or Serial number. Describe.

6.20.6.1 Different citation types give different fields for enforcers to utilize, based upon University defined parameters

For example starting a bicycle citation is able to show different citation than a vehicle citation, or Student Account number for things like smoking citations on campus

6.20.7. (M)Must have the ability to enter vehicle makes, models, color and type of vehicle or customer being cited.

6.20.8. (M)Must have the ability to assign a unique number for every citation issued

6.20.8.1. (5)(E)Ability to define numbering series prefix to identify different citations from different years. Describe.

LF14-057 Page 43 of 68 5/7/2023

6.20.9. (M)Be able to take pictures from module on handheld and assign to citation being written.

6.20.10.(M)Module must interface with permit tracking system to show previous citations, account holder’s personal information such as phone number, name and vehicles attached to their account

6.20.11.(M)Module must show history of citations on account and show difference between warnings and citations

6.20.12.(M)Module must allow user to check daily citation history summary and allow user to see expanded details of citations written

6.20.13.(ME)Must have the ability to insert additional University defined fields, preferably up to an unlimited amount. Field definitions include data type (date, flag, character, etc.), field title, length of field, etc. Describe.

6.20.14.(M)Module must have a final review page to ensure information is correct before printing.

6.20.15.(ME)Module must connect wirelessly to citation printers

6.20.15.1 University prefers Bluetooth connection, if module does not connect via bluetooth, Offeror can submit a similar connection style for University consideration

6.20.16.(M)Must allow user to see notifications for scofflaw or revoked privileges based on citation, vehicle, or customer history.

6.20.17.(ME)The system must include an automated scofflaw system. This means it will create scofflaw rules based on the citations or account balance associated with a vehicle. Please describe your system’s capabilities.

6.20.17.1. Provide a scofflaw flag on the vehicle record for easy identification.

6.20.17.2. University definable settings for automated process to add and remove the active scofflaw flag if the vehicle no longer meets the scofflaw requirements.

6.20.17.3 Definable parameters to meet Boise State needs for scofflaw requirements

6.20.17.4 Automatic notification in LPR reader and in enforcement handheld applications when scofflaws are attached to a searched vehicle/customer/permit

6.20.18.(ME)Module must interface with License Plate recognition (LPR) softwarewhen a license plate is read by the LPR and determined to be either scofflaw orrevoked parking or other University defined parameter. Describe.

6.20.19.(E) Email notifications based on scofflaw settings to customers as a warning of future citations. Describe.

LF14-057 Page 44 of 68 5/7/2023

Example: an email to customer for revoked parking privileges, or vehicle to be impounded, etc. based on number of open citations.

6.20.20.(E) University prefers a software that allows the ability to use what we call a “Graduated Citation Program” wherein a citation will reach increased levels of cost based upon number of repeated violations by vehicle or customer repeat across multiple vehicles. Describe.

Example: after 3rd repeat of citation type A on vehicle since beginning of academic year, the 4th citation will be at an increased cost. After 7th repeat citation, 8th will be at an increased cost, etc. This will be implemented across all citation categories

6.20.21.(E) It is desired that there be integration with pay station equipment located at parking lots and parking structures (Luke’s machines listed under Hardware section) . Describe.

6.21 PARKING PERMIT SYSTEM

6.21.1. (M) Must allow users to add multiple license plates per permit for primary, secondary, etc. vehicles.

6.21.2. (M) Must allow users the ability to change their primary license plate on-line for a permit to another license plate (vehicle) if needed.

6.21.3. (M) Must provide for multiple types of permits and locations. including sub-classifications based on customer University classification

6.21.4. (M) System must have the ability to print out and use temporary permits with University defined parameters

6.21.5. (M) System must allow the ability for accounts to have permits changed, adjusted, or

invalidated and revalidated by Parking employees as needed.

6.21.6. (M)Permits must be able to be purchasable with tender types including, but not limited to: payment plans, cash, credit cards.

6.21.7. (ME)Boise State uses customer classification as a basis for permission to purchase permit types. System must, at a minimum, provide for the following listed below. Please describe your system’s capabilities in full.

6.21.7.1 Student able to purchase category A of permit at $A defined price

6.21.7.2. Employee able to purchase category A of permit at $B defined price

6.21.7.3 The software must allow a similar permit setup for permit sales

6.21.7.4 Respondent explanations of similar functionality is requested. 6.21.7.5. By type of customer

6.21.7.6. Use University customer classifications including but not limited to: 6.21.7.6.1. Resident on Campus6.21.7.6.2. Student non-resident

LF14-057 Page 45 of 68 5/7/2023

6.21.7.6.3. Employee

6.21.8.7 Ability to use University ID numbers in list format for permission list.

6.21.8.8 (E)University prefers system allow the institution of parameters that prevent customers who have greater than X outstanding citations to purchase a permit on line. The parameters must be adjustable to allow the number of outstanding citations to be adjusted due to policy changes. Please describe your system’s capabilities.

6.22 EVENT PARKING RESERVATION AND TRANSACTION PROCESSING SYSTEM

The University prefers an Event Parking Reservation and Event Transaction Processing System. This module will include a customer facing portal for event request submissions based on University form and website model. This module will also be used for parking management related to events occurring on campus, not limited to athletic events. These events will be occurring in multiple locations across campus, with the possibility of multiple events per day in different locations or in the same location. Offeror event system functionality must be detailed in response.

6.22.1. (ME) Must allow online customer interfacing form to submit event requests with ability to define form structure, form logic, and form fields to University parameters and needs. Below are examples of fields to be included. Please describe your system’s capabilities.

6.22.1.1 Vehicle count estimate

6.22.1.2. Attendee estimates

6.22.1.3. Location, date, time requested

6.22.1.4. (5)(E)University would like logic based form setup

6.22.1.5. (30)(E) University prefers online customer form submissions be automatically imported after submission and dispersed into a record within the Offeror’s system for review in the Event module. Please describe this functionality.

6.22.2. (E) Must have the ability to provide follow-up communication on form submission from the system, either automatic or manual process. Please describe your system’s capabilities.

6.22.2.1. Notifications to customer of any changes or updates to event

6.22.2.2. Quote for event estimates

6.22.2.3. Final invoice

6.22.2.4. Past due notices

LF14-057 Page 46 of 68 5/7/2023

6.22.2.5. Ability to provide estimate and invoice to requestor by paper or digital formats

6.22.3. (E) Desired to have a calendar or similar style management of events to manage multiple campus events per day. Please describe your system’s capabilities.

6.22.4. (E) Desired to have built in event reporting features such as the following. Please describe your system’s capabilities.

6.22.4.1. Report export functionality

6.22.4.1.1 local and vendor customizable reports

6.22.4.1.2. example reports: total attendees for same event over multiple years, total vehicles on event day, pending/unapproved daily events, weekly events, unpaid events, aging events by invoice date (30, 60, 90….days past due). Please list available.

6.22.5. (M) Includes event parking modules

6.22.5.1. (M) Must allow for management of event by lot or location on campus.

6.22.5.2. (E)Desired ability for temporary permit or online permit pre-reservation for event with ability for handhelds to verify. Preferably connected to customer facing form submission module to connect the online purchases with the event automatically on admin side for accounting functions. Describe.

6.22.5.3. (E)Desired that University has manual control of pre-pay event permit styles, number series, etc. Describe.

Example: a sister department on campus gives us their permit numbers, we upload to system, and we report their in field usage

6.22.6. (M)Must have the ability to operate in real time over cellular wireless and/or the University hosted wireless network (Wi-Fi)

6.22.6.1. (M)Must have the ability for handhelds to be connected to administrative software to check event details

6.22.6.2. (E)Desired that system will allow event staff to process on demand payments for event parking

6.22.6.3. (E) Desired that system will allow customer to pre-pay via mobile web on site. Describe.

6.22.7. (M)Must have the ability to manage multiple events at multiple rates per event and more than one event at the same time of day in multiple locations or same locations.

LF14-057 Page 47 of 68 5/7/2023

6.22.7.1. (E)University prefers a system that has understanding of how many lot spaces are already sold during an event’s time schedule. Describe.

6.22.8. (E) Desired that onsite payment via handheld unit for University event parking would be available at all times. Describe your system’s ability.

6.22.8.1. Via cellular wireless or university hosted wireless access points.

6.22.8.2. Process vehicles quickly and cashier via handheld mobile units process high volume of credit cards under heavy network utilization

6.22.8.3. (M)PCI Compliance Certification, and/ or PA DSS application certification.

6.22.8.4. (M)Must not store customer credit card numbers in the handhelds or system server

6.22.9. (M) Admin Software must be capable of accepting payments by multiple options of cash, or real-time credit/debit card transactions, or pre-paid reservations, or pre-purchased permits or season ticket parking passes.

6.22.10.(M)Must provide two way communication between the server/central office and the handhelds with real time data integrity, any changes on handheld or admin software updates to opposite in real time.

6.22.11.(E) University prefers the ability to perform automatic management updates to managers for certain changes made. Please describe your system’s capabilities.

6.22.11.1. Manager can specify a VIP event that sends updated information to manager as it is changed

6.22.12.(E)Desired that tickets/pre-pay permits/reservations issued on site will be issued in sequential number order and on demand. Please describe your system’s capabilities.

6.22.12.1. Offeror can specify an alternate method of nomenclature and numbering methods

6.22.12.2. On demand means being able to sell at entrance to event

6.22.13.(E) Desired that VIP module would allow for VIP lists to be modified and updated in real-time. Please describe your system’s capabilities.

6.22.13.1. Provides a VIP module that allows for up to 500 names per event to be treated as VIP giving the parking attendant the ability to see the patron’s name and communicate with the patron or other parking attendants

6.22.14.(E) Desired that system would be accessible off-site through website, only when security controls on administrative user profiles give specific ability to log in off siteor blanket access from any location on/off campus. Please describe.

6.23 REPORTING

LF14-057 Page 48 of 68 5/7/2023

University requires a dynamic, robust reporting module to be demonstrated in response with specific capabilities by Offeror.

Most database and administrative website structures will allow for all of these reports. If your system does not specifically include one of these reports, Offeror response must indicate your alternative reporting option and list the timeframe by which the report will be functional, preference is that the functionality will be in place by go-live date.

6.23.1. (ME) Must have the ability to have reports scheduled to run at specific times. Please detail your system’s ability to schedule reports and queries.

6.23.2. (ME) Must have the ability to track regulation and enforcement by various criteriaMust have the ability to track by citation and citation payments by various criteria, including but not limited to the following. Describe your system’s capabilities.

6.23.2.1 Citations by date range

6.23.2.2 Citations by Enforcement officer

6.23.2.3. Citations by amount 6.23.2.4. citations by location

6.23.2.5. total citations per month

6.23.2.5.1. total6.23.2.5.2. by location6.23.2.5.3. by enforcer6.23.2.5.4. by vehicle specific information

6.23.3. (ME)Must have the ability to track vehicle permits by various criteria, including but not limited to the list below. Describe your system’s capabilities.

6.23.3.1 Total # of permits sold by name and revenue given combinations of 6.23.3.1.1 permit type6.23.3.1.2. permit location6.23.3.1.3. sales year6.23.3.1.4. category of permit user (student, employee, vendor,

etc) 6.23.3.1.5. university definable expansion

6.23.3.2. # of permits sold and # of permits still available per lot6.23.3.2.1. general inventory reporting 6.23.3.2.2. including returned permits6.23.3.2.3. event permit pre-purchase details

6.23.4. (ME)Must have the ability to produce Cashiering Reports including but not limited to the following list. Please describe your system’s capabilities.

6.23.4.1. Cashier closeout reports

LF14-057 Page 49 of 68 5/7/2023

6.23.4.1.1. daily intake categories by tender type6.23.4.1.2. expected intake vs. real intake

6.23.4.2. Transaction reports6.23.4.2.1. by tender type6.23.4.2.2. by user6.23.4.2.3. by date range6.23.4.2.4. refund reports

6.23.4.3. Admin. override reports6.23.4.3.1. administrative override of pricing (when and by

which user)6.23.4.3.2. refund reports

6.23.4.4. By date range, by user

6.23.5. (E) University prefers a built in report analysis tool which would be able to create year over year sales comparisons, or year over year revenue comparisons with breakdowns by lots would be preferred by the University. University would also prefer the ability to produce Financial administrative reports in this type of tool. Please describe your system’s capabilities.

6.23.5.1. Accounts Receivable aging6.23.5.1.1. by day, month, year, user6.23.5.1.2. pending payment accounts6.23.5.1.3. by past due status (30, 60, 90….)

6.23.5.2. Miscellaneous accounting6.23.5.2.1. meter payments input6.23.5.2.2. pay station revenue input6.23.5.2.3. on demand event payments

6.23.5.3. Pending orders6.23.5.3.1. pending fulfillment6.23.5.3.2. pending payment

6.23.5.4. Auditing6.23.5.4.1. paid, partial paid, unpaid

6.23.5.5. Must allow for the reporting of data concerning individuals choosing to purchase parking permits through a payroll deduction or payment plan option. This report must be customizable to University payroll deduction/payment plan settings based on a specific payroll deduction or payment plan type the University has already defined within the software.

6.23.5.5.1. customer6.23.5.5.2. which payment plan they are on6.23.5.5.3. total number of payments completed6.23.5.5.4. total cost of product6.23.5.5.5. product specific information6.23.5.5.6. payment plan start and end dates

LF14-057 Page 50 of 68 5/7/2023

6.23.5.5.7. calculated cost of each payment to be posted

6.23.6. (ME)Software module must include the ability to create custom reports on site when needed against any parts of the database. Describe your system’s ability to create custom reports to include, but not limited to the following:

6.23.6.1. Ad hoc reports able to be created on demand

6.23.6.2. Ability to save custom reports for usage at another time, saved to user Pprofile OR to system for any user to access (prefer both)

6.23.6.3. Ability to define parameters of report on demand with Graphical User interface

6.23.6.4. Ability to create reports similar to Crystal report style(not required to be Crystal format)

6.23.6.5. Ability to add department logos for sending of reports

6.23.6.6. Ability to define additional information fields on the final report printout

6.23.6.7. University mailing address/contact information6.23.6.8. Billing codes fields for invoices sent from reporting section (i.e. past due)

6.23.6.9. Charges for specific account within system)

6.24 (M) MAINTENANCE AND SUPPORT

6.24.1. Must cover each module purchased individually or collectively

6.24.2. Must include all Offeror supplied hardware and equipment

6.24.3. Must include software support through phone, email, chat, website and on-site technicians. List available hours.

6.24.4. Must include preventive maintenance such as troubleshooting, upgrades, training, performing backups and routine checks for maximum performance

6.24.5. Upgrades and preventative maintenance will be completed outside Transportation and Parking Services hours in order to prevent downtime. University understands this is not always possible and requires early notification of downtime during normal business hours

6.24.6. Upgrades to software must be provided to the University as soon as they become available for distribution. This must include Release Notes, Changes, Known Issues and Instructions.

6.25 (M) INSTALLATION REQUIREMENTS

6.25.1. (M)Contractor must install a complete and fully functional system including necessary

LF14-057 Page 51 of 68 5/7/2023

hardware and software. All data conversion from the existing computerized system (Iparq) and all future updates to the system. Provide technical support for the customization of reports and file formats and the conversation of existing data saved on the current system. This data conversion requires the migration and conversion of minimum 2 years of historical data from current system. Boise State University will work with successful Offeror to discuss further migration and conversion of older historical data based on Offeror’s capabilities.

6.25.2. (M)Contractor must work with Boise State's Network team to set up system on Boise State's Network.

6.25.3. (E) Boise State University prefers a contractor that can provide a separate test system version for training purposes if available.

6.26 (M) DATA MIGRATION 6.26.1. (M)Contractor must convert all data in University Parking Services existing system and

import to new system.

6.26.2. (M)Contractor must be responsible for the importing and conversion of existing data on the current system to the new system following University defined structure.

6.26.3. (M)Contractor must provide a reliable check method to ensure that all required data from the current system export files are passed to the new system.

6.26.4. (M)A reference file of the old system account numbers with a link to the new account numbers must be available in the new system.

6.27 IMPLEMENTATION REQUIREMENTS

6.27.1. (E) Boise State University is seeking to have software implemented and ready for go live within the month of July 2016. In your response please indicate your ability to meet this requirement. In addition to this, if you are unable to meet this requirement, please give a detailed description of delays and reasoning and provide a go-live date that you can meet based on the required specifications of this RFP.

6.27.2. (M) Proposer must provide qualified staff that must assist, consult, install, train and oversee the system implementation.

6.27.3. (M) Provide a documented implementation plan with reasonable timeline.

6.27.4. (M) Upon award of the RFP, signing of the contract and within ten (10) days of receipt of the University’s purchase order, the successful Contractor must provide a complete project timeline to the University’s Parking Services Department and the University’s Purchasing Department.

6.27.5. (M) Successful proposer must provide an integrated implementation process that incorporates on-line tools, on-site and web based technical services and on-site consultation.

LF14-057 Page 52 of 68 5/7/2023

6.27.6. (M) Successful proposer must assist in the development of reports prior to implementation.

6.27.7. (M) Successful proposer must provide an on-site support member during the launch of the new software to help and monitor any issues that may come up.

6.28 (ME)TESTING REQUIREMENTS

6.28.1. (ME) Offeror response to include testing timeline, and processes covered.

6.28.2. (M)The system will be tested thoroughly by the University prior to final acceptance.

6.28.3. (ME) A minimum of four (4) weeks of testing is to be conducted. The University’s current system and the new production system and new test system will run concurrently during the test period. In addition to the production system, a test system is to be provided to allow for testing of changes, upgrades, new maintenance to the system, while the current production system is still functioning and allowing for adequate time to test for any issues with the new system. Describe your proposed testing procedure to include the above listed criteria.

6.29 (M)TRAINING

6.29.1 (M)The successful proposer must send qualified technical personnel along with any other representatives the company chooses to send (sales reps must not be the only assistants) to the University to assist with the consulting, training, installing, and overseeing the system deployment process as necessary and determined through discussion between parties.

6.29.2. (M)Successful proposer must provide on-site training of University employees during implementation. Cost of training to be included within Offeror cost proposal, ATTACHMENT 4.

6.29.3. (M)5 day training of staff, minimum.

Example: Specific training for finance department, enforcement, management, customer facing individuals, and system admin training, etc.

6.29.4. (M)The University will provide hardware, we require that the raining be hands-on training in a live or test environment with a technical trainer conducting the training in a University located training or conference room, scheduled in advance.

6.29.5. (M)Training listed above must occur prior to go live

Provide description of on-site follow-up training and consultation as needed after implementation

6.29.6. (M)The University requires on-site Offeror follow-up training thirty days post implementation consisting of a minimum of 2 days of training. Must be included in your total cost, in the Cost Proposal, ATTACHMENT 4

.

LF14-057 Page 53 of 68 5/7/2023

6.29.5.1. (M)Training to individuals as needed while working with customers

6.29.5.2. (M)Include Offeror detailed plan for this training

6.29.7. (M)Beyond this requirement, the University requires Offeror response to include the hourly billable rate for any training requested by University on demand at future dates, must be included in Cost Proposal, ATTACHMENT 4.

6.29.8. (M)Access provided to any knowledge base information regarding work flow and proper procedures to complete tasks in the software for reference during working conditions as needed. Your proposal must include a description of training materials to be provided to University staff.

6.29.9. (M)The Offeror must identify if they offer a web-based training program to train personnel on software use for initial use or continuing education (for current and new staff).

6.29.10.(M) In response, Offeror must include an Offeror designed training outline detailing expected training per unit, and possible topics covered to explain training model the proposer will be providing.

6.29.11.Training materials must be provided with adequate time for University review prior to training.

6.29.12.University will give two weeks notice, in writing, when requesting additional training for the purposes of scheduling training outside of the training outlined in this RFP as mandatory. Offeror to submit their standard Billable Hourly rate for this type of training in the Cost Proposal, ATTACHMENT 4.

7. PROPOSAL REVIEW AND EVALUATION

7.1 The objective of the University in soliciting and evaluating proposals is to ensure the selection of a firm or individual that will produce the best possible results for the funds expended.

7.2 The proposal will be evaluated first as either “pass” or “fail,” based on compliance with Mandatory (M) and Mandatory/Evaluated (ME) requirements. All proposals that meet the Mandatory and Mandatory/Evaluated requirements will continue in the evaluation process. Proposals not meeting the Mandatory and Mandatory/Evaluated requirements may be found non-responsive.

LF14-057 Page 54 of 68 5/7/2023

7.3 The University will establish an evaluation team, who may consult with subject matter experts to review and advise on any portion of the response, to evaluate responses. Upon opening the responses, the Boise State University Purchasing Department will inspect the proposal for responsiveness. Under the facilitation of the Purchasing Department, the evaluation team will score the responsive proposals. The University may request online or other electronic style demonstrations from the top several scoring Offerors. If demonstrations are requested, the University may submit demonstration scenarios to Offerors. The team will discuss and finalize their scoring with the Purchasing Department. Prior to award, the apparent successful Offeror’s response may be forwarded to a representative(s) of the Office of Information Technology and/or General Counsel to confirm that the System will work within the University’s infrastructure and policies.

7.4 The criteria described below will be used to evaluate and score the proposals for the purpose of ranking them in relative position based on how fully each proposal meets the requirements of this RFP. Particular emphasis will be placed on the Offeror’s understanding of the RFP, quality of product/service, and the description of how the activities will be performed.

7.5 The scores for each category named in the Evaluation Criteria (Section 7.10), except references, will be normalized. Excepting cost, the proposal with the highest raw score per category will receive all available points for the category. Other proposals will be assigned a portion of the maximum available points, using the formula:

(Raw score of proposal being evaluated / highest raw score) x Total possible category points.

7.6 The Cost evaluation will be based on: Total Cost as listed by Offeror in the Cost Proposal, ATTACHMENT 4.

The cost evaluation will be based on the total cost proposed for required services as itemized in Attachment 4, “Cost Proposal.” The scores for the Cost Proposal will be normalized as follows: The proposal with the lowest overall total cost proposed will receive all the cost points as assigned in the Evaluation Criteria below. Other proposals will be assigned a portion of the maximum score using the formula:

Lowest Cost / other proposal cost x total possible cost points.

7.7 The cost points will be added to the rest of the evaluation points and proposals will be ranked by final total score. The number of total points for each Proposal will be determined by adding the normalized score for the “Business and Scope of Work Proposal” to the normalized score for the “Cost Proposal”.

7.8 Award will be made to the responsive, responsible Offeror whose Proposal receives the

highest number of total normalized points, including points for demonstrations, if demos are elected to be required by the University.

7.5 At the discretion of the University, demonstrations may be required. 7.6 Demonstrations, if required, will be conducted before the Notice of Intent to Award is

issued. Demonstrations will be required to be in-person, at Boise State University, set

LF14-057 Page 55 of 68 5/7/2023

up by the Offeror and provided at no cost to the University. It is possible that an Offeror will have only one week’s notice that they have been selected for a demonstration, so it is suggested that the Offeror have the ability to quickly set up a demonstration and be prepared to exhibit their product.

Demonstrations may include hypothetical scenarios, real life test samples, quality assurance issues, reporting and/or anything else the University is specifically interested in seeing or hearing about. The demonstration becomes an official part of the response. At its discretion, the University will choose either “Evaluated” or “Pass/Fail” demonstrations, as detailed below.

7.6.1 (E) Evaluated Demonstrations - At the discretion of the University, several of the highest scoring Offerors may be contacted to give an overview/demonstration of their System and respond to questions. Evaluated Demonstrations will be scored and normalized and added with the rest of the points to get an overall score for the Offerors from whom a demonstration was requested. Results of the demonstrations may result in adjustment of points awarded in the Business and Scope of Work Proposal, as the evaluation committee deems appropriate. Failure to successfully demonstrate functions of the System listed as mandatory in this RFP may result in rejection of the Offeror’s proposal.

7.6.2 (E) Pass/Fail Demonstration - Alternatively, the University reserves the right to require an in-person demonstration or web conference of only the top scoring Offeror. If this option is chosen, the evaluation is strictly Pass/Fail for the apparent successful Offeror. If the apparent successful Offeror fails, then the next highest scoring Offeror will be considered the apparent successful Offeror and the demonstration process may be repeated.

7.6.3 For those proposals making it to the demonstrations, the total evaluation points will be summed with the cost points and demonstration points (if requested) and the proposals will be ranked by final total score.

7.9 Offeror will be notified of the result of the solicitation process in writing. Written notification will be sent to the authorized signer designated on the signature page.

7.10 Evaluation Criteria:

Technical Proposal:Mandatory (M, ME) Submission Requirements Met Pass/FailBusiness Information (Section 4 & Attachment 3) 85 pointsVPAT (Section 5) 25 pointsData Security Assessment (Attachment 5) 25 pointsScope of Work (Section 6, Appendix A) 1265 points

Cost Proposal:Cost Proposal (Section 8, Attachment 4) 600 points

Total Points 2000 points

Demonstrations: (if needed, Section 7) 300 additional points

LF14-057 Page 56 of 68 5/7/2023

7.11 Response checklist reminder: This checklist is not intended as a complete list of requirements to respond to this proposal, but merely as a reminder of some of the required items. Failure to submit any of the following items or late submission of any of the following items may result in disqualification of your proposal. Mail your hard copy response to the buyer to be received by the closing time and date as specified in Section 1.1.

Section 2: Signature Page (Attachment 1) Number of original and copies of proposal Electronic version Redacted version / Trade Secrets Cover Letter Proposed modifications to Terms & Conditions Supplemental document or agreements Amendment Confirmation

Section 4: Experience Qualifications References (Attachment 3) Project Schedule

Section 5: Voluntary Product Accessibility Template (VPAT)

Section 6: Scope of Work (Appendix A) Vendor Security Assessment Form (Attachment 5)

Section 8: Cost Proposal (Attachment 4)

8. COST PROPOSAL

Pricing will be evaluated using a cost model that offers the University the best possible value over the initial term of the Contract.

8.1 (ME) Use the format established in Attachment 4 as your response to the Cost Proposal of this RFP. Altering the format may result in a finding that your proposal is non-responsive.

8.2 All costs associated with the specifications of the RFP must be included in the mandatory Cost Proposal. All proposed pricing will be firm/fixed and fully-burdened with all direct and indirect costs, and must include (but not be limited to), all operating, administrative, and personnel expenses, such as overhead, salaries, profit, supplies, per diem, travel (airfare and/or mileage), lodging, and quality improvement.

LF14-057 Page 57 of 68 5/7/2023

8.3 Standard, basic maintenance and support costs must be included on the Cost Sheet. For budgetary reasons, maintenance and support costs must be broken out from the rest of the costs, as a separate line item, on the cost sheet.

8.3.1 Licensing and maintenance/support costs are to include all software, including 3rd

party software necessary for System operation.

8.3.2 Annual maintenance/support cost shall include the right to upgrades, including major upgrades.

8.3.3 Annual maintenance/support costs are to be billed annually in advance based upon the acceptance date.

8.4 At the time of contract extension, if any, the costs will not exceed five (5) percent over the previous year’s costs without nullifying the Contract.

8.5 Proposal must include any applicable freight charges.

8.6 Prices must be FOB Boise State University. 8.7 Contractors are not allowed to direct bill expenses or to receive advance payments for

services not rendered.

8.8 Payment terms shall be NET 30. All invoicing is to be directed to the University Purchasing Department, Attn: Lori Farris, or other as designated by Boise State University

8.9 Boise State University doesn’t pay until a product/service is received, and will hold a portion of the total payment until acceptance. The University intends to pay per the finalized project management plan (including milestones and/or deliverables) as mutually agreed upon between Contractor and University.

Payment terms shall be NET 30.

8.10 In addition to the acceptance terms detailed in the State of Idaho Standard Contract Terms and Conditions, acceptance from the University will be based upon the satisfactory performance and deliverance of the milestones listed and agreed upon by University and Contractor in the Project Management Plan.

LF14-057 Page 58 of 68 5/7/2023

APPENDIX A

Scope of Work

(The Contractor’s proposal will be included in the Contract as Appendix A – Scope of Work)

LF14-057 Page 59 of 68 5/7/2023

ATTACHMENT 1 - SIGNATURE PAGE

THIS SHEET MUST BE FILLED OUT, SIGNED AND RETURNED WITH PROPOSAL. THIS SIGNATURE PAGE MAY NOT BE MODIFIED AND MUST BE HAND SIGNED IN BLUE INK. MODIFICATIONS TO THIS PAGE WILL DEEM THE ENTIRE QUOTE NON-RESPONSIVE AND NO FURTHER CONSIDERATION WILL BE GIVEN.

BY SUBMISSION OF THIS PROPOSAL TO BOISE STATE UNIVERSITY, THE UNDERSIGNED HEREBY OFFERS TO SELL TO BOISE STATE UNIVERSITY THE SPECIFIED PROPERTY AND/OR SERVICES, IF THIS PROPOSAL IS ACCEPTED WITHIN A REASONABLE TIME FROM DATE OF CLOSING, AT THE PRICE SHOWN IN OUR PROPOSAL AND UNDER ALL THE SPECIFICATIONS, TERMS AND CONDITIONS CONTAINED IN, OR INCORPORATED BY REFERENCE, INTO THE BOISE STATE UNIVERSITY’S RFP, AS MAY BE AMENDED PRIOR TO THE DATE HEREOF IN ACCORDANCE WITH THE TERMS OF THE SOLICITATION.

AS THE UNDERSIGNED, I ALSO CERTIFY I AM AUTHORIZED TO SIGN THIS PROPOSAL FOR THE OFFEROR AND THE PROPOSAL IS MADE WITHOUT CONNECTION TO ANY PERSON, FIRM, OR CORPORATION MAKING A PROPOSAL FOR THE SAME GOODS AND/OR SERVICES AND IS IN ALL RESPECTS FAIR AND WITHOUT COLLUSION OR FRAUD.

NO LIABILITY WILL BE ASSUMED BY BOISE STATE UNIVERSITY FOR AN OFFEROR’S FAILURE TO OBTAIN THE TERMS AND CONDITIONS IN A TIMELY MANNER FOR USE IN THE RESPONSE TO THIS RFP OR ANY OTHER FAILURE BY THE OFFEROR TO CONSIDER THE TERMS AND CONDITIONS IN THE RESPONSE TO THE RFP.

ADDITIONAL OR SUPPLEMENTAL TERMS AND CONDITIONS MAY BE CONSIDERED FOLLOWING THE DATE HEREOF ONLY IN ACCORDANCE WITH THE TERMS AND CONDITIONS OF THE SOLICITATION. (See Sections 2.1.3, 2.1.4, 2.3.11 and 3.4)

Failure to comply with these requirements may result in disqualification and your entire response will be deemed nonresponsive.

Respond by to: lorifarris@boisestate.edu, Lori Farris phone (208) 426-5449

Please complete the following information:

OFFEROR (Company Name)_____________________________________________________

ADDRESS____________________________________________________________________

CITY _________________________ STATE _______________ ZIP CODE _______________

TOLL-FREE #___________________________ PHONE #_____________________________

FAX #_________________________________ EMAIL________________________________

FEDERAL TAX ID / SSN #______________________________________________________

SIGNATURE PAGE MUST BE SIGNED & RETURNED FOR PROPOSAL TO BE CONSIDERED.

_________________________________________ ________________________________Signature Date

_________________________________________ ________________________________Please type or print name Title

LF14-057 Page 60 of 68 5/7/2023

ATTACHMENT 2OFFEROR QUESTIONS

PLEASE DO NOT IDENTIFY YOUR NAME OR YOUR COMPANY’S NAME OR PRODUCT NAMES OF INTELLECTUAL PROPOERTY IN YOUR QUESTIONS.

ADD ROWS BY HITTING THE TAB KEY WHILE WITHIN THE TABLE AND WITHIN THE FINAL ROW.

The following instructions must be followed when submitting questions using the question format on the following page.

1. Questions must be received by the Deadline to Receive Questions noted in Section 1.1 of the RFP or will be rejected and not considered.

2. DO NOT CHANGE THE FORMAT OR FONT. Do not bold your questions or change the color of the font.

3. Enter the RFP section number that the question is for in the “RFP Section” field (column 2). If the question is a general question not related to a specific RFP section, enter “General” in column 2. If the question is in regards to a State Term and Condition or a Special Term and condition, state the clause number in column 2. If the question is in regard to an attachment, enter the attachment identifier (example “Attachment A”) in the “RFP Section” (column 2), and the attachment page number in the “RFP page” field (column 3).

4. Do not enter text in column 5 (Response). This is for the University’s use only.5. Once completed, this form is to be emailed per the instructions in the RFP. The email

subject line is to state the RFP number followed by “Questions.”

LF14-057 Page 61 of 68 5/7/2023

RFP ST16-022, Enterprise Content Management System for Boise State UniversityOfferor Questions are due by 5:00 PM MT, per the date listed in Section 1.1 RFP Administrative Information.Question RFP Section RFP

PageQuestion

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

LF14-057 Page 62 of 68 5/7/2023

ATTACHMENT 3REFERENCES

INSTRUCTIONS TO THE OFFEROR:

Offerors will be scored on three (3) completed reference questionnaires. If more than the minimum number are received, the first three (3) received will be scored. If fewer than the minumum number of references are received prior to the closing date, the offeror will receive a zero (0) for all questions not scored and questionnaires not received. If multiple references are received from the same company only the first received will be accepted. Scores from reference questionnaires will be averaged.

The reference questionnaires must be from individuals, companies or agencies for whom the Offeror provided products or services that are similar in nature and scope to those requeisted by this solicitation, and within the last year from the posting date of this solicitation. References outside the requisite number of years and references determined by the University, in its sole discretion, to be not of a similar nature and scope to the products or services requested here will receive a score of zero (0). Determination of “similar” will be made by using the information provided by the reference in Section II General Information and any additional information provided by the reference, or otherwise obtained by the University. Only one (1) reference will be received/qualified per reference company. Boise State University may not be utilized as a reference.

REFERENCES MUST BE RECEIVED BY THE RFP LEAD (preferably by email), DIRECTLY FROM THE REFERENCE, IN ORDER TO BE CONSIDERED.

1. Offerors must complete the following information on page 2 of the “Reference’s Response To” document before sending it to the Reference for response.

a. Print the name of your reference (company/organization) on the “REFERENCE NAME” line.

b. Print the name of your company/organization on the “OFFEROR NAME” line.

c. Be certain that the RFP Closing Date and Time in Instruction 5, on the following page, is correct.

2. Send the “Reference’s Response To” document to your references to complete.

NOTE: It is the Offerors responsibility to follow up with their references to ensure timely receipt of all questionnaires. Offerors may email the RFP Lead prior to the RFP closing date to verify receipt of references.

LF14-057 Page 63 of 68 5/7/2023

REFERENCE QUESTIONNAIREREFERENCE’S RESPONSE TO:RFP Number: LF15-067      

RFP Title: Parking Management System

REFERENCE NAME (Company/Organization):_____________________________________

OFFEROR (Vendor) NAME (Company/Organization): _______________________________ has submitted a proposal to Boise State University to provide the following services: Parking Management System. We’ve chosen you as one of our references.

INSTRUCTIONS 1. Complete Section I. RATING using the Rating Scale provided.

2. Complete Section II. GENERAL INFORMATION (This section will be used to determine the similarity of the reference’s system to the proposed solution.)

3. Complete Section III. ACKNOWLEDGEMENT by manually signing and dating the document. (Reference documents must include an actual signature.)

4. Email THIS PAGE and your completed reference document, Sections I through III to:

RFP Lead: Lori Farris     

Email: lorifarris@boisestate.edu     

5. This completed document MUST be received by 3/21/2016 5:00:00 MDT (Mountain Daylight Time). Reference documents received after this time will not be considered. References received without an actual signature will not be accepted.

6. Do NOT return this document to the Offeror (Vendor).

7. In addition to this document, the University may contact references by phone or email for further clarification if necessary.

LF14-057 Page 64 of 68 5/7/2023

Section I. RATING

Using the Rating Scale provided below, rate the following numbered items by circling the appropriate number for each item:

Rating Scale Category Score

Poor or Inadequate Performance 0

Below Average 1 – 3

Average 4 – 6

Above Average 7 - 9

Excellent 10

Circle ONE number for each of the following numbered items:

1. Rate the overall quality of the vendor’s services:

10 9 8 7 6 5 4 3 2 1 0

2. Rate the response time of this vendor:

10 9 8 7 6 5 4 3 2 1 0

3. Rate how well the agreed upon, planned schedule was consistently met and deliverables provided on time. (This pertains to delays under the control of the vendor):

10 9 8 7 6 5 4 3 2 1 0

4. Rate the overall customer service and timeliness in responding to customer service inquiries, issues and resolutions:

10 9 8 7 6 5 4 3 2 1 0

5. Rate the knowledge of the vendor’s assigned staff and their ability to accomplish duties as contracted:

10 9 8 7 6 5 4 3 2 1 0

6. Rate the accuracy and timeliness of the vendor’s billing and/or invoices:

10 9 8 7 6 5 4 3 2 1 0

LF14-057 Page 65 of 68 5/7/2023

7. Rate the vendor’s ability to quickly and thoroughly resolve a problem related to the services provided:

10 9 8 7 6 5 4 3 2 1 0

8. Rate the vendor’s flexibility in meeting business requirements:

10 9 8 7 6 5 4 3 2 1 0

9. Rate the likelihood of your company/organization recommending this vendor to others in the future:

10 9 8 7 6 5 4 3 2 1 0

Section II. GENERAL INFORMATION

1. Please include a brief description of the services provided by this vendor, including the version number of the System in use:

2. During what time period did the vendor provide these services for your business?

Month:_________ Year:_________ to Month:_________ Year:_________.

Section III. ACKNOWLEDGEMENT

I affirm to the best of my knowledge that the information I have provided is true, correct, and factual:

____________________________________ ________________________________Signature of Reference Date

____________________________________ ________________________________Print Name Title

____________________________________ ________________________________Phone Number E-mail Address

LF14-057 Page 66 of 68 5/7/2023

ATTACHMENT 4COST PROPOSAL (ME)

Part 1. Cost Proposal: The completion and submission of this Cost Proposal is mandatory. No other proposer supplied pricing shall be evaluated for award. No other proposer supplied pricing shall constitute the pricing for any resulting Agreement.

Company & Product InformationCompany Name:

Software Details: (Name, Title, Modules Included, etc.)

Software Version Number:

Estimated # weeks for implementation, including all associated activities such as testing, acceptance and training:

TOTAL COST: Firm/Fixed, Fully Burdened Total Cost for implementation, training, licensing, technical support, maintenance, hardware, if applicable (required for the proposed system, in addition to existing hardware), and two (2) years of System operation(broken out in table below). This cost must include ALL items listed as Mandatory (M), (ME) in this RFP and all items listed as (E), which are included in your proposed system. This cost must include all permits and citations issued during the contract term.Optional Hourly, Billable Rates (for custom software development, future training, on-site needs, etc. in addition to what is specified in this RFP as mandatory)

Project Cost Breakdown (these should all be reflected in TOTAL COST, listed above.)Fully Burdened Technical and Functional Implementation Costs

2 (two) years of system operation. Must include all permit and citations costs.

LF14-057 Page 67 of 68 5/7/2023

Training

Maintenance, Support & Upgrades

Other (Additional hardware required, etc. List and Itemize all other costs)

Initial term of the Contract will be for an implementation phase plus two (2) calendar years. The implementation phase shall commence upon signing of a contract and terminate upon System acceptance and Go Live. The two-year (2) period shall commence immediately following implementation, commencing upon System acceptance and Go Live, and terminating two (2) years following the Go Live Date. Following the Initial Term, the parties may extend the Contract under the same terms and conditions, on an annual basis, upon mutual written consent. At the time of extension, the annual per unit renewal pricing will not exceed five (5) percent over the previous year’s costs without nullifying the Contract.

Part 2. Billing Procedure:

The invoice must include, but not be limited to:

1. Contract/PO number. 2. Total amount billed for the billing period.3. All services delivered during the billing period, identified by each item as reflected in the cost

matrix and the total for each.

Invoices are to be submitted to:

Boise State UniversityAttn: Lori Farris MS 1210 (or other as indicated by University)1910 University DriveBoise, ID 83725-1210

LF14-057 Page 68 of 68 5/7/2023