Lead
Online Application 尚未提交
eLead Offer 尚未确认
← 全部项目
IGNITE / LEAD MANAGEMENT / CASE STUDY 02
将线下人工询价接入 Ignite
Ignite 是面向保险代理人的数字化销售平台。原有购买流程主要覆盖可以直接在线报价的产品，但并不是所有保险需求都能通过标准化表单立即获得价格。
通过 eLead，我们把原本在线下完成的人工询价接入 Ignite，让 Agent 可以提交需求、接收保险公司的方案，并继续推进付款和出单。
设计挑战
怎样把一套依赖多人线下协作、状态复杂且充满例外的询价流程纳入 Ignite，同时不把这些复杂度全部留给 Agent？
01 / SERVICE CONTEXT
即时报价覆盖不了的保险需求
Employee Benefit、Marine 和高保额 Property 等需求，通常需要根据客户的具体风险向保险公司单独询价。即使平台已经提供同类线上产品，Agent 也可能找不到适合客户的方案。
过去，Agent 在线下提交资料，Placement 团队联系一家或多家保险公司，沟通承保条件和价格，再把方案反馈给 Agent。一项需求可能经历多轮资料补充和协商，也可能同时收到多个不同方案。Placement 和 Admin 还依赖 Excel 台账记录和跟进处理进度。
一条 Lead 代表一项待解决的保险需求；一个 Offer 代表某家保险公司针对这项需求提供的方案。专业协商可以在线下继续，但处理结果需要回到系统，成为下一步操作的依据。
服务链路
- 提交需求
- 人工询价
- 返回多个 Offer
- 选择方案
- 推进交易
Agent 负责提交需求和确认方案；Placement 团队负责询价和整理 Offer；后续审核、付款和出单由相应的 Admin 角色接手。首页通过 Personal Line / Commercial Line 提供两种入口，分别承接线上报价与人工询价。两条路径获取价格的方式不同，但 Agent 最终都需要在 Ignite 中找到业务、理解进展并完成下一步。设计 eLead 时，我需要判断哪些现有规则可以沿用，哪些人工询价的差异必须保留。
02 / BUSINESS ALIGNMENT
用 Online 的业务节点界定 eLead 的差异
在设计页面前，我先寻找两条路径可以比较的业务节点。Ignite 已有的 Online 状态图覆盖报价、申请、付款和出单，但其中混合了不同业务对象、用户动作与处理条件。直接按状态名称对照 eLead，容易把名称相近、含义不同的动作当成同一步。
我以业务对象、触发动作、处理角色、进入条件和下一步操作作为对照维度，借助 AI 将 Online 状态图整理成可追溯的结构化材料。然后结合 eLead 的人工询价流程，判断需求何时开始被跟进、方案何时确定，以及交易何时能够继续推进。
| 共同业务含义 | Online | eLead |
|---|---|---|
| 发起一笔可以继续跟进的需求 | 提交 Quote | 提交 Lead |
| 确认方案，进入后续交易 | 提交 Application | Agent 确认一个 Offer |
| 发生成功付款 | Payment Success | 非分期付款成功；分期某一期 Paid，但整体可能仍未付清 |
Online 提交 Application 时，价格已经计算完成；eLead 提交 Lead 时还没有价格，需要等待工作人员询价。只有 Offer 返回并由 Agent 确认后，方案和保费才确定。因此，确认 Offer 对应提交 Application，而非按“提交”二字对应。
这些关系用于比较业务阶段，不意味着两条路径使用相同的状态名称或审核、付款规则。页面如何按进展分类，还要结合各自的触发条件判断。AI 负责把现有流程整理成便于比较的材料；我负责判断业务含义、保留必要差异，并把缺少依据的问题带回与 PM 对齐。
03 / MODEL THE COMPLEXITY
让整体进展与子对象状态保持一致
Online 与 eLead 的共同节点建立了基本主线，但不足以描述真实交易。一条 Lead 下可能有多个各自进展的 Offer；分期付款时，Policy 下的每期付款也会独立变化。我需要判断整体记录应表达什么、子对象的变化何时影响整体，以及 Agent 接下来能做什么。
MODEL 01 / LEAD & OFFER
一条 Lead，多个独立进展的 Offer
一条 Lead 表达整项保险需求的进展，Offer 则保留各家保险公司方案的独立状态。Placement 可能同时推进多个 Offer，因此 Lead 不能直接采用其中某一个 Offer 的状态；它需要概括这项需求是否正在被处理，以及 Agent 当前是否有方案可审核、是否需要采取行动。
Offer 的变化对 Lead 的影响并不相同。有方案可审核时，Lead 应让 Agent 发现这个机会；Agent 确认其中一个 Offer 后，这一不可逆的选择决定了后续交易，其他 Offer 随之失效。设计的关键是识别哪些子对象变化会改变整项需求的进展或下一步操作，而不是把所有 Offer 状态都呈现在 Lead 上。
MODEL 02 / PAYMENT
整体付款与单期付款需要分层
Policy 表达整笔业务的付款进展。没有分期时，一笔付款的结果可以直接反映在 Policy 上；加入分期后，每期付款独立变化，Policy 则需要汇总整笔业务是否仍有待付款项。
因此，某一期付款成功不能让整笔业务显示为已付清。列表呈现 Policy 的整体进展，帮助 Agent 判断这笔业务是否还需要处理；详情页再展开各期金额、到期日、付款结果和对应佣金，让 Agent 找到下一笔需要处理的付款。这里与 Lead–Offer 遵循同一原则：父级说明整笔业务的进展，子级保留各自的真实状态；子级变化只有在影响整体判断或下一步行动时，才改变父级的表达。
VALIDATION / AI CHECK
用 AI 检查跨角色流程
eLead 的 Lead、Offer 和 Payment 由不同角色异步推进。单独的状态图可以解释各自的流转，却无法保证事件交错后，Agent 看到的整体进展、负责人和可执行操作仍与真实交易一致。为在页面定稿前检查这一风险，我将状态条件、角色分工和页面操作交给 AI 推演，再与 PM 和工程核对边界情境，将成立的问题转化为设计约束。
| 检查情境 | 我的设计约束 |
|---|---|
| 并行 Offer：一个方案已可审核，其他方案仍在处理中 | Lead 提示可处理的方案；确认一个 Offer 后，其他 Offer 自动失效，选择入口随之关闭 |
| 付款延迟：付款已提交，结果尚未返回，页面仍显示可再次支付 | 增加“处理中”反馈，控制重复付款入口，并明确结果如何更新 |
| 补件交接：保险公司要求补资料，Agent 与 Placement 看到不同进度，责任悬空 | 同步暂停原因、当前负责人和恢复条件，让待办回到正确角色 |
04 / SALES EXPERIENCE
复杂模型最终不应该成为用户的学习成本
准确的底层模型是设计的前提，但 Agent 不应该先学会 Lead、Offer、Payment 和 Policy 的内部关系，才能找到业务和下一步操作。原有 Sales 页面按照 Quote 和 Policy 分类，两类记录内部已包含大量状态；加入 Lead、Offer 和分期后，如果继续增加对象分类，查找业务就会越来越依赖对系统结构的理解。
我找到两条路径可以共用的判断方式：Online 提交 Application / eLead 确认 Offer，代表方案已确认、业务进入后续交易；此后还要看 Agent 是否仍有需要完成的操作。分期首次付款只是单期状态的变化，不代表整笔业务已经结束。
因此，我提出按用户能够感知的进展，将原来的 Quote / Policy 分类重组为 Lead / In Progress / Sales，并与 PM 对齐：
In Progress
Online Application 已提交，Agent 仍有待完成的操作
eLead Offer 已确认，Agent 仍有待完成的操作
分期部分已付但仍待付款，也留在这里
Sales
Online / eLead Agent 一侧的必要操作已完成，当前无待办
后续 Admin 处理和出单状态仍可查看
这里的 Lead / In Progress / Sales 是页面阶段，与底层的 Lead 对象或 Lead In Progress 状态属于不同层级。页面阶段帮助 Agent 找到业务，记录状态解释当前发生什么，下一步操作指向该如何继续。
一次成功付款不能单独决定页面阶段：只要 Agent 仍需完成后续付款，就留在 In Progress。进入 Sales 时，Agent 一侧已无待办，但 Admin 仍可能继续处理或出单。新的结构保留底层必要的业务差异，让 Agent 按进展找到记录、理解当前情况并继续处理。我没有减少业务本身的复杂度，而是把复杂度放在了合适的层级。
05 / RESULT
人工询价进入 Ignite 的日常运营
eLead 已上线。Placement 和 Admin 原先依赖 Excel 台账记录和跟进的人工询价，转入 Ignite 的业务流程。必要的专业询价与协商仍可在线下完成，但需求、返回的方案和处理进展会回到同一条 Lead，让不同角色在同一份业务记录上接续工作。
线下协作与平台记录断开
需求离开线上流程：询价、方案与交接分散在系统之外。
线下处理，线上保持上下文
资料、方案和处理结果在每次交接后回到同一条 Lead，Agent 可以继续推进。
REFLECTION
把复杂业务整理成团队和用户都能理解的结构
这个项目让我更清楚地认识到，复杂业务中的设计工作不只发生在界面上。我的核心贡献，是把分散在不同角色和线下流程中的业务知识，整理成团队可以对齐、系统可以实现、用户可以理解的结构。
复杂业务的难点不只是梳理完整的状态，还要在多方案并行、付款等待和补件交接时，让每个角色都清楚发生了什么、谁负责处理，以及流程如何继续。