Service Level Agreement and Support Policy

Technical Support Services and Response Service Level

Tradeshift shall provide Customer Contracting Party with technical support services relating to the Services via web form at support.tradeshift.com.

For all non-Urgent incidents support is available from 9am-5pm on normal business days in the relevant time zone in which the Services are being used (“Working Hours”).

For Urgent incidents support is available 24 hours a day and seven days per week.

Retained Responsibilities

Priority Level Response target (Response defined below)
Urgent 95% of incident requests responded to within three (3) hours
High 85% of incident requests responded to within four (4) Working Hours
Normal 75% of incident requests responded to within eight (8) Working Hours
Low 50% incident requests responded to (as defined below) within sixteen (16) Working Hours

Note: All time is shown as absolute elapsed time unless otherwise noted.

Response”: Defined as Tradeshift has accepted and acknowledged the ticket and assigned an engineer to the issue.

Customer shall determine the level of criticality (acting reasonably) for each incident as per the following definitions:

Urgent”: Total Loss of Service such as: (1) Users are unable to login due to a loss of access to the web GUI or are otherwise unable to use the Service at all.  (2) Loss of connectivity via the API or other technical integration to the Tradeshift platform.  (3) Inability to access the Company Content or to send or receive documents or to use the document processing service

High”: Material or significant loss of Service for Customer Contracting Party’s users.  A material service impact shall inter alia be deemed if it is not a Total Loss of Service, but there is an issue with the platform that blocks essential business processes with no workaround available. A significant loss of service shall inter alia be deemed if there is a loss of one or more essential applications or functions in the platform or if it affects more than 20% of Customer Contracting Party’s users; in both cases with no workaround available.)

Normal”: Non-material service impact for significant number of users (A service impact for a significant number of users should inter alia be deemed if it affects more than 20% of Customer Contracting Party’s users.  In any case a workaround with similar functionality and comfort is always available.)

Low”: Service impacted in a non-significant fashion (Any error that has no or little effect on the productive use of the Service.)

Excused performance: Tradeshift shall not be liable for a Resolution Failure to the extent that the failure to achieve the Resolution service level is directly as a result of the Customer Contracting Party’s failure to comply with the Retained Responsibilities (as set out below)

Retained Responsibilities

  1. Resolution efforts
    1.  In the case of Urgent Incidents, Customer Contracting Party shall use reasonable efforts to make appropriate personnel available on a timely basis.
    2. Customer Contracting Party will provide Tradeshift, as soon as reasonably possible, with all relevant information for any given incident, as applicable and known: priority level, rapid response needed by date as appropriate, data integration files, response/failure files, step-by-step screen shots that demonstrate the incident, screencast recordings of the incident where applicable under Customer Contracting Party standards and guidelines, the time of the incident, the amount of time a system action takes to complete (or timeout), users involved in each step, frequency of error, consistency of error, replicability of error, specificity (which specific individual, groups or types of branches, users, suppliers, transactions, or suppliers are impacted), system configuration for impacted users (browser and version, installed browser extensions, operating system, screen resolution, etc) etc, in each case to the extent Customer Contracting Party is permitted to disclose such information to Tradeshift. Customer Contracting Party will provide Tradeshift with any new or changed information regarding the Incident in a timely fashion.
    3. Customer Contracting Party shall use reasonable efforts to consolidate all further communication about an incident via the method agreed with Tradeshift.
    4. Customer Contracting Party shall confirm or reject resolution of each incident.
  2. Integration Interfaces
    1. Customer Contracting Party shall make use of the error reporting and reconciliation interfaces made available by Tradeshift on the integration interfaces that Tradeshift provides, to determine whether the data transferred is syntactically and semantically correct.
    2. When Customer Contracting Party receives for processing an invoice or a credit note from Tradeshift, it shall respond within a reasonable time frame with an Application Response system message with status “BusinessAccept”. This shall allow for Tradeshift to generate recurring reconciliation reports allowing for the timely discovery of integration regressions.
  3.  Configuration Change Control
    1. Customer Contracting Party shall give Tradeshift notice no later than twenty (20) Business Days in advance of major version upgrades of browser versions within the Customer User population.
    2. Customer Contracting Party shall be responsible for making changes to any of the end-to-end functionality that is within Customer’s control including the ERP, middleware, FTP connections, file mappings etc.
    3. Customer Contracting Party shall notify Tradeshift when Customer Contracting Party changes any configuration in the end-to-end ERP to/from Tradeshift environment.
    4. Customer Contracting Party shall test and sign-off on any Tradeshift side configuration changes requested by Customer Contracting Party in the Tradeshift UAT system (currently known as Sandbox) prior to either Tradeshift or Customer Contracting Party migrating such changes to production.
    5. Customer Contracting Party shall verify that the configuration documentation maintained by Tradeshift is updated prior to Customer Contracting Party signing-off that a configuration change can be migrated to production.