一台充电桩在仪表板上显示为在线状态,却仍可能无法通过真正重要的实际测试:驾驶员能否启动充电、获得预期功率并按时离开?这种差距正是采购团队在选定供应商之前,需要仔细审视正常运行时间SLA的原因。
对于基础设施买家、车队运营商、站点业主和渠道合作伙伴而言,只有当正常运行时间承诺反映了运营现实时,它才有价值。如果供应商对正常运行时间的衡量标准过于宽松,排除了最常见的故障模式,或者对高优先级充电桩的故障响应过慢,那么一份纸面上看起来不错的合同仍然可能让站点暴露在风险中。
为什么一个标题式的SLA可能误导买家
许多买家通过一个显眼的数字来比较供应商:承诺的正常运行时间百分比。这可以理解,但这通常远远不够。
一个SLA可能看起来很有竞争力,但仍然允许过多的运营中断。问题不仅仅在于百分比本身,还在于供应商如何定义可用性、哪些资产被覆盖、哪些中断被排除,以及如何跨硬件、软件和通信衡量性能。
当站点服务于不同的充电角色时,这一点更为重要。一个工作场所的交流充电项目通常能容忍比停车场或商业地点更长的恢复时间窗口,因为在这些地方,直流快充保障着车辆周转和收入连续性。买家应该将SLA与故障的业务后果相匹配,而不是仅仅看供应商的营销话术。
在比较供应商之前,先定义“正常运行时间”的含义
第一个问题很简单:在这份合同中,究竟什么才算作正常运行时间?
一些供应商将正常运行时间定义为基本的网络连接。另一些则将其定义为充电桩可用于启动充电会话。更强有力的定义是追踪充电桩是否能够实际执行其工作,而不仅仅是它是否在发送心跳信号。
在签约前,买家应询问正常运行时间是按充电桩级别、连接器级别、站点级别还是网络级别衡量的。在多端口设备上,一个故障连接器不应被隐藏在一个更宽泛的设备级数字中。在混合资产组合中,一个表现不佳的高优先级充电桩不应被其他不太关键的单元所掩盖。
同样值得询问的是,功率降额、授权失败、支付错误、冷却故障或重复的会话中断是否算作停机时间。如果一个充电桩技术上在线但无法提供可用的充电体验,许多运营商会将其视为运营不可用。
询问性能如何衡量和报告
即使对正常运行时间的定义是合理的,如果报告方法模糊不清,它也会变得薄弱。
买家应在采购批准前索取一份正常运行时间报告样本。该报告应显示供应商如何对事件进行分类、如何记录中断开始和结束的时间戳、如何处理部分故障,以及如何区分计划内和计划外事件。一份好的报告还应便于将服务工单与性能声明进行核对。
这就是买家应该超越充电桩本身,审视运营模式的地方。拥有规范监控、远程支持和升级工作流程的供应商通常更有能力证明SLA性能,因为他们已经在追踪故障是如何被检测、分类和解决的。
如果供应商无法解释正常运行时间是如何按月、按充电桩角色和按故障类型衡量的,那么该SLA可能更多是装饰性的,而非运营性的。
在信任承诺之前,先审查排除条款
大多数SLA风险隐藏在排除条款部分,而不是在标题承诺中。
排除条款本身并非不合理。公用事业停电、不可抗力事件、客户方误用、故意破坏和第三方电信故障可能超出供应商的直接控制。真正的问题是,排除清单是否过于宽泛,以至于买家承担了大部分运营风险,而供应商却仍在宣传一个很高的正常运行时间目标。
仔细查看这些常见的排除项:
- 计划内维护窗口
- 固件和软件更新期间
- 支付网关或授权服务故障
- 电信或SIM卡连接问题
- 客户方局域网、路由器或防火墙问题
- 公用事业侧断电或上游电力限制
- 超出规定运行假设的环境条件
合同应说明每一类责任由哪一方承担,事件如何记录,以及在排除一次中断之前需要什么证据。否则,买家可能每次重大事件后都要争论不休,而不是依赖一个共同的服务标准。
将硬件责任与平台责任分开
许多电动汽车充电问题介于硬件和软件之间。电缆故障、控制器问题、支付失败和OCPP通信中断都可能停止充电,但它们不属于同一个响应团队。
这就是为什么买家应坚持要求一个清晰的责任矩阵。谁负责充电桩硬件?谁负责后端软件?谁处理云服务、漫游、支付流程、固件验证以及与第三方系统的互操作性?当根本原因最初不明确时,谁领导事件解决?
这个问题在开放生态系统中尤其重要。买家通常更喜欢开放充电网络和互操作性模型,因为它们减少了锁定,并在站点生命周期内提供了更多灵活性。但是,只有当供应商明确说明其SLA在多个系统交互时的起点和终点时,开放性才有帮助。
如果平台由一方提供,充电桩由另一方提供,买家不应接受一种允许各方相互指责而站点仍部分停机的合同结构。
将响应时间与站点关键性相匹配
没有响应和恢复承诺的正常运行时间SLA是不完整的。
对于车队停车场、交通枢纽、高速公路走廊或任何充电停机可能中断日程的站点,买家应要求基于严重性的响应时间窗口。一个轻微的显示故障和一个故障的高优先级直流充电桩不应进入同一个服务队列。
实际问题是:
- 供应商多快能确认一个关键事件?
- 远程诊断多快能开始?
- 现场派遣何时进行?
- 临时解决方案与完全修复的目标时间是多少?
- 备件是本地、区域还是仅在工厂库存?
- 对于高价值故障,是否有更换单元策略?
这就是买家背景重要的地方。在长停留环境中的交流充电通常支持更灵活的恢复窗口。用于短周转操作的直流快充通常需要更严格的服务承诺,因为每损失一小时都会影响吞吐量和站点经济效益。
询问更新如何影响可用性
软件和固件是正常运行时间讨论的一部分,而不是与之分离的。
更新可以提高可靠性、安全性和兼容性,但如果部署不当,它们也可能造成计划内停机、部署失败或新的故障。买家应询问维护窗口是否计入SLA,更新如何批准,回滚如何处理,以及供应商是否在更广泛部署之前先在有限子集上验证新版本。
最强大的供应商将固件更新策略视为一个正常运行时间保护过程,而不是一个后台技术任务。这通常意味着变更控制、分阶段部署、发布后的告警监控,以及在风险升高时与客户进行清晰的沟通。
如果合同赋予供应商广泛的自由,可以在没有有意义的通知或服务问责的情况下将充电桩下线进行更新,买家应在签约前收紧该措辞。
明确正常运行时间之外哪些KPI更重要
一个充电桩可以满足一个狭窄的正常运行时间指标,但仍然提供糟糕的运营结果。这就是为什么买家应要求与SLA一起提供支持性绩效指标。
有用的问题包括供应商是否追踪:
- 成功会话启动率
- 成功会话完成率
- 确认关键事件的平均时间
- 恢复服务的平均时间
- 按充电桩或连接器统计的重复故障频率
- 功率降额事件及其持续时间
- 按故障原因统计的离线持续时间
这些指标构成了更完整的服务质量图景。在许多情况下,买家应该像关心标题上的正常运行时间百分比一样,关心事件恢复纪律和会话成功率。
在续约或退出成为问题之前确保数据访问权
一个正常运行时间SLA还应支持长期的运营控制。如果买家无法访问事件历史、日志、固件记录或充电桩性能数据,就更难验证供应商的声明,也难在以后关系发生变化时进行过渡。
在签约前,买家应确认运营数据、事件日志、配置记录和服务历史的所有权和访问权。合同还应描述导出格式、保留期限,以及如果买家更换网络提供商或服务合作伙伴时的交接义务。
这就是为什么在任何一个平台承诺变得根深蒂固之前,一份结构化的数据交接清单如此重要。一个无法检索运营历史的买家,往往在事后才发现该SLA从一开始就难以审计。
使补救措施与业务风险相称
服务积分在SLA设计中很常见,但买家应询问提议的补救措施是否真正匹配故障的运营后果。
对于非关键站点,适度的积分结构可能是可以接受的。对于高利用率的商业或车队部署,仅靠积分可能无法弥补吞吐量损失、调度中断、客户不满或与下游用户的合同罚款。
在这些情况下,买家可能希望获得更强有力的商业保护,例如:
- 针对重复未达标目标的升级补救措施
- 严重中断后的强制性根本原因报告
- 明确的备件库存义务
- 故障高价值单元的优先更换
- 在重复重大违约后的终止权
正确的补救结构取决于站点的商业模式,但原则很简单:合同应反映充电桩故障在实际中的代价有多大。
买家在签约前应提出的问题
| 要问什么 | 为什么重要 | 一个更强的答案是什么样的 |
|---|---|---|
| 你们如何定义正常运行时间? | 防止仅基于心跳信号的定义掩盖真实的充电故障 | 可用性与可用充电挂钩,而不仅仅是连接 |
| 正常运行时间是按充电桩、连接器还是站点衡量的? | 避免掩盖部分中断的平均化处理 | 按资产和角色进行细粒度报告 |
| 哪些事件被排除在SLA之外? | 揭示有多少风险留给了买家 | 狭窄的排除范围,并有清晰的证据规则 |
| 你们基于严重性的响应和恢复目标是什么? | 将SLA与业务关键恢复联系起来 | 针对关键和非关键故障的单独工作流程 |
| 谁负责硬件、后端、固件和第三方集成? | 减少复杂事件中的责任推诿 | 清晰的责任矩阵和升级路径 |
| 更新是如何分阶段部署和回滚的? | 防止自我造成的停机 | 受控的发布流程,并具备回滚纪律 |
| 哪些运营KPI支持正常运行时间声明? | 在单一百分比之外增加会话级别的可见性 | 会话成功率、MTTR、重复故障和中断原因追踪 |
| 在续约或迁移期间,买家可以导出哪些数据? | 保留可审计性和未来的控制权 | 明确的访问、保留和交接义务 |
| 如果目标被重复未达标,适用什么补救措施? | 使合同条款与运营风险保持一致 | 有意义的积分,加上升级、报告或退出权 |
实用总结
充电桩正常运行时间SLA的价值远不止一个标题百分比。对于买家来说,真正的问题是供应商的承诺是否反映了充电桩的可用性、事件响应纪律、软件问责制以及站点层面故障的运营后果。
最好的合同清晰定义正常运行时间,透明地衡量它,谨慎限制排除条款,并将服务承诺与充电桩关键性挂钩。它们还将更新、互操作性、数据访问和升级工作流程视为服务绩效的一部分,而不是次要话题。
在与任何供应商签约前,买家应将讨论从表面的SLA数字推进到可靠性如何实现的机制层面。正是在那里,采购风险才能转化为运营清晰度。


