Service Level Agreement

  1. Agreement Overview
    This Service Level Agreement (SLA) serves as an integral part of the contractual agreement between fileAI and the Customer. Within this exhibit, the Parties articulate a shared responsibility Support Model, and establish the defined service levels, performance targets, reporting mechanisms, and issue resolution guidelines. The SLA matrix included herein delineates critical service parameters, targets, reporting requirements, service credits, and other relevant criteria, ensuring a comprehensive understanding of the commitments and expectations governing the provision of fileAI’ services. Additionally, Incident Priority Matrix further refines the approach to addressing and resolving potential challenges. By mutually acknowledging and adhering to the terms set forth in this SLA, both Parties affirm their commitment to maintaining a high standard of service quality and reliability.
  2. Definitions

The following detailed service parameters are the responsibility of the Service Provider in the ongoing support of this Agreement.

  1. Service Scope. The following Services are covered by this Agreement;
    1. Technical Supportsome text
      1. Incident/Request resolution  
      2. Inquiry/ad hoc Service Requests
    2. Service Management some text
      1. Service management and operations
      2. Reporting
    3. Processing
  2. Customer Requirements. Customer responsibilities and/or requirements in support of this Agreement include: 
    1. Payment for all support costs at the agreed interval.
    2. Reasonable availability of customer representative(s) when resolving a service related incident or request.
  3. fileAI Requirements. Service Provider responsibilities and/or requirements in support of this Agreement include:
    1. Meeting response times associated with service related incidents.
    2. Appropriate notification to Customer for all scheduled maintenance.
  4. Incident. Refers to a reported issue or problem encountered by the customer organization that requires advanced technical expertise and intervention beyond the scope of fileAI core support. To be considered ready for processing and escalation, an incident must meet the following criteria (Definition of Ready):some text
    1. Language: The incident title should be in English language, containing clear one-sentence description of the issue reported and avoiding generic statements (e.g. System not working). The Incident report also must be submitted in English language, ensuring clear communication of the issue and related details.
    2. Comprehensive Information: The incident report must contain explicit and detailed information about the issue and how to reproduce it. This may involve providing supporting materials such as photos, videos or relevant files that aid in understanding and replicating the problem.
    3. Detailed Description:
      1. Elaborate on the issue, providing a step-by-step account of what happened.
      2. Include specific error messages, if any, and their exact wording.
      3. Specify any unusual behavior or symptoms observed.
    4. Impact on Business:
      1. Describe how the incident is affecting different aspects of the business.
      2. Quantify the impact if possible, such as the number of users affected, or financial losses incurred.
      3. Explain why the incident is considered urgent or high priority.
      4. Justify the chosen priority level based on business impact, potential risks, or service level agreements (SLAs).
    5. Attempts to Resolve:
      1. Provide an exhaustive list of all actions taken to troubleshoot or resolve the issue.
      2. Include information on tools used, commands executed, and responses received during troubleshooting.
    6. Attachments:
      1. Include annotated screenshots, highlighting relevant areas related to the incident.
      2. Attach log files with specific entries related to the problem.
      3. Provide configuration files with comments on the relevant sections.
    7. Escalation Information:
      1. Detail why the incident was escalated, providing evidence of the need for higher-level intervention.
      2. Specify the expertise or resources required for escalation.
      3. Expected behaviour of the application or the action taken.
    8. User identification: The incident report must include precise information about the person who reported the issue, including user identification and contact information. This is crucial for verifying authorization and access rights, ensuring that the support process aligns with security protocols. fileAI together with the Customer’s IT should complete the initial confirmation if authorization and access rights are the root cause of the incident before delegating the incident to fileAI.
    9. Support triage completed: Prior to escalation, the incident report must be signed off by the fileAI and Customer’s IT organization. This sign-off confirms that the following checks have been performed based on the nature of the reported issue: some text
      1. Infrastructure issues: the problem pertains to infrastructure managed by fileAI, not the Customer or third-party systems.
      2. Data issues: the reported issues are associated with data that does not originate from the Customer or third-party systems.
      3. Integration issues: the problem is a result of fileAI’ platform logic, not the Customer’s integration layer.
      4. Configuration issues: affirmation that the issue is related to configuration that is not managed by the Customer.
      5. Other issues (security incidents, performance, etc.): making sure that the issues reside fully on fileAI side before they are signed-off by the Customer.

This structured sign-off process ensures that the incident is appropriately categorized, allowing for targeted analysis and resolution by support.

  1. Non-compliant Incident. Refers to any incidents that do not meet the Definition of Ready criteria (above) for immediate escalation. These Incidents will be analyzed and potentially resolved by fileAI but are explicitly excluded from this Service Level Agreement (SLA) terms. As a result, they do not contribute to service credit calculations. fileAI has the right to charge for the analysis and resolution time of non-compliant incidents utilizing the agreed-upon rate card. This approach ensures that non-compliant incidents receive attention but are handled separately from SLA-bound matters, with transparent billing practices for the required additional efforts. fileAI also has the right to reject non-compliant incidents with proper explanation.
  2. Undetected-defect Incident. Refers to issues emerging for the first time in the live environment, after customer approval for the production release. These incidents have not been identified during the user acceptance test (UAT) phase, stemming from incomplete or inadequate testing processes. fileAI commits to resolving these incidents within allocated support hours. However, these incidents are not bound to the established SLA resolution targets, nor do they contribute to service credit calculations as they fall outside the Incident scope and could have been found, reported, and fixed during the UAT phase. 
  3. Pre-Approved Downtime. System unavailability (downtime) is not expected during the regular course of operating, maintaining, or upgrading the The Platform Platform, but may be required for heavy upgrading of the platform with custom-developed functionality or may be necessitated by specific requirements. Maintenance which may potentially result in downtime or unavailability of services shall be planned to take place outside of Customer’s business hours, notified at least 5 working days in advance, and subject to written approval by the Customer. Pre-Approved Downtime will not be taken into account for the measurement of the The Platform Availability service level up to a maximum of 6 hours.
  4. Platform Availability. Measures the availability of The Platform for Customer users or queries for Distribution Partner for approved reasons. It is determined by observable downtime excluding Pre-approved Downtime. Monitoring tool to measure availability of the platform is to be set up and operated by fileAI. Sufficient samples must be taken during peak times in order to accurately measure availability under peak loads. Appendix A for Platform Availability details.
  1. Service Management 

Effective support of in-scope services is a result of maintaining consistent service levels. The following sections provide relevant details on service availability, monitoring of in-scope services and related components.

  1. Platform. The Platform SLA targets become effective three months after the Service Level Commencement Date, providing a grace period for system stabilization post-implementation. This timeframe allows for optimal service delivery as the platform settles into regular operation. It is important to note that these SLAs exclude Pre-approved Downtime, as previously defined.
  2. Service hours & Exceptions. Following the Go-Live Date, the Maintenance & Support service shall operate during the following hours:
  1. Agreement Overview
    This Service Level Agreement (SLA) serves as an integral part of the contractual agreement between fileAI and the Customer. Within this exhibit, the Parties articulate a shared responsibility Support Model, and establish the defined service levels, performance targets, reporting mechanisms, and issue resolution guidelines. The SLA matrix included herein delineates critical service parameters, targets, reporting requirements, service credits, and other relevant criteria, ensuring a comprehensive understanding of the commitments and expectations governing the provision of fileAI’ services. Additionally, Incident Priority Matrix further refines the approach to addressing and resolving potential challenges. By mutually acknowledging and adhering to the terms set forth in this SLA, both Parties affirm their commitment to maintaining a high standard of service quality and reliability.
  2. Definitions

The following detailed service parameters are the responsibility of the Service Provider in the ongoing support of this Agreement.

  1. Service Scope. The following Services are covered by this Agreement;
    1. Technical Supportsome text
      1. Incident/Request resolution  
      2. Inquiry/ad hoc Service Requests
    2. Service Management some text
      1. Service management and operations
      2. Reporting
    3. Processing
  2. Customer Requirements. Customer responsibilities and/or requirements in support of this Agreement include: 
    1. Payment for all support costs at the agreed interval.
    2. Reasonable availability of customer representative(s) when resolving a service related incident or request.
  3. fileAI Requirements. Service Provider responsibilities and/or requirements in support of this Agreement include:
    1. Meeting response times associated with service related incidents.
    2. Appropriate notification to Customer for all scheduled maintenance.
  4. Incident. Refers to a reported issue or problem encountered by the customer organization that requires advanced technical expertise and intervention beyond the scope of fileAI core support. To be considered ready for processing and escalation, an incident must meet the following criteria (Definition of Ready):some text
    1. Language: The incident title should be in English language, containing clear one-sentence description of the issue reported and avoiding generic statements (e.g. System not working). The Incident report also must be submitted in English language, ensuring clear communication of the issue and related details.
    2. Comprehensive Information: The incident report must contain explicit and detailed information about the issue and how to reproduce it. This may involve providing supporting materials such as photos, videos or relevant files that aid in understanding and replicating the problem.
    3. Detailed Description:
      1. Elaborate on the issue, providing a step-by-step account of what happened.
      2. Include specific error messages, if any, and their exact wording.
      3. Specify any unusual behavior or symptoms observed.
    4. Impact on Business:
      1. Describe how the incident is affecting different aspects of the business.
      2. Quantify the impact if possible, such as the number of users affected, or financial losses incurred.
      3. Explain why the incident is considered urgent or high priority.
      4. Justify the chosen priority level based on business impact, potential risks, or service level agreements (SLAs).
    5. Attempts to Resolve:
      1. Provide an exhaustive list of all actions taken to troubleshoot or resolve the issue.
      2. Include information on tools used, commands executed, and responses received during troubleshooting.
    6. Attachments:
      1. Include annotated screenshots, highlighting relevant areas related to the incident.
      2. Attach log files with specific entries related to the problem.
      3. Provide configuration files with comments on the relevant sections.
    7. Escalation Information:
      1. Detail why the incident was escalated, providing evidence of the need for higher-level intervention.
      2. Specify the expertise or resources required for escalation.
      3. Expected behaviour of the application or the action taken.
    8. User identification: The incident report must include precise information about the person who reported the issue, including user identification and contact information. This is crucial for verifying authorization and access rights, ensuring that the support process aligns with security protocols. fileAI together with the Customer’s IT should complete the initial confirmation if authorization and access rights are the root cause of the incident before delegating the incident to fileAI.
    9. Support triage completed: Prior to escalation, the incident report must be signed off by the fileAI and Customer’s IT organization. This sign-off confirms that the following checks have been performed based on the nature of the reported issue: some text
      1. Infrastructure issues: the problem pertains to infrastructure managed by fileAI, not the Customer or third-party systems.
      2. Data issues: the reported issues are associated with data that does not originate from the Customer or third-party systems.
      3. Integration issues: the problem is a result of fileAI’ platform logic, not the Customer’s integration layer.
      4. Configuration issues: affirmation that the issue is related to configuration that is not managed by the Customer.
      5. Other issues (security incidents, performance, etc.): making sure that the issues reside fully on fileAI side before they are signed-off by the Customer.

This structured sign-off process ensures that the incident is appropriately categorized, allowing for targeted analysis and resolution by support.

  1. Non-compliant Incident. Refers to any incidents that do not meet the Definition of Ready criteria (above) for immediate escalation. These Incidents will be analyzed and potentially resolved by fileAI but are explicitly excluded from this Service Level Agreement (SLA) terms. As a result, they do not contribute to service credit calculations. fileAI has the right to charge for the analysis and resolution time of non-compliant incidents utilizing the agreed-upon rate card. This approach ensures that non-compliant incidents receive attention but are handled separately from SLA-bound matters, with transparent billing practices for the required additional efforts. fileAI also has the right to reject non-compliant incidents with proper explanation.
  2. Undetected-defect Incident. Refers to issues emerging for the first time in the live environment, after customer approval for the production release. These incidents have not been identified during the user acceptance test (UAT) phase, stemming from incomplete or inadequate testing processes. fileAI commits to resolving these incidents within allocated support hours. However, these incidents are not bound to the established SLA resolution targets, nor do they contribute to service credit calculations as they fall outside the Incident scope and could have been found, reported, and fixed during the UAT phase. 
  3. Pre-Approved Downtime. System unavailability (downtime) is not expected during the regular course of operating, maintaining, or upgrading the The Platform Platform, but may be required for heavy upgrading of the platform with custom-developed functionality or may be necessitated by specific requirements. Maintenance which may potentially result in downtime or unavailability of services shall be planned to take place outside of Customer’s business hours, notified at least 5 working days in advance, and subject to written approval by the Customer. Pre-Approved Downtime will not be taken into account for the measurement of the The Platform Availability service level up to a maximum of 6 hours.
  4. Platform Availability. Measures the availability of The Platform for Customer users or queries for Distribution Partner for approved reasons. It is determined by observable downtime excluding Pre-approved Downtime. Monitoring tool to measure availability of the platform is to be set up and operated by fileAI. Sufficient samples must be taken during peak times in order to accurately measure availability under peak loads. Appendix A for Platform Availability details.
  1. Service Management 

Effective support of in-scope services is a result of maintaining consistent service levels. The following sections provide relevant details on service availability, monitoring of in-scope services and related components.

  1. Platform. The Platform SLA targets become effective three months after the Service Level Commencement Date, providing a grace period for system stabilization post-implementation. This timeframe allows for optimal service delivery as the platform settles into regular operation. It is important to note that these SLAs exclude Pre-approved Downtime, as previously defined.
  2. Service hours & Exceptions. Following the Go-Live Date, the Maintenance & Support service shall operate during the following hours:

Privacy Policy

3. Provider has no obligation to provide Services relating to Errors that, in whole or in part, arise out of or result from any of the following (each a “Service Exception”):

  1. Software, or the media on which it is provided, that is modified or damaged by Customer or any third party;
  2. any operation or use of, or other activity relating to, the Software other than as specified in the Documentation, including any incorporation in the Software of, or combination, operation or use of the Software in or with, any technology (including any software, hardware, firmware, system, or network) or service not specified for Customer’s use in the Documentation[, unless otherwise expressly permitted in writing by Provider];
  3. any Third-Party Materials;
  4. any negligence, abuse, misapplication, or misuse of the Software other than by Provider Personnel, including any Customer use of the Software other than as specified in the Documentation or expressly authorized in writing by Provider;
  5. any Customer Failure, including Customer’s failure to promptly install any Maintenance Release that Provider has previously made available to Customer;
  6. the operation of, or access to, Customer’s or a third party’s system or network;
  7. any relocation, installation or integration of the Software other than by Provider Personnel; 
  8. any beta software, software that Provider makes available for testing or demonstration purposes, temporary software modules, or software for which Provider does not receive a license fee;
  9. any breach of or noncompliance with any provision of this Agreement or the Master Services Agreement/Statement of Work by Customer or any of its Representatives; or
  10. any Force Majeure Event, including, but not limited to, industrial disputes (other than between the affected Party and its employees), wars, revolutions, fires, floods, hurricanes, diseases, epidemics, explosions, earthquakes or governmental regulations.

4. Support Management. fileAI will provide bluesheets support to you via email and in-app chat support. You may submit a support request by emailing support@file.ai and/ or opening a chat ticket in-app to resolve a question, or report an issue concerning bluesheets. We will strive to provide an initial response to each Support Ticket within 24 hours from the time at which your Support Ticket has been validly raised through the Direct Support Channel.

5. Incident Resolution. The following service level targets are applicable exclusively for issues and Incidents that meet the established Definition of Ready criteria.

  1. Issue Support:
    1. Initial incident handling and basic troubleshooting.
    2. Escalation Criteria:
      1. Unable to resolve the incident within the specified time frame.
      2. Lack of expertise or resources to address the issue.
  2. Incident Support:
    1. Specialized support for more complex issues and Incidents.
    2. Escalation Criteria:
      1. Core support unable to resolve the incident.
      2. Need for deeper technical expertise or access to specific systems.
  3. Incident response framework:

Privacy Policy

4. Processing

  1. Digitization Time. Under normal circumstances, digitization time per document shall not exceed 24h; Bluesheets shall inform the client about turnaround time delays within 24 h after uploading documents.
  2. Annotation Time. Under normal circumstances, annotation handling per document shall not exceed 24h; Bluesheets shall inform the client about turnaround time delays within 24 h after submitting annotations.

5. Customer Obligations

  1. Notification. Customer shall notify Provider of any Error and provide Provider with reasonable detail of the nature and circumstances of the Error.
  2. Compliance. Customer shall comply with all terms and conditions of this Agreement and the Services Agreement and/or Statement of Work.
  3. Use. Customer shall use the Software solely in accordance with the terms and conditions set forth in this Agreement.
  4. Environment. Customer shall set up, maintain, and operate in good repair and in accordance with the Documentation all environmental conditions and components, including all networks, systems, and hardware, in or through which: (a) the Software operates; and/or (b) the Customer accesses or uses any of the Services.
  5. Access. In connection with the performance of the Services, Customer shall provide Provider Personnel with all such cooperation and assistance as they may reasonably request, or otherwise may reasonably be required, to enable Provider to perform its obligations (including the provision of the Services), and exercise its rights, under and in accordance with the terms and conditions of this Agreement, including:some text
    1. reasonable, uninterrupted access, both physical and virtual, to the Software and Customer's premises, systems, networks, and facilities;
    2. reasonable access to the appropriate Customer personnel, including network, systems, operations, and applications personnel; and
    3. all necessary authorizations and consents, whether from third parties or otherwise, in connection with any of the foregoing.
  6. Data Back-up. Customer agrees to back up all data, files, and information prior to the performance of any Services and hereby assumes sole responsibility for any lost or altered data, files, or information.
  7. Information. Customer shall provide Provider with all information reasonably requested by Provider from time to time relating to Customer's use of the Software, Services, or Deliverables, including information on Customer's hardware, network, systems, and any related Third-Party Materials.
  8. Current Release. Except as otherwise specified in this Agreement, Customer must run only the current release level of the Software that Provider has made available to its customers. Customer shall install all Maintenance Releases as soon as reasonably possible from the date they are made available by Provider.

6. Dispute Resolution

  1. Dispute Resolution Procedure. The following procedure will be followed to resolve disputes during the performance of this SOW: When a conflict or dispute arises between the Recipient and the Provider, the project team member(s) will first strive to resolve the problem internally.some text
    1. Step 1: If the project team cannot resolve the conflict or dispute within two (2) working days, the Recipient Project Manager and Provider Project Manager will meet to resolve the issue.
    2. Step 2: If the conflict or dispute is not resolved within three (3) working days after being escalated to Level 1, the Provider Service Manager will meet with the Recipient Service Manager to resolve the issue. 
  2. Service Continuity. During any conflict or dispute resolution, the Provider agrees to provide Services relating to items not in dispute, to the extent practicable, pending resolution of the conflict. Customer agrees to pay any undisputed invoices as per the agreements, including but not limited to bluesheets Services Agreement, Statements of Work, and Order Forms.
  3. Resolutions. Resolutions will be addressed in accordance with the SOW Change Management Process.

7. Change Orders

  1. Change Order Management. If either Party wishes to change the scope or performance of the Services, it shall submit details of the requested change to the other Party in writing in a format. The request report must contain explicit and detailed information about the change request. This may involve providing supporting materials such as photos, videos or relevant files that aid in understanding the request. The Provider shall, within a reasonable time after the date of such request, provide a written estimate to the Customer of:some text
    1. the likely time required to implement the change;
    2. any necessary variations to the Service Fees and other charges for the Services arising from the change;
    3. the likely effect of the change on the Services; and
    4. any other impact the change might have on the performance of this Agreement.
  2. Negotiation. Promptly after receipt of the written estimate, the Parties shall negotiate and agree in writing on the terms of such change (a “Change Order”).  Neither Party shall be bound by any Change Order unless mutually agreed upon in writing).
  3. Amendment/Modification/Waiver. No amendment to this Agreement or to any Statement of Work shall be effective unless it shall be in writing and signed by each Party hereto. Any failure of a Party to comply with any obligation, covenant, agreement, or condition contained in this Agreement may be waived by the Party entitled to the benefits thereof only by a written instrument duly executed and delivered by the Party granting such waiver, but such waiver or failure to insist upon strict compliance with such obligation, covenant, agreement, or condition shall not operate as a waiver of, or with respect to, any subsequent or other failure of compliance.