Measurable service commitments. Defined before they apply.

The Support Policy applies to all covered requests. A signed SLA Schedule adds only the specific measurable commitments stated in that schedule.

Each binding SLA should identify:

• Customer and covered service.
• Effective date and service term.
• Support plan or subscription tier.
• Covered production environment, tenant, database, application, integration, or workload.
• Coverage hours, time zone, holidays, and after-hours conditions.
• Priority definitions and initial-response targets.
• Status-update targets, if any.
• Availability target and measurement method, if any.
• Escalation contacts and authorized Customer contacts.
• Exclusions, dependencies, service credits, caps, and claim process.

Kool&Tech may offer differently named plans such as Essential, Business, Enterprise, Managed Services, or Custom. Plan names do not create standard entitlements unless a signed document specifies them.

Priority is determined from verified impact and urgency. Kool&Tech may reclassify a request when facts change or the initial classification is unsupported.

Initial Response Time begins only when a valid request reaches an authorized support channel during the applicable coverage window and contains enough information to begin triage.

An initial response may acknowledge the request, confirm ownership, request required information, establish next steps, or begin investigation. It is not a promise of resolution.

Response, restoration, workaround, and final resolution are different measures. Unless a signed Service Schedule expressly says otherwise, Kool&Tech does not guarantee a resolution time.

• Response: Acknowledgment and start of handling.
• Workaround: Temporary method that reduces impact.
• Restoration: Return of material service functionality.
• Resolution: Completed correction, accepted workaround, vendor disposition, or documented closure.

Resolution may depend on access, Customer decisions, data quality, testing, vendor action, product release, third-party restoration, replacement hardware, licensing, or a separately authorized change.

A signed Service Schedule may define an update cadence for active P1 or P2 incidents. Update timing may pause while Kool&Tech waits for Customer access, information, testing, authorization, or vendor action.

Status updates may include known impact, work performed, current blocker, workaround, vendor status, next action, or expected next update. An update is not a guarantee that material progress will occur within each interval.

Business-hour targets count only time inside the selected coverage window. Time outside that window carries to the next covered period unless after-hours coverage applies.

The Service Schedule must identify the applicable time zone, business days, observed holidays, and any maintenance or blackout periods. If those details are omitted, no public statement on this page supplies them automatically.

The applicable measurement clock may pause when progress requires:

• Customer access, information, evidence, authorization, acceptance, or testing.
• Availability of an authorized Customer contact.
• A maintenance window, backup, restore approval, or business decision.
• Vendor response, third-party correction, carrier action, or platform release.
• Payment, licensing, subscription renewal, or commercial authorization.
• Separation of multiple issues submitted as one request.

The clock may resume when the required dependency is satisfied during covered hours.

Kool&Tech may reclassify priority as verified impact, urgency, workaround availability, affected scope, or Customer availability changes.

A closed ticket may be reopened when the same issue recurs within a reasonable review period and remains materially related. A new cause, environment, requirement, or symptom may create a new request.

Multiple reports with the same root cause may be grouped into a parent incident for consistent communication and measurement.

An availability commitment applies only to a Kool&Tech service expressly identified in a signed Service Schedule. Consulting, administrative support, Customer-controlled systems, and third-party platforms do not receive an availability commitment merely because Kool&Tech supports them.

A binding schedule must define the measured service boundary, formula, monitoring source, measurement period, exclusions, rounding, minimum incident duration, and treatment of partial degradation.

Where selected, availability may be calculated using the formula stated in the Service Schedule. A common structure is:

The signed schedule must define what counts as “eligible,” “unavailable,” “degraded,” and “excluded.” Monitoring may come from Kool&Tech telemetry, the hosting provider, or another agreed source.

Planned maintenance, updates, migrations, security changes, vendor maintenance, and approved deployment windows may be excluded from SLA measurement when the signed schedule says so.

Emergency maintenance may be performed to address security, legal, stability, data-integrity, or material operational risk. Advance notice may be limited when delay would increase risk.

Customers must maintain current escalation contacts and review maintenance notices delivered through the agreed channel.

Unless expressly included, service-level calculations exclude delay or unavailability caused by:

• Customer systems, devices, networks, internet, power, data, credentials, configuration, or personnel.
• Unauthorized changes, misuse, unsupported software, unlicensed products, or policy violations.
• Odoo, Microsoft, Twilio, payment providers, carriers, hosting vendors, APIs, modules, or other third parties outside Kool&Tech's control.
• Scheduled or emergency maintenance covered by the applicable exclusion.
• Force majeure, widespread internet routing failures, government action, labor disruption, disaster, or events beyond reasonable control.
• Beta, preview, trial, demonstration, sandbox, staging, test, or free services.
• Suspension for security, nonpayment, legal compliance, or Customer breach.
• Customer delay or failure to satisfy required responsibilities.

Odoo Online, Odoo.sh, and Odoo-managed services are operated under Odoo's terms, product lifecycle, hosting model, and support capabilities. Kool&Tech may configure, administer, investigate, and escalate eligible issues but does not independently control Odoo platform availability or vendor remediation.

Self-hosted Odoo availability depends on the selected infrastructure, maintenance, backups, monitoring, licensing, custom code, modules, and managed-services scope. A separate hosting or managed-services schedule is required for infrastructure commitments.

Microsoft 365, Azure, Entra, Exchange Online, SharePoint, Teams, and Power Platform are operated by Microsoft under the Customer's licensing and Microsoft terms.

Kool&Tech may provide administration, triage, configuration, and vendor escalation within scope, but does not independently control Microsoft's cloud availability, incident handling, release schedule, or remedies.

When a covered workflow depends on a third-party provider, Kool&Tech's target applies only to Kool&Tech-controlled handling unless the signed Service Schedule expressly incorporates a vendor-backed commitment.

A vendor outage, API change, rate limit, authentication failure, carrier disruption, payment-provider issue, or required vendor release may extend restoration and resolution time.

Escalation does not guarantee that a specific person, vendor, or engineering resource will be continuously assigned.

SLA performance depends on Customer cooperation. The Customer must maintain authorized contacts, accurate severity information, required licenses, secure access, current backups, prompt decisions, test resources, and availability appropriate to the incident priority.

The Customer must avoid conflicting changes, preserve evidence, follow agreed communication channels, and promptly test proposed workarounds or restorations. Delays attributable to unmet Customer responsibilities are excluded or paused as stated in the schedule.

After-hours, weekend, holiday, standby, and 24x7 services apply only when expressly purchased and stated in the Service Schedule.

Emergency requests submitted without contracted after-hours coverage may be handled when resources are available and may be subject to premium rates, minimum charges, and separate authorization. Submission does not guarantee acceptance or immediate action.

Service credits exist only when expressly stated in a signed Service Schedule. If included, that schedule must define eligibility, calculation, cap, claim period, required evidence, exclusions, account standing, and whether credits are the exclusive contractual remedy for the affected service-level failure.

Credits are not cash refunds unless the signed agreement expressly says so, do not apply to third-party charges, and may not exceed the agreed cap.

If service credits are included, the Customer must submit a written claim through the identified channel within the claim period stated in the Service Schedule.

The claim should identify the service, incident or ticket, dates and times, alleged missed target, business impact, and supporting records. Kool&Tech may compare the claim with ticket history, monitoring, exclusions, pauses, maintenance, and Customer dependencies before determining eligibility.

Where included, service reports may summarize request volume, priority, initial response, closure status, recurring themes, vendor dependencies, availability, maintenance, and eligible SLA performance.

Reporting frequency, data source, recipients, format, retention, and review meetings must be specified in the applicable plan. Reports are operational aids and do not amend the agreement.

Future KoolArchitect service levels may separately address platform availability, authentication, workspace access, core workflow functions, data export, supported integrations, billing access, and AI-enabled dependencies.

AI output quality, correctness, uniqueness, completeness, or suitability is not an uptime metric. AI and connected-provider availability may be measured separately or excluded according to the subscription schedule.

Kool&Tech may suspend, isolate, rate-limit, disable, or modify a service to address a security threat, abuse, legal requirement, data-integrity risk, or provider restriction.

Protective action taken in good faith may be excluded from availability or response commitments as stated in the signed schedule. Security-event communications are governed by the applicable DPA, Security & Trust Center, incident terms, and law.

Service levels may be suspended for overdue payment, exhausted entitlement, missing authorization, expired subscription, unsupported environment, material breach, prohibited use, security risk, or Customer failure to maintain required dependencies.

Termination, renewal, transition assistance, and any survival of reporting or credit rights are governed by the applicable agreement.

For a covered service, the following order generally applies: mandatory law; signed service-specific SLA Schedule; signed order, SOW, subscription, or managed-services agreement; Data Processing Addendum for covered data-processing matters; Support Policy; Terms & Conditions; and this public framework.

A more specific signed term controls over a conflicting general public term for the same subject.

This template is incomplete until expressly accepted in a signed agreement.

Kool&Tech may update this public framework as services, plans, platforms, vendors, and operating practices evolve.

An update does not alter a signed SLA Schedule unless the governing agreement permits the change or the parties accept an amendment.