Attachment_D_System_Support_Agreement_-_Vendor_Management.docx

Attachment [D]

SYSTEM SUPPORT SERVICES AGREEMENT

The following terms apply to the System Support Services provided by Vendor to the City to support the System Functionality of the Vendor’s System. This Exhibit is incorporated into and supplements the terms and conditions of the Contract. In the event of conflict between the Contract and the System Support Services Agreement, the System Support Services Agreement shall control.

1. System Support Services. Vendor will provide to the City the System Support Services as set forth in this Exhibit to support Vendors System. System Support Services shall include, at a minimum, all necessary services for Vendor to maintain complete System Functionality as set for in the Contract and the Specifications. System Support Services shall also include any and all patches, enhancements, updates, upgrades and new versions of the System Software, including but not limited to the user mobile application and back office system... Any such patches, enhancements, updates, upgrades and new versions will be covered by the Support Services set forth in this Exhibit. Vendor shall also provide Support Services to answer operational and troubleshooting issues and provide the applicable issue resolution.

1.1 Scope of the System Support Services.

Vendor will provide to the City (as applicable) the application, infrastructure, and operational support for the Vendor’s mobile payment application service.

1.2 System Functionality Commitment. Vendor covenants and agrees that the System, as set forth in the Specifications (including any modifications made during the Implementation and Integration SOW) after completion of Acceptance Testing, and thereafter when covered by a Support Agreement will deliver the full System Functionality as set forth in the Specifications or Vendor shall repair or replace the non-conforming items causing such non-performance at Vendor’s cost.

2. DEFINITIONS. Capitalized terms used but not defined in this Exhibit have the meanings given in the Contract.

· “Content” means any information (including software, source code, documentation, materials, concepts, technologies, and data, including the City materials and Information) provided by or on behalf of the City to Vendor in connection with the System Functionality. Content includes any modifications to, or derivative works of, the foregoing materials, analytics or information entered into any Vendor database as part of the System.

· “Deliverables” means the software, hardware, services and all materials provided, developed, created or discovered in connection with the performance of Vendor's obligations under the Contract, along with accompanying Documentation.

· “Documentation” means all manuals, instructions and other documents (whether in hard copy, soft copy or web-based form) relating to, or necessary for, the use, operation or maintenance of any Deliverable, together with all enhancements, corrections, modifications and Specifications.

· “Defect” means a bug, defect or Defect in the System Functionality that prevents the System from performing according to the Specifications. Defects include operation and functionality defects, security defects, viruses and bugs.

· “Service Request” means a request for service for something other than a Defect. Examples of this are to change an authorized support representative, alter Content that the City does not have permissions to; or to change restricted roles.

· “Support Services” means, as applicable, the services to configure, integrate, host (if applicable), manage and provide access to applications, software, databases, platforms, infrastructure and other tools as set forth in the Contract, Exhibits, Work Orders, and any SOW. Support Services include any Vendor’s software, equipment, and technology necessary for Vendor to support the System Functionality of the Vendor’s Solution provided to the City.

· “System” means the hardware, software, Specifications, Documentation and all services required for Vendor’s solution to function as set forth in the Contract and Specifications

· “System Functionality” means the System’s functionality and performance based on the Specifications.

· “Specifications” means the technical requirements for, and performance standards of, the System and any Support Services or Deliverable as set forth in the Documentation, the Contract or an Order. Unless otherwise agreed in writing, Vendor may not modify Specifications previously made available to the City in a manner that would reduce, diminish or otherwise adversely impact such Specifications.

3. AVAILABILITY AND CONTACTS

Vendor will make technical support available to the City by toll-free telephone number, e-mail, voice mail and pager twenty-four (24) hours per day, seven (7) days per week. Vendor’s support personnel will provide the City with remote assistance for help in using and operating the System and to accept reports of bugs, defects or Defects in the System. Vendor will ensure that each of its personnel performing any Support Services are experienced, knowledgeable and qualified in the use, maintenance and support of the System.

Vendor Contact information for technical support is as follows:

Toll-Free Telephone Number:

Website:

E-Mail:

Voice Mail:

Vendor may change any of the foregoing contact information from time to time by delivery of not less than thirty (30) days prior written notice to the City, so long as at least one number or address is at all times available for each means of contact.

City Contact information for technical support:

4. SERVICE LEVELS AND SUPPORT

4.1. System Availability Service Level. Vendor’s System shall have an uptime guarantee of 99.95% during regular paid parking hours, excluding up to 120 minutes within the Maintenance Windows (as defined in Section 4.3. (e) below) minutes. This Availability extends up to the interface with the City’s back-end systems and any Third-Party service providers.

Vendor shall report date, time and duration of non-responsive external interfaces as applicable.

4.2. System Performance Service Levels.

4.3. General Support

(a) Vendor will provide all necessary resources to ensure the City has complete System Functionality (in accordance with the System Availability guarantee), technical expertise for troubleshooting and issue resolution, and all applicable updates and upgrades to the System.

(b) Vendor will provide business hour telephone and e-mail support from the hours of 7 am Pacific Standard Time to 8 pm Pacific Standard Time Monday through Friday, for assistance in identifying and resolving Defects (in accordance with the Severity Levels and Response Times set forth in Section 4.3 and 4.4 below) and will be available to answer questions related to the operational use of the System.

· In addition to the business hour support, Vendor shall provide the City 24x7 support for a period of forty-eight (48) hours after any update or upgrade to the System to assure the System is stable and providing full System Functionality.

(b) Vendor will monitor the System to ensure that the System is functioning in accordance with the Specifications.

(c) Vendor will immediately report all outages, including performance degradation, to the City contact person or email alias identified by the City.

(d) Vendor may schedule upgrades and maintenance for the System between the hours 12 am and 4 am Pacific Time (the “Maintenance Window”);

(e) Any non-scheduled or emergency maintenance that impacts the System must be communicated to the City immediately and tested appropriately by the City prior to implementation. Failure to notify the City of a Maintenance Window or unscheduled or emergency maintenance that results in one or more Severity 1 or Severity 2 incidents (as set forth in Section 4.4 below) in a given year will constitute a breach of this Exhibit.

4.4. Severity Levels. When Vendor initially detects a Defect with the System, or when the City reports to Vendor a Defect with the System, the Defect will be promptly classified by the reporting party in accordance with the following severity incident guidelines:

Severity 1

The System is unavailable, OR a critical business function is inoperable, OR performance of the System is unacceptable AND there is no work around in place.

Severity 2

A Critical Business Function is unavailable/operating in an unreliable manner OR Performance of the System is unacceptable AND there is a business approved temporary workaround.

Severity 3

A Non-Critical Business function is unavailable/operating in an unreliable manner OR Performance of the application does not meet agreed to performance targets. Severity Level 3 Defects need to be fixed or a business approved work around identified that can remain in place until a permanent solution is implemented.

4.5. Incident Response Service Level. Vendor will respond to the City and provide Initial Responses, Temporary Resolutions and Final Resolutions in accordance with the time requirements set forth in the table below.

For purposes of Section 4.5, the following definitions apply:

(a) “Initial Response” means a written or electronic response from Vendor to the City regarding a reported or discovered Defect acknowledging receipt.

(b) “Temporary Resolution” means a City approved temporary fix or patch that Vendor has implemented and incorporated into the Support Services to restore the System Functionality in accordance with its Specifications until the Final Resolution is available.

(c) “Final Resolution” means a City approved permanent fix that Vendor has implemented and incorporated into the software or hardware to restore System Functionality in accordance with its Specifications.

4.6 Escalation. In the event the agreed upon response/resolution timeframes in the SLAs are not being met, internal and external escalation procedures may be required. There are many reasons this may occur including time constraints, frequency of occurrence, or other potential risks associated with a given problem. In this event, the City shall follow the escalation procedures as outlined below to communicate the issue and expected response time while priority of the request remains unchanged.

To Escalate a Help Desk Ticket:

· Update the Ticket by providing an explanation as to why the Ticket is being escalated and any new or different business impacts associated with it.

· Call Vendor Help Desk and communicate the request to escalate the Ticket.

· The assigned resource or other analyst or technician will contact the person escalating the Ticket within the defined Help Desk ticket Response Time in accordance with the SLA.

· If progress or the resolution timeframe is still unsatisfactory, the City POC may escalate to the Vendor Support Service Delivery Manager.

Contact Name

Contact Phone

Contact Email

· If progress or the resolution timeframe is still unsatisfactory, the City POC may escalate to the Vendor VP/Director of Support Services.

Contact Name

Contact Phone

Contact Email

5. SERVICE LEVEL PERFORMANCE REMEDY. In the event Vendor does not meet the Support and Service Levels set for in this Exhibit and the City considers such performance to have critical impact to the functionality and performance of the System, Vendor shall immediately, upon request from the City, provide the following:

· A formal problem statement that states clearly the issues raised by the City

· A root cause analysis of the problem and a written corrective action plan

· A formal management reporting process for the City to see specific results of the corrective action plan

· A specific timeframe for the problem to be resolved If after these steps have been followed and the problem continues to have an impact on the System, it will be considered a material breach of this Exhibit and the City may, at its discretion and in addition to any and all other remedies available at law or at equity, terminate the Contract. Upon such Notice of Termination Vendor shall support the City by covering all costs of operation while the City finds an alternative solution and Vendor shall provide all required services to help support the transfer of data from Vendor’s System to the City’s new system.

6. TRAINING AND PROFESSIONAL SERVICES. As part of the Support Services, Vendor will provide the City with gap training/documentation that impacts the operation of the System as a result of any updates or upgrades to the System Functionality. Such training will be provided to the City at no additional costs and shall be structure to allow the Vendor to present the information to the applicable audience as efficiently as possible. Any additional professional services Vendor provides other than those incidental to facilitate the Support Services will be provided under a separate statement of work.

7. ONGOING PERFORMANCE/LOAD TESTING. Systems Performance regression testing shall be done after any major functionality modification, Service Pack implementation, or any other patching effort is made within the System.

Vendor shall provide Documentation to the City on all System enhancements, modifications, and upgrades including but not limited to the System test plan, test strategy, Defect Management, UAT scenarios, and release checklist.

Vendor shall complete full functional testing on the overall System prior to release to the City and resolve any identified bugs. Vendor shall perform Regression (via automated test scripts), Smoke and Sanity testing and prepare UAT scripts. Vendor shall provide the UAT scrips to the City and provide the ability to update or extend the UAT scripts for the City’s internal testing purposes.

Vendor shall perform performance testing after all functionality changes to the System. Vendor shall write performance test scripts and validate through regression test execution. During performance test execution and results analysis, Vendor will work with the City to make or recommend the appropriate tunings to maximize System performance, retesting as necessary to ensure SLAs are met, and to optimize the System Functionality.

Once the System passes the established tests during the System enhancement or upgrade, Vendor shall release the System to the City’s production environment.

8. MEASUREMENT AND REPORTING.

8.1. Monthly Reports. In addition to any measurement and reporting set forth in an applicable Exhibit/SOW, by the fifth business day of each month, Vendor will provide to the City a monthly written report that includes the previous month’s metrics for the Availability Service Level in Section 1.1 (i.e., showing availability percentage for the prior month) and the Incident Response Service Level in Section 1.4. Vendor will also include any other information reasonably requested by the City from time to time.

8.2. Regular Reviews. Vendor will engage in regular review sessions in a jointly agreeable cadence with the City to analyze any on-going problems with the System Functionality and the Support Services, analyze the root causes of both resolved and unresolved problems, and explore and employ methods of improving the Support Services generally.

8.3. Review of Defects and Enhancements. The Vendor and the City shall jointly agree on the date, duration and time for a review of service requests, defects, upcoming releases, enhancements and any additional enhancement requests. This meeting shall occur Monthly, unless otherwise agreed to, and be either a Web Conference Call or and onsite meeting.

8.4. Service Request/Defect Tracking. The Vendor shall operate and maintain a Service Request and Defect Tracking system for the life of the System Support Agreement. No fewer than five (5) City staff shall have access to this system for the purpose of tracking the incident, adding relevant information and observing status. This system will support the inclusion of a link to the City Service/Defect Tracking information.

9. BUSINESS CONTINUITY AND DISASTER RECOVERY.

A. Recovery Time Objective (RTO):

· Critical function within business hours (7AM to 7PM Pacific Time): 1 hour

· Critical function outside business hours: 2 hours

· Non-critical function within business hours (7AM to 7PM Pacific Time): 2 hours

· Non-critical function outside business hours: 8 hours or within next day business hours B. Assumptions

· The RTO is defined above assumes the System will have ability to operate in a “disconnected” mode when there is an outage (planned and unplanned)

· Critical vs non-critical functions will be identified during Functional Design C. Recovery Point Objective

· 1 minute or less data loss

9.4 Vendor will be required to notify the City of Seattle within 24 hours of any cybersecurity or data breach that affects the mobile payment system or data of any active or former users in Seattle. The proposal should include a description of this notification process. The selected vendor must be willing to include a contract clause addressing cybersecurity incident management for any breaches or incidents that may impact the City data and systems. It must include:

. Incident notification . Collaboration and Support . Liability and Remediation

RFP responses should summarize how the Vendor meets these certification and notification requirements.

10. APPROVED LOCATIONS. Vendor and its authorized subcontractors will perform all Support Services from, and process, transmit, and store all Content in the United States unless non-United States locations are agreed to by the parties and identified in an applicable Exhibit, or an applicable SOW (the United States and any other such location, “Approved Locations”). Vendor will not move, process, transmit or store Content outside of the Approved Locations, unless required to do so in order to comply with the requirements of a governmental entity having jurisdiction over it (e.g., subpoenas or court orders). Vendor must (a) provide the City with reasonable advance written notice of the requirement (no less than fifteen (15) days in advance of any Approved Location change); (b) provide the City with a reasonable opportunity to challenge such requirement and protect the Content; and (c) cooperate with the City in such efforts.

ENHANCEMENT REQUESTS

Enhancement Requests shall have the business requirements documented by the City. Vendor will review these requests to determine if there is an interest in including the new feature in the main product roadmap.

In the main product roadmap type of enhancements, Vendor will provide a high-level estimate and functional design for review by the City for prioritization. Accepted features will be deployed by Vendor in the normal course of business and provided as part of the License costs.

Should the schedule for implementation of an approved road map enhancement not meet the City’s needs or if an enhancement was not approved but the City believes that they will want that enhancement regardless, the City may ask Vendor for an estimate of the Enhancement Request. These Enhancement Requests shall be priced using the Vendor’s Rate Card included in the Contract.

The City and Milestone will negotiate terms and schedule for any Enhancement Request implementation including rebates for City developed Enhancement Requests that are integrated to the Milestone Roadmap.

12. PAYMENT. Payment for the Support Services will be as set forth in the applicable Exhibit or SOW. The City will pay fees for the Support Services in accordance with the payment terms set forth in the Contract.

13. TERM. The term of this Exhibit will be coterminous with the Contract, and each applicable Exhibit or SOW will have the term set forth therein.

14. INTERPRETATION. This Exhibit is intended to be consistent with and supplementary to the Contract. However, in the event of a direct conflict between language included in this Exhibit and language included in the Contract, the provisions of this Exhibit will control solely with respect to the Support Services.

SEATTLE IT - SYSTEM SUPPORT SERVICES AGREEMENT PAGE 8 OF 8

REVISED – OCTOBER 11, 2019