Tentunit Business — Service Level Agreement (SLA)

Version 1.1 (Draft — pending legal review) · Effective Date: July 11, 2026 · Applies to: Tentunit Business

1. Overview

This section explains what this document is and how it relates to your other agreements with Tentunit. In short: it defines our availability commitment, our support response targets, and the credits available if we miss them.

1.1 Scope and Incorporation

This Service Level Agreement (“SLA”) describes the availability commitment and support levels for Tentunit Business. It forms part of, and is governed by, the Tentunit Business Terms of Service (the “Terms of Service”). Capitalized terms not defined here have the meanings given in the Terms of Service.

1.2 Order of Precedence

If your signed order form contains a custom SLA, that custom SLA overrides this document to the extent of any conflict (see Section 12). Otherwise, this SLA applies to all Tentunit Business subscriptions.

2. Definitions

This section defines the terms used to measure and administer the SLA.

  • “Service” means the Tentunit Business web application and API made available under your subscription.
  • “Monthly Uptime Percentage” means, for a calendar month: (total minutes in the month − minutes of Downtime) ÷ total minutes in the month, expressed as a percentage.
  • “Downtime” means minutes during which the Service is unavailable to all of your Authorized Users, excluding the exclusions in Section 4.
  • “Business Hours” means Monday–Friday, 9:00–18:00 US Eastern Time, excluding US federal holidays.
  • “Business Day” means a day within Business Hours.
  • “Service Credit” means a credit against your monthly subscription fee calculated under Section 5.
  • “Scheduled Maintenance” means maintenance announced in advance under Section 11.
  • “Incident” means an unplanned event that causes, or may cause, Downtime or material degradation of the Service.

3. Uptime Commitment & Measurement Methodology

This section states the availability commitment and explains exactly how uptime is calculated, what counts as down, and whose measurements govern.

3.1 Commitment

Tentunit commits to a Monthly Uptime Percentage of 99.9%, measured per calendar month across the Service.

3.2 Calculation

Monthly Uptime Percentage is computed on total calendar minutes in the month. For example, a 30-day month contains 43,200 minutes; at a 99.9% commitment, no more than 43.2 minutes of Downtime may accrue in such a month before the commitment is missed. Downtime is measured in whole minutes from the time our monitoring first detects unavailability (or, if earlier, the time unavailability is confirmed from a customer report) until the Service is restored.

3.3 Monitoring Source of Truth

Availability is measured by Tentunit’s monitoring systems — external synthetic probes and internal health checks operating continuously against the production Service — which are the system of record for SLA purposes. We will review reasonable evidence you submit with a credit request (for example, timestamped error responses or request logs) and will reconcile it against our monitoring in good faith, but where the two conflict, our monitoring data controls.

3.4 Downtime Definition; Partial Degradation

Downtime requires that the Service is unavailable to all of your Authorized Users — for example, the application or API returning errors or failing to respond for all requests. The following are degradation, not Downtime, and do not accrue Downtime minutes: elevated latency; slowness of individual pages or reports; unavailability of a single non-core feature while the core Service remains usable; issues affecting only some users, browsers, or network paths; and cosmetic defects. Degradation is instead handled through support under the severity framework in Section 7. If a partial outage is severe enough that the Service is effectively unusable for all of your Authorized Users, we will treat it as Downtime in good faith.

4. Exclusions

This section lists events that do not count as Downtime, because they are planned, outside our control, or caused on the customer side.

The following do not count as Downtime and are excluded from the Monthly Uptime Percentage calculation:

  1. Scheduled Maintenance, up to 8 hours per calendar month, announced at least 48 hours in advance by email or in-product notice (see Section 11).
  2. Force majeure events, as defined in the Terms of Service.
  3. Third-party outages, including failures of Stripe or other payment processors, hosting or network providers outside Tentunit’s reasonable control, and integrations you have connected.
  4. Customer-caused issues, including your equipment, network, misconfiguration, misuse of the API, exceeding documented usage limits, or suspension of your account under the Terms of Service.

5. Service Credits

This section sets out the credits available when the uptime commitment is missed, how to claim them, and how they are applied.

5.1 Credit Tiers

If the Monthly Uptime Percentage falls below the commitment in a calendar month, you are eligible for a credit against your monthly subscription fee for that month:

Monthly Uptime Percentage Service Credit
99.0% to below 99.9% 10% of the monthly subscription fee
Below 99.0% 25% of the monthly subscription fee

5.2 Claiming Credits

You must request a credit by emailing [email protected] within 30 days after the end of the affected month, identifying your account and the dates and times of the claimed Downtime. Requests received later are ineligible. We will confirm receipt, verify the claim against our monitoring records, and notify you of the outcome.

5.3 Worked Example (Illustrative Only)

Assume, purely for illustration, a monthly subscription fee of $500 and a 30-day month (43,200 minutes). Suppose the Service accrues 130 minutes of Downtime after exclusions. Monthly Uptime Percentage = (43,200 − 130) ÷ 43,200 = 99.70%, which falls in the 99.0%–99.9% tier. The Service Credit is 10% × $500 = $50, applied to a future invoice upon an approved claim submitted within the 30-day window. Had Downtime exceeded 432 minutes (uptime below 99.0%), the credit would instead be 25%.

5.4 Applying Credits

Approved credits are applied to future invoices only. Credits have no cash value, are not paid as refunds, cannot be transferred, and do not apply to pass-through rent amounts, per-unit fees for the affected month already invoiced, or one-time charges. Only one credit may be earned per calendar month, calculated on the monthly subscription fee actually paid for the affected month. If your subscription ends before a credit is used, the credit lapses (except as provided in the chronic failure clause in Section 10). We may deny requests made in bad faith or where our monitoring shows the uptime commitment was met.

6. Support Tiers

This section describes the support channels and first-response targets for each subscription plan.

6.1 Tier Table

Plan Support Channel First Response Target
Starter Email support 2 Business Days
Professional Priority email and chat 1 Business Day
Enterprise 24/7 premium support Severity-based (Section 7)

6.2 Measurement of Response Targets

First response targets for Starter and Professional are measured within Business Hours; a ticket submitted outside Business Hours is treated as received at the start of the next Business Day. Enterprise severity targets apply 24/7 for Sev-1 and as stated in Section 7 for lower severities. A “first response” is a substantive reply from a support engineer acknowledging the issue and beginning triage — not an automated receipt.

7. Severity Definitions (Enterprise)

This section defines the four severity levels for Enterprise support, with concrete examples of each, and the response target for each level.

7.1 Severity Table

Severity Definition First Response Target
Sev-1 Service down or rent payments failing platform-wide for your account 1 hour (24/7)
Sev-2 Major feature degraded; no reasonable workaround 4 hours
Sev-3 Minor issue; workaround available 1 Business Day
Sev-4 General question or feature request 2 Business Days

7.2 Examples by Level

  • Sev-1: the web application and API are unreachable for all of your users; every tenant payment attempt on your account is failing; a security incident is actively exposing your data.
  • Sev-2: payout reporting is unavailable so you cannot reconcile rent received; auto-pay enrollment is failing for all new tenants; the API is rejecting a class of requests essential to your integration, with no workaround.
  • Sev-3: a report exports with a formatting defect but the data is available on screen; one notification template is not sending while dashboard status remains visible; a non-critical page loads slowly.
  • Sev-4: how-to questions, requests for new features, documentation clarifications, and sandbox or configuration guidance.

7.3 Classification and Reclassification

Tentunit assigns severity in good faith based on the definitions above and may reclassify a ticket as more information becomes available; we will tell you when we reclassify and why. First response targets are response commitments, not resolution guarantees; we will work continuously on Sev-1 issues until resolved or downgraded.

8. Escalation Path

This section explains how to escalate if an issue is not progressing as expected.

If you believe a ticket is misclassified, stalled, or not receiving appropriate attention, you may escalate at any time by replying on the ticket and requesting escalation, or by emailing [email protected] with the ticket number and the word “Escalation” in the subject line. Escalated tickets are reviewed by a support lead, who will confirm or adjust the severity, provide a current status and next steps, and, for Enterprise customers, engage the on-call engineering owner where warranted. Enterprise customers with a designated account contact in their order form may additionally escalate through that contact. Escalation never resets a response target; the original clock continues to run.

9. Incident Communication

This section describes how we keep you informed during incidents.

For Incidents causing Downtime or material platform-wide degradation, we will publish status information and provide updates at a cadence appropriate to the severity — more frequently while a Sev-1 incident is active, and at reasonable intervals thereafter until resolution — via our status channel, email, or in-product notice. Each update will describe, to the extent then known, the current impact, the state of the investigation or fix, and the expected next update. Following resolution of a significant Incident, Enterprise customers may request a written incident summary describing the cause, impact window, and remediation steps. Incident communications are provided in good faith based on information available at the time and do not amend this SLA.

10. Chronic Failure; Termination Right

This section gives you an exit if availability is persistently poor, beyond the month-by-month credits.

If the Monthly Uptime Percentage is below 99.0% for three (3) consecutive calendar months, you may terminate your Tentunit Business subscription for cause by written notice to [email protected] (with a copy to [email protected]) delivered within 30 days after the end of the third such month. Upon such termination, Tentunit will refund the pro-rata portion of any prepaid, unused subscription fees for the terminated subscription, calculated from the effective date of termination through the end of the prepaid period. This chronic failure remedy is in addition to Service Credits already earned for the affected months, but you may not recover both a refund and credits for the same post-termination period. This Section does not apply to months in which the shortfall is attributable to the exclusions in Section 4.

11. Maintenance Windows

This section describes when and how we perform maintenance, and how emergency maintenance is treated.

We schedule maintenance to minimize disruption, typically outside US business hours. Scheduled Maintenance is limited to 8 hours per calendar month in aggregate and announced at least 48 hours in advance by email or in-product notice, identifying the window and expected impact. Emergency maintenance required to address security vulnerabilities or imminent instability may be performed with shorter or no notice; we will notify affected customers as soon as practicable, and emergency maintenance beyond the scheduled allowance counts as Downtime.

12. Enterprise and Custom SLAs

This section confirms that a negotiated SLA in your order form takes precedence.

Enterprise customers may negotiate custom availability commitments, support terms, and credit schedules in their order form. If your signed order form contains a custom SLA, that SLA overrides this document to the extent of any conflict; this SLA continues to apply to matters the order form does not address.

13. Customer Responsibilities

This section lists what we need from you for the SLA to work as intended.

To be eligible for the remedies in this SLA, you must: (a) report suspected Downtime or Incidents promptly through the support channel for your plan, with your account identifier and the observed start time; (b) provide reasonable diagnostic information on request — for example, timestamps, affected users, error messages, request IDs, browser or client details, and network traces where relevant; (c) cooperate reasonably with troubleshooting, including testing fixes and confirming restoration; (d) keep your own systems, integrations, and configurations within documented requirements and usage limits; and (e) maintain current administrative contact details so that maintenance and incident notices reach you. Failure to report promptly or to provide requested diagnostics may limit our ability to verify a claim, and periods of unavailability we cannot reasonably verify are not Downtime.

14. Scope; Rent Payouts Not Covered

This section makes clear that payment processing and payout timing sit outside this SLA.

This SLA covers availability of the software Service and support responsiveness only. Rent payout timing is not covered by this SLA. Payout timing, holds, and settlement are governed by the Business Payments & Rent Collection Terms (typically 1–2 business days for US payouts and 5 business days for EU payouts) and by the applicable Stripe terms. No Service Credits accrue for payout timing, chargebacks, or other payment-processing matters.

15. Sole and Exclusive Remedy

This section confirms that credits — plus the chronic failure right in Section 10 — are the full extent of the remedy for missed availability.

Service Credits under Section 5, together with the chronic failure termination right in Section 10, are your sole and exclusive remedy for any failure by Tentunit to meet the uptime commitment in this SLA. Credits do not limit either party’s rights under the Terms of Service for matters other than availability, and all credits and refunds under this SLA remain subject to the limitation of liability in the Terms of Service.

16. Contact

This section lists where to send claims, tickets, and notices.

Credit requests and support: [email protected] Legal notices: [email protected]

Tentunit, Inc. (Delaware) · This SLA is incorporated into the Tentunit Business Terms of Service.