保险业务平台的指标体系：从询价到投保，如何拆解业务流程

一个保险业务平台，每天可能产生很多次查询、询价、报价和投保操作。页面访问量上升，按钮点击次数增加，看起来都很热闹。但这些变化，是否真的带来了更多有效业务？

另一种情况更常见：总保费下降了，团队很快列出一串可能的原因——流量少了、报价慢了、产品不合适、投保流程出了问题。每一种解释似乎都有道理，却很难判断应该先查哪一个。

指标体系的作用，就是把这些模糊的问题拆开。先看业务结果，再沿着流程定位变化，最后找到需要验证的原因和可以采取的行动。

这篇文章以保险业务平台为例，从一笔业务的经历出发，逐步搭建一套能解释问题的指标体系。讨论范围主要是产品运营、询价与投保流程；保险公司的整体经营、偿付能力和人员绩效，需要另行建立分析框架。

一、先定义业务目标，再决定看哪些指标

在罗列指标之前，我会先问三个问题：平台最终要产生什么结果？用户需要经过哪些环节？哪些问题会阻碍业务完成？

对应到这个场景，可以把指标分成三个相互连接的层次。

层次	要回答的问题	代表指标
业务结果	最后完成了多少有效业务？	成功出单数、总保费、件均保费
流程效率	业务在哪一步推进，在哪一步停下？	各阶段转化率、等待时长、完成时长
使用与质量	有多少人在使用，是否顺利完成操作？	功能使用人数、活跃与留存、失败率、报错原因

渠道、产品、端、出单模式和用户类型，则是拆解这些指标的维度。例如，“H5”本身是一个维度，“H5 投保提交成功率”才是一个具体指标。

这三个层次需要一起看。只有总保费，我们知道结果发生了变化，却不知道变化在哪里；只有点击量，我们知道用户做了什么，却不知道操作是否产生了有效业务。

实际看板可以先保留少数结果指标，再用流程和质量指标解释它们。这样，指标之间有关系，阅读顺序也有重点。

二、用一条主流程，把分散的页面连接起来

先把页面名称放到一边，观察一笔业务从开始到结束经历了什么。

这是一条用于分析的主线。实际产品可能跳过部分节点，也可能增加人工沟通、补充资料或支付等步骤。最终“成功出单”采用哪个业务状态，需要与实际系统确认，不能仅凭前端页面名称判断。

操作发生，不代表业务已经完成

同一个环节，至少可以观察三种不同的状态。

状态	例子	适合回答的问题
操作意图	点击“申请投保”	用户有没有尝试继续？
操作完成	后端确认投保申请提交成功	提交是否真正完成？
业务结果	达到约定的保单签发成功状态	是否形成了有效业务？

这三种状态不能互相替代。用户可能点击多次，也可能在点击后遇到校验失败；申请提交成功之后，业务还可能处于后续处理阶段。

因此，按钮点击适合分析交互，提交结果适合分析操作完成率，最终业务状态适合统计有效业务。保单数和保费规模，应从相应的业务记录获得。

页面路径可以不同，分析节点需要可比较

WEB 与 H5、常规询价与协议出单、新保与续保，可能使用不同页面和入口。如果把每一种点击路径都写成独立漏斗，很快就会出现大量无法比较的报表。

更容易理解的做法是：先定义共同的业务节点，再把具体路径映射到这些节点。

实际路径	分析时的处理方式
常规产品询价、常用产品入口	保留入口差异，统一确认询价提交成功的节点
复制询价	区分原业务与新流程；同一流程内的修改和重试另行记录
协议出单	保留协议路径标识，确认实际经过哪些节点
新保、续保	分开比较业务类型，再分析各自的阶段转化
人工报价、自动报价	区分报价方式，分别观察成功率和等待时长

映射的目的，是让读者能够回答：“哪一类业务，在同一个环节表现不同？”

如果某条路径没有经过一个节点，就不应直接套用包含该节点的漏斗。需要比较时，应选择双方都经过的节点，或者分别展示路径。

三、沿着流程，逐步解释每一组指标

下面每个环节都围绕一个问题展开：用户要做什么？我们怎样判断它是否完成？出现变化时，下一步查什么？

1. 产品查询：用户是否找到需要的入口？

这个阶段先看功能是否被使用。

• 操作次数（PV）：某个页面或按钮发生了多少次操作。页面访问 PV 与按钮点击 PV 应分别命名。
• 使用人数（UV）：发生相应操作的去重用户数，需要明确使用平台账号、访客标识还是其他身份。
• 功能使用率：在具备使用资格的活跃账号中，使用该功能的账号占比。
• 按钮点击率：在看到该按钮的用户中，实际点击的用户占比。这一口径需要可靠的按钮曝光记录。

功能使用率与按钮点击率的分母不同。前者更接近“这个功能覆盖了多少使用者”，后者更接近“看到入口之后，有多少人选择点击”。

同一个“查询”按钮出现在不同页面时，还应带上页面或位置维度。否则，把多个入口合并之后，很难判断用户究竟在哪里找到了功能。

分享次数、分享人数也可以保留，但只有在能够追踪后续业务时，才能进一步判断分享是否带来了询价或投保。

2. 询价：用户能否把需求完整提交？

点击“发起询价”，并不意味着已经有一笔有效询价。可以继续观察：进入录入页面、开始填写、提交成功，分别有多少业务流程到达。

这里建议关注三个指标：

• 询价提交成功流程数：完成询价提交的去重业务流程数。
• 询价录入完成率：进入录入阶段的同一批流程中，在约定观察窗口内完成提交的占比。
• 询价录入耗时：从进入录入阶段到首次成功提交的时长。

如果进入录入页面的流程数稳定，但完成率下降，就可以继续检查必填项、表单校验、资料上传和接口结果。此时先增加入口流量，未必能解决问题。

3. 报价：已提交的询价能否得到及时回应？

询价之后，需要观察业务是否获得了可用报价。

获得报价率可以定义为：同一批有效询价流程中，在约定窗口内获得至少一次可用报价的流程占比。

一笔询价可能产生多个报价版本，也可能涉及多个报价方。做流程漏斗时，应按“是否获得报价”统计流程；研究报价工作量时，可以另外统计报价条数。两者的统计对象不同。

等待时长也很有用，但只看平均值可能掩盖少数等待很久的业务。可以同时展示中位数 P50 和 P90：前者观察典型等待情况，后者观察较慢的一部分业务。

如果等待时长只统计已经获得报价的流程，还应另列待报价流程数和当前等待时长。否则，仍在等待的慢业务被排除后，报表可能显得比实际情况更快。

人工报价与自动报价应分别展示。它们面对的业务复杂度可能不同，差异需要结合产品、渠道和资料完整度解释。

4. 转投保与提交：获得报价之后，业务是否继续推进？

这个阶段可以拆成两个问题。

第一个问题是：获得报价之后，有多少流程进入转投保？它帮助观察报价后的推进情况，但价格、保障内容、客户决策和业务跟进都可能影响这个指标。

第二个问题是：进入转投保之后，有多少流程完成投保提交？它更接近资料填写和提交环节的完成情况。

以第二个问题为例，可以把口径写成：

投保提交成功率 = 同一批进入转投保阶段的业务流程中，在观察窗口内完成投保提交的流程数 ÷ 该批进入转投保阶段的流程数。

分子来自分母中的同一批流程。如果只是用“今天提交成功的单数”除以“今天进入转投保的单数”，两者可能并不对应：今天提交成功的业务，也许昨天就已经进入了这个阶段。

因此，运营日报可以展示每日各节点的发生量，流程漏斗则需要追踪同一批业务。两种报表都有价值，但回答的问题不同。

5. 最终业务结果：到底形成了多少有效业务？

到了结果层，需要回到已经确认的业务状态。

本文先采用一个用于说明分析方法的口径：在指定签发时间范围内，统计达到成功签发状态且按约定排除作废记录的保单，并使用这些保单在同一版本规则下记载的保费。真实报表应确认状态、版本、时间和金额规则；退保、批改、实收金额等可以另外建立对应指标。

在保单集合和金额口径一致时，有一个很实用的拆解关系：

总保费 = 保单数 × 件均保费。

总保费下降，首先可以看是保单数下降，还是件均保费下降，或者两者同时发生变化。

• 保单数下降：继续检查业务来源、流程转化和最终完成情况。
• 件均保费下降：继续检查产品组合、保额、业务类型和价格等维度。

“人均保费”还需要明确这里的“人”是谁。按平台操作账号、投保人或被保险人计算，会得到不同含义的结果。不要只写一个“人均”就让读者自行猜测。

总保额、件均保额可以作为补充，但跨险种比较前应确认保额是否具有可比含义。数字能够相加，并不意味着业务上适合直接比较。

四、把用户与体验指标放回业务语境

流程之外，用户规模和使用体验可以帮助解释变化，但需要先确定分析对象。

平台操作用户，与投保人不是同一个概念

平台操作用户可能是业务人员、合作渠道人员或其他操作账号；投保人和被保险人则是业务中的角色。具体关系需要根据实际平台确认。

如果把这些身份混在一起，活跃、留存、人均保费等指标就容易失去含义。

对于平台操作账号，可以观察新增、活跃和留存。例如，把“每周至少完成一次约定核心业务操作的去重账号数”定义为业务活跃账号数，就比只有登录行为的活跃指标更贴近流程使用。

这个定义是设计建议，核心操作应由实际业务目标决定。新增账号、首次业务使用账号也应分别命名。

留存可以从首次完成核心操作的账号开始分组，观察它们在后续指定周是否再次完成核心操作。起点、复访行为和时间窗口都应写清楚，而“粘性”也需要落成明确的频次或活跃比例。

画像用于解释差异，偏好需要与曝光一起看

投保人、被保险人、险种和产品特征，可以用于分组分析。它们帮助回答：“变化集中在哪一类业务？”

用户行为偏好也可以观察，但点击多未必就代表偏好强。某个产品可能只是曝光更多、位置更靠前，或者默认被选中。解释点击差异时，应同时检查曝光和入口条件。

失败次数之外，还需要失败率与恢复情况

失败次数增加，可能是问题变多，也可能只是业务量增长。因此，需要同时看失败涉及的流程数和相应尝试流程数。

重试也应单独记录：同一笔业务失败五次、最后成功，与五笔业务各失败一次、最终全部放弃，代表不同的使用体验。

一个较清楚的展示方式是同时保留：

• 失败请求次数，用于观察技术故障的发生量。
• 至少发生一次失败的去重流程数，用于观察受影响的业务范围。
• 失败后在观察窗口内恢复成功的流程占比，用于观察问题能否被解决。

报错原因可以进一步分为资料校验、认证、权限、接口超时等类别，但分类应以实际错误记录为基础。注册登录、实名认证和线上服务办理，可以各自建立流程，再与投保主线关联分析。

理赔金额和理赔完成情况则属于另一个业务闭环。附件中的这部分仍是待定内容，本文先不把它合并进投保漏斗。

五、统计口径决定了指标能否被信任

指标名称看起来相同，不代表计算方式相同。为了让团队能够复用，建议为核心指标保留一张简洁的指标卡片。

下面仍以投保提交成功率为例。

项目	建议写清的内容
业务问题	进入转投保阶段后，业务能否顺利提交？
统计对象	去重业务流程，不是按钮点击次数或用户人数
分母	在规定起始时间范围内首次进入转投保阶段的流程
分子	分母中的流程，在规定观察窗口内获得后端提交成功结果
去重与版本	同一流程重试如何处理；重新发起的业务如何识别
时间规则	统一时区；同时保留进入阶段和成功提交的时间
数据来源	业务状态或服务端成功事件；前端埋点用于补充行为
拆解维度	产品、渠道、端、出单模式、报价方式等
未完成业务	区分仍在处理中、明确失败和超出观察窗口

先把记录连接起来，再计算漏斗

要追踪一笔业务，最好有能够贯穿阶段的分析流程标识，并维护它与询价、报价、投保申请和保单的对应关系。这是数据设计建议，并不意味着现有系统已经具备这些字段。

只靠一个用户账号，无法区分该用户同时操作的多笔业务；只靠页面时间，也很难可靠地连接修改、重试和跨端操作。

如果一笔询价最终对应多张保单，流程成功数和保单张数需要分别统计。不能直接用保单张数除以询价流程数，把它称为普通的流程转化率。

给每一批业务足够的观察时间

假设约定观察进入某阶段后的七天内是否完成后续动作，刚进入阶段一天的业务，尚未得到完整观察。把它直接与已经观察满七天的业务比较，会低估新一批业务的完成率。

可以分别展示“已完成观察窗口的批次”和“仍在观察中的批次”。七天只是本文示例，真实窗口应根据业务节奏确定；超过窗口才完成的业务也可以单独追踪。

未进入下一步的业务，不一定已经失败。等待处理、主动放弃、技术失败和超时未完成，应尽可能分开记录。

六、用一个保费下降的例子，走完分析过程

前面的指标如何一起使用？下面用一个简化案例演示。

以下全部为假设数据，不代表真实经营结果。 两批业务都从询价提交成功开始追踪，已经获得相同且完整的观察时间；示例假设每条流程最多签发一张保单，金额使用同一币种，两批业务采用相同的保单与保费统计规则。

表中的保单与保费也归属于这两批询价流程，统计的是各自观察窗口内的结果，而不是按签发日另取的全平台总量。

节点或结果	上一批业务	当前批业务
询价提交成功流程数	1,000	1,000
获得可用报价流程数	800	800
进入转投保流程数	560	560
投保提交成功流程数	448	336
成功签发保单数	400	300
件均保费	2,000 元	2,000 元
总保费	800,000 元	600,000 元

第一步：先确认结果是不是可比较

在解释下降之前，先检查两批业务的统计规则、观察时间和金额口径是否一致，有没有数据延迟、事件漏报或业务状态调整。

如果口径发生变化，应该先解释变化，不能把它直接当作业务变差。

第二步：把总保费拆成保单数和件均保费

这里的件均保费仍然是 2,000 元，保单数从 400 张下降到 300 张，所以总保费从 80 万元下降到 60 万元，降幅为 25%。

在这个示例中，下降来自保单数变化。接下来优先检查业务完成的流程，而不是先去解释单张保单的金额。

第三步：找到变化最明显的阶段

询价提交成功、获得报价、进入转投保的流程数都没有变化。进入转投保后，提交成功率却从：

448 ÷ 560 = 80%

下降到：

336 ÷ 560 = 60%

下降了 20 个百分点。这里应使用“百分点”描述两个百分比的差值。

投保提交成功到签发的比例，两批业务都约为 89.3%。在这组简化数据中，最值得优先排查的是转投保到提交成功的环节。

这个结论定位了变化所在的阶段，还没有确定原因。

第四步：把总体变化拆到具体业务群体

继续按端、渠道、产品和出单模式拆解，观察下降是否集中在某一类业务。还应检查各群体占比是否变化：总体转化率下降，可能来自某个群体表现变差，也可能来自群体组合改变。

如果下降主要集中在 H5 的某种出单路径，就可以进一步检查那条路径的资料填写、认证、接口结果和重试情况。

第五步：提出解释，并安排验证

假设排查时又发现某一步资料校验失败增加，同时失败后的恢复成功率下降，就可以提出一个待验证的解释：资料填写或校验环节可能阻碍了投保提交。

接下来，应核对该批业务的错误记录、表单版本和状态衔接，确认这些异常是否发生在同一批受影响流程上。修复或调整之后，继续观察完整业务批次的提交成功率、耗时和失败率，并关注后续业务质量。

到这里，指标才真正连接到行动：从“保费下降”这个笼统问题，走到一个可以定位、核对和持续观察的流程环节。

把这套方法用于下一次分析

这套框架可以按照下面的顺序使用：

1. 明确业务目标和最终成功状态。
2. 画出主流程，标记不同路径经过的节点。
3. 在关键节点定义数量、转化率和耗时。
4. 写清身份、去重、时间窗口和数据来源。
5. 用产品、渠道、端和业务类型拆解变化。
6. 结合失败原因与恢复情况，提出并验证解释。

对于保险业务平台，这条主线是询价、报价、转投保、提交和最终业务结果。换成汽车销售或商品购买，具体节点会改变，但“结果—流程—原因—行动”的分析顺序仍然可以复用。

一个好的指标体系，应该让读者知道先看什么、变化后查什么，以及什么证据能够支持下一步行动。

---

素材说明：示例数据为假设值。实际应用时，需要确认对应系统的业务定义与数据口径。