Service Level Agreement

1. PURPOSE

The purpose of this Service Level Agreement is to define:

Service availability commitments; uptime objectives; incident severity classifications; support response objectives; maintenance procedures; Customer responsibilities; Service Credits where applicable; operational expectations for Enterprise Customers.

This SLA is intended to establish transparent operational standards while recognizing that cloud services, artificial intelligence systems, third-party providers, and internet infrastructure may occasionally experience disruptions beyond the reasonable control of Saees.

2. SCOPE

Unless otherwise stated in an Enterprise Agreement, this SLA applies to:

Saees AI Commerce OS Web Platform Dashboard AI Assistant AI Agents Workflow Automation API Services Authentication Services Marketplace Integrations Reporting Services Organization Management User Management Notification Services

This SLA also applies to integrations supported directly by Saees, including:

Amazon Walmart Marketplace eBay TikTok Shop

Future integrations may become covered upon official release.

3. DEFINITIONS

For purposes of this SLA:

Availability

The percentage of total time during which the core Services are operational and available for Customer access, excluding permitted downtime.

Downtime

A period during which the core Services are unavailable to substantially all Customers due to an issue within Saees' control.

Downtime does not include excluded events described in this SLA.

Incident

An unexpected interruption or reduction in Service quality.

Maintenance

Planned or emergency work performed to maintain, improve, repair, update, or secure the Services.

Monthly Uptime Percentage

The percentage calculated as:

((Total Minutes − Downtime Minutes) ÷ Total Minutes) × 100

during a calendar month.

Scheduled Maintenance

Maintenance announced in advance by Saees.

Emergency Maintenance

Immediate maintenance necessary to:

protect security; prevent data loss; address critical vulnerabilities; maintain system stability; comply with legal or regulatory obligations. Service Credit

A credit applied toward future Subscription fees when the Monthly Uptime Percentage falls below the applicable SLA commitment, subject to this Agreement.

Business Hours

Unless otherwise stated:

Monday through Friday

8:30 AM – 9:30 PM

Eastern Time (United States)

excluding recognized United States holidays.

4. SERVICE AVAILABILITY

Saees is designed as a cloud-native Software-as-a-Service platform.

The Services are intended to be continuously available through redundant cloud infrastructure and managed service providers.

Saees continuously monitors:

platform availability; API performance; authentication systems; database health; infrastructure utilization; AI service availability; integration status; application errors; security events.

Although uninterrupted availability cannot be guaranteed, Saees makes commercially reasonable efforts to maximize Service reliability.

5. AVAILABILITY COMMITMENT

For paid Subscription plans, Saees targets a Monthly Uptime Percentage of 99.9% for the core production Services.

This commitment applies only to production environments.

The commitment excludes:

beta features; experimental AI capabilities; preview releases; sandbox environments; development environments; customer-specific custom software unless expressly included.

The following table summarizes the availability objective:

Service Target Availability Core Platform 99.9% Authentication 99.9% Dashboard 99.9% AI Services Best Effort* APIs 99.9% Marketplace Integrations Best Effort**

* AI services depend partially upon third-party model providers.

** Marketplace integrations depend upon the availability of third-party APIs including Amazon, Walmart Marketplace, eBay, TikTok Shop, and future supported integrations.

6. SCHEDULED MAINTENANCE

Saees periodically performs scheduled maintenance to:

improve performance; deploy new features; upgrade infrastructure; improve security; install patches; optimize databases; maintain APIs; improve AI capabilities.

Whenever reasonably practicable, scheduled maintenance will be announced at least 48 hours in advance.

Notice may be provided through:

Dashboard notifications; email; status page; administrative alerts.

Scheduled maintenance normally occurs during periods of reduced customer activity whenever reasonably possible.

Scheduled maintenance does not count as Downtime for purposes of this SLA.

7. EMERGENCY MAINTENANCE

Saees may immediately perform emergency maintenance without prior notice when reasonably necessary to:

mitigate cybersecurity threats; respond to active attacks; prevent data corruption; protect Customer information; restore system stability; comply with legal requirements; prevent widespread outages.

Where practical, Saees will notify Customers promptly after emergency maintenance begins.

Emergency maintenance is excluded from uptime calculations where reasonably necessary to protect the security, integrity, or availability of the Services.

8. SERVICE MONITORING

Saees continuously monitors the operational health of the Services using automated monitoring systems.

Monitoring may include:

uptime monitoring; API response times; server health; database performance; authentication success rates; queue processing; workflow execution; AI Agent execution; AI provider connectivity; cloud infrastructure metrics; application logs; security alerts; incident detection.

Monitoring data may also be used to:

improve reliability; investigate incidents; prevent abuse; optimize infrastructure; forecast capacity.

Monitoring activities do not create an obligation for Saees to detect every incident before it affects Customers.

9. AVAILABILITY MEASUREMENT

Availability is measured monthly using internal monitoring systems maintained by Saees.

Downtime begins when the core Services become materially unavailable to substantially all Customers.

Downtime ends when normal functionality has been restored.

Short-duration interruptions resulting from:

browser refreshes; customer network interruptions; isolated ISP failures; local device issues; temporary routing instability;

may not constitute Downtime.

Saees' internal monitoring systems shall be used to determine official uptime calculations unless otherwise agreed in writing.

10. EXCLUSIONS

This SLA does not apply to Service interruptions caused by:

Customer equipment; Customer internet connectivity; browser issues; mobile device issues; third-party software installed by the Customer; unsupported integrations; misuse of the Services; violation of the Terms of Use; API abuse; malware introduced by the Customer; force majeure events; government actions; labor disputes; power failures outside Saees' control; failures of cloud providers beyond commercially reasonable redundancy; failures of AI providers; failures of Commerce Platforms; failures of payment processors; failures of shipping providers; DNS failures; Internet backbone failures; scheduled maintenance; emergency maintenance; beta functionality.

Downtime resulting from these exclusions shall not be included when calculating Monthly Uptime Percentage.

11. CUSTOMER RESPONSIBILITIES

To receive the benefits of this SLA, Customers must:

maintain accurate Account information; promptly report Service issues; maintain supported browsers; maintain secure authentication credentials; configure integrations correctly; follow published technical documentation; cooperate during incident investigations; provide sufficient information to reproduce reported issues; avoid unauthorized modifications to supported integrations; maintain stable internet connectivity; install updates where applicable.

Failure to satisfy these responsibilities may affect Saees' ability to meet the response objectives described in this SLA.

12. SUPPORT SERVICES

Saees provides technical and operational support according to the Customer’s Subscription plan, Enterprise Agreement, or applicable Order Form.

Support may include assistance with:

Account access; platform errors; API connectivity; marketplace integrations; AI feature availability; workflow execution; authentication issues; billing-related technical questions; incident reporting; supported configuration issues; data synchronization issues; product defects; service interruptions.

Support does not include, unless expressly included in a Professional Services Agreement or Enterprise Agreement:

general marketplace consulting; legal advice; tax advice; accounting advice; product sourcing; product authenticity verification; appeal preparation; catalog optimization; advertising management; seller account reinstatement; custom software development; unsupported third-party configuration; training beyond the applicable Subscription; issues caused by Customer systems or devices.

Saees may require the Customer to purchase Professional Services for requests that fall outside standard technical support.

13. SUPPORT CHANNELS

Customers may contact Saees through one or more of the following channels:

in-platform support; support ticket system; email; administrative dashboard; designated Enterprise support channel; emergency escalation channel, where purchased; account manager, where assigned.

General support requests may be sent to:

support@saees.ai

Enterprise Customers may receive a dedicated support address, shared communication channel, or designated account representative.

Saees may require support requests to be submitted through a specific channel to ensure appropriate tracking, prioritization, and documentation.

14. SUPPORT HOURS

14.1 Standard Support

Unless otherwise stated in the applicable Subscription plan, Standard Support is available during the following hours:

Monday through Friday

8:30 AM to 9:30 PM Eastern Time

Saturday

9:00 AM to 2:00 PM Eastern Time

Standard Support excludes recognized United States holidays unless otherwise communicated.

14.2 Enterprise Support

Enterprise Customers may receive extended or twenty-four-hour support where expressly included in an Enterprise Agreement or Order Form.

Twenty-four-hour support generally applies only to Priority 1 incidents unless otherwise agreed in writing.

14.3 Support Outside Business Hours

Support requests submitted outside applicable support hours will be received and logged.

Response timing will begin at the start of the next applicable support period, except for Priority 1 incidents covered by an active twenty-four-hour Enterprise support entitlement.

15. INCIDENT PRIORITY CLASSIFICATION

Saees classifies incidents according to their impact, severity, scope, and operational urgency.

Saees may reclassify an incident if the actual impact differs from the Customer’s initial classification.

Priority classifications are as follows.

15.1 PRIORITY 1 — CRITICAL

A Priority 1 incident is a severe production issue that causes the core Services to become unavailable or creates a material security or data-integrity risk.

Examples may include:

complete production platform outage; inability of substantially all Customers to access the Services; widespread authentication failure; confirmed unauthorized access to Customer Data; material data corruption affecting multiple Customers; critical API outage affecting substantially all API Customers; failure of a core service without a reasonable workaround; widespread failure of essential workflows; a security incident creating an imminent risk of material harm.

A Priority 1 incident generally requires:

production impact; broad Customer impact or material Enterprise Customer impact; no reasonable workaround; immediate operational attention.

A Customer-specific marketplace suspension, listing removal, product restriction, or third-party enforcement action is not a Priority 1 incident unless caused directly by a verified Saees platform defect affecting multiple Customers.

15.2 PRIORITY 2 — HIGH

A Priority 2 incident is a significant production issue that materially impairs important functionality but does not render the entire Service unavailable.

Examples may include:

major feature unavailable; significant degradation of API performance; material delays in order or inventory synchronization; multiple essential workflows failing; Organization Administrators unable to perform critical functions; integration failure affecting a material portion of a Customer’s operations; substantial performance degradation; recurring errors without a practical workaround; a suspected security issue requiring urgent investigation but not presenting confirmed widespread harm.

Priority 2 incidents may have a workaround, but the workaround is incomplete, inefficient, or operationally burdensome.

15.3 PRIORITY 3 — NORMAL

A Priority 3 incident is a non-critical defect or issue that affects limited functionality and does not materially prevent use of the core Services.

Examples may include:

isolated feature error; intermittent synchronization delay; reporting inconsistency; non-critical workflow failure; limited user-interface issue; issue affecting a small number of Users; documented workaround available; configuration assistance; unexpected behavior without material operational impact.

Most standard technical support requests are classified as Priority 3.

15.4 PRIORITY 4 — LOW

A Priority 4 request is a low-impact issue, question, or enhancement request that does not materially affect current operations.

Examples may include:

general product questions; documentation clarification; cosmetic user-interface issue; feature request; workflow recommendation; non-urgent reporting question; training-related question; minor usability concern; request for future functionality.

Priority 4 requests are handled according to available support capacity and product planning priorities.

16. INITIAL RESPONSE OBJECTIVES

The Initial Response Time is the target period between receipt of a sufficiently detailed support request and the first substantive acknowledgment by a qualified Saees representative.

An automated confirmation does not necessarily constitute a substantive response.

Unless otherwise stated in an Enterprise Agreement, the following target response times apply:

Priority Standard Support Enterprise Support Priority 1 — Critical 2 business hours 30 minutes Priority 2 — High 8 business hours 2 hours Priority 3 — Normal 1 business day 8 business hours Priority 4 — Low 2 business days 1 business day

Response times are objectives and not guaranteed resolution times.

For Priority 1 incidents, the Enterprise response objective applies outside Business Hours only when the Customer has purchased twenty-four-hour incident support.

17. TARGET RESTORATION AND RESOLUTION OBJECTIVES

Saees will use commercially reasonable efforts to restore affected functionality as promptly as practicable.

The following are operational targets and do not constitute guaranteed resolution deadlines unless expressly incorporated into an Enterprise Agreement.

Priority Target Workaround or Restoration Target Resolution Objective Priority 1 — Critical 4 hours Continuous effort until stabilization Priority 2 — High 1 business day 3 business days Priority 3 — Normal As reasonably available 10 business days Priority 4 — Low Not generally applicable Product roadmap or future release

Resolution timing may depend on:

incident complexity; Customer cooperation; access to diagnostic information; third-party provider involvement; marketplace API availability; cloud provider response; security considerations; testing requirements; regulatory or contractual restrictions; the availability of a safe workaround.

Saees does not guarantee that every defect will be resolved within a specific period.

A feature request, design change, new integration, or unsupported configuration is not subject to resolution objectives.

18. CUSTOMER INCIDENT REPORTING REQUIREMENTS

To facilitate timely investigation, the Customer should provide:

Account or Organization name; affected User or Users; date and time the issue began; time zone; affected feature; marketplace or integration involved; error message; screenshots or screen recordings; affected SKU, order, listing, or workflow identifiers; steps to reproduce the issue; browser and device information; operational impact; available workaround; recent configuration changes; relevant API request or response identifiers; whether the issue affects one User or multiple Users.

Saees may delay classification or investigation until sufficient information is provided.

Customers must not include passwords, complete payment card details, private authentication tokens, or unnecessary sensitive information in support requests.

19. INCIDENT ACKNOWLEDGMENT AND VALIDATION

After receiving a reported incident, Saees may:

confirm receipt; validate the reported behavior; assign a priority level; request additional information; attempt to reproduce the issue; identify affected systems; determine whether the issue is within Saees’ control; provide an initial workaround; escalate the incident internally; contact an affected third-party provider.

A reported issue will not be considered confirmed Downtime solely because a Customer submits a support ticket.

Saees may determine that an incident:

is caused by Customer configuration; is caused by a third party; is an expected system behavior; is an unsupported use case; is a feature request; cannot be reproduced; is excluded from the SLA.

20. INCIDENT COMMUNICATION

For confirmed Priority 1 incidents, Saees will use commercially reasonable efforts to provide periodic updates until the Service is stabilized.

Updates may include:

incident acknowledgment; affected systems; current operational impact; mitigation measures; workaround availability; restoration status; next planned update; final resolution notice.

For Priority 1 incidents, Enterprise Customers may receive updates approximately every sixty minutes during active investigation, unless:

there is no material new information; disclosure could create a security risk; disclosure is restricted by law; the incident is controlled by a third-party provider; another update schedule is agreed.

Priority 2 through Priority 4 updates may be provided as meaningful progress occurs.

Saees may communicate incidents through:

support tickets; email; status page; platform notifications; designated Enterprise channels; direct communication with Organization Administrators.

21. ESCALATION PROCEDURE

Customers may request escalation when:

a Priority 1 incident has not been acknowledged within the applicable target; a Priority 2 incident has a materially greater impact than initially assessed; a support request has remained inactive for an unreasonable period; the Customer believes an incident was incorrectly classified; the issue creates material contractual, operational, or security risk.

An escalation request should include:

the support ticket reference; business impact; affected operations; requested priority; executive or operational contact; reason for escalation.

Saees may escalate an incident to:

senior support personnel; engineering; security; cloud operations; product management; legal or compliance personnel; third-party service providers; executive management.

Escalation does not guarantee a specific resolution or priority classification.

22. PRIORITY 1 INCIDENT MANAGEMENT

For a confirmed Priority 1 incident, Saees may activate an internal incident-response process.

The process may include:

appointment of an incident lead; establishment of a technical response team; containment measures; service restoration activities; security review; third-party coordination; Customer communication; preservation of relevant logs; post-incident analysis; corrective action planning.

Saees may prioritize rapid restoration over permanent correction during the initial response phase.

A temporary workaround may be used to restore functionality while a permanent solution is developed and tested.

23. ROOT CAUSE ANALYSIS

For significant confirmed Priority 1 incidents, Enterprise Customers may request a written Root Cause Analysis.

Where reasonably available, the Root Cause Analysis may include:

incident summary; duration; affected services; operational impact; primary cause; contributing factors; mitigation actions; corrective actions; preventative measures.

Saees generally aims to provide a Root Cause Analysis within ten business days after resolution of a qualifying incident.

Additional time may be required where:

a security investigation remains active; third-party information is pending; legal restrictions apply; the incident is technically complex; disclosure could create a security vulnerability.

Root Cause Analysis reports may contain confidential information and may be provided subject to confidentiality obligations.

24. SUPPORT FOR ARTIFICIAL INTELLIGENCE SERVICES

AI-powered features may depend on:

third-party model providers; model availability; rate limits; regional availability; safety filters; prompt-processing capacity; Customer AI Credits; input size; feature configuration.

Saees provides AI Services on a commercially reasonable best-effort basis unless a specific Enterprise Agreement states otherwise.

An AI feature may be temporarily unavailable or degraded due to:

third-party model outages; provider capacity limitations; safety enforcement; model retirement; provider policy changes; unsupported input; excessive request volume; AI Credit exhaustion; technical maintenance.

The following do not constitute Downtime of the core Services:

inaccurate AI outputs; incomplete AI outputs; refusal of a prompt due to safety controls; variation between model responses; changes in writing style; hallucinations; delays caused by unusually large prompts; temporary unavailability of a specific model where another supported model remains available.

Saees may substitute one AI model for another when reasonably necessary to maintain functionality, improve safety, or respond to provider changes.

25. AI AGENT INCIDENTS

An AI Agent issue may include:

Agent failure to execute; repeated execution error; unauthorized or unexpected action; incorrect workflow routing; integration failure; excessive execution delay; failure to respect configured limits.

Priority classification will depend on the actual operational impact.

A single inaccurate recommendation or output does not generally constitute a Service outage.

Customers must promptly:

pause affected Agents; revoke unnecessary permissions; preserve relevant logs; notify Saees; avoid repeated execution where harmful results are possible.

Saees may suspend an AI Agent or automation while investigating suspected harmful or unauthorized behavior.

26. API SUPPORT

The API availability target applies to Saees-controlled production API endpoints expressly covered by the Customer’s plan.

API support may include:

authentication errors; documented endpoint failure; material response degradation; webhook delivery issues; rate-limit questions; permission errors; production defects.

The API SLA does not apply to:

undocumented endpoints; deprecated endpoints after the published retirement date; unauthorized usage; requests exceeding rate limits; malformed requests; Customer code defects; unsupported software development kits; third-party APIs; sandbox environments; beta APIs.

Customers are responsible for implementing:

retries; exponential backoff; timeout handling; idempotency where applicable; error logging; secure credential storage; monitoring; reasonable fallback procedures.

27. MARKETPLACE INTEGRATION SUPPORT

Saees supports authorized integrations with:

Amazon; Walmart Marketplace; eBay; TikTok Shop.

Marketplace integration functionality depends on the applicable third party’s:

API availability; authorization rules; seller Account status; permissions; rate limits; data-access policies; technical documentation; product restrictions; security requirements.

Saees may assist with diagnosing integration issues, but does not control the Commerce Platform.

The following are not considered Saees Downtime unless directly caused by a verified Saees defect:

marketplace API outage; seller Account suspension; listing removal; category restriction; brand restriction; rejected application; revoked marketplace permission; inaccurate third-party data; delayed marketplace reporting; marketplace throttling; changes to marketplace policies; failure of marketplace credentials; third-party maintenance.

Saees does not guarantee uninterrupted synchronization with any Commerce Platform.

28. DATA SYNCHRONIZATION DELAYS

Certain Services depend on scheduled or event-driven synchronization.

Synchronization frequency may vary based on:

Subscription plan; marketplace API limits; data volume; Customer Account configuration; third-party availability; queue processing; product type; workflow priority.

A delay does not constitute Downtime unless it materially exceeds the applicable documented synchronization interval due to a verified Saees-controlled system failure.

Data displayed in Saees may not always reflect real-time third-party data.

Customers should verify time-sensitive information directly in the applicable Commerce Platform before making irreversible operational decisions.

29. THIRD-PARTY PROVIDER COORDINATION

Where an incident depends on a third-party provider, Saees may:

open a provider support case; provide available logs; implement a temporary workaround; monitor provider status; communicate material updates; modify affected functionality; temporarily disable an integration.

Saees cannot guarantee third-party response or resolution times.

Any estimated restoration time provided by a third party is informational and not binding on Saees.

30. ENTERPRISE TECHNICAL CONTACTS

Enterprise Customers should designate at least:

one primary technical contact; one backup technical contact; one billing contact; one security contact where appropriate.

The Customer must keep contact information current.

Saees may rely on instructions provided by designated contacts unless it has reason to believe the instructions are unauthorized, unlawful, or create a security risk.

31. SUPPORT LANGUAGE

Unless otherwise agreed, support may be provided in English or Spanish.

Technical documentation, third-party API responses, incident logs, and provider communications may be available only in English.

Translation assistance does not alter the meaning of third-party technical requirements or contractual terms.

32. NO GUARANTEE OF PERMANENT CORRECTION

Saees may determine that the most reasonable response to an issue is to:

provide a workaround; modify functionality; replace a provider; retire a feature; restrict an unsupported workflow; update documentation; schedule a correction for a future release.

Saees does not guarantee permanent correction of every reported issue, particularly where the issue:

is low impact; depends on a third party; relates to unsupported behavior; conflicts with security requirements; requires disproportionate engineering effort; results from an external policy change.

33. BUSINESS CONTINUITY

Saees maintains commercially reasonable business continuity practices designed to reduce the impact of operational disruptions.

Business continuity planning may address:

cloud infrastructure interruption; software deployment failure; database disruption; authentication failure; network interruption; cybersecurity incidents; third-party provider outages; loss of access to facilities or personnel; regional infrastructure events; emergency communication; restoration of critical functions.

Business continuity measures are intended to support restoration of the Services but do not guarantee uninterrupted operation.

Saees may periodically review and update its continuity procedures based on:

changes in infrastructure; material Service changes; new security risks; incident findings; changes in third-party providers; legal or regulatory requirements.

34. DISASTER RECOVERY

Saees maintains commercially reasonable disaster recovery procedures for core production systems.

Disaster recovery procedures may include:

restoration from backups; infrastructure redeployment; database recovery; replacement of affected cloud resources; credential rotation; restoration of application services; restoration of authentication systems; restoration of monitoring and logging; coordination with critical vendors.

Recovery priorities may be based on:

impact on Customers; security risk; importance of the affected system; dependency relationships; data-integrity considerations; availability of alternate systems.

Saees may restore partial functionality before complete functionality.

35. RECOVERY OBJECTIVES

Unless otherwise stated in an Enterprise Agreement, Saees maintains internal recovery objectives rather than guaranteed recovery commitments.

The following targets may apply to core production systems:

Objective Target Recovery Time Objective (RTO) Up to 12 hours Recovery Point Objective (RPO) Up to 24 hours

These targets are operational objectives and may vary depending on:

the affected service; the nature of the incident; data volume; backup availability; third-party dependencies; security requirements; the extent of infrastructure damage; legal or regulatory restrictions.

A Customer requiring stricter RTO or RPO commitments must enter into a separate Enterprise Agreement expressly providing those commitments.

36. BACKUP PRACTICES

Saees uses commercially reasonable backup procedures for selected production data and system configurations.

Backup practices may include:

automated database backups; point-in-time recovery where supported; encrypted backup storage; geographic or logical separation; access restrictions; periodic backup validation; backup retention schedules; infrastructure configuration backups; recovery testing.

Not every data element, event log, temporary file, cache, AI output, external integration response, or Customer-generated intermediate artifact is guaranteed to be backed up.

Customers should maintain independent copies of business-critical information where appropriate.

37. CUSTOMER DATA EXPORT

Depending on the Subscription plan and available functionality, Customers may be able to export certain Customer Data.

Exportable information may include:

product catalogs; reports; inventory information; selected order information; workflow logs; Organization information; generated documents; supported analytics.

Export availability may be limited by:

third-party platform restrictions; data-retention rules; privacy obligations; technical format; Subscription status; applicable fees; security requirements.

Customers are responsible for performing timely exports where independent retention is important to their business.

Saees is not responsible for the Customer’s failure to export available data before Account termination or expiration of an applicable retention period.

38. RESTORATION OF CUSTOMER DATA

Where Customer Data is lost or corrupted due to a verified Saees-controlled system failure, Saees will use commercially reasonable efforts to restore affected data from available backups.

Restoration may be limited where:

the data was never successfully transmitted to Saees; the data originated from a third-party platform and is no longer available; the Customer deleted the data; the Customer authorized an irreversible action; the applicable retention period expired; backups were affected by the same incident; restoration would create a security or compliance risk; the data was temporary or excluded from backup.

Saees does not guarantee restoration of every data element.

39. DATA INTEGRITY

Saees uses commercially reasonable controls intended to preserve the integrity of Customer Data.

Such controls may include:

validation checks; transaction controls; access controls; logging; monitoring; versioning where supported; reconciliation procedures; backup processes; error detection.

Customers remain responsible for verifying:

product information; pricing; inventory quantities; order data; shipping information; supplier information; AI-generated content; data synchronized from Commerce Platforms.

If a material discrepancy is identified, the Customer must promptly notify Saees and avoid taking irreversible actions based on unverified information.

40. SECURITY PROGRAM

Saees maintains a security program designed to protect the confidentiality, integrity, and availability of the Services and Customer Data.

The security program may include:

identity and access management; least-privilege access; role-based permissions; multi-factor authentication; encryption; secure development practices; vulnerability management; logging and monitoring; incident response; vendor risk management; employee confidentiality obligations; backup controls; security awareness; change management.

The specific controls used may evolve based on:

risk; technology; business needs; legal requirements; Customer requirements; industry practices.

41. ENCRYPTION

Saees uses commercially reasonable encryption measures for supported systems.

These may include:

Transport Layer Security for data in transit; encryption at rest for selected databases and storage systems; encrypted backups where supported; secure storage of secrets and credentials; managed encryption services provided by cloud vendors.

Encryption does not eliminate all security risk.

Customers must not transmit passwords, payment card security codes, private keys, or unnecessary sensitive information through unapproved fields or support channels.

42. ACCESS CONTROL

Saees limits internal access to production systems and Customer Data based on business need.

Internal access may be granted to personnel responsible for:

engineering; infrastructure; security; support; professional services; legal or compliance; incident investigation; system administration.

Access may be protected through:

unique accounts; role-based permissions; multi-factor authentication; audit logs; access reviews; termination procedures; confidentiality obligations.

Saees may access Customer Data where reasonably necessary to:

provide support; investigate incidents; maintain the Services; perform authorized professional services; enforce agreements; comply with law.

43. CUSTOMER ACCESS MANAGEMENT

Customers are responsible for administering access within their Organization.

Customer responsibilities include:

assigning appropriate roles; limiting administrative access; removing former employees and contractors; reviewing permissions; protecting credentials; enabling multi-factor authentication where available; avoiding shared Accounts; monitoring unusual activity; securing connected Commerce Platform credentials.

Saees is not responsible for unauthorized access resulting from:

shared credentials; weak passwords; compromised Customer devices; failure to revoke access; phishing; credential reuse; unauthorized third-party tools; Customer misconfiguration.

44. SECURITY INCIDENT RESPONSE

Saees maintains procedures for responding to suspected security incidents.

The response process may include:

detection; validation; containment; investigation; evidence preservation; eradication; restoration; notification; post-incident review; corrective action.

Saees may temporarily restrict access, disable integrations, rotate credentials, or suspend affected features during an investigation.

Security-related restrictions implemented to protect the Services or Customer Data may not constitute Downtime under this SLA.

45. SECURITY NOTIFICATION

Where required by applicable law or contract, Saees will notify affected Customers of a confirmed security breach involving Customer Data.

Notification may include available information concerning:

the nature of the incident; affected systems; categories of information involved; containment actions; restoration status; recommended Customer actions; Saees contact information.

Notification timing may be affected by:

law-enforcement requests; active investigations; the need to verify facts; security considerations; third-party provider involvement.

A suspected event, unsuccessful attack, blocked attempt, scan, or vulnerability without confirmed unauthorized access does not necessarily constitute a reportable breach.

46. VULNERABILITY MANAGEMENT

Saees uses commercially reasonable procedures to identify, assess, and address vulnerabilities.

These procedures may include:

automated dependency scanning; code review; infrastructure scanning; security alerts; penetration testing where appropriate; patch management; risk-based prioritization; third-party assessments.

Remediation timing may depend on:

severity; exploitability; production impact; availability of a patch; testing requirements; third-party dependencies; risk of introducing instability.

Saees does not warrant that the Services will be free from all vulnerabilities.

47. CHANGE MANAGEMENT

Saees may use change-management procedures for material production changes.

Such procedures may include:

development and testing; code review; deployment approval; staged deployment; rollback planning; monitoring; incident review.

Not every routine, automated, low-risk, or emergency change requires the same approval process.

Saees may deploy emergency changes immediately where necessary to address:

security threats; critical defects; service instability; legal requirements; third-party platform changes.

48. SOFTWARE RELEASES

Saees may release:

new features; corrections; security updates; performance improvements; interface changes; API versions; AI model changes; workflow enhancements.

Releases may be performed:

continuously; incrementally; by Customer group; through feature flags; as beta or preview functionality.

Saees may modify or withdraw a release where it creates:

security risk; unexpected errors; material performance degradation; third-party incompatibility; legal or compliance concerns.

49. DEPRECATED FEATURES AND APIS

Saees may deprecate or discontinue features, APIs, integrations, models, or workflows.

Where commercially reasonable, Saees may provide advance notice of a material deprecation affecting paid production use.

Notice periods may be shorter where discontinuation is required because of:

a security vulnerability; law or regulation; third-party provider action; marketplace policy changes; intellectual-property concerns; provider termination; urgent infrastructure needs.

Customers are responsible for migrating from deprecated functionality before the applicable retirement date.

Deprecated functionality is not covered by this SLA after its published retirement date.

50. CAPACITY MANAGEMENT

Saees monitors capacity and may take reasonable steps to maintain system performance.

Capacity planning may consider:

number of Customers; data volume; API request volume; AI usage; workflow executions; storage use; database utilization; third-party limits; expected growth.

Saees may impose reasonable limits to protect system stability.

Such limits may include:

rate limits; concurrency limits; file-size limits; storage limits; execution limits; AI Credit limits; queue prioritization; temporary throttling.

Restrictions applied because a Customer exceeds documented or reasonable usage limits do not constitute Downtime.

51. PERFORMANCE MANAGEMENT

Saees may monitor:

page load times; API response times; database performance; queue latency; synchronization duration; AI response latency; infrastructure utilization.

Performance may vary based on:

Customer location; internet connectivity; device performance; browser configuration; request complexity; data volume; marketplace availability; AI provider capacity; third-party services.

Temporary latency does not constitute Downtime unless it results in material unavailability of the core Services.

52. DEPENDENCE ON CLOUD PROVIDERS

The Services may depend on third-party cloud infrastructure providers.

Cloud services may include:

computing; storage; databases; networking; monitoring; authentication; security; content delivery; backup infrastructure.

Saees selects providers based on operational, technical, security, and commercial considerations.

Saees may change providers or infrastructure architecture without Customer approval, provided that such change does not materially reduce applicable contractual data-protection commitments.

53. DEPENDENCE ON AI PROVIDERS

AI features may rely on third-party model and infrastructure providers.

Third-party AI providers may:

change models; modify rate limits; retire models; alter safety controls; restrict regions; experience outages; change pricing; update terms.

Saees may respond by:

substituting models; adjusting workflows; limiting features; changing AI Credit consumption; suspending affected functions; providing alternative processing.

A third-party AI provider outage is excluded from the core uptime calculation unless otherwise expressly agreed.

54. DEPENDENCE ON COMMERCE PLATFORMS

Saees integrations depend on external Commerce Platforms.

Commerce Platforms may independently:

change APIs; revoke permissions; modify authorization scopes; impose rate limits; delay data; remove endpoints; suspend seller Accounts; restrict listings; change product requirements; perform maintenance.

Saees will use commercially reasonable efforts to adapt supported integrations, but cannot guarantee continued access to any third-party API or data source.

A Commerce Platform’s decision to restrict a Customer does not constitute Saees Downtime.

55. CUSTOMER SYSTEMS AND THIRD-PARTY SOFTWARE

Customers are responsible for systems and software outside Saees’ control, including:

local devices; browsers; networks; firewalls; virtual private networks; email systems; third-party extensions; custom code; middleware; unsupported integrations.

Saees may require the Customer to:

disable conflicting software; update browsers; test without extensions; provide logs; reproduce the issue in a supported environment.

Issues caused by Customer systems or unsupported software are excluded from the SLA.

56. SUPPORTED ENVIRONMENTS

Saees may publish supported technical requirements.

Supported environments may include:

current versions of major browsers; supported operating systems; approved API versions; supported authentication methods; documented integration configurations.

Saees is not required to support:

obsolete browsers; unsupported operating systems; jailbroken or compromised devices; unofficial APIs; modified clients; unapproved browser extensions; unsupported network configurations.

Customers are responsible for maintaining supported environments.

57. CUSTOMER CHANGE NOTIFICATION

Customers should notify Saees before material changes that may affect the Services, including:

major API volume increases; large data migrations; launch events; significant catalog imports; new custom integrations; major workflow automation; Organization restructuring; expected seasonal traffic increases.

Advance notice allows Saees to evaluate capacity and operational risk.

Failure to provide reasonable notice may affect performance and support response.

58. CUSTOMER BUSINESS CONTINUITY

Customers are responsible for maintaining their own business continuity and contingency procedures.

Such procedures should consider:

temporary loss of access to Saees; temporary loss of marketplace connectivity; manual order processing; inventory verification; customer communication; alternative shipping procedures; backup copies of essential reports; emergency credential management; AI Agent suspension; rollback of automated actions.

Saees should not be the sole repository for information that the Customer must retain independently for legal, tax, financial, product-safety, or operational purposes.

59. CUSTOMER SECURITY OBLIGATIONS

Customers must:

use strong authentication; protect Account credentials; restrict administrative access; maintain secure devices; use supported software; report suspected compromise; revoke access promptly; protect exported data; avoid unnecessary sensitive information; monitor integrations; comply with applicable privacy and security laws.

Customers must not attempt to test, scan, probe, or exploit the Services without Saees’ prior written authorization.

60. CUSTOMER COOPERATION DURING INCIDENTS

During an incident, Customers must reasonably cooperate by:

providing accurate information; responding to requests; preserving evidence; avoiding actions that worsen the incident; suspending affected automations; rotating credentials where requested; testing proposed workarounds; identifying affected Users; communicating through designated contacts.

Saees is not responsible for delays caused by lack of Customer cooperation.

61. CUSTOMER MITIGATION DUTY

Customers must take reasonable steps to reduce harm from an incident.

Such steps may include:

pausing an AI Agent; disabling a workflow; revoking credentials; verifying marketplace data; using a manual workaround; notifying internal teams; suspending publication of affected listings; preserving transaction records.

A Customer may not continue a known harmful workflow and later claim the resulting impact as compensable Downtime.

62. LOGS AND DIAGNOSTIC INFORMATION

Saees may collect and retain operational logs for:

troubleshooting; security; monitoring; audit; incident investigation; performance analysis; fraud prevention.

Logs may include:

timestamps; User identifiers; IP addresses; API events; workflow actions; error codes; integration responses; authentication events; AI Agent activity.

Log retention varies based on system, purpose, legal requirements, and Subscription plan.

Operational logs are not intended to serve as the Customer’s permanent system of record unless expressly agreed in writing.

63. AUDIT AND COMPLIANCE INFORMATION

Enterprise Customers may request reasonable information concerning Saees’ security and continuity practices.

Subject to availability, confidentiality, and security restrictions, Saees may provide:

security questionnaires; policy summaries; architecture descriptions; Subprocessor information; incident-response summaries; available audit reports; available certifications; data-protection documentation.

Saees is not required to disclose:

source code; penetration-testing details that create security risk; confidential information concerning other Customers; internal credentials; privileged legal material; information restricted by vendors.

Any onsite audit, custom assessment, or extensive compliance review may require a separate agreement and additional fees.

64. NO IMPLIED CERTIFICATION

Nothing in this SLA represents that Saees currently holds any certification unless Saees expressly identifies the certification in writing.

References to security or continuity practices do not constitute a representation that Saees is certified under:

SOC 2; ISO 27001; ISO 22301; PCI DSS; FedRAMP; another external standard.

Any future certification applies only within the scope stated in the applicable certification or report.

65. ELIGIBILITY FOR SERVICE CREDITS

Service Credits are available only where:

the Customer has an active paid Enterprise Subscription; the applicable Order Form or Enterprise Agreement expressly includes Service Credits; the Monthly Uptime Percentage for a covered production Service falls below the applicable Availability Commitment; the Customer has paid all undisputed fees when due; the Customer submits a valid claim within the required claim period; the outage is not subject to an exclusion under this SLA.

Unless expressly stated in an Enterprise Agreement, Service Credits are not available for:

free plans; trial plans; promotional access; beta Services; preview features; sandbox environments; development environments; Professional Services; consulting services; implementation projects; Customer-specific customizations; third-party Commerce Platforms; AI model providers; unsupported integrations; accounts that are suspended or delinquent.

Service Credits are calculated only against recurring Subscription fees paid for the affected covered Service during the affected calendar month.

66. SERVICE CREDIT SCHEDULE

Subject to the eligibility requirements and exclusions in this SLA, the following Service Credit schedule applies to covered Enterprise production Services:

Monthly Uptime Percentage Service Credit 99.9% or greater No credit Less than 99.9% but at least 99.5% 5% Less than 99.5% but at least 99.0% 10% Less than 99.0% but at least 95.0% 20% Less than 95.0% 30%

The percentage is applied to the eligible monthly recurring fee attributable to the affected covered Service.

Where a Subscription includes multiple products or service components, Saees may reasonably allocate the monthly fee among those components for purposes of calculating a Service Credit.

Service Credits may not exceed thirty percent of the eligible monthly recurring fee for the affected Service during the applicable calendar month unless an Enterprise Agreement expressly provides otherwise.

67. SERVICE CREDIT CALCULATION

Service Credits are calculated using Saees’ official monitoring records and the Monthly Uptime Percentage determined under this SLA.

The calculation will exclude:

Scheduled Maintenance; Emergency Maintenance; permitted downtime; excluded third-party incidents; Customer-caused interruptions; events outside Saees’ reasonable control; periods during which the Customer could not use the Services for reasons unrelated to platform availability.

Where an incident affects only a limited feature or portion of the Service, Saees may calculate the credit based on the recurring fee reasonably attributable to the affected feature.

A partial impairment that does not make the covered Service materially unavailable may not qualify for a Service Credit.

68. SERVICE CREDIT CLAIM PROCEDURE

To request a Service Credit, the Customer must submit a written claim to:

legal@saees.ai

The claim must be received within thirty calendar days after the end of the calendar month in which the alleged qualifying Downtime occurred.

The claim must include:

the Customer’s legal name; Organization name; Subscription or Order Form reference; affected production Service; date of the incident; start and end time; applicable time zone; description of the outage; business impact; relevant support ticket number; screenshots, logs, or other available evidence; requested Service Credit; billing contact information.

Failure to submit a complete claim within the required period waives the Customer’s right to receive a Service Credit for that incident.

Saees may request additional information reasonably necessary to investigate the claim.

69. REVIEW OF SERVICE CREDIT CLAIMS

Saees will review timely submitted claims using:

internal monitoring records; infrastructure logs; incident records; status communications; support tickets; third-party provider information; Customer-provided evidence.

Saees will use commercially reasonable efforts to issue a determination within thirty days after receiving a complete claim.

Saees may:

approve the claim; approve the claim in part; deny the claim; request additional information; apply an exclusion; adjust the calculated credit.

Saees’ determination will be final absent manifest error or a contrary express contractual provision.

70. APPLICATION OF SERVICE CREDITS

Approved Service Credits will ordinarily be applied to a future invoice for the same Customer Account.

Service Credits:

have no cash value; are not refunds; are not redeemable for money; are not transferable; may not be sold; may not be assigned to another Customer; may not be applied to taxes; may not be applied to third-party charges; may not be applied to Professional Services; may not be applied to past-due balances; expire twelve months after issuance unless otherwise stated.

Where there are no future eligible invoices, the credit expires and is not payable in cash unless required by applicable law.

71. EXCLUSIVE REMEDY

To the maximum extent permitted by law, Service Credits are the Customer’s sole and exclusive financial remedy for Saees’ failure to meet an Availability Commitment under this SLA.

Service Credits do not:

constitute an admission of liability; waive contractual limitations; create a warranty; establish negligence; increase Saees’ aggregate liability; compensate for lost profits, lost sales, marketplace penalties, or indirect damages.

Nothing in this section limits remedies that cannot lawfully be limited or excluded.

72. NO CREDITS FOR THIRD-PARTY PLATFORM FAILURES

Service Credits are not available for incidents caused by or attributable to:

Amazon; Walmart Marketplace; eBay; TikTok Shop; Mercado Libre, when available; payment processors; shipping carriers; authentication providers; cloud infrastructure outside Saees’ reasonable control; telecommunications providers; internet service providers; domain name systems; content delivery networks; AI model providers; data licensors; other third-party services.

Saees may assist with escalation or investigation but does not assume contractual responsibility for third-party availability.

73. NO CREDITS FOR MARKETPLACE ENFORCEMENT ACTIONS

The following events do not qualify for Service Credits:

seller Account suspension; reserve or fund hold; listing deactivation; product removal; brand restriction; category restriction; intellectual-property complaint; counterfeit allegation; product-safety enforcement; KYC or identity-verification failure; delayed marketplace approval; rejected appeal; rejected ungating application; marketplace policy change; advertising Account restriction.

These matters are controlled by the applicable Commerce Platform and are not Service outages.

74. NO CREDITS FOR AI OUTPUT QUALITY

Service Credits are not available because an AI-powered feature produces:

inaccurate information; incomplete information; inconsistent information; unexpected wording; unsuitable recommendations; unsupported conclusions; hallucinated information; biased or undesirable content; a refusal to respond; an output requiring correction; a result different from a previous model version.

AI output quality is governed by the Terms of Use, AI Policy, applicable documentation, and Customer review obligations.

75. AGGREGATE SERVICE CREDIT LIMIT

The total Service Credits issued for all incidents occurring during a single calendar month may not exceed thirty percent of the eligible recurring Subscription fee paid for that month.

Multiple incidents arising from the same underlying cause may be treated as one incident.

A Customer may not receive duplicate compensation for the same event under:

this SLA; another Service Level Agreement; an Order Form; an Enterprise Agreement; a refund; a settlement; another credit arrangement.

Where multiple remedies could apply, Saees may apply the remedy that provides the greatest contractually required benefit without duplication.

76. CHRONIC SERVICE FAILURE

Where an Enterprise Customer experiences a material failure to meet the Availability Commitment during three consecutive calendar months, the Customer may request an executive service review.

The review may include:

incident history; affected systems; root causes; remediation actions; infrastructure changes; monitoring improvements; continuity measures; future risk-reduction plans.

A Customer may request termination of the affected covered Service where:

the Service falls below 99.0% Monthly Uptime Percentage in three consecutive months; the Customer submitted timely valid Service Credit claims for each month; the failure was not caused by an excluded event; the Customer provides written notice within thirty days after the third affected month.

Where approved, termination applies only to the materially affected covered Service and does not automatically terminate unrelated Services.

Any termination right under this section is subject to contrary terms in an applicable Enterprise Agreement.

77. LIMITATION OF LIABILITY

This SLA does not expand Saees’ liability beyond the limitations established in the Terms of Use, Enterprise Agreement, Master Services Agreement, or other controlling agreement.

To the maximum extent permitted by law, Saees is not liable under this SLA for:

lost revenue; lost profits; loss of business opportunity; loss of anticipated savings; lost marketplace rankings; advertising losses; inventory loss; supplier disputes; marketplace penalties; loss of goodwill; loss of data that the Customer was responsible for retaining; indirect damages; incidental damages; consequential damages; punitive damages; exemplary damages; special damages.

The existence of multiple claims does not increase the applicable aggregate liability limit.

78. CUSTOMER DAMAGES AND MITIGATION

The Customer must take reasonable steps to mitigate any actual or potential loss associated with an incident.

Saees is not responsible for losses that could reasonably have been avoided through:

use of a documented workaround; suspension of an affected automation; verification of marketplace data; correction of Customer configuration; timely revocation of compromised credentials; implementation of backup procedures; compliance with Saees instructions; independent preservation of critical business records.

The Customer must not knowingly permit an incident to continue for the purpose of increasing a claim.

79. NO BUSINESS OUTCOME GUARANTEE

Saees does not guarantee:

sales; revenue; profitability; advertising performance; account approval; listing approval; brand approval; marketplace eligibility; inventory availability; customer conversion; seller Account reinstatement; supplier acceptance; regulatory compliance; uninterrupted third-party operations.

The Service Availability Commitment concerns access to covered Saees production Services and does not guarantee commercial results.

80. FORCE MAJEURE

Saees is not responsible for delay, interruption, or failure caused by events beyond its reasonable control.

Such events may include:

natural disasters; hurricanes; floods; earthquakes; fires; epidemics; pandemics; war; terrorism; civil unrest; sabotage; labor disputes; governmental actions; embargoes; sanctions; power-grid failures; telecommunications outages; internet backbone failures; widespread cyberattacks; cloud-provider failures; supply-chain disruptions; emergency legal orders; changes in applicable law; failures of critical third parties.

Saees will use commercially reasonable efforts to mitigate the impact of a force majeure event.

81. SUSPENSION OF SERVICES

Saees may suspend all or part of the Services where reasonably necessary to:

prevent or mitigate a security threat; stop unlawful use; protect Customer Data; prevent material harm; respond to a compromised Account; comply with law; comply with a court order; address nonpayment; enforce the Terms of Use; protect infrastructure stability; investigate suspected abuse; prevent unauthorized automated activity.

A suspension permitted under this section does not constitute Downtime.

Where reasonably practicable, Saees will provide notice of the suspension and the conditions for restoration.

82. TERMINATION OF THIS SLA

This SLA terminates automatically when:

the applicable Subscription ends; the Enterprise Agreement terminates; the covered Services are discontinued; the Customer ceases to be eligible; the Customer Account is terminated; the parties replace this SLA with another written agreement.

Termination does not affect:

previously accrued payment obligations; valid Service Credit claims timely submitted; confidentiality obligations; limitations of liability; provisions intended to survive termination.

83. MODIFICATIONS TO THE SLA

Saees may update this SLA from time to time.

Updates may be made to reflect:

changes in the Services; infrastructure improvements; new support plans; changes in third-party dependencies; legal requirements; operational practices; security improvements; new product capabilities.

The updated SLA will identify a revised “Last Updated” date.

Material changes that reduce an active Enterprise Customer’s contractual service commitment will not apply during the then-current committed Subscription term unless:

required by law; required for security; required because of a third-party provider; accepted by the Customer; permitted by the Enterprise Agreement.

Renewal of a Subscription after an updated SLA becomes effective constitutes acceptance of the updated SLA.

84. ORDER OF PRECEDENCE

In the event of conflict among applicable documents, the following order of precedence applies unless expressly stated otherwise:

A signed Enterprise Agreement or Master Services Agreement; An applicable signed Order Form; A signed Data Processing Addendum for data-protection matters; This Service Level Agreement; The Terms of Use; The Acceptable Use Policy; Product documentation.

A more specific provision governs over a general provision concerning the same subject.

85. RELATIONSHIP TO THE TERMS OF USE

This SLA is incorporated into and governed by the Saees Terms of Use.

Capitalized terms not defined in this SLA have the meanings assigned in the Terms of Use or applicable Enterprise Agreement.

The disclaimers, indemnification obligations, limitations of liability, governing-law provisions, and dispute-resolution provisions in the controlling agreement apply to this SLA.

86. CONFIDENTIALITY

Non-public information exchanged in connection with incidents, support cases, security investigations, Root Cause Analyses, architecture reviews, or Enterprise support is Confidential Information.

The receiving party must:

use Confidential Information only for authorized purposes; protect it using reasonable care; restrict disclosure to personnel with a need to know; comply with applicable confidentiality obligations.

Saees may withhold or redact information where disclosure could:

create a security risk; expose another Customer’s information; violate law; breach a third-party obligation; disclose privileged material; reveal sensitive internal controls.

87. DATA PROTECTION

Processing of personal information in connection with support and incident management is governed by:

the Saees Privacy Policy; the applicable Data Processing Addendum; the Terms of Use; applicable data-protection law.

Customers should limit support submissions to information reasonably necessary for investigation.

Customers must not submit unnecessary:

government identification numbers; full payment card numbers; health information; biometric information; authentication secrets; special-category personal information.

88. ASSIGNMENT

The Customer may not assign this SLA separately from the controlling Subscription or Enterprise Agreement.

Any permitted assignment of the controlling agreement includes this SLA unless otherwise stated.

Saees may assign this SLA in connection with:

a merger; acquisition; reorganization; financing; sale of assets; transfer to an Affiliate; corporate restructuring.

Assignment does not relieve either party of obligations accrued before the effective date of assignment.

89. NO THIRD-PARTY BENEFICIARIES

This SLA is intended solely for the benefit of Saees and the applicable Customer.

No User, marketplace, supplier, contractor, employee, consumer, or other third party is entitled to enforce this SLA unless expressly identified in a written agreement.

90. NO WAIVER

Failure to enforce any provision of this SLA does not waive the right to enforce that provision later.

A waiver is effective only where made in writing by an authorized representative.

A waiver concerning one incident does not constitute a waiver concerning another incident.

91. SEVERABILITY

If any provision of this SLA is held invalid, illegal, or unenforceable, that provision will be modified to the minimum extent necessary to make it enforceable.

If modification is not possible, the provision will be severed.

The remaining provisions will continue in full force and effect.

92. ELECTRONIC COMMUNICATIONS

Notices and operational communications under this SLA may be delivered electronically through:

email; the Saees platform; support tickets; administrative notifications; the Saees status page; designated Enterprise channels.

The Customer is responsible for maintaining accurate contact information and monitoring applicable communication channels.

93. FORMAL NOTICES

Formal legal notices concerning this SLA must be sent to:

Saees LLC

Email: legal@saees.ai

Privacy matters: privacy@saees.ai

Security matters: security@saees.ai

General support: support@saees.ai

Saees may update its notice information by publishing revised contact details on its website or in the applicable legal documentation.

A Customer’s formal notice address is the address identified in the applicable Order Form, Enterprise Agreement, or Account records.

94. GOVERNING LAW

Unless a signed Enterprise Agreement expressly provides otherwise, this SLA and any dispute arising out of or relating to it shall be governed by and construed in accordance with the laws of the State of Washington, without regard to its conflict-of-laws principles.

The United Nations Convention on Contracts for the International Sale of Goods does not apply.

95. DISPUTE RESOLUTION AND JURISDICTION

Any dispute arising out of or relating to this SLA shall be subject to the dispute-resolution provisions contained in the Saees Terms of Use or the applicable Enterprise Agreement.

Before commencing formal proceedings, the parties shall use commercially reasonable efforts to resolve the dispute through good-faith discussions.

A dispute concerning an uptime calculation or Service Credit must first be submitted through the Service Credit claim procedure described in this SLA.

Unless the controlling agreement requires arbitration or provides otherwise, the state and federal courts located in King County, Washington shall have exclusive jurisdiction over any judicial proceeding arising out of or relating to this SLA, and each party consents to the personal jurisdiction and venue of those courts.

Nothing in this section prevents either party from seeking urgent equitable or injunctive relief where reasonably necessary to prevent unauthorized access, security harm, misuse of Confidential Information, intellectual-property infringement, or other irreparable harm.

96. ENTIRE SLA

This SLA, together with the controlling agreement and applicable Order Form, constitutes the complete agreement concerning the specific service-level commitments described herein.

Statements in:

sales presentations; demonstrations; marketing materials; proposals; support conversations; product roadmaps; informal communications;

do not create binding service-level commitments unless expressly incorporated into a signed written agreement.

97. ENTERPRISE CUSTOMIZATION

Enterprise Customers may negotiate customized service levels through a signed Order Form, Enterprise Agreement, or SLA addendum.

Customized provisions may include:

different uptime commitments; enhanced support hours; stricter response objectives; dedicated technical contacts; customized maintenance windows; enhanced reporting; additional Service Credits; specific RTO or RPO commitments; incident notification requirements; dedicated infrastructure; custom escalation procedures.

No customized service level is binding unless documented in writing and signed by authorized representatives.

98. ENTERPRISE SLA ADDENDUM TEMPLATE

Where the parties execute a customized SLA addendum, it should identify:

Customer legal name; Saees legal entity; covered Services; Subscription term; availability commitment; applicable time zone; support hours; incident priorities; response objectives; restoration objectives; maintenance windows; Service Credit schedule; escalation contacts; reporting requirements; exclusions; effective date; authorized signatures.

Any fields not expressly modified remain governed by this standard SLA.

99. NO REPRESENTATION OF LEGAL COMPLIANCE

This SLA describes operational service levels and does not constitute:

legal advice; tax advice; regulatory advice; cybersecurity certification; marketplace compliance advice; assurance of legal compliance.

Customers remain responsible for determining whether the Services satisfy their particular legal, technical, regulatory, and operational requirements.

100. CONTACT INFORMATION

Questions about this SLA may be directed to:

Support

support@saees.ai

Legal

legal@saees.ai

Privacy

privacy@saees.ai

Security

security@saees.ai

Mailing Address

4730 University Wy NE, Seattle, WA 98105

101. EFFECTIVE DATE

This Service Level Agreement is effective as of:

July 27, 2026

Last Updated: July 27, 2026

102. LEGAL REVIEW

These documents should be reviewed by qualified legal counsel experienced in SaaS, artificial intelligence, privacy, and technology transactions, including applicable Washington State and United States federal law.

It applies to eligible Services provided on or after the Effective Date, subject to any controlling Enterprise Agreement, Order Form, or other written agreement.

102. ACCEPTANCE

By purchasing, renewing, accessing, or continuing to use an eligible paid Service after this SLA becomes effective, the Customer acknowledges that it has reviewed and accepted this SLA, unless a signed agreement provides otherwise.

For negotiated Enterprise arrangements, acceptance may also be evidenced by execution of an applicable Order Form, Enterprise Agreement, or SLA Addendum.