Документы

SERVICE LEVEL AGREEMENT (SLA)

Version 6.2 as of April 20th, 2023

This SERVICE LEVEL AGREEMENT (the “SLA”) is made and entered into the Effective Date of the MASTER SERVICE AGREEMENT (the “MSA” or the “Agreement”) by and between the Contractor and the Customer.

Now, therefore, it is agreed as follows:

  1. Definitions
    1. In this SLA the following words have the meanings set out below:
      1. Only for the purposes of this SLA and the Mindbox Service interface “Customer” refers to the customer’s clients, i.e. users in the database, whereas “Client” refers to the company subscribed to Mindbox Services.
      2. “Monitoring System” refers to the Contractor’s system that allows Parties to monitor Service performance.
      3. “Critical Data” refers to customer information related to the unique customer identificator issued by the Mindbox Service. This data can be viewed and used for processing via the Mindbox Service interface.
      4. “Data processing center (DPC)” refers to a company that provides the Contractor with the following services: an Internet data transmission channel, power supply, and physical security of servers.
      5. “RPM” means requests per minute.
      6. “RPS” means requests per second.
      7. “API methods for calculating discounts and bonus points in the cart” refers to any of the following API methods:
        • API methods containing at least one of the following steps:
          • “Calculate prices”
          • “Calculate order”
          • “Get available promoti”
          • but excluding any of the following steps:

          • “Merge”
          • “Issue prize”
        • V2 protocol API methods for the following services:
          • Price and message calculation for products v2.1
          • Obtaining preliminary order information v2.1
          • Order cost recalculation
      8. “API methods for processing orders” refers to any of the following API methods:
        • API methods containing the step:
          • “Save order”
          • but excluding any of the following steps:

          • “Merge”
          • “Issue prize”
        • V2 protocol operations for services:
          • Ordering v 2.1
      9. “API methods for sending a transactional message” refers to API methods containing at least one step from the list, if the campaign with the “Transactional” profile is selected in the settings of the following steps:
        • “Send Email”
        • “Send Sms”
        • “Send Mobile Push”
      10. “API methods for saving order” refers to API methods containing at least one of the following steps:

        • “Update order details”
        • “Place order”
        • “Saving offline order”
        • “Change order status”
        • “Change order item status”
        • “Commit order save transaction”
      11. “Service API methods required to display the Client’s customer interfaces” refers to API methods returning data in response if such API methods contain at least one of the following steps:

        • “Username”
        • “Register”
        • “Register or enrich”
        • “Enrich”
        • “Edit”
        • “Get existing”
        • “Import”
        • “Check authentication code”
        • “Confirm mobile number and SMS subscription”
        • “Get existing order”
        • but excluding any of the following steps:
        • “Merge”
        • “Issue prize”
        • “Export actions”
        • “Export promo codes”
        • “Export customer merges”
        • “Export orders”
      12. “API methods for getting recommendations” refers to API methods containing at least one of the following steps:

        • “Get personal recommendations”
        • “Get popular category recommendations”
        • “Get popular product recommendations”
      13. “Sending a message” refers to any of the following events:

        • first attempt to send a message to the mail server (when sending via the Email channel)
        • first attempt to send a message to a cloud service (when sending via the Mobile Push channel)
        • message rendering (when it is sent via other channels)
      14. “Guaranteed sending speed” is defined by the values in the table below

      15. Number of customers in the database Guaranteed number of messages sent in 30 minutes
        less than 100,000 105,000 messages
        100,000 – 3,000,000 250,000 messages
        3,000,000 – 10,000,000 600,000 messages
        10,000,000 – 15,000,000 750,000 messages
        more than 15,000,000 750,000 messages
      16. “Variables with a guaranteed sending speed” refers to the variables listed below and their child variables:

        • CustomParameters
        • Message
        • Ticket
        • Recipient.AdditionalData
        • Recipient.Area
        • Recipient.BirthDate
        • Recipient.Card
        • Recipient.Email
        • Recipient.EmailToBeConfirmed
        • Recipient.ExternalIdentity
        • Recipient.FirstAndLastName
        • Recipient.FirstAndMiddleName
        • Recipient.FirstName
        • Recipient.FormattedMobilePhone
        • Recipient.FullName
        • Recipient.Id
        • Recipient.IsMale
        • Recipient.LastName
        • Recipient.Login
        • Recipient.MobilePhone
        • Recipient.MobilePhoneConfirmationCode
        • Recipient.MobilePhoneToBeConfirmed
        • Recipient.OnlyStandardFirstName
        • Recipient.Password
        • Recipient.Settlement
        • Recipient.Sex
        • Recipient.GetBonusPointsAccount
      17. Variables without a guaranteed sending speed” refers to all other variables.“

      18. “Maximum workload for workflows that send transactional messages” refers to the number of launched workflows that are marked in the Mindbox interface as those that guarantee fast sending. The workflow has been launched if:

        • workflow steps from one of the “Steps” nodes have been executed;
        • the customer or event didn’t match the conditions of the workflow and/or were rejected according to the configured launch frequency;
        • the customer has entered the “Delay” node.
        Number of customers in the database Maximum workload for workflows that send transactional messages (events per minute)
        less than 10,000 100
        10,000 – 100,000 200
        100,000 – 1,000,000 400
        1,000,000 – 10,000,000 2800
        10,000,000 – 20,000,000 3400
        20,000,000 – 40,000,000 4000
        more than 40,000,000 10000
      19. “APDEX (Application Performance Index)” is an index for measuring the performance of the Mindbox Service:

        where:
        • “Satisfied count” is the number of API method requests completed in T or less.
        • “Tolerating count” is the number of API method requests completed in 4T or less.
        • “T” is the target time for the API method request to be completed.
      20. “Error Rate” is the value reflecting the proportion of erroneous responses (with a response code of 500 or 503) for API method requests:

    2. The SLA sets out the level of quality of the “Subscription to Mindbox Service” and does not apply to other services provided by Contractor.
  2. Table of Incidents
    1. “Incident” means an event that meets the type and criteria of one or more situations from Table of Incidents.
    2. Only cases expressly provided for in this SLA and specified in the tables below are considered incidents:

      Incidents interfering with client service

      Charged by the minute. The compensation is 0.1% of the monthly subscription per minute.

      Type and criteria of Incidents Exceptions
      The APDEX of synchronous requests for API methods for calculating discounts and bonus points in the cart is less than 0.9 at T = 0.5 seconds Violation lasting less than 4 consecutive minutes
      The APDEX of synchronous requests of API methods for processing orders is less than 0.9 at T = 1 seconds Violation lasting less than 4 consecutive minutes
      The APDEX of synchronous requests of Mindbox Service API methods required to display the Client’s customer interfaces is less than 0.8 at T = 1 seconds RPM of the operation is less than 10;
      Violation lasting less than 5 consecutive minutes
      The Error Rate of synchronous requests of Mindbox Service API methods required to display the Client’s customer interfaces is more than 0.1 Violation lasting less than 3 consecutive minutes
      Disruptions in personalization campaigns which caused inoperability of the Client’s website, including failures in the display (layout) of the Client’s customer interfaces; Changing the layout of the site on the Client’s side, which led to problems with the display of personalization blocks;
      Non-standard campaigns (JavaScript narrowing) written specifically for the Client: A/B tests, rendering for segment, and special display conditions;
      Operation of third-party systems blocking the execution of JavaScript code (for example, ad blockers)
      The APDEX of synchronous requests of API methods for getting recommendations is less than 0.9, with T = 0.5 sec RPM of the operation is less than 10;
      Violation lasting less than 10 consecutive minutes
      The APDEX of API methods for sending a transactional message via Email, SMS, Mobile Push channels (from calling the API method to save a transactional message to sending it to a third party) is less than 0.9 at T = 120 seconds An email over 102Kb; Sending of transactional messages from automated campaigns and scripts
      The APDEX of sending a transactional message via Email and Mobile Push channels, following the launch of an order-related workflow (from calling the API method to save order data, to sending an order message to a third party), is less than 0.9 at T=300 seconds An email over 102Kb in size;
      General RPM of sending messages from transactional scripts is less than 10;
      Workflows that have not been marked in the Mindbox Service interface as guaranteeing fast sending speed;
      Workflows set up for any non order-related events such as “Order added or changed” and “Order status changed”;
      Exceeding the maximum workload for workflows sending transactional messages
      The APDEX of displaying recommendation widgets on the Client’s website is less than 0.9 at T = 5 seconds RPM of the requests is less than 10;
      Violation lasting less than 5 consecutive minutes

      Other incidents

      Type and criteria of Incidens Compensation period Compensation rate Exceptions
      The number of messages sent in all channels in the last 30 minutes is less than the guaranteed sending speed. Every minute 0.03% An email over 102Kb in size; automated campaigns, workflows and API methods;
      Campaigns that use variables without a guaranteed sending speed;
      Campaigns lasting less than 30 minutes;
      Campaigns with a speed or sending hours limit in the Mindbox Service interface;
      Campaigns with the “preparing to send” status
      Incorrect operation of automated campaigns Every twenty-four hours of the incident 0,75% Incorrect campaign settings setup by user
      Failure to launch new campaigns or change existing ones An alternative way to solve the problem was provided or the issue was fixed during the first twenty-four-hour period
      Loss of Critical Data within Mindbox Service Loop Every twenty-four hours of the loss 8%
      The time it took to respond to a request by Means of Communication constituted more than one working day (a request sent at X hours of one working day was left unanswered by X hours of the next working day) Every case 1%
  3. Incident detection
    1. In the case of an Incident or suspected Incident the Client must send a relevant notification to the Contractor within 7 days from the beginning of the Incident.
    2. Within 2 business days after receipt of the relevant notification, the Contractor must send the Client references to Monitoring System reports which contain information on whether the Incident occurred. The Incident may also be detected by the Monitoring System after it is over.
    3. At the request of the Client, the Contractor is obliged to prepare a detailed technical report on the Incident within 5 business days from the date of the request or the end of the Incident, if it has not yet ended.
    4. The time (the duration) of the Incident is a period of time the beginning and the end of which were stated by the Parties by Means of Communication.
    5. Levels of escalation when the Client detects an Incident or suspects it:
      1. Contractor’s Customer support: support@mindbox.cloud, intercom or other communication tool agreed by Parties.

      2. Manager.

      3. Lead manager.

  4. Compensation
    1. The Contractor shall provide compensation as a percentage of the cost of the Subscription to the Mindbox Service for the Accounting Period in which the Incident began. The total % of compensation will be calculated by dividing the duration of the Incident by the relevant compensation period, rounded up and multiplied by % according to Table of Incidents hereof.
    2. Compensations for Incidents caused by the same event are not cumulative and will be provided exclusively for the Incident with the maximum % of compensation.
    3. Compensation is provided exclusively as a relevant deduction of the cost of the Subscription to the Mindbox Service for the current or/and following Accounting Periods.
  5. Limitation of liability
    1. Notwithstanding anything to the contrary herein, the Client acknowledges and agrees that the liability of the Contractor arising directly or indirectly from any Incident herein is limited to Compensation. The total sum of Compensation cannot exceed 100% of the cost of the Subscription to the Mindbox Service for the relevant Accounting Period.
    2. The Contractor shall not incur any liability to the Client for any breach of its obligations hereunder or for any losses by the following events which shall not be considered as Incidents:
      1. Interruptions in the Mindbox Service at any scheduled time agreed by Parties.
      2. Time for the Contractor’s technical infrastructure maintenance:
        1. Every Monday within the period from 2 a.m. to 3 a.m. New York time.
        2. Up to 10 minutes every day at the time specified in the Mindbox Service interface or agreed upon by Parties via Means of Communication.
      3. Periods of interruptions that included less than 100 measured events (including API calls, messages sent, campaign operations) or RPM (or the frequency of measured events) that was less than 10 (less than 10 events per minute).
      4. Interruptions caused by the Client or any third parties involved by the Client, as a result of a breach of compliance with Mindbox Service Documentation (the link to which is available in the Mindbox Service interface) during or as a result of the integration with the Mindbox Service, or third-party interruptions caused for other reasons.
        or caused disruptions for other reasons.
      5. Interruptions caused by interruptions in external services and tools: DPC, Basecamp, beefree.io, Microsoft Azure, readme.io, Intercom, Slack, mobile operators and other third parties.
        1. At the request of the Client, the Contractor is obliged to provide evidence of the interruptions in external services and tools within 10 days since the end of interruptions.
        2. In the event of interruptions in the operation of the DPC with a complete or partial loss of equipment, the Contractor obligates, within 3 working days from the date of interruptions in operation, to provide the Client with a plan for restoring the Mindbox Service’s operability with a list of restoration work and the timing of its implementation. In case of failure to provide such a plan within the specified period, the Contractor shall be liable for interruptions in the Mindbox Service.
    3. Interruptions caused by reasons beyond the reasonable control of the Contractor which could not have reasonably been foreseen (force majeure), including but not limited to: statutory regulations that blocked service provision, injunctions, restrictive orders, wars, armed conflicts, terrorism, fires, floods, epidemics.
    4. Interruptions caused by directed network DDOS attacks.
    5. Interruptions in the Mindbox Service caused by acts and/or actions of state bodies, including those related to blocking, seizure of the Contractor’s servers (as well as its contractors, lessors) hosting Mindbox Service, and/or their withdrawal (seizure) and/or other barrier to access.
  6. Miscellaneous
    1. The SLA applies only to the Subscription to the Mindbox Service and cannot be applied to any other services provided by the Contractor.
    2. The SLA shall prevail Agreement provisions and supersedes understandings, whether oral or written in connection therein.
    3. The Contractor reserves the right to update the SLA from time to time. If changes are made, the Client will be notified by revising the date at the top of the SLA and, in some cases, the Contractor may provide additional notice (such as adding a statement to its website or sending a notification).

____________________________

Previous version list of SLA:

SLA version 5.0 as of July 5th, 2021

SLA version 4.0 updated October 07th, 2019

SLA version 4.0 since January 16th, 2019

SLA version 3.0 since August 17th, 2018