Kony Service Level Agreement

1. Definitions.

1.1. “Hosted Software” means the hosting service performed by Kony for Customer.

1.2. “Customer Application” means a Kony Platform-enabled mobile application developed by or for Customer or the pre-configured mobile application included in the Kony Pre-Packaged Application that is configured for its use.

1.3. “Program” has the meaning assigned to it in the Subscription License Agreement.

1.4. The Kony cloud is comprised of the Kony platform software stack and the Kony cloud foundation that contains the required APIs, automation, security, scalability and monitoring to run the Kony Platform. The infrastructure for the Kony cloud is provided by Amazon's AWS cloud. Kony is an official partner and reseller of AWS services.

1.5. The Kony Server product is provided on the Kony cloud as “App Services” and is deployed as a dedicated single-tenant environment.

1.6. The Kony Sync product is provided on the Kony cloud as “Sync Services” and is deployed as a dedicated single-tenant environment.

1.7. The Kony Messaging product is provided on the Kony cloud as “Messaging Services” and is a multi-tenant shared environment

1.8. The Kony Enterprise Mobility Management (EMM) product is provided on the Kony cloud as “Management Services” and is a multi-tenant shared environment

1.9. The terms and service levels under this agreement are between the Customer and Kony. No additional contract, agreement or terms are granted or required between the Customer and Amazon.

1.10. Each Kony Cloud environment includes Redundancy and Failover capabilities. Redundancy provides at least two instances of every system component required for the operation of the system. Failover provides the ability to automatically route request or workloads to the second instance of a system component if one of the components becomes unavailable. Redundancy and Failover are achieved through a combination of the software deployment architecture and the Redundancy built-in to the infrastructure hosted by Amazon AWS. The Kony application cluster is deployed behind a load balancer within the same Amazon AWS Region, but across at least two Amazon AWS Availability Zones in two separate physical datacenters. The application cluster deployed will consist of a minimum of two server instances to provide Redundancy, and additional instances added or removed based on server resource usage. The allowed max scale out capacity limit is dynamically adjusted based on the app session consumption rate or number of concurrent licensed user interacting with the system using a ratio determined by Kony to easily meet the resource needs of a typical application and will include the ability to scale up to an increased number of concurrent license users at no cost to Customer. Database layer redundancy is provided through the use of the Amazon AWS RDS Multi-AZ deployment model offering redundant database servers in two separate availability zones. For more information about Amazon Availability zone, please visit: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html.

2. Hosting Support Services Overview

2.1. HostingSupport Services will include:

· Email and Web Portal support for hosting incidents on a 24x7x365 basis

· Telephone support for Severity 1 incidents on a 24x7x365 basis

· Error resolution and escalation support

· 24x7x365 access to Kony’s Support Portal

· Access to technical support bulletins related to Hosted Software

Customer may contact Kony through the following means:

Web: https://basecamp.kony.com

Phone: Telephone: 1 (888) 323- 9630 (Press 5 for Severity 1 Incidents)

2.2. Definition of Support Severity and Response Times: Kony will provide support services based on Errors logged by Customers in Kony’s Support Portal (following Customer’s initial investigation and confirmation that the Error is related to the Hosted Service). Errors will be logged by Customer in accordance with the severity level definitions below. Kony and Customer will work together to achieve consensus should there be any disagreement in assigned severities. Severities assigned to an Error may change with time if mutually agreed to by both parties. For example, an issue may be initially categorized as Severity Low and upon further investigation or after a certain period of time, it may be mutually concluded by Kony and Customer that the issue should be reclassified as Severity Medium. Response and Target Resolution times for Errors will be measured from the time the Errors logged by Customer into Kony’s Support Portal. Error activity will subsequently be managed and tracked through the Support Portal. The Customer will have access to audit or review response and resolution times of Errors logged through the Support Portal.

“Error” means a hardware infrastructure or server software issue which renders the operation and use of the Hosted Software in non-conformance with its documentation or the specified SLA’s.

A “Critical” or “Severity 1” Error renders the Hosted Software completely unusable or nearly unusable or introduces a high degree of operational risk. No Workaround is available that would effectively enable the Error to meet the classification of a Severity 2 or lower. Until this Error is resolved, the Hosted Software usage is essentially halted. A large number of users and/or the Hosted Software performance is severely impacted.

A “High” or “Severity 2” Error renders the Hosted Software consistently unavailable or obstructed, and causes a moderate level of hindrance or risk. Workarounds may be available, but use of the Hosted Software or performance is acutely degraded and causes continuing operational risk. A moderate number of users are significantly impacted, but overall the Hosted Software is operational and functional.

A “Medium” or “Severity 3” Error is an inconvenience or causes inconsistent behavior, which does not impede the normal functioning of the Hosted Software. It could be an Error that occurs inconsistently and affects small number of users. It may also contain visual errors where the graphical display of the Program is not ideal, but still functioning correctly.

A “Low” or “Severity 4” Error has a small degree of significance, or is a minor operational or configuration issue, or is a “one off” case. A “one off” case occurs when the Error occurs infrequently and cannot be replicated easily. These are Errors that do not impact the daily use of the Hosted Software. A Low Error is something does not affect normal use, and can be accepted for a period of time, but user would eventually want to be fixed.

2.3. Error Investigation & Reporting Procedures

In order to correct an Error, an initial phase of investigation is necessary. When an Error is reported by a user of the Hosted Software, Customer’s support personnel shall first perform an initial investigation to ensure that the Error is not caused by improper usage of the Hosting Service; Customer developed / provided software, any dependency on Customer back-end systems, or due to third party applications/software being used by Customer. Once this process is completed and Customer’s support team has investigated the issue and reasonably determined it is Hosting Service related, the Error will be reported to Kony via Kony’s Support Portal.

Customer must report Error(s) in sufficient detail to enable Kony to identify and reproduce the Error. Delays in supplying such information by Customer may impact the Response/ Target Resolution timelines.

An initial report should include (but not limited to) the following, as applicable based on the nature of the Error:

· A general description of the Error and its characteristics

· The number of occurrences or frequency of the Error

· Steps to reproduce the Error

· The exact text of any error messages reported by the Hosting Service

· Screenshots if applicable

· The mobile device type and carrier

· Time of occurrence of the issue(s) (with time zone)

On receipt of the Error and initial investigation details from Customer, Kony will begin diagnosing the Error and will assist Customer until: (i) the Error is resolved or a workaround is provided; (ii) is assigned back to Customer as a “Customer issue” if the Error is deemed to be Customers responsibility; or (iii) assigned to a Third-Party (e.g. Oracle for a Java Virtual Machine runtime issue) if the Error is deemed to be a Third Party’s responsibility except in the case that the Third-Party is Amazon AWS where the Error will remain assigned to Kony. Kony and Customer will work jointly during the investigation such that the current status is visible to both parties. All Errors reported in the Kony support portal will be responded to in accordance with the Severity level as described below.

2.4. Support Response and Resolution Table

Production Infrastructure Errors

Support Plan	Severity	Response	Resource Assigned Within	Updates	Target Resolution*
Enterprise	Critical (S1)	1 Hour	1 Hour	Every 1 Hour	4 Hours
	High (S2)	2 Hours	2 Hours	2 Hours	8 Hours
	Medium (S3)	1 Business day	1 Business days	2 Business days	5 Business days
	Low (S4)	2 Business days	Based on Resource Availability	Every Week	Next major software update (quarterly)

Non-Production Infrastructure or Software related Errors

Support Plan	Severity	Response	Resource Assigned Within	Updates	Target Resolution*
Enterprise	Critical (S1)	1 Hour	2 Hour	Every 2 Hours	1 Business Day
	High (S2)	2 Hours	4 Hours	Every 24 Hours	7 Business Days
	Medium (S3)	1 Business day	2 Business Day	Every 48 Hours	21 Business Days
	Low (S4)	2 Business days	Based on Resource Availability	Every Week	Next major software update (quarterly)

· * Kony will make every effort to achieve the Target Resolution times, however, the time needed to provide a correction may vary depending on the specific nature of the Error requiring correction. In the case of a resolution that includes a software update, additional time may be required to deploy the update to the production environment due to maintenance windows, coordination with customer app rebuild, customer system updates, customer maintenance windows, customer testing, or other deployment activities that must occur after the Error has been resolved within the software.

· Customer will ensure that a resource is assigned to work with Kony to provide information or verification on an ongoing basis, until the issue is resolved.

· In the event of multiple reported Errors being worked concurrently, unless otherwise requested by Customer, Kony will prioritize based on Severity starting with Critical (S1) and then on the time the Error was reported starting with the oldest. The SLA will apply to the top two Errors being worked based on this priority.

· In the event Kony’s response time to an Error is negatively impacted due to Customer’s delayed response to Kony's request for additional information to correct an Error, the response times provided above will be extended by an amount of time proportionate to such delay.

· Both parties may agree that due to technical dependencies and other factors, certain Errors classified as Medium and Low may be resolved in the an appropriate scheduled maintenance window. Customer acknowledges that Kony does not and cannot guarantee that all Errors can or will be corrected.

· System changes for upgrades or patches will be applied during Scheduled Maintenance unless the change is required to restore system availability.

· Business Days are Monday through Friday excluding US national Holidays.

Service Level Reporting

Each month Kony will provide Customer with a report detailing its adherence to the Service Levels for reported Errors for the prior month.

2.5. Escalation Table

Kony provides an escalation mechanism to ensure that Critical and High issues are addressed in a timely manner. Escalation is triggered when an issue is not resolved within the defined Target Resolution Time Table set forth in section 2.4 above.

The escalation time windows for resolution, and contact matrix are as follows;

Production Infrastructure Errors

Support Plan	Severity	Level 1	Level 2	Level 3
Enterprise	Critical (S1)	4 Hours - Support Manager	12 Hours – VP of Account Management	24 Hours – COO
	High (S2)	8 Hours - Support Manager	24 Hours – VP of Account Management	2 Business Days – COO

Non-Production Infrastructure and Software Errors

Support Plan	Severity	Level 1	Level 2	Level 3
Enterprise	Critical (S1)	1 Business Day - Support Manager	3 Business Days – VP of Account Management	1 Week – COO
	High (S2)	7 Business Days - Support Manager	3 Weeks – VP of Account Management	6 Weeks – COO

3. Service Level Description

Kony provides Hosted Software within a single Amazon AWS region across at least two Amazon AWS Availability Zones. All systems are managed through the Kony Network Operations Center (NOC) in India, which is staffed 24 hours per day, 365 days per year.

3.1. In addition to the service level “Support Response and Resolution” set forth in Section 2 above, Kony provides Service Level Agreements (SLA) on System Availability, Sync Time and Response Time as set forth below.

“Downtime” is defined as a periodof time when the Hosted Software and Kony Platform is unavailable or not accessible to Customer and its Users. Downtime does not include performance impacts during a customer initiated app deployment at which time the associated servers may recycle to update their runtime code. Downtime also excludes Scheduled Maintenance Windows where Kony performs upgrades or maintenance to the Hosted Software, during which time the system may not be available, or may not perform at the committed SLA levels. Downtime also excludes any performance impacts due to failures in the Customer’s website, Customer provided software or Customer back-end data sources which cause the Hosted Software functionality to be rendered unavailable or operating with degraded performance.

“Scheduled Maintenance Windows” means periods during which the Hosted Software may be unavailable due to scheduled maintenance windows. Kony will use commercially reasonable efforts to avoid impacting the System Availability or Average Response Time of the system and any other adverse impact on use of the Kony Cloud and Hosted Software during Scheduled Maintenance and to schedule the maintenance windows during off-peak times. The total Scheduled Maintenance time will not exceed 6 hours per calendar month for each cloud service. Customers will be notified via email of Schedule Maintenance Windows at least one (1) month in advance.

“System Availability” is defined as: Total number of minutes in a given calendar month MINUS Total number of minutes of Downtime in a given calendar month, DIVIDED BY Total number of minutes in a given calendar month.

“App Services Response Time” is defined as the time taken to process a request received from the device to the Kony cloud app services component of the Hosted Software, to the time it responds to the mobile device barring custom application code execution time. Response Time also excludes any delays due to the mobile wireless network and the time required to retrieve and process data from the Customer owned or other external back end systems. This time can be measured through the reporting capabilities of the Kony Cloud using the internal service duration metric available in the service detail report. The Response Time SLA shall not apply to the additional processing time required as a result of custom logic within the Customer Application including, but not limited to preprocessors, java connectors, response parsing, and post processors.

“Sync Services Response Time” is defined as the time taken to process a request received from the device to the Kony cloud sync services component of the Hosted Software, to the time taken to return with a response to establish the data transfer session. The Sync Service ResponseTime excludes any custom code execution time or delays delivering the response due to the mobile wireless network. The Sync Services Response Time also excludes the time to connect to the backend datastore and transfer the data required to sync the device to the backend datastore as this is dependent on the size of the data and the network speed of the device. The Sync Services Response Time can be measured using the performance reports available in the Kony cloud sync services admin console. In the event that the data transfer time is limited due to the network bandwidth between the Amazon AWS network and the enterprise datacenter, the Customer may request Kony will work with Amazon AWS Support and the customer’s enterprise datacenter network team to establish a dedicated network connection using the AWS DirectConnect service as defined at http://aws.amazon.com/directconnect.The additional network costs will be passed through from Amazon as-is to the Customer.

“Messaging Services Response Time” is defined as the time taken to process a request received from the device to subscribe or unsubscribe for push notifications to the Kony cloud messaging services component of the Hosted Software, to the time it responds to the mobile device barring the time taken to transmit data over the mobile wireless network. This time cannot currently be measured through the reporting capabilities of the Kony Cloud, but customers can open a support ticket to have the Kony cloud hosting support team verify the response time if they suspect it is not performing within the defined SLA. The Kony cloud messaging services administration console will provide a performance report in a future release to display the average service response time.

“Management Services Response Time” is defined as the time taken to process a request received from the device to the service endpoints provided by the Kony cloud management services component of the Hosted Software, to the time it responds to the mobile device barring the time taken communicate with an external system or transmit data over the mobile wireless network. This time cannot currently be measured through the reporting capabilities of the Kony Cloud, but customers can open a support ticket to have the Kony cloud hosting support team verify the response time if they suspect it is not performing within the defined SLA. The Kony cloud management services administration console will provide a performance report in a future release to display the average service response time.

System Availability & Response Time SLA Commitment

Metric	SLA
Monthly System Availability	99.95% Monthly
App Services Response Time	1.0 second
Sync Services Response Time	2.0 seconds
Messaging Services Response Time	2.0 seconds
Management Services Response Time	2.0 seconds

Program Support Services

A. Kony will use all commercially reasonable efforts to provide updates of the Programs to function with new releases of currently supported mobile device manufacturer’s Operating Systems “OS” as per the timelines below:

(i) New releases of currently supported manufacturer’s OS or SDK - within 30 business days “from General Availability (GA) release by the manufacturer to the developer community or the next GA” release of Programs, whichever is later. Customer must update new GA plugins made available by Kony to: a) take advantage of the new features or enhancements in the Programs current feature set; and b) overcome any backward compatibility issues with the newer versions (major, minor) of currently supported OS’s or SDK’s. New GA plug-in’s may require testing to ensure the Customer mobile application is optimized on/for the new OS’s and SDK. In case there are any backward compatibility issues identified by Kony on the new platform GA version, they will be communicated through release notes and necessary build scripts will be provided with the platform plug-in, where applicable.

(ii) New versions of currently supported mobile browsers or new form factors for devices using the currently supported OS and Mobile Browser - within 30 business days from GA release by the manufacturer to the developer community or next GA release of Programs, whichever is later. Customer must implement new GA plug-in’s to take advantage of the new releases of currently supported Browsers or new form factors. New GA plugins may require testing to ensure the Customer mobile application is optimized on/for the new Browser. In case there are any backward compatibility issues identified by Kony on a new platform GA version, they will be communicated through release notes and necessary build scripts would be provided with the platform plug-in, where applicable.

B. Kony will use all commercially reasonable efforts to provide updates to the Program in a new GA release, to function with net new OS within 90 business days from GA release of the new OS to the developer community, subject to Kony’s determination that the net new OS is commercially viable to support. Net new OS GA releases will ensure forward compatibility, in the sense that mobile applications developed on previous versions of OS are fully compatible with the new OS and not necessarily supporting the new features released with the new OS. Customer’s must implement new GA plugins to overcome any backward compatibility issues with the new OS versions or take advantage of the new OS features. New GA plugins may require testing to ensure the Customer mobile application is optimized on/for the new OS. In case there are any backward compatibility issues identified by Kony with the new platform GA version, they will be communicated through release notes and necessary build scripts will be provided with the platform plug-in, where applicable. Kony reserves the right to support to a new OS’s / browsers / devices at its sole discretion.

C. Kony will provide Support Services for the version of Programs licensed hereunder to Customer as of the effective date (“Current Version”) for a period of time equal to twelve months from the date of the next immediate release of a new version of the Program (“New Version”). Support for the prior version, during the time period referenced above, after the release of the New Version will consist of limited support (hotfixes and patches only, no enhancement or re-releases). If Customer upgrades to New Versions of the Programs, the upgraded versions of Programs will be considered the Current Version for purposes of this Section.

D. The list of Kony supported versions of 3rd party software is listed in the Kony Studio and server installation guides and can be viewed at https://basecamp.kony.com/.

E. Subject to Kony’s obligations under Section (C) above, Kony will upon request and on a time and material basis at rates currently in effect, provide services to ensure either versions of Programs remain compatible with older or new publically supported versions of 3rd party software, not supported by the Programs (as evidenced by such 3rd party’s notice generally made available to the public).

F. Kony will revise the Programs documentation to reflect any corrections, enhancements or updates no later than the time of official releases of Programs to customers.

G. General releases schedule for the Programs will be published on Kony Base Camp (http://basecamp.kony.com) site for on-premise enterprise customers and also published on the standard Kony Studio Eclipse update site that enables the Customer to download and install the updates from within Kony Studio. Hot fix / defect fix releases, if any, are also published on both sites. Patches or fixes will be provided based on priority, either as a Program update or as part of the next scheduled Program release. Customers will be provided credentials to access this abovementioned Kony Base Camp site for on-premise server installation software if required.

H. Kony will post notices (new releases dates for Programs, new supported devices & OS’s etc.) on Kony Base Camp for on-premise customers, along with regular announcements/ newsletters.

I. A list of supported devices, OS and browsers is published as part of the standard Kony documentation. Devices, browsers and OS versions not published on the “supported” list may or may not operate with current version of the Programs. For non-supported or older versions of devices, browsers and OS versions, hotline support is available on a time and material basis.

Exclusions: Kony will have no obligation of any kind to provide Support Services of any kind for problems in the operation or performance of Programs to the extent caused by any of the following: (a) non-Kony supported software or hardware products or use of the Programs in conjunction therewith; (b) modifications to Programs made by any party other than Kony; (c) Customer’s or its users’ use of Programs other than as authorized in the License Agreement or as provided in the documentation; or (d) Customer’s or its users’ use of other than the version of Programs identified in C above or any error corrections or updates thereto provided by Kony (each an “Excluded Error”). If Kony determines that it is necessary to perform Support Services for a problem in the operation or performance of Programs that is caused by an Excluded Error, then Kony will notify Customer thereof as soon as Kony is aware of such Excluded Error and Kony will have the right to invoice Customer at Kony’s then-current published time and materials rates for all such Support Services performed by Kony.

 

Software Updates, Maintenance and Support

A. Kony releases a new major version of its software about every 12-18 months and follows a ‘Service Pack’, ‘Fix Pack’, and ‘Hot Fix’ approach to providing software updates, maintenance and support. A ‘Hot Fix’ is created in response to a specific customer support request where a product update is required to resolve the issue. The goal of a hot fix is to release a fix as quickly as possible for a specific customer. The details of hot fixes are not published publicly because they are customer specific at first. Hot Fixes are bundled together in a later Fix Pack and then published publicly for any customer to consume. Fix Packs are released about every 6 weeks, but that schedule may vary depending on how many fixes are pending and the complexity of testing, packaging and releasing the Fix Pack. In some cases, small feature additions or enhancements will be included in a Fix Pack. A ‘Service Pack’ adds new functionality to a major version with the goal of complete backward compatibility. A Service Pack are released about every 3-4 months and will also include all Fix Packs since the previous Service Pack.

B. Kony strongly recommends that customers stay current with each Fix Pack and Service Pack by applying them as quickly as possible. Staying current helps customers maintain the highest level of security, stability, and performance. Each Fix Pack and Service Pack is designed to be backward compatible to minimize any disruption to customers when applying these updates. When customer specific Hot Fixes are required, it is Kony’s policy to add that hotfix to the most recent Fix Pack for the Customer’s current Service Pack level. For example, if a Customer is on V8, Service Pack 1, and Fix Pack 2 then their Hot Fix will be on Service Pack 1 but may be applied to a later Fix Pack such as Fix Pack 4 if that is the most recent available Fix Pack for Service Pack 1. Fix pack 4 would have updates from fix pack 1, fix pack 2, fix pack 3 and some more. Following this approach has proven to be the most effective in delivering the best results for customers.