When EV charging infrastructure is important to day-to-day business operations, having technical support is only part of the requirement. What matters is what happens when something goes wrong: who registers the incident, when the response begins, how the fault is diagnosed, when an on-site engineer is required and who is responsible for the next action.
That is what a well-defined SLA — Service Level Agreement — should establish.
An SLA is not simply a promise of a “fast response.” It defines measurable service levels and creates a shared understanding between the customer and service provider of how technical incidents will be managed.
For EV charger maintenance, this distinction is particularly important because incident detection, response, diagnostics and full restoration of service are separate stages. They cannot always be completed within the same timeframe.
What Is an SLA for EV Charging Infrastructure Maintenance?
An SLA defines specific service parameters that can be used to determine whether the agreed level of technical support is being delivered.
Depending on the service scope, these may include:
- how incidents are registered and prioritised;
- response time;
- diagnostic time or diagnostic targets;
- rules for remote intervention;
- conditions for on-site attendance;
- escalation procedures;
- communication during an incident;
- customer and service-provider responsibilities;
- conditions relating to spare parts and external dependencies;
- how uptime and other service indicators are measured;
- periodic reporting.
The SLA should reflect the actual scope of the service. Not every maintenance agreement requires the same metrics, and not every charging site has the same operational criticality.
Response Time Is Not Repair Time
This is one of the most important distinctions in technical maintenance.
Response time tells you how quickly the support process starts. It does not necessarily tell you when the fault will be fully resolved.
If an SLA specifies a response within four hours, that should not automatically be interpreted as a commitment to repair the charger within four hours.
A response may mean that the incident has been acknowledged, classified and that remote investigation or communication with the customer has begun.
What happens next depends on what is found.
The issue may be resolved remotely. Further diagnostics may be required. An engineer may need to visit the site. If a replacement component is required, full restoration may also depend on spare-parts availability.
An SLA should therefore use its terminology consistently and define exactly what each timeframe measures.
Four Different Stages of a Technical Incident
To make an SLA understandable, it is useful to treat incident management as a sequence of distinct stages.
Incident Registration
This is the point at which the issue becomes known to the support process.
An incident may be reported by the customer or user, detected through remote monitoring or registered through another agreed channel.
This moment matters because it may determine when specific SLA timers begin.
Response
Response confirms that the incident has been taken into the support process and that handling has begun.
Depending on the agreed service model, this may include an initial assessment, priority classification and the start of remote diagnostics.
Diagnostics
Diagnostics has a different purpose: to isolate the fault and determine what needs to happen next.
As discussed in our guide to EV charger diagnostics and repair, the visible symptom is not necessarily the technical root cause.
Diagnostic time and response time should therefore not be treated as interchangeable terms.
Service Restoration or Final Resolution
Once the fault has been assessed, the next question is how charging service will be restored.
In some cases this can happen remotely. In others it may require an on-site repair, a configuration change, a replacement component or action by another party.
This is where an SLA needs to reflect real dependencies rather than promise a timeframe that the maintenance provider cannot control independently.
Why Diagnostic Time Should Be a Separate Metric
For complex technical infrastructure, a fast response has limited value if it is not followed by a clear diagnostic process.
The customer needs to know not only that the incident has been acknowledged, but also when a technical assessment and a decision on the next action can be expected.
That does not necessarily mean that every root cause must be conclusively confirmed within the diagnostic target.
Certain faults require an on-site inspection or physical testing before the cause can be verified.
A well-defined diagnostic stage should, however, move the incident from “there is a problem” to “we know enough to determine the next technical action.”
Should an SLA Guarantee a Final Repair Time?
Not necessarily.
For some services and types of equipment, a specific resolution target may be appropriate. In other cases, a guaranteed repair time could be misleading because full restoration depends on factors outside the maintenance provider's immediate control.
These may include:
- spare-parts availability;
- manufacturer delivery times;
- the need for manufacturer-specific intervention;
- access to the site;
- specialist equipment;
- electrical supply interruptions;
- actions by the distribution network operator or another third party;
- a fault outside the contracted technical scope.
The stronger SLA is therefore not necessarily the one with the shortest headline number.
A stronger SLA is one that clearly defines what is being measured, when the clock starts and which dependencies are included or excluded.
Incident Priority Matters
Not every technical fault has the same operational impact.
A completely unavailable DC charger at a site with a single charging point has a different business impact from a non-critical fault affecting one point within a larger charging installation where alternative chargers remain available.
An SLA may therefore use different incident-priority categories.
Classification can take into account factors such as:
- whether charging is completely unavailable;
- how many charging points are affected;
- whether alternative charging capacity remains available;
- whether the incident affects a critical business operation;
- whether the problem is functional, communication-related or another type of fault;
- whether there is a potential safety concern requiring the equipment to remain out of service pending technical inspection.
The important point is that these categories should be defined in advance rather than invented after an incident occurs.
Remote Diagnostics as Part of the SLA Process
With connected charging infrastructure, the first technical response can often begin remotely.
Depending on the equipment and management system, technicians may be able to review statuses, events, communications, diagnostic logs and other operational information.
OCPP can support part of the communication between the charging station and the central system, but the diagnostic capabilities actually available depend on the protocol version, charging equipment and specific implementation.
Remote access does not guarantee that a fault can be resolved remotely.
Its value is that it can help isolate the issue more quickly and support a better-informed decision about whether an on-site visit is required.
When Does the SLA Clock Start?
This may sound like an administrative detail, but it is critical.
If an agreement states “response within four hours,” it should be clear what those four hours are measured from.
Is it from the moment a driver first notices the problem? From automated detection? From receipt of a support ticket? From the point at which the customer has provided the information required to investigate?
A well-structured service defines the starting point clearly.
The same applies to periods when progress is blocked because site access, required information or another contractually defined dependency is unavailable.
Without these definitions, even a precise number of hours can remain ambiguous in practice.
Business Hours or 24/7?
An SLA should also define the service window.
“Four hours” can mean four elapsed hours or four business hours. These represent very different service levels.
For some charging sites, support during standard business hours may be sufficient.
For others — such as infrastructure required for daily fleet operations or a continuously available public charging service — a different support model may be necessary.
The requirement should be based on the operational role of the infrastructure rather than on making every SLA appear as strict as possible.
An SLA Requires Clear Responsibilities on Both Sides
Technical maintenance does not depend on the service provider alone.
For an incident to be handled effectively, the customer may also have defined responsibilities.
These can include providing site access, maintaining up-to-date contacts, supplying information about the observed issue, assisting with certain checks and notifying the maintenance provider about changes to the infrastructure.
For some systems, access to manufacturer or backend platforms, technical documentation, configuration data and service tools may also be relevant.
If these dependencies are not established in advance, an SLA may contain precise timeframes while still failing to define who is responsible for the next action.
What Happens When a Spare Part Is Required?
Spare parts are one of the clearest reasons why diagnostic time and service-restoration time can differ.
The fault may be identified quickly, while the required component is not available at the site or in local stock.
For business-critical infrastructure, spare-parts strategy therefore forms part of reliability management.
Depending on the equipment and contracted service scope, this may involve identifying critical components, maintaining local stock, establishing delivery procedures or using another approach to limit downtime.
The SLA should make clear where the diagnostic commitment ends and how dependencies on replacement components are handled.
What Is the Role of a Temporary Workaround?
Sometimes completing the final repair is not the fastest way to restore the operational function.
Where a safe and technically appropriate temporary solution, workaround or replacement infrastructure is available, it may reduce the operational impact while the permanent repair is being completed.
This can be particularly important where charging infrastructure supports a core business activity.
A temporary solution should not, however, be presented as a final repair.
Service restoration and final resolution can be two different events — and a good SLA should allow that distinction to be made.
SLA and Uptime Are Not the Same Thing
SLA and uptime are related, but they measure different things.
An SLA defines how the service process should operate — for example response, diagnostics, escalation and other agreed service parameters.
Uptime describes the availability or operational state of the charging infrastructure over a defined period according to a defined methodology.
A short response time can help reduce downtime, but it does not by itself guarantee a particular level of uptime.
Actual availability is also influenced by equipment reliability, preventive maintenance, spare-parts availability, installation quality, communications, external power supply and other factors.
SLA is a tool for managing response and responsibility; uptime is an outcome influenced by the wider system.
How Do You Verify Whether an SLA Is Being Met?
An SLA has limited value if there is no reliable incident history.
For each support ticket, key events should be traceable, such as:
- when the incident was registered;
- which priority was assigned;
- when the response began;
- what was established during diagnostics;
- whether an on-site visit was required;
- what intervention was performed;
- when charging functionality was restored;
- whether any final corrective action remains outstanding.
This turns an SLA from a promise into a measurable process.
Periodic reporting can show not only whether agreed targets were met, but also which faults are recurring, where downtime is accumulating and which preventive actions may be appropriate.
How Should Two SLA Proposals Be Compared?
The headline number is rarely enough.
An offer promising “response within two hours” is not automatically stronger than one offering “response within four hours” if the first does not define what response means, how diagnostics proceeds or what happens afterwards.
When comparing SLA proposals, useful questions include:
- What exactly does response time mean?
- When does the clock start?
- Is there a separate diagnostic target?
- How is incident priority determined?
- When is an on-site engineer dispatched?
- How are spare parts handled?
- What happens if the fault is outside the charger itself?
- Is there an escalation process?
- How is restoration documented?
- How is SLA performance measured?
An SLA should be compared as a process, not as a single number.
SLA as Part of the EV Charging Infrastructure Lifecycle
A well-organised SLA connects monitoring, diagnostics and repair, preventive maintenance and technical reporting.
When these activities operate as one process, each incident creates information that can improve the next response.
Recurring faults can be analysed. Critical spare parts can be identified. Priorities can be adapted to the actual operating conditions of the site.
This turns the SLA from a contractual timeframe into part of EV charging infrastructure reliability management.
Within Qerra Care, specific service parameters follow the agreed scope and service level. The objective is to establish clarity not only about how quickly a response begins, but also about how a technical incident is managed from registration through to the next required action.
A good SLA does not promise that problems will never occur. It defines what happens when they do.
Frequently Asked Questions
What does SLA mean in EV charger maintenance?
An SLA defines measurable parameters for technical support, such as response time, the diagnostic process, incident priorities, escalation and other agreed responsibilities. The specific metrics depend on the service scope and service level.
Does response time mean the charger will be repaired within that period?
No. Response time generally defines when incident handling begins according to the agreed definition. Full repair may require diagnostics, an on-site visit, a spare part or intervention by another party.
What is the difference between response time and diagnostic time?
Response time indicates how quickly the incident is taken into the support process and handling begins. Diagnostic time relates to the technical assessment required to isolate the fault and determine the next action.
Should an SLA include a guaranteed repair time?
Not necessarily. Some services may include a resolution target, while in other cases full restoration depends on spare parts, site access, the manufacturer or other external factors. The important point is that the agreement clearly defines what is measured and which dependencies apply.
How is an SLA related to uptime?
Faster response and an organised diagnostic process can help reduce downtime, but an SLA does not by itself guarantee uptime. Availability also depends on equipment reliability, preventive maintenance, spare parts, power supply, communications and other factors.
How do I know whether an SLA is appropriate for our EV charging infrastructure?
The SLA should reflect the infrastructure's role in the business, the number and type of charging points, available redundancy, operating hours and the consequences of an outage. More critical infrastructure generally requires more clearly defined priorities, escalation and service-restoration processes.
Need a Clearly Defined Level of Technical Support?
Qerra Care connects monitoring, diagnostics, technical response and EV charging infrastructure maintenance within an agreed service scope and service level.