Support Policy (Enterprise SaaS) — Universal

ENTERPRISE SAAS SUPPORT POLICY

UNIVERSAL (JURISDICTION-NEUTRAL) EDITION

CUSTOMIZATION NOTE: This universal template is designed as a starting point for all U.S. jurisdictions. Sections marked with "[JURISDICTION NOTE]" require state-specific customization. Before execution, counsel should review and adapt this template for the applicable governing law, including consumer protection statutes, data breach notification requirements, electronic signature laws, and implied warranty rules. State-specific editions are available for California, New York, Texas, Florida, Colorado, Arizona, Mississippi, Missouri, and Montana.

Support Policy Reference Number: [________________________________]

Effective Date: [__/__/____]

Last Revised: [__/__/____]

This Enterprise SaaS Support Policy ("Support Policy" or "Policy") is incorporated into and forms part of the Master SaaS Agreement or equivalent subscription agreement ("Master Agreement") between the parties identified below. Capitalized terms not defined herein shall have the meanings set forth in the Master Agreement.

Provider: [________________________________] ("Provider")

• Address: [________________________________]
• State of Organization: [________________________________]

Customer: [________________________________] ("Customer")

• Address: [________________________________]
• State of Organization: [________________________________]

Master Agreement Date: [__/__/____]

Master Agreement Reference: [________________________________]

TABLE OF CONTENTS

1. Definitions
2. Scope of Support
3. Support Tiers and Pricing
4. Support Hours and Channels
5. Named Support Contacts
6. Severity Definitions
7. Response and Resolution Targets
8. Escalation Matrix
9. Customer Obligations
10. Exclusions
11. Status Updates and Communication
12. Maintenance Windows
13. Version Support and End-of-Life
14. Service Credits
15. Support Performance Reporting
16. Security Incident Support
17. Changes to Support Policy
18. Order of Precedence
19. Governing Law and Legal Provisions
20. Electronic Signatures
21. Signature Blocks
22. Exhibit A: Support Contact Information
23. Exhibit B: Supported Configurations

1. DEFINITIONS

For the purposes of this Support Policy, the following terms shall have the meanings ascribed below:

1.1 "Authorized Contact" means an individual designated by Customer who is authorized to submit support requests, access the Support Portal, and communicate with Provider's support personnel on Customer's behalf.

1.2 "Business Day" means Monday through Friday, excluding federal holidays observed in the United States and, if applicable, state holidays in the state designated as the governing law jurisdiction.

1.3 "Business Hours" means 8:00 AM to 6:00 PM in the timezone specified in the Master Agreement on Business Days, unless otherwise specified in the applicable Support Tier. [JURISDICTION NOTE: Adjust timezone to match governing law state. Arizona does not observe DST.]

1.4 "Customer Environment" means the totality of Customer's hardware, software, network infrastructure, configurations, third-party integrations, and operating conditions in which the SaaS Service operates or with which it interacts.

1.5 "Defect" means a reproducible failure of the SaaS Service to perform materially in accordance with the applicable Documentation.

1.6 "Enhancement" means a request for new functionality, features, or capabilities not described in the current Documentation, which shall be addressed through Provider's product roadmap process rather than through this Support Policy.

1.7 "Error" means any verifiable and reproducible failure of the SaaS Service to conform to the specifications set forth in the Documentation.

1.8 "Fix" means a permanent code change or configuration modification that resolves a Defect or Error and is incorporated into a generally available release of the SaaS Service.

1.9 "Hot Fix" means an emergency code change deployed outside of the standard release cycle to address a Severity 1 or Severity 2 Incident in the Production Environment.

1.10 "Incident" means any event that is not part of the standard operation of the SaaS Service and that causes, or may cause, an interruption to or a reduction in the quality of the SaaS Service.

1.11 "Maintenance Window" means a pre-designated period during which Provider may perform scheduled maintenance, updates, patches, or upgrades to the SaaS Service infrastructure.

1.12 "Named Support Contact" means a specific individual designated by Customer in Exhibit A who is trained and authorized to serve as the primary liaison between Customer and Provider's support organization.

1.13 "Production Environment" means the live, operational instance of the SaaS Service used by Customer's end users for actual business operations, as distinguished from staging, testing, or development environments.

1.14 "Resolution" means the point at which an Incident has been resolved through a Fix, Hot Fix, Workaround, or other corrective action such that the SaaS Service operates materially in accordance with the Documentation.

1.15 "Root Cause Analysis" ("RCA") means a structured investigation to identify the underlying cause of a Severity 1 or Severity 2 Incident, resulting in a written report that includes the timeline of events, contributing factors, corrective actions taken, and preventive measures implemented.

1.16 "Service Credit" means a credit against future fees owed by Customer to Provider, calculated in accordance with Section 14 of this Policy, issued when Provider fails to meet specified Service Levels.

1.17 "Service Level" means a measurable standard of performance that Provider commits to meeting, as specified in Section 7 and the Master Agreement.

1.18 "Severity Level" means the classification assigned to an Incident based on its impact and urgency, as defined in Section 6 of this Policy.

1.19 "Support Portal" means Provider's web-based ticketing and knowledge base system accessible at [________________________________] through which Authorized Contacts submit and track support requests.

1.20 "Ticket" means a uniquely numbered record created in the Support Portal to track a support request from initial submission through Resolution, including all communications, status updates, and resolution details.

1.21 "Uptime" means the percentage of time during a given calendar month that the Production Environment is available and operational, calculated as set forth in the Master Agreement.

1.22 "Workaround" means a temporary method of achieving a result equivalent or comparable to the intended function of the SaaS Service, which circumvents a known Defect or Error without constituting a permanent Fix.

2. SCOPE OF SUPPORT

2.1 Included Support Services

Provider shall furnish the following support services under this Policy:

(a) Break/Fix Support — Diagnosis and resolution of Errors, Defects, and Incidents that cause the SaaS Service to fail to perform materially in accordance with the Documentation.

(b) Configuration Assistance — Guidance on configuring the SaaS Service within the parameters described in the Documentation, including standard settings, user management, and role-based access configuration.

(c) Standard Integration Support — Assistance with integrations that are documented and supported by Provider as part of the SaaS Service, including API usage guidance for published endpoints.

(d) Software Updates — Delivery and deployment of patches, minor releases, and major releases as part of the subscription, including release notes and migration guidance.

(e) Knowledge Base Access — Self-service access to Provider's searchable library of articles, how-to guides, FAQs, and troubleshooting documentation.

(f) Health Checks — For Premium and Enterprise tier customers, periodic reviews of Customer's usage patterns, configuration, and performance metrics with recommendations for optimization.

2.2 Excluded Services

The following services are not included within the scope of this Support Policy and, if available, shall be provided under a separate statement of work or professional services agreement at Provider's then-current rates:

(a) Custom software development, bespoke integrations, or modifications to the SaaS Service source code;

(b) On-site support, including travel to Customer's physical locations;

(c) Training services beyond standard onboarding documentation and knowledge base materials;

(d) Data migration, extraction, or conversion services;

(e) Support for third-party software, hardware, or services not expressly listed in Exhibit B;

(f) Performance tuning or optimization of Customer's network, hardware, or third-party infrastructure; and

(g) Support for deprecated or end-of-life versions of the SaaS Service as described in Section 13.

3. SUPPORT TIERS AND PRICING

Provider offers three (3) support tiers. Customer's selected tier is identified in the Master Agreement or applicable Order Form.

Customer's Selected Tier: ☐ Standard | ☐ Premium | ☐ Enterprise

4. SUPPORT HOURS AND CHANNELS

4.1 Support Hours by Tier

[JURISDICTION NOTE: Adjust timezone to match governing law. Common choices: ET, CT, MT, PT. Arizona uses MST year-round.]

4.2 Support Channels

4.3 After-Hours Support

For Severity 1 and Severity 2 Incidents occurring outside of standard Support Hours, Premium and Enterprise tier customers may reach the on-call support team via the emergency support line at [________________________________]. Standard tier customers may submit a Portal ticket; the SLA clock begins at the start of the next Business Day.

4.4 SLA Clock Commencement

The SLA clock for Response Time begins when a Ticket is created in the Support Portal with sufficient information for Provider to begin diagnosis. Tickets submitted via email shall be deemed received upon Ticket creation confirmation. The SLA clock pauses when Provider is awaiting information or action from Customer and resumes when Customer responds.

5. NAMED SUPPORT CONTACTS

5.1 Number of Named Support Contacts

• Standard Tier: Up to two (2) Named Support Contacts
• Premium Tier: Up to five (5) Named Support Contacts
• Enterprise Tier: Up to ten (10) Named Support Contacts

5.2 Role Requirements

Each Named Support Contact shall:

(a) Have completed Provider's standard support training or onboarding process;

(b) Possess sufficient technical knowledge of the SaaS Service and Customer's environment to provide first-level triage before engaging Provider support;

(c) Have authority to approve Workarounds, schedule maintenance, and authorize access to Customer's environment for diagnostic purposes; and

(d) Be available during Business Hours to respond to Provider inquiries related to open Tickets.

5.3 Contact Change Process

Customer may change Named Support Contacts by submitting a written request to Provider through the Support Portal or by email to [________________________________]. Changes shall become effective within two (2) Business Days. New contacts must complete onboarding within fifteen (15) calendar days.

5.4 Contact Information

Named Support Contacts are listed in Exhibit A, which Customer shall keep current.

6. SEVERITY DEFINITIONS

All Incidents shall be classified according to the following Severity Levels. Provider reserves the right to reclassify Severity Levels in good faith based on investigation findings, with written justification to Customer.

6.1 Severity Classification Disputes

If Customer disagrees with a Severity classification, Customer may escalate to Provider's Support Manager, who shall review and respond within two (2) hours during Business Hours. Unresolved disputes follow the Escalation Matrix in Section 8.

7. RESPONSE AND RESOLUTION TARGETS

7.1 Response and Resolution Times by Severity and Tier

7.2 Measurement and Assumptions

(a) Response Time is measured from Ticket receipt in the Support Portal to Provider's acknowledgment and active diagnosis.

(b) Resolution Targets are goals, not guarantees, except to the extent that failure triggers Service Credits per Section 14.

(c) The SLA clock pauses when: (i) Provider is awaiting information or action from Customer; (ii) the Incident requires a third-party vendor fix; or (iii) a force majeure event occurs.

(d) Resolution Targets assume Customer provides timely access per Section 9.

8. ESCALATION MATRIX

8.1 Internal Escalation Path

8.2 Customer-Initiated Escalation

Customer may initiate escalation at any time through the Support Portal, by emailing [________________________________], or by contacting the Dedicated Account Engineer (Enterprise tier).

8.3 Escalation Documentation

All escalations shall be documented in the Ticket with reason, level, personnel, and next steps.

9. CUSTOMER OBLIGATIONS

9.1 Supported Configurations

Customer shall maintain its environment within the supported configurations listed in Exhibit B.

9.2 Log and Diagnostic Access

Customer shall provide Provider with reasonable access to relevant system logs, error messages, screenshots, and diagnostic data necessary to investigate Incidents. For Severity 1 and Severity 2 Incidents, Customer shall use commercially reasonable efforts to provide such access within one (1) hour.

9.3 Patch and Update Application

Customer shall apply critical security patches within fourteen (14) calendar days of release notification and non-critical updates within thirty (30) calendar days.

9.4 Contact Availability

Customer shall ensure at least one Named Support Contact is available during Business Hours and, for Severity 1 Incidents, within thirty (30) minutes outside Business Hours.

9.5 Incident Reporting Quality

Customer shall submit Tickets including: (a) description; (b) expected vs. actual behavior; (c) reproduction steps (if known); (d) business impact; (e) Customer Environment details; and (f) relevant screenshots, logs, or error messages.

9.6 Environment Change Notification

Customer shall notify Provider at least five (5) Business Days in advance of material changes to the Customer Environment.

10. EXCLUSIONS

Provider shall have no obligation to support Incidents arising from:

(a) Customer's network, hardware, or telecommunications infrastructure;

(b) Third-party software, services, or integrations not listed in Exhibit B;

(c) Unauthorized use of the SaaS Service;

(d) Modifications by anyone other than Provider or its authorized agents;

(e) Customer's failure to apply required patches per Section 9.3;

(f) Failure to maintain supported configurations per Exhibit B;

(g) Unsupported browsers, operating systems, or devices;

(h) Force majeure events as defined in the Master Agreement;

(i) Issues arising from Customer's data or content; and

(j) End-of-life versions per Section 13.

11. STATUS UPDATES AND COMMUNICATION

11.1 Update Cadence by Severity

11.2 Communication Content

Each update shall include: (a) investigation status; (b) actions taken; (c) planned next steps; (d) estimated time to milestone; and (e) any Customer action required.

11.3 Incident Resolution Notification

Upon Resolution, Provider shall deliver a closing notification with: (a) Incident summary; (b) root cause (Sev 1/2); (c) Resolution or Workaround applied; (d) Customer actions required; and (e) preventive recommendations.

12. MAINTENANCE WINDOWS

12.1 Scheduled Maintenance

Provider shall perform routine maintenance during the standard Maintenance Window of [________________________________]. Provider shall provide at least seventy-two (72) hours' advance written notice.

12.2 Emergency Maintenance

Provider may perform emergency maintenance when necessary for critical security, data integrity, or Severity 1 issues. Provider shall provide at least four (4) hours' advance notice when feasible.

12.3 Planned Downtime

Properly noticed scheduled maintenance shall not count against the Uptime SLA. Emergency maintenance shall count against the Uptime SLA unless caused by force majeure or Customer action.

12.4 Status Page

Provider shall maintain a status page at [________________________________] with real-time system status, upcoming maintenance, and historical uptime.

13. VERSION SUPPORT AND END-OF-LIFE

13.1 Supported Versions

Provider shall support the current generally available version and the two (2) most recent prior major versions ("Supported Versions").

13.2 End-of-Life Notice

Provider shall provide at least one hundred eighty (180) calendar days' written notice before designating a major version as end-of-life, including EOL date, migration guidance, available tools, and last date of support.

13.3 Security Patches Post-EOL

Provider shall provide critical security patches for ninety (90) calendar days post-EOL ("Extended Security Support Period").

13.4 Migration Assistance

For Premium and Enterprise tier customers, Provider shall provide reasonable migration assistance at no additional charge if initiated within the notice period.

14. SERVICE CREDITS

14.1 Eligibility

Service Credits are available when Provider fails to meet Response Time targets or the Uptime SLA, subject to Section 10 exclusions.

14.2 Service Credit Calculation — Response Time Failures

14.3 Service Credit Calculation — Uptime Failures

14.4 Credit Cap

Total Service Credits shall not exceed 100% of the affected month's fees. Credits are not redeemable for cash, not transferable, and applied to the next invoice.

14.5 Claim Process

Customer must submit a written claim within thirty (30) calendar days of month-end, identifying the failure, Ticket number(s), and dates/times. Provider shall respond within fifteen (15) Business Days.

14.6 Sole Remedy

Service Credits constitute Customer's sole and exclusive remedy for Service Level failures, except for willful misconduct, gross negligence, or breach of confidentiality. [JURISDICTION NOTE: Some states restrict "sole remedy" clauses in consumer transactions. Review applicable state consumer protection law.]

15. SUPPORT PERFORMANCE REPORTING

15.1 Monthly Reports

Provider shall deliver monthly support performance reports within ten (10) Business Days of month-end, including:

(a) Tickets opened/closed by Severity;
(b) Response Time performance vs. targets;
(c) Resolution Time performance vs. targets;
(d) Escalations beyond L2;
(e) Uptime percentage;
(f) Sev 1/2 Incident summaries and RCA status; and
(g) Service Credit calculations.

15.2 Quarterly Business Reviews

Premium customers: quarterly. Enterprise customers: monthly.

15.3 Key Performance Indicators

First Response Time, MTTR, Customer Satisfaction Score (CSAT), Ticket Reopen Rate, Escalation Rate, and Uptime percentage.

16. SECURITY INCIDENT SUPPORT

16.1 Security Incident Classification

Security-related Incidents shall be classified as Severity 1 by default and receive immediate priority regardless of Support Tier.

16.2 Elevated Support During Security Incidents

During confirmed or suspected security incidents: (a) dedicated coordinator within 15 minutes; (b) updates every 30 minutes until containment; (c) coordination with Customer's security team; (d) interim report within 24 hours; and (e) full RCA within 5 Business Days.

16.3 Data Breach Notification Compliance

[JURISDICTION NOTE: Data breach notification requirements vary significantly by state. Key variations include:]

Provider shall:

(a) Comply with the data breach notification requirements of the governing law jurisdiction;

(b) Cooperate with Customer in providing required notifications within statutory deadlines;

(c) Maintain incident documentation sufficient to support Customer's compliance obligations; and

(d) Provide forensic data and investigative reports as reasonably available.

16.4 Coordination with Customer's Incident Response

Provider's security incident support shall integrate with Customer's incident response plan. Customer shall designate a security incident contact in Exhibit A.

17. CHANGES TO SUPPORT POLICY

17.1 Notice of Changes

Provider may update this Policy with at least sixty (60) calendar days' notice for material changes and thirty (30) calendar days for non-material changes.

17.2 Material Reduction Protections

If a change constitutes a material reduction, Customer may within thirty (30) days either accept the change or require the prior version through the current term.

17.3 Non-Diminishment

Response Time and Uptime commitments shall not be reduced below Effective Date levels during the current term without Customer's written consent.

18. ORDER OF PRECEDENCE

This Policy is incorporated into the Master Agreement. For support-specific metrics and procedures, this Policy controls. For all other matters, the Master Agreement controls. Order Forms with differing support terms control if they expressly reference this Policy and identify the modified provisions.

19. GOVERNING LAW AND LEGAL PROVISIONS

19.1 Governing Law

This Support Policy shall be governed by the laws of [________________________________] [insert state], without regard to conflict of laws principles.

[JURISDICTION NOTE: Select the governing law state carefully. Key considerations:]

• California: Strong consumer protections (CCPA/CPRA, Song-Beverly Act); liberal discovery; large potential exposure
• New York: Sophisticated commercial law; N.Y. Gen. Bus. Law §§ 349-350 consumer protection; SHIELD Act
• Texas: DTPA with treble damages for knowing violations; 60-day breach notification
• Florida: FDUTPA; 30-day breach notification; no private right of action for data breaches
• Delaware: Business-friendly; commonly selected in commercial contracts

19.2 Venue and Jurisdiction

The parties submit to the exclusive jurisdiction and venue of the state and federal courts located in [________________________________] County, [________________________________] State.

19.3 Consumer Protection

[JURISDICTION NOTE: Insert applicable state consumer protection statute. All 50 states and D.C. have consumer protection acts. Key statutes:]

Provider represents that all Service Levels, descriptions, and commitments in this Policy are truthful and not misleading.

19.4 Implied Warranty

[JURISDICTION NOTE: UCC Article 2 implied warranty rules apply if SaaS is classified as a "good" or mixed transaction. Key considerations:]

(a) Implied warranties of merchantability (UCC § 2-314) and fitness for a particular purpose (UCC § 2-315) may apply;

(b) Disclaimers must comply with UCC § 2-316 — must be conspicuous and mention "merchantability";

(c) Some states restrict disclaimers in consumer transactions (e.g., Mississippi restricts software warranty disclaimers to merchant-to-merchant sales);

(d) This Policy does not disclaim implied warranties; any disclaimer is in the Master Agreement and must comply with applicable state law.

19.5 Jury Waiver

TO THE FULLEST EXTENT PERMITTED BY APPLICABLE LAW, EACH PARTY WAIVES ANY RIGHT TO TRIAL BY JURY.

[JURISDICTION NOTE: Jury waiver enforceability varies by state. Some states (e.g., California, Montana) have limited or uncertain enforceability. Consult local counsel.]

19.6 Cure Period

Provider shall have thirty (30) calendar days to cure material breach after written notice, except for Severity 1 failures unresolved beyond twice the Resolution Target.

20. ELECTRONIC SIGNATURES

This Support Policy may be executed electronically in accordance with the governing jurisdiction's enactment of the Uniform Electronic Transactions Act (UETA) and the federal Electronic Signatures in Global and National Commerce Act (E-SIGN Act, 15 U.S.C. § 7001 et seq.). Electronic signatures shall have the same legal effect as manual signatures.

[JURISDICTION NOTE: 49 states and D.C. have adopted UETA. New York has the Electronic Signatures and Records Act (ESRA), N.Y. State Tech. Law §§ 301-309, instead of UETA. Illinois has the Electronic Commerce Security Act (815 ILCS 333). Cite the correct state statute.]

21. SIGNATURE BLOCKS

IN WITNESS WHEREOF, the parties have executed this Enterprise SaaS Support Policy as of the Effective Date.

PROVIDER:

Signature: [________________________________]

Printed Name: [________________________________]

Title: [________________________________]

Date: [__/__/____]

CUSTOMER:

Signature: [________________________________]

Printed Name: [________________________________]

Title: [________________________________]

Date: [__/__/____]

EXHIBIT A: SUPPORT CONTACT INFORMATION

Provider Support Contacts

Customer Named Support Contacts

(Add rows as needed based on Support Tier allocation)

Customer Security Incident Contact

EXHIBIT B: SUPPORTED CONFIGURATIONS

Supported Browsers

Supported Operating Systems

Network Requirements

Supported Third-Party Integrations

SOURCES AND REFERENCES

1. Federal E-SIGN Act — 15 U.S.C. § 7001 et seq.
   https://www.law.cornell.edu/uscode/text/15/chapter-96

2. Uniform Electronic Transactions Act (UETA) — Uniform Law Commission
   https://www.uniformlaws.org/committees/community-home?CommunityKey=2c04b76c-2b7d-4399-977e-d5876ba7e034

3. Uniform Commercial Code Article 2 (Sales)
   https://www.law.cornell.edu/ucc/2

4. State Consumer Protection Statutes — National Consumer Law Center
   https://www.nclc.org/

5. State Data Breach Notification Laws — National Conference of State Legislatures
   https://www.ncsl.org/technology-and-communication/security-breach-notification-laws

This template is provided for informational purposes only and does not constitute legal advice. It is a jurisdiction-neutral starting point that must be customized with state-specific provisions by a qualified attorney licensed in the applicable jurisdiction. Laws and regulations change frequently; verify all citations before relying on this document. This template is designed for the ezel.ai platform.