Service Level Agreement

Part 1. Purpose, scope and status

1.1 This Service Level Agreement sets out the service levels, support process and escalation route that apply to the Customer’s use of the Rentalize platform. It is a standalone document so that it can be maintained, versioned and improved without reopening the Master Subscription Agreement.

1.2 It is incorporated into the Master Subscription Agreement by clause 1.3 and clause 12.1 of that agreement. Capitalised terms not defined here carry the meaning given there.

1.3 A single service level applies to every commercial customer. The availability target, the service credit table, the severity classification and the response and resolution targets in this document are the same for all customers and are not varied on a deal by deal basis. Section 9 of the Order Form reproduces the headline figures for convenience and does not select between alternatives.

1.4 Commencement. This document takes effect on the Go-Live Date, being the date certified in the Go-Live Certificate issued and countersigned under clause 5.9 of the Master Subscription Agreement, or the date on which go-live is deemed to have occurred under clause 5.9(d). No availability target, service credit, response target or resolution target applies to any period before the Go-Live Date. Part 16 sets out what applies during implementation.

1.5 Availability is measured over Measurement Months only. The first Measurement Month is the first complete calendar month beginning after the Go-Live Date. A partial month between the Go-Live Date and the start of the first Measurement Month is reported for information but is not measured against the target and does not attract service credits.

1.6 Parts 3 to 6, being the availability commitment, service credits, severity classification and response targets, are contractually binding and may be varied only by written agreement signed by both parties. The remaining Parts describe operational process and may be updated by Rentalize in accordance with clause 1.4 of the Master Subscription Agreement.

1.7 Where this document conflicts with the Master Subscription Agreement, that agreement prevails.

Part 2. Service hours and definitions

Part 3. Availability commitment

3.1 From the Go-Live Date, Rentalize commits to platform availability of 99.5 per cent in each Measurement Month. Across a 30 day month that permits approximately 3 hours and 39 minutes of unplanned unavailability.

3.2 Availability is measured by automated monitoring operating independently of the platform, polling from outside the hosting environment. The monthly figure is generated from that monitoring rather than compiled manually.

3.3 Availability is calculated as total minutes in the month, less excluded minutes, less unavailable minutes, divided by total minutes less excluded minutes, expressed as a percentage.

3.4 Unavailable means the platform is not accessible to users, or a core function cannot be performed, for reasons within Rentalize’s control. Degraded performance that still permits the function to be completed is managed as a severity 2 incident rather than counted as unavailability.

3.5 Excluded minutes are:

• planned maintenance carried out in a Standard Maintenance Window, or in another window agreed in advance with the Customer, and notified in accordance with Part 9. Time spent in such a window is not unavailability and is not counted in the availability calculation at all
• emergency security patching, subject to the notification obligation at Part 9
• suspension under clause 12.8 of the Master Subscription Agreement where the cause is outside Rentalize’s control
• suspension under clause 7.7 of the Master Subscription Agreement for non-payment
• failure of a third party service outside Rentalize’s control where Rentalize has followed its own continuity procedures
• failure of the Customer’s own network, devices or internet connection
• force majeure as defined in the Master Subscription Agreement

3.6 The availability figure is published in the monthly service report within 5 Working Days of month end, whether or not the target was met.

Part 4. Service credits

4.1 Where availability in a Measurement Month falls below target, the following credits apply against the next Subscription invoice. Credits are applied automatically and do not need to be claimed. No credit arises in respect of any period before the first Measurement Month.

4.2 Service credits are an adjustment to the price of the platform, reflecting the reduced level of service received in the Measurement Month to which they relate. They are not a penalty and are not liquidated damages.

4.2A Service credits are the Customer’s sole financial remedy for failure to meet the availability target, in accordance with clause 12.3 of the Master Subscription Agreement. This does not affect the right to terminate under Part 12.

4.3 Credits accrue per Measurement Month and are not cumulative within a month. The maximum credit in any month is 20 per cent of the monthly Subscription value.

4.4 Where the Subscription is invoiced annually, the monthly Subscription value is one twelfth of the annual Subscription then in force.

4.5 Where no further Subscription invoice falls due, whether because the Agreement has ended or for any other reason, an accrued service credit is paid to the Customer within 30 days of the monthly service report in which it is reported, rather than lapsing.

Part 5. Severity classification

Severity reflects business impact, not technical complexity. The Customer proposes a severity when logging an issue. Rentalize confirms or adjusts it within one Working Hour and explains any change in the ticket. Where the parties disagree, the higher severity applies until the point of disagreement is resolved through the escalation route at Part 8.

Severity 4 enhancement suggestions are logged, acknowledged and reviewed together at the quarterly business review under clause 4.7 of the Master Subscription Agreement. Requests for work outside the subscription, including bespoke development, additional integrations, further migrations, bespoke reporting, extra training or on site attendance, are handled as Additional Services under clause 4.10 and are quoted rather than resolved as tickets. A defect in a delivered Change Order is raised as a normal ticket and assessed under the Change Order warranty at clause 4.14, not against the response targets in this document. Rentalize will tell the Customer which route a request has taken and why.

A suspected personal data breach is always treated as severity 1 regardless of apparent scale, and additionally triggers the notification obligations at clause 7 of the Data Processing Agreement. It should be logged in the Support Portal and sent to the severity 1 route at the same time.

Part 6. Response and resolution targets

6.1 Response means substantive acknowledgement by a named engineer with an initial assessment, not an automated receipt. The automated receipt is issued immediately on logging and carries the ticket reference.

6.2 Resolution means the issue is fixed, or a workaround acceptable to the Customer is in place and the residual work is reclassified at the appropriate severity. Where a workaround is applied, the underlying fix is tracked to closure and reported at the quarterly review.

6.3 Targets pause while a ticket is in Awaiting Customer status, being where Rentalize has requested information, access or a decision and is unable to progress without it. The ticket records the time and date the status changed and what was requested.

6.4 Rentalize will not close a ticket without confirmation from the Customer, save where a ticket has been in Awaiting Customer status for 10 Working Days following two written reminders, in which case it is closed with a note and may be reopened on request.

6.5 Remedy for a missed target. No service credit arises in respect of a failure to meet a response or resolution target. The Customer’s remedy is the escalation route at Part 8, which operates automatically on the triggers stated there and does not require the Customer to ask, together with the service improvement plan at Part 11 where a target is missed in two consecutive months. This is the sole remedy for such a failure, in accordance with clause 12.3A of the Master Subscription Agreement. Sustained failure to meet response or resolution targets remains capable of amounting to a material breach of that agreement.

Part 7. Logging issues: the Rentalize Support Portal

The Support Portal is the single channel of record for all issues, questions and requests. It is accessible from within the platform through the support icon, and by direct URL for use when the platform itself is unavailable. Every Customer user has access.

Why the Support Portal is the required channel

• Every ticket receives a reference and a timestamp, which is what the response and resolution clocks measure against. An issue raised by email or in conversation has no clock running against it.
• Tickets are visible to the whole Rentalize support team, so progress does not depend on one person being at their desk.
• The Customer retains a complete, exportable history of every issue raised, which supports the monthly report and the quarterly review.
• Duplicate reports of the same underlying issue are linked rather than worked twice.

How to raise an issue

Information to include

The quality of a ticket is the single largest factor in how quickly it is resolved. Tickets that include the following are typically resolved without a further exchange.

Ticket lifecycle

Alternative channels

Part 8. Escalation

Either party may escalate at any time. The Customer does not need to wait for a target to be missed, and escalating does not require a justification. Escalation is requested through the ticket using the escalate action, or by contacting the next level directly.

Automatic escalation triggers

Rentalize escalates without being asked when any of the following occurs. The Customer is notified in the ticket each time a matter is escalated.

Customer escalation route

8.1 Escalation does not restart or reset any clock. The original target continues to be measured from the time the ticket was logged.

8.2 Where a matter reaches L4 and remains unresolved, Rentalize will provide a written statement of the position, the plan to resolve it and the expected timescale, within 2 Working Days.

8.3 Nothing in this Part limits the Customer’s rights under the Master Subscription Agreement, including the termination right at clause 12.6.

Major incident process

A major incident is declared where a severity 1 affects all users, where data integrity is in question, or where a security or data protection incident is suspected. On declaration:

• An incident manager is appointed and named to the Customer within 30 minutes
• A dedicated communication channel is opened with the Customer’s named contact and L3
• Written updates are issued hourly until the incident is downgraded, whether or not there is progress to report
• Where personal data may be affected, the notification obligations in the Data Processing Agreement run in parallel and are not deferred pending investigation
• A written post incident review is provided within 5 Working Days of resolution, covering timeline, root cause, customer impact, remediation and preventative actions with owners and dates

Part 9. Planned maintenance and change notification

Planned maintenance is how the platform stays secure and current. It is carried out at times chosen so that it does not interrupt the Customer’s working day, its rent collection runs or its month end. Maintenance carried out on those terms is not treated as downtime, because the Customer has been told in advance, the work happens when nobody is using the platform, and the alternative is an unpatched system.

The standard windows

9.1 Maintenance carried out in a Standard Maintenance Window, notified in accordance with the table above, is excluded from the availability calculation under Part 3.5. It is not unavailability and it does not consume any part of the availability allowance.

9.2 The Customer may object to a notified window within 2 Working Days where it clashes with a critical period or with a specific operational commitment. Rentalize will move the work to the next available window, and the moved work is treated the same way.

Maintenance outside a standard window

9.3 Rentalize may occasionally need a window outside those above, for example for a database upgrade that cannot be completed in four hours. Where that arises:

• Rentalize gives at least 10 Working Days written notice, proposing a window and stating the expected impact and the reason
• the window takes effect only where the Customer agrees it in writing, and the Customer shall not unreasonably withhold or delay agreement
• maintenance carried out in an agreed window is excluded from the availability calculation in the same way as a standard window, and
• maintenance carried out outside a Standard Maintenance Window without the Customer’s agreement is not excluded, and every minute of it counts as unavailability

Critical periods

9.4 Where the Order Form provides for critical period protection, Rentalize will not carry out non-emergency maintenance during a critical period agreed under Part 2, in either window. The Customer confirms its critical period dates at go-live, reviews them annually, and may update them on 10 Working Days notice. Rent collection run days, month end reconciliation and statutory return deadlines are the dates that usually matter.

9.5 Independently of any critical period, Rentalize will avoid non-emergency maintenance on the last two and the first two Working Days of a calendar month wherever it is practicable to do so, because that is when reconciliation and reporting are heaviest across the customer base.

Emergency security patching

9.6 Where a security vulnerability requires immediate action, Rentalize may patch at any time without the notice periods above. It will notify the Customer as soon as practicable and in any event within 4 Working Hours, stating what was done and why. Emergency patching is excluded from the availability calculation, and Rentalize will keep it as short as the vulnerability allows.

9.7 Emergency patching is reported in the monthly service report, with the date, the duration and the reason, so that the Customer can see how often it is being relied on.

Releases and API changes

Part 10. Continuity and recovery

Part 11. Reporting and governance

Monthly service report

Issued within 5 Working Days of month end, whether or not targets were met.

• Availability figure and any service credit applied
• Tickets logged, resolved and open, by severity
• Response and resolution performance against target, by severity
• Any target missed, with the reason and the corrective action
• Any escalations raised and their outcome
• Planned maintenance carried out and scheduled
• Open items carried forward

Quarterly business review

Held from the point the dedicated account manager provision applies under the Order Form. Before that point, a written quarterly summary is provided.

• Trend analysis across the quarter rather than a single month
• Recurring issues and the underlying fixes tracked to closure
• Adoption and usage across the Customer’s teams, with any training need identified
• Backup restore test result and any continuity finding
• Enhancement requests logged, prioritised and roadmap position
• Service improvement plan, where any target has been missed in the quarter
• Portfolio count and any band movement under the Order Form

Service improvement plan

Where a target is missed in two consecutive months, Rentalize produces a written service improvement plan within 10 Working Days setting out root cause, corrective actions with named owners and dates, and how progress will be measured. The plan is reviewed at each monthly report until the targets are met for three consecutive months.

Part 12. Termination for sustained service failure

Where availability falls below 99.0 per cent in three consecutive Measurement Months, and Rentalize fails to remedy the underlying cause within 30 days of written notice, the Customer may terminate the Master Subscription Agreement immediately on written notice, without exit fee and without further liability save for Charges accrued to the date of termination. A full data export is provided at no charge. This reflects clause 12.6 of the Master Subscription Agreement, which governs.

The termination threshold of 99.0 per cent is deliberately set below the availability target of 99.5 per cent, so that service credits address a missed target and termination addresses sustained serious failure.

Part 13. Getting the most from the service

This Part is guidance rather than obligation. It reflects what tends to distinguish accounts that get fast resolution from those that do not.

Concentrate ticket raising through nominated super users

Two or three trained super users raising tickets on behalf of colleagues produces better tickets, fewer duplicates and faster resolution than every user raising their own. It also builds internal capability, since a super user resolves a proportion of questions without a ticket at all. Rentalize provides additional training to nominated super users at no charge during the first year.

Log everything, including matters discussed by telephone

A conversation is not a ticket. If it was worth a phone call it is worth a reference number, because that is what the response clock, the monthly report and any future service credit are measured against. Rentalize will create the ticket if asked, but the record needs to exist.

One issue per ticket

Three problems in one ticket move at the speed of the slowest and cannot be reported on separately. Where several issues share a root cause, Rentalize will link them.

Be specific about business impact rather than about urgency

Everything feels urgent to the person raising it. What determines severity is what the business cannot do while the issue persists. A ticket that says the rent run is due Thursday and cannot be executed carries more weight, correctly, than a ticket marked urgent with no impact stated.

Agree critical period dates in advance

Tell Rentalize which dates matter, rent run days, month end, statutory return deadlines, audit dates, and they are protected from maintenance and staffed accordingly. This costs nothing and is the most effective single step a customer can take.

Batch enhancement requests

Enhancement suggestions logged as severity 4 tickets are collected and reviewed together at the quarterly review, where they can be prioritised against each other and against the roadmap. A request that arrives as a one off between reviews competes with incidents and tends to lose.

It also helps to say what the request is trying to achieve rather than how you think it should be built. A request framed as an outcome can often be met by existing configuration, or by a change that suits the whole customer base and therefore goes onto the roadmap at no cost. A request framed as a specific build tends to end up as chargeable additional work.

Search the knowledge base first

A meaningful proportion of severity 3 and 4 tickets are answered by an existing article. Where an article is missing or unclear, say so in the ticket. Rentalize writes the article as part of resolving the issue, which reduces the same question arriving again.

Keep the contact list current

Escalation only works if the names and numbers are right. Confirm the contact list at each quarterly review and notify Rentalize between reviews when a named contact changes.

Use the monthly report

The report exists to be challenged. If the figures do not match the Customer’s experience of the month, that gap is itself worth a conversation, and it is far easier to address at the time than six months later.

Part 14. Responsibilities

Part 15. Exclusions

The availability commitment and the response targets do not apply to:

• Failure of the Customer’s own network, devices, browsers or internet connection
• Use of the platform in a manner not permitted by the Master Subscription Agreement or the Acceptable Use Policy
• Issues arising from data supplied by the Customer or by a third party on its behalf, including during migration
• Failure of a third party service outside Rentalize’s control, where Rentalize has followed its own continuity procedures. Rentalize will assist in resolving the issue with that provider
• Beta or preview features that the Customer has opted into, which are supported on a reasonable endeavours basis and labelled as such
• Additional Services delivered under a Change Order, which are governed by clause 4.14 of the Master Subscription Agreement
• Planned maintenance carried out in a Standard Maintenance Window, or in another window agreed with the Customer, and notified in accordance with Part 9
• Suspension under clause 7.7 or clause 12.8 of the Master Subscription Agreement, in the circumstances set out at Part 3.5
• Force majeure as defined in the Master Subscription Agreement

Part 16. The implementation period

This Part governs the period between execution and the Go-Live Date. Nothing in Parts 3 to 6 applies during that period.

Why the service levels start at go-live

During implementation the platform is being configured and populated, data is being migrated and validated in stages, and the Customer continues to operate its existing systems in parallel. An interruption during that period does not carry the operational consequence it carries once the business is running on the platform. Applying availability targets and service credits to a system that is still being built measures the wrong thing and would discourage exactly the kind of iterative configuration work that makes a migration succeed.

What applies instead

Sign off and hypercare

Go-live occurs only when the Go-Live Certificate is issued by Rentalize and countersigned by the Customer under clause 5.9 of the Master Subscription Agreement, or is deemed to have occurred under clause 5.9(d). The Customer has 5 Working Days to countersign or to object in writing identifying the specific outstanding items by reference to the Implementation Plan.

The hypercare period stated in the Order Form begins on the Go-Live Date. Severity 1 and severity 2 targets are halved during that period. The availability target applies from the first Measurement Month, so a partial first month is reported for information only.

Part 17. Contacts and version control

Rentalize

Customer

Customer contacts, nominated super users and critical period dates are recorded at section 11 of the Order Form and confirmed at go-live. Either party may update its contacts by written notice without a version change.

Version history

Changes to Parts 3 to 6 require written agreement by both parties. Changes to the remaining Parts are made under clause 1.4 of the Master Subscription Agreement and recorded above.