Cut electric vehicle charger downtime with AI triage

Applied by
Siemens Sanayi ve Ticaret A.Ş.Siemens Sanayi ve Ticaret A.Ş.
In partnership with
    SKD TürkiyeSKD Türkiye

Summary

An AI assistant triages charger faults from protocol alerts and routes them to an engineer in about a minute, cutting resolution from days to hours.

Context

Submitted through the COP31 Sustainable Transformation Awards · SKD Türkiye (WBCSD Global Network Partner)

Siemens Sanayi ve Ticaret A.Ş. is the Turkish organisation of an industrial technology group, and its electric vehicle charging business supplies and services charging infrastructure for network operators.

Fault handling in the charging sector is still largely manual and passes through several organisations. A fault is reported to the operator's team, the operator refers it to the station manufacturer's technical support unit, technical support analyses the fault code, attempts a remote intervention, and if a site visit is needed a service crew and spare parts have to be scheduled. Because each step is carried out by different teams on different systems, resolving a fault takes an average of 6-8 days in the sector, which is approximately 168 hours. The charger stays out of service for that period, drivers are turned away, and operational efficiency falls.

The problem is scaling with the market. According to the Turkish energy market regulator's April 2026 report there are 18,957 direct current sockets in Türkiye, and the regulator's medium scenario projects a total of 328,000 alternating and direct current charge points by 2040, against a national target of approximately 200,000 charge points by 2030 (2).

The wider policy backdrop is the COP31 electrification agenda, described as "35 by 35", together with a call to cut building sector energy intensity by at least 25 per cent by 2035 (3). Charging availability is the point at which that agenda either holds or fails, because a charger that is out of service delivers none of the transport emissions benefit it was installed for.

No regulation requires the work. It was developed in 2025 and entered pilot operation in 2026.

Location of the initiative: Türkiye, with cross-border validation in Portugal


Solution

The system is a multi-agent artificial intelligence platform that places a single conversational layer over the operational systems that already exist, rather than replacing them.

Six specialist agents operate within it: fault diagnosis and technical support; customer relationship management and case handling; customer health scoring and risk analysis; electric vehicle market and competitive intelligence; and sales opportunity identification. Each is built for a defined task rather than as a general assistant, which is what allows domain knowledge specific to charging infrastructure to be embedded in the diagnosis.

Every agent operates with a human in the loop. No critical decision is taken autonomously; the system is positioned as decision support that strengthens the judgement of the engineer or manager using it.

The trigger is the equipment itself. A fault enters the system through a notification under the Open Charge Point Protocol, the communication standard common to charging stations, so the process starts from the asset rather than from a telephone call.

The design choice that makes adoption possible is that the existing customer relationship management infrastructure is left in place. The assistant is reached through the corporate collaboration and chat tools that teams already use, and is connected to the corporate service management platform, workflow automation and the document library, so no separate technical infrastructure is required.

The architecture is modular and loosely coupled, built on a platform-independent model context protocol approach, which is what allows the same system to be deployed by a different operator on a different service management stack without redesign.

The effect on the operating model is a shift from reactive, manual service to a proactive and data-driven one, and the corporate memory that previously sat with individual engineers becomes a system asset available to every team.

Figure 1: Modelled Annual Avoided Emissions - assumption chain

Modelled annual avoided emissions - assumption chain

The assumption chain behind the modelled annual avoided emissions, from 14,000 accessible direct current sockets through faults per asset and hours of availability recovered to net and gross tonnes of CO2.

Figure 2: The Platform Architecture

The platform architecture: six specialist agents, one core

Specialist agents for field service, customer health, marketing, reporting, sales and asset lookup, sharing one core interface reachable from the collaboration tools teams already use.


Impact

Sustainability impact

Climate

The initiative is an enabler rather than a direct abatement measure. It does not reduce the company's own Scope 1 or Scope 2 emissions; the environmental effect is calculated as avoided emissions under the Greenhouse Gas Protocol avoided emissions methodology, which sits outside the corporate emissions inventory.

The mechanism is charger availability. Each fault resolved in about 6 hours instead of the sector average of approximately 168 hours recovers approximately 162 hours of availability, which is charging capacity that would otherwise have been lost.

The scale-up figures are a projection based on a stated assumption chain, not a measured result. The partnership model and customer portfolio are expected to reach approximately 70 per cent of the Turkish market, or 14,000 sockets.

Based on the 453 faults handled during the pilot, the impact calculation estimates approximately 73,386 hours of recovered charging availability. Based on an estimated average charging output of 3.54 kW, this corresponds to approximately 260 MWh of additional charging energy made available, enabling approximately 1.30 million additional EV-km. This represents approximately 156 tCO2 of gross avoided emissions. After accounting for the emissions associated with the electricity used for the recovered charging activity, the resulting net avoided emissions are estimated at ~39 tCO2.

Based on a projected deployment of 14,000 covered sockets and an assumed average fault rate of 0.8 faults per socket per year, the solution could address approximately 11,200 faults annually. At an estimated 162 hours of recovered charging availability per fault, this would correspond to approximately 1,814,400 recovered operating hours per year. Applying the estimated average charging output of 3.54 kW, this represents approximately 6.4 GWh of additional charging energy made available annually.

At an average EV efficiency of 0.20 kWh/km, this could enable approximately 32 million additional EV-km per year. Using a petrol vehicle emission factor of 0.12 kgCO2/km and accounting for 0.45 kgCO2/kWh grid emissions associated with the recovered charging energy, the projected impact corresponds to approximately 0.97 ktCO2 of net avoided emissions per year. On a gross basis, before deducting grid electricity emissions, the projected avoided emissions are approximately 3.86 ktCO2 per year.

These annual figures are projections based on the assumed deployment and impact parameters; they do not represent emissions avoided to date.

Social

Charging availability is a public service question as well as a commercial one. A charger out of service for 6-8 days removes capacity from the network at the point of use, and drivers without home charging are the group most affected. Faster restoration supports access to clean urban transport, particularly in the cities where public direct current charging is the main option.

The operating model contributes to keeping availability at public direct current charging stations above 99 per cent, which is the level at which drivers can rely on a charger being usable without checking first.

Inside the organisation, the effect is on how knowledge is held. Diagnostic experience that previously depended on particular individuals becomes accessible to every field engineer, which removes a single point of failure and shortens the time a new engineer needs to become effective.

Automating the routing and administrative steps moves field teams towards higher-value work, and the human-in-the-loop design keeps the engineer in the decision rather than replacing the judgement with an automated output.

Business impact

Benefits

The operational result in pilot operation is speed. Faults that can be resolved remotely are closed in approximately 2 hours and those requiring a site visit in approximately 6 hours, against a sector average of 6-8 days, and the first routing to a field engineer arrives in approximately 1 minute instead of passing through a manual referral chain. That is a reduction of approximately 95 per cent in fault response time.

Recovered availability is the commercial value. Approximately 162 hours of uptime is recovered per fault, and for an operator that availability is revenue that would otherwise have been lost, alongside the customer relationship that a station out of service for days damages.

The platform also earns beyond service. Customer health scoring and risk analysis identify accounts at risk before they churn, and market and competitive intelligence supports the sales function, so the same investment serves service operations and commercial teams.

Adoption cost is low because no separate technical infrastructure is required. The assistant runs on the collaboration, service management, workflow automation and document platforms the organisation already licenses, which removes the infrastructure project that normally accompanies a system of this kind.

There is a revenue route as well as a cost route: a white label licensing model is targeted from 2027, which would make the platform a product rather than an internal tool.

Costs

Development required approximately 640 person-hours across a four-person team over eight months, which at an internal engineering rate of 125 EUR per hour represents a one-off investment of approximately 80,000 EUR. Annual running cost is approximately 16,500 EUR, comprising the low-code platform licence at 6,000 EUR a year and consumption-based artificial intelligence charges of approximately 10,500 EUR a year at an expected volume of 5,000 requests a month. Because the artificial intelligence cost is metered per request rather than per seat, it scales with fault volume rather than with headcount.

The payback case rests on reclaimed engineer time rather than on new revenue. Triage and documentation fell from 60-90 minutes to 10-20 minutes per case, and ticket creation from 15-30 minutes to under 2 minutes, releasing approximately 80 minutes of engineer time per case. At approximately 444 cases a year this is worth approximately 74,000 EUR annually, giving a net annual benefit of approximately 57,500 EUR after running costs and a payback period of approximately 1.4 years. Recovered station availability is an additional benefit that accrues to the network operator rather than to the manufacturer, and is not counted in this payback.

The identifiable cost structure has four parts: development of the six agents and the domain knowledge behind the diagnosis; the running cost of the artificial intelligence models and cloud services, which scales with the volume of faults processed rather than being fixed; integration effort with each operator's own service management stack; and the human review time that the human-in-the-loop design requires by construction.

Change management is a real cost rather than an overhead. Corporate adoption resistance is one of the identified risks, and it is addressed by delivering the assistant inside tools teams already use rather than as a new application to be learned.

Costs are contained by the modular, loosely coupled architecture, which allows adaptation to a different geography or sector at low cost, and by leaving the existing customer relationship management platform in place instead of replacing it.

The dependencies are the availability of fault notifications under the Open Charge Point Protocol, continuity of the underlying enterprise platform contracts, and data protection compliance where the deployment crosses borders, which is what the collaboration with the group's Portuguese organisation is testing.

Impact beyond sustainability and business

Co-benefits

The architecture is not specific to charging. The pattern of specialist agents over an unchanged service management system, triggered by equipment telemetry and delivered through existing collaboration tools, applies to any field service operation with dispersed assets and a manual referral chain.

Making corporate memory independent of individuals has an effect beyond speed: knowledge that was previously held by the most experienced engineers becomes available to the whole team, which changes how a service organisation trains and how it absorbs staff turnover.

The partnership route spreads the benefit outside one company. Validation with an external charging network operator and an e-mobility solutions partner is intended to lead to those organisations using the platform in their own service operations, and a white label licensing model from 2027 would extend it to independent operators.

Potential side-effects

The initiative is at pilot stage. The response time results come from pilot operation and the environmental figures are modelled projections, so the model should be read as demonstrated in a limited deployment rather than proven at the scale the projections assume.

Four risks are identified and managed: artificial intelligence error, platform dependency, corporate adoption resistance and competition. The mitigations are the human-in-the-loop design, a platform-independent architecture, delivery through existing collaboration tools, domain knowledge specific to charging infrastructure, and the multi-agent structure that keeps each agent narrow enough to be checked.

The dependency risk is genuine rather than theoretical. Building on one vendor's collaboration, service management, workflow and document platforms lowers the adoption barrier but concentrates the operating model on a single supplier stack.

Automating diagnosis also changes how expertise develops. If routine triage no longer passes through junior engineers, the practical experience that produced the diagnostic knowledge in the first place has to be created deliberately through training rather than acquired on the job.

The projection is sensitive to its assumptions. The avoided emissions figure rests on reaching 70 per cent of the market, on 0.8 faults per asset per year and on an average of 85 kWh delivered per socket per day; a change in any of these moves the result proportionally.


Implementation

Typical business profile

The model suits electric vehicle charging network operators, field service companies and infrastructure managers that run dispersed assets under a service level obligation, where the cost of a fault is driven by the time the asset is unavailable rather than by the repair itself.

It is designed to be adopted without replacing existing customer relationship or service management systems, so it fits organisations that have already invested in those platforms and cannot justify a migration.

Delivery engages field service engineering, service operations, customer management and sales, with corporate information technology responsible for platform scaling and compliance. The same pattern transfers to other asset-heavy service sectors with equipment telemetry and a multi-party fault chain.

Approach

  1. Baseline the fault chain before automating it: Record every hand-off from fault report to closure, with the time each step consumes and the system it runs on, and establish the current average, which in this sector is 6-8 days or approximately 168 hours.

  2. Take the fault signal from the equipment, not the call centre: Subscribe to notifications under the Open Charge Point Protocol so that a fault enters the system automatically at the moment it occurs, rather than when a driver reports it.

  3. Route first, diagnose second: Send an automated first assignment to the responsible field engineer within approximately 1 minute of the notification, so that mobilisation runs in parallel with diagnosis instead of after it.

  4. Build specialist agents rather than one general assistant: Define separate agents for fault diagnosis and technical support, case management, customer health and risk scoring, market and competitive intelligence, and sales opportunity identification, so that each carries the domain knowledge its task requires.

  5. Keep a human in the loop by design: Require human approval for every critical decision, so that the system is decision support rather than an autonomous controller, and so that errors are caught by the person who will carry out the work.

  6. Layer the assistant over the existing systems: Connect to the corporate service management platform, workflow automation and document library instead of replacing them, and hold all case records, resolution times, asset status and customer data in the existing system of record.

  7. Deliver inside the tools teams already use: Provide access through the corporate collaboration and chat environment so that adoption does not require staff to learn a new application, and no separate technical infrastructure has to be commissioned.

  8. Validate with external organisations before scaling: Run integration and validation testing with an external charging network operator and an e-mobility solutions partner to confirm the platform works across different business models and service management stacks, then test multi-country rollout and data protection compliance through a cross-border deployment.

  9. Report weekly and then automate the reporting: Track first response, resolution time, ticket closure rate and asset-level case density on a weekly cycle, and commission an automatic reporting module, targeted for the second half of 2026, so that metrics can be shared with stakeholders without manual preparation.

Stakeholders involved

  • Project leads: The platform is owned by the electric vehicle charging business in Türkiye and run by its digital services unit. It reports on a regular cycle to the manager responsible for digitalisation and artificial intelligence in that business, which is where strategic oversight sits. Ownership at business level rather than in a central technology function is what kept the design anchored to service operations rather than to a technology roadmap.

  • Company functions: Four internal user groups shaped the system and use it daily: field service engineers for fault diagnosis and technical support; the service operations team for customer relations and case management; customer managers for health monitoring and risk detection; and the sales team for market and competitive intelligence. The real operational needs and field experience of these teams determined the agent architecture, the prioritisation logic and the scope decisions. Feedback runs continuously, and requirements raised in the field are reflected back into the platform, so the system is shaped by its users rather than specified once. The corporate information technology function in Türkiye works with the team on the underlying platform infrastructure, platform scaling and corporate compliance.

  • Main providers: An enterprise software provider supplies the underlying collaboration, customer relationship management, workflow automation and document platforms on which the assistant runs. The platform is built as a layer over that stack rather than as a replacement for it, and the architecture is deliberately platform-independent so that the layer is not permanently bound to one provider.

  • Other: Two external organisations run integration and validation. A major national electric vehicle charging network operator contributes the network operator's perspective on operational needs and user experience, and an e-mobility solutions partner tests compatibility with field service processes and with different customer relationship management infrastructures. The long-term intention is for both to use the platform in their own service operations, which would be the first deployment outside the company's own ecosystem. A collaboration with the group's Portuguese organisation tests multi-country rollout and data protection compliance.

Key parameters to consider

The platform was developed in 2025 and entered pilot operation in 2026, so the results reported are pilot results rather than results from full deployment. European market expansion is targeted over the 2025-2026 period and a white label licensing model for independent operators from 2027.

The environmental projection rests on a stated assumption chain that a reader should test against local conditions: access to approximately 70 per cent of the Turkish market, or 14,000 of the 18,957 direct current sockets recorded; 0.8 faults per asset per year, giving approximately 11,200 faults; 162 hours of uptime recovered per fault, giving 1,814,400 hours; an average of 85 kWh delivered per socket per day, equivalent to approximately 3.54 kW of continuous output, giving approximately 6.4 GWh a year; an electric vehicle efficiency of 0.20 kWh/km, giving approximately 32 million km; and a petrol car emission factor of 0.12 kg CO2/km, net of grid emissions at 0.45 kg CO2/kWh, giving approximately 964 tonnes of CO2 a year, or approximately 3,856 tonnes on a gross basis.

Impact data is monitored continuously through the corporate customer relationship and service management platform, which holds all fault records, resolution times, asset status and customer information centrally. First response, resolution time, ticket closure rate and asset-level case density are reported weekly, and an automatic reporting module is targeted for the second half of 2026 (1).

The technical prerequisite is fault notification under the Open Charge Point Protocol; the organisational prerequisite is an existing service management system of record to layer onto.

Implementation and operations tips

Start from the equipment signal. The largest single saving is not faster diagnosis but the removal of the manual referral chain between the fault occurring and an engineer being assigned, which is where days are lost.

Do not replace the system of record. Leaving the existing customer relationship and service management platform in place removes the migration project that normally delays this kind of work, and it means the assistant can be withdrawn without losing data.

Narrow agents beat one broad assistant. Splitting the work across six task-specific agents makes each output checkable by the person responsible for that task, which is what makes a human-in-the-loop design workable rather than a formality.

Deliver inside existing tools. Adoption resistance was identified as a principal risk, and the mitigation was not training but placing the assistant in the chat environment teams already open every morning.

Separate demonstrated results from projections when presenting the case. The response time improvements come from pilot operation, while the capacity and emissions figures are modelled from an assumption chain; presenting them together without that distinction weakens both.