Skip to main content
Service level agreements (SLAs) let you record the response times you have agreed with your customers and bind them to the locations they cover, so anyone working an issue can see which sites take priority.
The SLA information modal in Spirii Connect, showing the SLA name, description, first- and second-level resolution times, on-site contractor contact, SLA type, and creation date

​
Overview

Not every location deserves the same response. A high-traffic DC hub losing a charge box costs more per hour than a quiet suburban AC site, and your agreements with your customers usually reflect that. An SLA in Connect captures one of those agreements: a name, the response times you have committed to, and who to call for on-site work. Every location is bound to one. You manage SLAs in Connect under Operations → Service Level Agreements, which is available to users with the Operator role.
These are your agreements with your own customers. Any service commitments acquired from Spirii’s support teams are not displayed or configured here.
An SLA documents the priority attached to a location and the contacts behind it. Connect keeps the response times visible to whoever is working an issue; you measure performance against them in your own service desk.

​
How it works

​
What an SLA records

​
The two resolution levels

Both levels are mandatory, and each carries its own Restrict to weekdays option, so a weekday-only first level can sit alongside a second level that counts weekends. The labels follow a conventional support escalation:
1

1st level — remote diagnosis and commands

The initial response: an agent picking up the report and attempting remote diagnosis, including sending commands to the charge box.
2

2nd level — deeper technical investigation

The deeper technical pass for issues that survive the first, reading OCPP logs and interrogating platform data.
3

On-site attendance — contact details only

Conventionally third line, and an SLA has no deadline field for it. Instead it carries the installer or OEM contact, so whoever is working the issue knows who to call.
How you define each level, and whether you treat the two deadlines as cumulative or independent, is yours to decide. Connect stores both figures as you enter them and does not add them together.

​
Binding SLAs to locations

Mark one SLA as Default and every location created afterwards is bound to it automatically. Marking a different SLA as default moves that flag, but it does not reassign locations that were already bound to the old one. For locations that need something other than the default, bind them manually in either direction:
  • From the SLA’s Locations tab, search for locations and bind them in bulk
  • From a location’s edit screen, pick the SLA at the bottom of the page
A location bound to anything other than the default carries a flag. Whoever picks up an issue sees the exception rather than having to remember it.

​
What your customers see

Anyone viewing a location can click its SLA name to open a modal showing the response times and details. That includes your customers, on the locations they own, so the commitment is visible to the party you made it to. The Service Level Agreements page itself, where SLAs are created and edited, remains operator-only.

​
A worked example

Rheinstrom GmbH runs a mixed estate. It creates an SLA named Standard, with a 24-hour first level and a 48-hour second level, both restricted to weekdays, and marks it as default. Every new location it adds is bound to Standard without anyone touching it. Munich DC Hub is different: high-traffic DC, and Rheinstrom has committed to a four-hour response including weekends. So Rheinstrom creates a second SLA named Critical sites with 4-hour and 8-hour levels, weekday restriction off, and the site installer’s number in the contact field. From that SLA’s Locations tab, it binds Munich DC Hub. An agent opening Munich DC Hub months later sees the flag, clicks the SLA name, and has the four-hour commitment and the installer’s number in front of them.

​
When to use it

One default, and specials only where the commitment genuinely differs. The flag on a non-default location is only useful while non-default locations are rare. An estate where half the sites carry bespoke SLAs gives an agent nothing to notice, and each extra SLA is another record to keep aligned with the contract behind it. Create the default before you start adding locations. Locations inherit the default at creation, so setting it up first saves binding them by hand afterwards.

​
Dependencies & limitations

  • SLAs document; your service desk measures. An SLA records the commitment and the contacts, and makes them visible on the locations it covers. Performance against the response times is tracked in your own service desk.
  • Operators only. Creating and editing SLAs requires the Operator role. Customers can view an SLA on their own locations but cannot reach the Service Level Agreements page.
  • Changing the default is not retroactive. Locations bound to a previous default stay bound to it.
  • Deleting an SLA leaves locations without one. Locations bound to a deleted SLA end up with no SLA rather than falling back to the default, so rebind them before you delete it.
  • One SLA per location. A location carries a single SLA at a time.
  • Contact details are free text. The installer or OEM contact is not validated and is not linked to a contact record elsewhere in the platform.
To bind an SLA to a site, use the SLA’s Locations tab, or pick it from the location’s edit screen.

Location configuration

Where a location’s SLA is bound, alongside its other settings.

Customer management

The customers your agreements are with, and the hierarchy they sit in.

Locations

What a location is, and what else it anchors.

Remote commands

The remote diagnosis a first-level response usually starts with.