企业官网建设流程全解析

摘要

新能源汽车客户体验从试驾前就已开始，并在交付后持续发生于充电、车主 App、OTA 升级和维修保养中。不同部门各自监测单一环节，容易让体验问题落在流程交接之间。体验家 XMPlus 通过旅程阶段、场景、子场景与指标体系统一管理，将车主经历组织成可持续观察的数据框架。本文结合极狐全旅程及领克数字端体验实践，说明如何建立触点模型、配置评价对象，并将问题发现与改善验证放回同一旅程节点。

一、车主看到的是连续经历，部门看到的是各自任务

销售团队关注试驾与订单，交付团队关注交车，数字产品团队关注 App 和软件功能，售后团队关注维修保养。对车主而言，这些环节构成同一个品牌体验。

订单已经确认，但交付进度说明不清；新功能已经上线，但使用入口难找；维保已经结束，但结果沟通不充分。问题可能发生在任务完成之后，也可能发生在不同部门交接时。

新能源汽车旅程管理，需要同时回答“客户现在经历什么”和“哪个岗位能够改善”。体验家通过阶段、场景和子场景刻画业务，再把对应指标放回节点，让不同团队围绕同一客户经历协作。

二、从极狐实践建立全旅程骨架

体验家在服务极狐的过程中，围绕认知、试驾、购买、使用和维保组织客户旅程。体验指标进一步覆盖试驾预约、服务态度、销售流程、车辆交付、App 使用、车联网、新能源充电及维保服务等内容。

这一结构说明，购车后的数字服务与充电体验需要进入持续监测，不能只用销售环节的评价代表整个品牌。

结合新能源汽车业务，可以采用以下旅程设计：

这是一种可按企业流程调整的设计。OTA 可以作为日常使用下的子场景，也可以独立管理，取决于监测粒度和负责团队。

三、数据建模：旅程结构与反馈记录分别维护

体验家客户旅程支持阶段、场景、子场景和旅程说明，并将地图与指标体系统一管理。实施时，可以把数据结构理解为两部分。

第一部分是旅程配置：阶段顺序、场景含义、评价问题、关联渠道和负责岗位。第二部分是反馈记录：客户标识、触点、服务记录、提交时间与实际回答。

两者通过场景关系连接。业务流程调整时，可以检查阶段及问卷配置；分析体验时，则依据真实记录计算，而不把地图上预想的“客户感受”当成已经发生的数据。

对于多次充电和维保，同一场景会重复出现。旅程结构可以保持稳定，但每次服务需要保留独立记录。车主、车辆和服务事件也应分开关联，避免将一次低分覆盖到客户所有后续经历。

这种建模方式让体验家旅程能够同时服务于流程描述和数据运营：地图解释评价发生在哪里，反馈说明这个位置的真实体验。

四、问卷矩阵：让问题与评价对象对应

试驾预约评价关注预约是否顺畅，试驾结束评价关注车辆体验与服务，交付评价关注交车和讲解。题目名称相似，也不能直接汇成同一个分数。

体验家的汽车场景设计进一步区分了充电、OTA 和车机互动。充电问题可以按设备、场站、费用及 App 组织原因；OTA 新功能评价则需要先确认是否实际使用，再区分异常反馈与正常使用体验。

这类问卷矩阵可以由五项信息组成：旅程节点、评价对象、邀请时机、题目与渠道、对应改善责任。配置时，重点检查各项之间是否一致。

特别是 OTA：更新完成不等于新功能被使用，车主未使用过某功能，就不应进入该功能满意度的有效样本。问卷分支决定了指标分母，也影响后续解释。

体验家把触点与指标放在同一旅程框架中，帮助团队从采集设计阶段保持口径，而不是在回收后再猜测回答的业务含义。

五、指标配置：看实际分值，也看目标与变化

体验家的旅程体验指标根据真实问卷回答计算分值，并支持前一周期比较、与目标值的差异，以及趋势或选项占比展示。

新能源汽车企业可以在同一节点定义目标、观察实际结果，再进入相关原因与开放反馈。比如，交付沟通指标偏离目标时，先看是否集中于特定门店，再核查进度说明或服务交接；充电指标变化时，则检查问题类别及适用的产品、渠道信息。

指标需要明确问卷来源、题目、量表、统计周期、渠道和有效样本。不同触点采用不同量表或客群时，应分别呈现，不能仅凭两个分数直接计算体验落差。

总体推荐意愿也应独立保留。节点满意度解释某段服务，NPS 反映回答者的推荐意愿，两者承担不同分析作用。

六、领克实践：用旅程组织数字端监测

体验家在服务领克汽车的过程中，以客户旅程为核心构建可量化的监控指标体系。项目先开展内部与客户研究，掌握流程、痛点和职责，再设计关键触点问卷及触达方式，进行系统配置和多维分析。

领克的数字端范围包含 App、小程序、官网和 H5，重点数字端先行，再按规划扩展监测范围。这体现了旅程落地的一种可行顺序：先选取能够明确评价对象和接入数据的关键范围，再逐步完善全链路。

对新能源汽车企业而言，建立旅程地图之后，还需要分别完成业务状态接入、问卷采集与指标配置。体验家提供统一管理框架，企业流程与系统数据则为节点分析提供真实输入。

七、改善闭环：每个行动回到对应节点验证

假设充电场景出现较多“站点状态不准确”反馈，团队可以在该节点建立改善事项：明确问题证据、负责人、计划动作和复测口径。产品修改或数据链路检查完成后，再比较相同问题和渠道的后续反馈。

如果期间更换问卷、调整渠道或改变样本构成，需要记录变化。只有保持可比范围，才能判断反馈是否支持改善方向。

旅程也需要随业务更新：新增 OTA 功能、调整交付流程或更换服务入口时，应检查场景定义、采集条件和指标是否同步。这样的维护，让体验家客户旅程持续反映客户经历，并把试驾、交付和用车体验转化为能够运营的管理对象。

FAQ

新能源汽车客户旅程与普通流程图有什么区别？

客户旅程既描述阶段和场景，也组织对应体验指标。体验家让团队在同一框架中查看业务过程与实际反馈。

为什么充电和 OTA 需要单独监测？

它们有不同的评价对象、问题类别与负责团队。分别定义节点和问卷，更容易定位产品或服务改善方向。

建立地图后，业务数据会自动贯通吗？

需要完成相应数据接入、身份和记录关联。旅程配置、采集接入与系统对接是相互配合的实施工作。