READYSPACE SERVICE LEVEL AGREEMENT

Version: 2.0
Effective date: 20 OCT 2025

PART I - GENERAL SERVICE LEVELS

1. Application and service documents

This Service Level Agreement (SLA) sets out the service commitments of ReadySpace (SG) Pte Ltd (ReadySpace) for eligible subscriptions. Only provisions applicable to the service purchased apply. This SLA does not give every subscription the features or support entitlements of every other product.

The accepted quotation or order, applicable service specification and identified support schedule together define the customer's subscribed service. A customer-specific agreement overrides this SLA only to the extent it expressly changes the relevant service-level terms, unless that agreement provides a different order of precedence. The main service agreement continues to govern matters not addressed here.

Schedule A applies specifically to Managed SMTP Relay subscriptions. It does not reduce the availability commitments of separately purchased infrastructure services. Customer-specific allowances, prices, locations and optional features belong in the order, not in this general SLA.

Existing subscriptions adopt this revision only through the notice, consent or amendment procedure applicable to their agreements. Publishing a new version does not retrospectively change an earlier incident or claim.

2. Data centre infrastructure

Covered facility power, cooling and supporting infrastructure carry a 99.95% monthly availability commitment, excluding eligible maintenance and customer-side power. Each 30 minutes of qualifying interruption earns 5% of the affected server's monthly fee, capped at 100%.

3. Network

ReadySpace's covered routers, switches and cabling carry a 99.95% monthly commitment, excluding eligible maintenance and customer-server software. Each 30 minutes of qualifying interruption earns 5% of the affected server's monthly fee, capped at 100%.

4. Hardware

Covered ReadySpace-owned hardware is replaced without charge within the subscribed plan's deadline. Each overdue hour earns 5% of the affected server's monthly fee, capped at 100%. RAID rebuilding, software reinstallation and customer-owned hardware are excluded from this replacement-time commitment.

On a pooled managed service, ReadySpace may restore service by using alternative infrastructure. A specific underlying server-replacement entitlement applies only where included in the order.

5. Software

ReadySpace supplies legitimate, appropriately licensed software and applicable vendor updates; installation is not necessarily automatic.

Managed installation, compatibility testing, maintenance and customer change approvals depend on the subscribed scope. Software maintenance does not promise that software is defect-free. Nor is a managed-service incident automatically excluded merely because the fault involves a third-party software supplier.

6. Technical support

Baseline support accompanies subscriptions. Technical scope, coverage hours, response targets, channels and hardware entitlements follow the identified purchased support plan. Schedule A defines the standard Managed SMTP Support terms.

For this SLA, business days are Monday to Friday excluding Singapore public holidays, unless an applicable schedule expressly states otherwise.

An initial technical response means a support engineer has begun assessment and provided a meaningful response or engaged the customer. An automated acknowledgement alone does not satisfy that target. Initial response, subsequent updates and restoration are separate measures; a response target is not a restoration deadline.

The clock starts when an identifiable incident report reaches an included support channel. Missing non-essential information does not delay initial triage. ReadySpace may request information needed for further diagnosis. Customer-wait periods do not automatically suspend the availability calculation.

The support portal is the primary incident record. Where email or chat is included, ReadySpace will record the report without requiring duplicate submission before the response clock starts. An alternative included channel must be identified for reporting when the portal is unavailable.

Phone support, an exclusive engineering team, an assigned technical manager and onsite attendance apply only where expressly included. General sales contact details do not establish a contracted incident-reporting channel.

7. Availability measurement, maintenance and exclusions

Availability is measured for the affected subscribed service, not simply by whether other customers or servers remain operational. Monthly measurement uses calendar months in Singapore time, unless the service schedule specifies otherwise.

Monthly availability (%) = 100 x (eligible service minutes - qualifying unavailable minutes) / eligible service minutes.

Eligible minutes are the active subscription minutes in the month after permitted exclusions. The same excluded minutes are removed from both the observation period and any claimed outage. Overlapping incidents are not counted twice. Where no eligible minutes exist, no percentage is calculated for that period.

A qualifying interruption starts at the earliest substantiated time shown by ReadySpace monitoring or credible customer evidence and ends when the affected function is restored. Ticket timestamps, SMTP transactions, monitoring and other relevant records may be used. Neither party's unsupported assertion is conclusive. ReadySpace will explain disputed calculations using available evidence.

ReadySpace will give at least 48 hours' notice of planned service-impacting maintenance, identifying the expected effect and window. Maintenance qualifies for exclusion only within the notified window and any applicable limit. Overruns are assessed as ordinary interruptions. Schedule A further caps excluded SMTP maintenance.

Emergency maintenance may proceed without advance notice where necessary to address an immediate risk. ReadySpace will notify affected customers as soon as practicable. Calling work emergency maintenance does not automatically exclude resulting downtime.

Exclusions apply only to the extent an interruption is attributable to an identified excluded cause: customer equipment or connectivity outside the managed boundary; customer-controlled credentials, DNS or configuration faults; usage outside the agreed supported scope; proportionate suspension permitted by the agreement for prohibited or unsafe activity; external services not included in ReadySpace's managed responsibilities; eligible maintenance; or force-majeure circumstances to the extent provided in the main agreement.

A supplier dependency, shared infrastructure, a security incident or a customer action is not by itself sufficient grounds for an exclusion. ReadySpace-controlled capacity, configuration, hardware and software failures remain assessable under the applicable service commitment. ReadySpace must explain the relevant cause and excluded duration.

8. Service-credit administration

Credits are calculated against the net recurring subscription charge for the affected service, excluding tax, setup, professional services, separately billed overages and unrelated services. For longer billing periods, the recurring charge is converted to a monthly equivalent. Partial service months are assessed against the recurring charge attributable to the active period.

For data centre and network credits, qualifying interruption periods are aggregated for the month. Each completed 30-minute interval earns the stated credit. For hardware replacement, each completed overdue hour earns the stated credit. Schedule A provides the SMTP calculation.

For the same service and overlapping interruption, availability and hardware credits are not added together; the higher applicable credit applies. Independently billed affected services may be assessed separately. Credits for an affected service cannot exceed 100% of its applicable monthly recurring charge.

Claims must be submitted through an included support channel within 30 calendar days after the affected month ends. Include the service identifier, dates, approximate times, incident references and reasonably available evidence. Customers need not provide credentials, complete message contents or evidence already held by ReadySpace.

ReadySpace will provide a claim decision, calculation or reasoned request for essential additional information within 15 business days. Approved credits are applied to the next invoice where practicable. Any balance when service ends is handled under the main agreement and applicable law.

A missed support-response target is an escalation matter and earns a support credit only if the support schedule expressly provides one. It does not replace an otherwise valid availability claim. These provisions do not remove rights that cannot lawfully be excluded or remedies expressly preserved by the customer's agreement.

9. Versioning and changes

Orders must identify the applicable SLA and support-schedule version. Updates take effect through the applicable agreement's change procedure, with customer notice where required. Previously incurred credits are not recalculated under later terms. A separately agreed service level is not silently replaced by a website edit.

SCHEDULE A - MANAGED SMTP RELAY SERVICE

A1. Service model and scope

ReadySpace operates the SMTP relay as a managed service. Unless the order expressly provides otherwise, customer accounts use shared delivery infrastructure and processing capacity. ReadySpace remains the main administrator; customer permissions are limited to authorised domains and enabled functions.

The order and service specification identify the approved workload, domains, authentication methods, source-IP scope, endpoints, included usage, message-size limit, hosting locations, retention, support and optional features. Standard service uses ReadySpace-managed connection hostnames and certificates.

Dedicated delivery IPs, where included, do not provide dedicated servers, reserved throughput or an exclusive engineering team. Custom connection hostnames, isolated resources, guaranteed sustained/burst capacity, custom APIs, bespoke reporting, archiving and extensive application remediation require express inclusion. Additional charges require customer approval before implementation.

Availability measurement begins on the agreed production activation date. Pilots, migration activities and any test-service commitments are governed by their agreed scope; they do not silently replace an already-active production SLA.

A2. SMTP availability commitment and boundary

ReadySpace commits to 99.9% monthly availability of the subscribed managed SMTP relay, unless a different commitment is expressly agreed. Measurement follows Part I, with the additional conditions below.

Availability requires functioning access for authorised clients using the supported configuration: connection, applicable TLS/authentication, acceptance of permitted messages and ReadySpace-controlled onward processing. A TCP port answering is not sufficient evidence of a functioning service.

A ReadySpace-caused fault affecting the customer's agreed sending path is assessed even when unrelated customers remain unaffected. A platform failure that accepts messages but prevents onward processing is also assessed; successful acceptance alone does not end such an incident.

Normal queueing for a recipient-system deferral is not, by itself, an availability failure. No fixed recipient-delivery time or inbox placement is guaranteed. Exclusions are assessed by cause, not simply by the presence of an external mail system.

Loss of one redundant endpoint is not a service outage where the customer's documented, supported configuration can use the tested alternative. A hypothetical fallback that the customer was not instructed or enabled to use does not establish availability. Failover and recovery behaviour must be documented during onboarding; instantaneous switching is not promised.

Portal, reporting, log-search and archiving availability are distinct from SMTP processing. Incidents affecting them receive support under this schedule, but no separate numerical availability guarantee applies unless expressly included. Their failure counts toward SMTP downtime where it also prevents the covered SMTP function.

Excluded service-impacting planned maintenance is limited to 120 minutes per calendar month, with the notice and window requirements in Part I. Excess or otherwise non-qualifying interruption is included in the SMTP availability calculation. Maintenance with no customer service interruption consumes none of this allowance.

A3. Shared capacity and operational controls

Monthly recipient-send allowances are usage entitlements, not guaranteed per-minute rates. The standard shared service provides neither unlimited bursts nor reserved throughput. Connection, recipient, message-size and abuse-prevention controls may apply.

ReadySpace may adjust routing and operational controls for stability, security and delivery quality. These changes remain subject to the agreed supported workload, availability and dedicated-IP obligations. They must not be used merely to reclassify ReadySpace capacity or configuration failures as customer misuse.

ReadySpace will provide practical connection, timeout and retry guidance and assess representative traffic during onboarding. Planned material changes affecting a customer's application configuration will be communicated in advance where practicable. Immediate protective changes will be explained promptly when safe to do so.

Legitimate traffic temporarily exceeding operational limits may receive a retryable response. Permanent rejection or protective quarantine follows the applicable security policy. ReadySpace will provide relevant diagnostic information through the enabled logs or support channels. The service does not guarantee that every message will pass filtering.

A requirement outside the supported shared-service profile will be discussed and separately scoped. It does not authorise unapproved additional charges or silently remove an existing agreed entitlement.

A4. Dedicated delivery IPs and customer configuration

Where exclusive delivery IPs are included, ReadySpace will maintain their exclusive allocation across configured delivery paths, including supported failover. Other customers must not use those addresses, and the customer's traffic must not fall back to a general shared delivery pool without express agreement. Enabled IPv4 and IPv6 paths must follow this allocation.

Addresses remain ReadySpace-managed resources unless ownership or portability is expressly agreed. Necessary changes must preserve exclusivity and include coordination of relevant DNS and authentication changes. Exclusive IPs do not guarantee recipient acceptance or reputation outcomes.

Customer administrators may manage enabled source-IP authorisations and SMTP credentials within their permitted domains. Source-IP authorisation is distinct from outbound delivery-IP allocation. IP-based and username/password authentication are separate methods unless a supported combined restriction is expressly agreed.

ReadySpace retains control of infrastructure, protected service limits and platform security. Supported domain association, permitted sending identities and SPF/DKIM/DMARC arrangements must be validated during onboarding, including where several domains share a source IP. A customer account alone does not establish that every authentication/signing combination is supported.

A5. Message acceptance, queueing and customer responsibilities

Service acceptance occurs when ReadySpace returns the final successful SMTP response for a complete message transaction and its accepted recipients. Establishing a connection or accepting an individual recipient command is not sufficient.

Before acceptance, the sending application remains responsible for retaining and retrying temporarily rejected messages according to the connection guidance. After acceptance, ReadySpace operates the applicable delivery queue, retry and failure-handling process. Accepted messages held under the configured filtering policy are handled through the applicable quarantine, notification and review process rather than guaranteed delivery.

The service specification must describe retry/expiry settings, supported failure notifications and recovery handling. A multi-node cluster does not by itself promise zero message loss or replicated message queues. Nevertheless, a recovery limitation does not remove ReadySpace's responsibility to investigate, communicate and handle an accepted-message incident under the agreement. A delivered status does not confirm reading or inbox placement.

Customers must use approved domains and legitimate recipient lists, protect credentials, restrict source-IP authorisations to addresses they control, maintain supported applications and implement agreed DNS changes. They must provide current incident contacts and promptly address compromised senders or prohibited content.

ReadySpace may proportionately restrict affected senders to protect the service under the applicable acceptable-use terms. It will notify the customer where safe, explain the reason and required remediation, and review restoration promptly. External filtering or reputation decisions do not excuse a ReadySpace configuration fault.

A6. Usage, message size, logs and reporting

One recipient send is one complete message accepted for onward handling for one SMTP envelope recipient. A message accepted for ten recipients counts as ten sends. ReadySpace-internal transport retries are not counted again. Attempts rejected before completed acceptance are not billable sends.

Allowances, billing periods and overage prices follow the order. Where overage billing is included, exceeding the monthly allowance alone does not automatically suspend service unless an agreed spending limit or other contractual restriction applies. Operational and abuse controls remain applicable.

The maximum message size is the complete encoded email, including headers, body and attachments, not a separate limit per attachment. The default Managed SMTP service limit is 50 MB unless the service specification states otherwise.

The standard Managed SMTP service includes 30 days of searchable delivery metadata unless otherwise agreed. This is not message archiving, a queue-retention promise or a backup of complete message contents. Longer retention and archiving require separate scope.

Authorised users receive the enabled operational logs, statistics and native reports on a self-service basis. A custom consolidated dashboard, scheduled billing statement or manually prepared monthly report is not included unless specified.

ReadySpace will maintain reconciled usage and incident evidence sufficient to support billing and the claim process independently of the customer portal's rolling log window. Access and handling remain governed by the applicable privacy and data-processing terms.

A7. Managed SMTP Support

This support schedule applies only to Managed SMTP Relay services purchased with it. It does not replace support levels for unrelated ReadySpace products.

The service includes a shared 24x7 operations and support team through the designated support email, portal and online chat, with escalation contacts supplied during onboarding. Initial-response clocks for P1 and P2 incidents run 24x7. Initial-response clocks for P3 incidents and P4 service requests run only during the business hours defined below. Phone support and exclusively assigned personnel are not included unless ordered.

P1 - Critical: The covered SMTP service is unusable, or a major ReadySpace-controlled processing failure causes widespread disruption, with no usable workaround. Initial engineer engagement: within 2 hours, 24x7.

P2 - High: Significant degradation or substantial disruption with partial service or a usable workaround. Initial engineer engagement: within 4 hours, 24x7.

P3 - Normal: Limited-impact technical incidents affecting an application, sender, domain or management function. Initial engineer engagement: within 1 business day.

P4 - Service request: General enquiries, routine administrative requests and planned configuration assistance. Initial engineer engagement: within 2 business days. Completion of a requested change follows its agreed scope and schedule.

Business hours for the P3 and P4 response targets are Monday to Friday, 09:00-18:00 Singapore time, excluding Singapore public holidays. For these response targets, one business day means nine hours accumulated within that window; two business days mean eighteen such hours. P1 and P2 response clocks run continuously, including weekends and public holidays.

Severity follows actual impact, not the number of tickets. ReadySpace may reclassify with a documented explanation, but cannot restart an elapsed initial-response clock merely by changing the classification. A later escalation is assessed from when the greater impact became known or reasonably apparent.

The initial response will identify the next action and expected update time. Material developments and revised update expectations will be communicated. Resolution, permanent repair, vendor response and onsite arrival are not guaranteed by the initial-response targets. No separate financial credit for response-time breaches is created by this schedule.

A8. SMTP service credits

Where monthly SMTP availability is below 99.9%, the customer is eligible for a credit of 5% of the affected SMTP subscription's monthly recurring fee for each completed 30 minutes of qualifying unavailable time. A minimum 5% credit applies whenever the monthly commitment is missed, including a short first or final service month. The credit is capped at 100% of the applicable monthly fee.

Once the monthly availability threshold is missed, the calculation uses all qualifying unavailable time in that month, not only time exceeding the threshold. For example, 60 qualifying unavailable minutes earn a 10% credit where monthly availability is below 99.9%.

Part I governs claims, evidence, fee calculation and overlapping credits. The SMTP subscription fee is the credit base, not the cost of the shared cluster. Separately subscribed infrastructure is assessed under its own applicable terms.

A9. Activation and changes to the service

Before production activation, ReadySpace and the customer will record the agreed domains, authentication paths, source-IP scope, endpoint instructions, workload assumptions, retention, escalation details and any separately ordered features. The pilot should validate representative sending, domain authentication, customer access and supported failure/retry behaviour.

Implementation and migration follow the agreed professional-services scope. The customer remains responsible for its application and DNS changes unless expressly delegated. Unpriced custom development, additional infrastructure and optional features require an approved variation.

Operational adjustments do not authorise retroactive price changes, undisclosed reduction of an agreed entitlement or silent replacement of this SLA. Material contractual changes follow the main agreement and the agreed change procedure.