DRAFT — for solicitor review; not yet in force.
Property Inspector — Service Level Agreement
1. Scope
1.1 This Service Level Agreement (SLA) describes the availability, support and maintenance commitments that MBGW Limited (MBGW) makes for the Property Inspector service (the Service). It forms part of the Terms of Service.
1.2 The SLA applies to every active workspace under a paid subscription. It does not apply to workspaces that are paused by the subscriber, suspended for non-payment, in provisioning, or in the process of being torn down, nor to free, trial or demonstration workspaces. [TBC: whether any free or trial tier will exist.]
1.3 Where this SLA states a target as "[TBC]", MBGW has not yet committed to a figure; the structure below shows what will be committed. No figure should be relied on until this document is in force.
2. Definitions
- Available — the workspace office can be signed into and the API responds to authenticated requests from the mobile app.
- Downtime — any period during which the workspace is not Available, measured from when MBGW's monitoring detects it or the subscriber reports it (whichever is earlier) until service is restored, excluding the Exclusions in section 6.
- Monthly Availability — the percentage of minutes in a calendar month during which the workspace was Available: (total minutes − Downtime) ÷ total minutes × 100.
- Business Hours — [TBC: e.g. 09:00–17:30 UK time, Monday to Friday excluding English bank holidays].
- Severity — the classification of an incident under section 4.
3. Availability
3.1 Target. MBGW aims to provide Monthly Availability of at least [TBC: e.g. 99.5%] for each workspace.
3.2 Measurement. Availability is measured from MBGW's records: the health checks of the workspace and the API that are shown on the workspace's health page in the subscriber portal, MBGW's infrastructure monitoring, and MBGW's incident records, together with any Downtime the subscriber reports. MBGW's records are the basis of measurement unless shown to be wrong. [TBC: continuous, automated per-workspace availability monitoring is not yet in place — the health page checks a workspace when it is opened; the measurement basis must be built before an availability target is committed.]
3.3 Service credits. [TBC: whether service credits will be offered. If so, for example: Monthly Availability below the target but at or above [TBC]% — credit of [TBC]% of that month's fee for the affected workspace; below [TBC]% — credit of [TBC]%. Credits are the sole remedy for failure to meet the availability target, must be claimed within 30 days of the end of the month, and are applied against future fees, not refunded in cash.]
4. Support
4.1 How to contact us. Support requests should be sent to [TBC: support email address] or raised through [TBC: portal support form, if one is provided]. Include your workspace name, the User affected, what you were doing, the time it happened and any error message shown on screen. [TBC: error pages do not yet show a support reference; add "and the support reference shown on the error page" once that is built.]
4.2 Support hours. Support is provided during Business Hours. Requests received outside Business Hours are treated as received at the start of the next Business Hours period, except that Severity 1 incidents are [TBC: monitored / responded to] outside Business Hours.
4.3 Severity levels and response targets.
| Severity | Definition | Response target | Update frequency |
|---|---|---|---|
| 1 — Critical | The workspace or the mobile app is unusable for all Users, or there is a suspected security breach or data loss. | [TBC: e.g. 1 Business Hour] | [TBC: e.g. every 2 hours] |
| 2 — Major | A core function (inspections, forms, photographs, work orders, reports, sign-in) is unavailable or seriously degraded for many Users, with no reasonable workaround. | [TBC: e.g. 4 Business Hours] | [TBC: e.g. daily] |
| 3 — Minor | A function is impaired for some Users, or a workaround exists. | [TBC: e.g. 1 Business Day] | [TBC: e.g. on change of status] |
| 4 — Request | Questions, how-to, feature requests, cosmetic issues. | [TBC: e.g. 2 Business Days] | Not applicable |
4.4 "Response" means a substantive acknowledgement from a person who has started work on the issue, not an automated receipt. Resolution times depend on the nature of the issue and are not guaranteed, but MBGW will work continuously on Severity 1 incidents during Business Hours until resolved [TBC: and outside Business Hours].
4.5 MBGW assigns the Severity in good faith after initial assessment and may reclassify an issue as more is learned, telling the subscriber why.
4.6 Support covers the Service as provided by MBGW. It does not cover the subscriber's own devices, networks, Google or Microsoft accounts, or third-party services, although MBGW will help identify where a problem lies.
5. Maintenance
5.1 Scheduled maintenance. MBGW may take the Service or a workspace offline for planned maintenance. MBGW will give at least [TBC: e.g. 48 hours'] notice by email and, where possible, carry out maintenance in the window [TBC: e.g. 22:00–06:00 UK time]. Scheduled maintenance within that window and notice period is not Downtime, up to a maximum of [TBC: e.g. 4 hours] per month.
5.2 Routine deployments. MBGW deploys updates to the Service regularly. Most deployments cause no interruption or only a brief one (seconds). These are not scheduled maintenance and are not Downtime unless they exceed [TBC: e.g. 5 minutes].
5.3 Emergency maintenance. Where urgent maintenance is needed to address a security issue or prevent a wider outage, MBGW may proceed with shorter or no notice, will tell subscribers as soon as practicable, and will keep the interruption as short as possible. Emergency maintenance is counted as Downtime unless it was caused by an Exclusion.
6. Exclusions
6.1 The following are not Downtime and do not count against the availability target:
- scheduled maintenance under section 5.1 and routine deployments under 5.2;
- failures of the subscriber's own equipment, internet connection, devices or mobile network;
- failures or changes in third-party services the subscriber has connected (Google, Microsoft) or that lie outside MBGW's control (payment provider, app stores, identity providers, DNS beyond MBGW's estate, public internet);
- a workspace that is paused by the subscriber, suspended under the Terms of Service or the Acceptable Use Policy, in provisioning, closing after its effective date, or being torn down;
- use of the Service in breach of the Terms of Service or the Acceptable Use Policy, including exceeding rate limits;
- events beyond MBGW's reasonable control, including power or connectivity failures affecting MBGW's hosting site that are not caused by MBGW's negligence [TBC: whether the hosting site has UPS/generator cover — do not promise it until it exists];
- degraded performance that does not amount to the workspace being unavailable.
7. Backups and recovery
7.1 Backups are taken and retained as described in the Data Retention and Backup Policy. Following an incident causing data loss, MBGW's recovery objectives are: recovery point [TBC: e.g. the most recent backup, no more than 24 hours old where a daily schedule is set] and recovery time [TBC: e.g. 8 Business Hours]. These are objectives, not guarantees.
8. Status and incident communication
8.1 Each workspace's current health and last backup time are shown in the subscriber portal. During a Severity 1 or 2 incident affecting many subscribers MBGW will send email updates at the frequency in section 4.3 and [TBC: publish updates on a status page, if one is provided].
8.2 After a Severity 1 incident MBGW will, on request, provide a written summary of the cause, impact and steps taken to prevent recurrence within [TBC: e.g. 10 Business Days].
9. Review
9.1 MBGW may update this SLA as described in the Terms of Service. Changes that reduce a commitment are treated as a major version and take effect only at the subscriber's next renewal after 30 days' notice.