From embedded protection to insurance platform capability 从嵌入式保障体验到保险平台能力
A UX case study spanning two products: buyer-paid product protection and seller-paid shipping protection, together with the shared eligibility, policy, claim, and partner states behind them. 面向 TikTok Shop 与 PIPO 国际支付体系的保险体验建设。项目包含两条独立业务线：To C 是买家付费的商品保障，To B 是卖家付费的物流保障，并分别承接购买、投保、保单与理赔体验。
这个项目包含两条独立业务线：To C 商品保障由买家在结账时自愿购买，To B 物流保障由卖家为符合条件的包裹付费。我的工作既覆盖两端不同的购买与服务旅程，也需要统一准入、交易、保单、理赔和合作方状态，确保前台信息与后台处理一致。
两条业务线不能共用同一条前台旅程。商品保障要让买家在付款前理解保障范围和价格；物流保障要让卖家判断成本与适用订单，并在风险发生后减少重复举证。它们只在平台层共享订单、保单、理赔状态与合作方协作能力。
Paid Gross Written Premium（GWP）用于衡量已支付保单的业务规模，但它不是体验质量指标。渗透率和采纳率用于判断问题来自产品覆盖、前台触达还是用户决策；上线后还要结合 NPS、客服咨询和理赔质量，避免只增加保费而损害售后体验。
已支付保单的应付保费总额，统一折算为 USD。它把产品覆盖、用户购买、支付成功和保单出单串成一个业务结果指标。
保险渗透率衡量已售保单数量与已支付电商主订单数量之间的关系，用来判断保险能力在整体订单大盘中的触达程度。
保险采纳率把分母收窄到符合保险条件的品类订单，用来判断用户在“可购买保险”场景中的真实接受度。
如果用户不理解保障范围，采纳率会先受影响。因此结账和订单页需要把权益、边界和理赔入口讲清楚。
渗透率不仅是前台问题，也取决于类目准入、机构覆盖和产品配置能力，设计需要让准入状态可解释。
GWP 增长必须和保单理解、理赔完成率和售后评价一起看，避免只追求投保规模而牺牲售后信任。
商品损坏会影响买家是否愿意购买高风险品类；包裹丢失、破损和未收到则会增加卖家的履约与售后成本。平台因此提供两种保险产品：商品保障帮助买家理解并选择额外保障，物流保障帮助卖家管理特定包裹风险。两者的付费方、触发条件和服务流程不同。
保险把“坏了怎么办、丢了怎么办、延迟怎么办”变成可被理解的保障承诺，减少购买犹豫。
主要竞对已将保险作为基础服务能力。保险选项会影响转化、复购和平台可信度。
物流险不是单纯赔付工具，而是把售后争议转化为可追踪、可自动化处理的协作机制。
围绕商品质量、损坏、使用风险建立购买信心。前台表达需要让买家在下单前理解权益，后台能力需要支持类目、权益和交易之间的灵活匹配。
围绕履约风险提供确定性，重点不只是“赔付”，而是通过自动化理赔减少买卖双方沟通成本，让商家把精力放回服务升级。
商品保障与物流保障面向不同付费方，但都依赖统一的准入、交易、保单、理赔和合作方协作能力。平台层负责让前台承诺与后台执行保持一致。
两条业务线的付费关系不同：To C 由买家在交易中选择并支付保费；To B 由卖家为物流保障承担服务费。平台负责交易与体验承接，broker、insurer 或第三方服务商完成承保及理赔。页面不展示敏感分成比例，只保留影响用户决策和责任理解的结构。
我整合了 SEA 与 US 竞品分析、体验问题诊断和多市场全链路截图三类证据，不只比较购买页长什么样，而是沿着购买、保单与理赔三个阶段追问：平台如何把保障讲清楚，又如何在售后兑现这份承诺。
Amazon 与 Walmart 在 PDP 只露出保障名称、期限和价格，不打断主商品决策；用户加购或展开后，再补充跌落、液损、故障、维修、客服和理赔方式。信息不是越多越可信，而是要在正确的时机回答正确的问题。
用户容易把电子险、延保与厂商保修混为一谈。US 竞品直接强调保障“超出厂商保修”，SEA 则把最高赔付、有效期和液损、盗抢等场景前置。更有效的心智模型是：保修解决产品本身的问题，保险承接用户使用中的意外。
多市场链路走查显示，保单入口、承保状态与理赔路径经常分散，部分流程还会跳转到保险公司网页，用户因此失去订单上下文。保单需要持续说明是否生效、保障多久、由谁承保；理赔则需要独立展示进度、材料、下一步和结果。
购买前，平台用稳定的信息顺序讲清“保什么、怎么赔、保多久、谁承保”；购买后，Policy 与 Claim 分别管理保障状态和理赔进度。这样既能跨市场复用，也能让前台承诺在后台被配置、履行和追踪。
以渐进式信息促进购买，并在订单内持续提供保单状态、理赔入口、处理进度和下一步。
用一致的保障字段支持投保决策；售后满足条件后自动触发理赔，商家只需查看状态，失败时再按原因恢复。
以 Paid GWP、Penetration、Adoption 衡量增长，并结合理赔率、赔付质量和纠纷率持续校准产品。
To C 的重点是渐进解释：购买前讲清保障范围、价格和生效条件，购买后把 Policy 与 Claim 分开追踪。To B 的重点是经营效率：用统一字段支持方案比较，并在满足条件后复用订单、物流与售后证据自动发起理赔。
买家关心“这份保障是否值得买、出问题后能否顺利获赔”；商家关心“为什么要投保、风险发生后平台是否会自动补偿”。设计需要分别回应双方诉求，同时让保障承诺在购买、履约和售后阶段保持一致。
C 端讲清权益与状态，B 端讲清成本并减少操作。关键权益、责任边界和理赔结果保持透明，便于买家做知情选择，也便于卖家判断保障是否适合自己的订单。
三者不是同一条用户旅程，而是通过订单、保单、理赔和证据状态连接。买家侧关注知情选择与售后进度，卖家侧关注投保成本与自动理赔，平台侧负责准入规则、责任边界和风险质量。
前台清晰表达保障权益，让买家看得懂、放心购买；商家端讲清保障成本，并把符合条件的售后事件自动转为理赔；平台再用 NPS、咨询量、Paid GWP、渗透率、采纳率与理赔质量 分别验证体验、增长和风险表现。
建设分为三个阶段：先定义买家和卖家的核心旅程与状态；再沉淀可复用的权益表达、入口和理赔框架，并按国家与合作机构做本地化；最后补齐营销、控赔与运营工具。
先识别买家与商家的关键问题，梳理从保障理解、投保决策到保单管理、理赔提交和结果追踪的完整旅程，并统一关键状态与责任表达。
沉淀可复用的权益表达、投保入口和理赔流程，再根据不同国家、险种和保险公司的规则进行本地化适配，让核心体验保持一致。
在核心旅程稳定后，再建设保险营销、控赔、卖家运营和自助服务工具，使团队能够持续配置产品、监控风险并处理异常。
对用户来说，保险不应该像一个突然出现的金融产品。它需要在商品、结账、订单和售后里以合适的信息密度出现：下单前说明保障价值，支付时给出清晰选择，购买后保留保单入口，出险时提供可理解的理赔进度。
根据类目和履约风险判断保障是否适用。
在不打断支付的前提下呈现权益、价格和边界。
订单页承接保单详情、机构信息和保障状态。
从售后问题进入 claim，并展示材料和处理进度。
页面表达避免制造焦虑，用清晰场景告诉用户保障何时生效、如何申请、预计会发生什么。
物流险和自动化理赔帮助商家减少售后纠纷，把复杂赔付流程从人工沟通中抽离出来。
投保、出单、理赔和售后状态需要被用户、商家和运营侧一致理解，支撑后续服务策略迭代。
由买家在购物链路中自主选择并支付保费，核心任务是讲清保障价值、选择状态、保单资格与理赔进度，帮助用户在付款前知情选择、出险后有明确预期。
这是一条由买家主动选择并支付保费的 Gadget protection 购买路径。保险信息不突然打断购物，而是随着购买意图逐层展开：PDP 先建立保障感知，Bottom Sheet 在用户主动查看时补充范围与规则，Checkout 再明确价格和选择状态，让买家在支付前完成知情选择。
在配送和退货信息下方露出 Gadget protection，用熟悉的服务语言告诉用户商品可获得保障，同时保持主购买任务的连续性。
用户点击后再展开保障范围、期限与 Learn more 入口，把详细说明放在兴趣发生之后，既回应疑问，也避免在 PDP 堆叠金融信息。
在商品卡片下方直接展示保障价格、覆盖范围和勾选状态，让保险与当前商品信息成组呈现，方便用户在支付前集中查看并调整选择。
三处触点对应不同的信息任务：PDP 回答“有保障吗”，Bottom Sheet 回答“具体保什么”，Checkout 回答“我是否选择、需要支付多少”。信息随购买意图逐步加深，既不打断交易，也让金融选择保持透明。
当用户在 Gadget protection 中点击 Learn more，会进入一组完整的保障详情页。页面使用稳定的三段式导航，将用户最关心的问题拆开回答：Benefits 解释能获得什么，How to claim 说明出险后怎么做，T&C 提供可查证的条款与责任边界。
用额外保障、可信承保方和便捷理赔建立价值认知，再通过对比表明确 Gadget protection 与厂商保修的覆盖差异，降低重复购买疑虑。
从 Orders 找到对应订单，进入 Gadget protection，再点击 Submit claim。页面同时提供保险公司的邮箱、电话和服务时间，让自助理赔与人工支持都可找到。
将平台保障条款、隐私政策与 Chubb 团体保单条款分开呈现，明确平台与承保方的责任来源，使用户在购买前能够核对关键规则。
三页分别回答“我能获得什么、出险后怎么做、需要同意哪些规则”。用分栏而非一页堆叠全部金融信息，让价值、行动和条款各自清晰，同时保持同一产品语境。
保险不是结账时的一次性选择。完成购买后，我让 Gadget protection 继续跟随对应商品出现在订单详情中，并根据订单阶段承接不同任务：刚下单时提供可找到的保障入口，订单完成后保留售后访问路径，进入保单页后再清楚解释当前状态与生效条件。
在订单状态和商品卡片下方保留 Gadget protection 入口，让用户刚完成支付就能确认已购买保障，并明确它属于哪一件商品。
交易完成后入口不随订单状态消失，仍与商品信息成组呈现。用户后续需要查看权益、确认保单或处理售后时，不必离开订单上下文重新寻找。
进入 Gadget protection 后，用生命周期进度说明保单正在处理，并明确订单完成后生效；商品、承保方、保费和订单编号集中展示，帮助用户核对保障关系。
订单页持续回答“我的保障在哪里”，保单页进一步回答“现在是什么状态、什么时候生效、保障对应什么商品”。入口、商品与状态保持关联，让保险承诺在支付完成后仍然可见、可查、可解释。
首版优先解决“状态缺失”的问题：订单进行中时保单尚未生效；进入 Protected 后才开放 Submit claim，并跳转至合作保险公司提交。用户返回 TikTok Shop 后，平台继续同步 Reviewing、Action required 与 Paid 等理赔结果；出单失败、订单取消与保障到期则作为保单退出状态。完整覆盖让链路先跑通，也暴露出保单生命周期与理赔进度耦合的问题，为后续迭代提供了明确基线。
明确告知保单将在订单完成后生效，不提前展示理赔按钮，避免用户在保障尚未成立时进入无效流程。
保单生效后突出 Submit claim，用户可前往第三方合作保险公司完成理赔提交，同时保留保单与商品上下文。
从合作方返回后告知用户理赔正在审核，并提供 Check claim status，减少跨平台提交后的不确定感。
审核被打回时说明需要额外材料，并给出邮件与客服联系方式，让用户知道去哪里补充、如何继续处理。
当保险经纪拒绝出单时，明确展示失败原因并提供退款详情入口，避免用户把失败误解为仍在等待。
订单被买家取消后，保单状态同步变为 Policy canceled，并显示取消原因与退款详情，保持交易和保障状态一致。
时间轴走到 Expired 后，保留起止日期与历史保单入口，让用户理解不再受保的原因并继续查阅记录。
在 Policy detail 中同时保留 Approved 与 Paid 记录，分别展示核准金额、赔付金额及对应时间，让用户明确理赔是否通过、款项是否已经发放。
第一版让每个节点同时回答“现在发生了什么”与“接下来能做什么”，解决链路断点；上线后再根据用户困惑，把保单资格与理赔进度拆成两套更直接的状态表达。
在保单与理赔状态跑通后，我重新审视用户首次理解保险的入口。迭代聚焦首屏信息密度、导航连贯性、理赔流程完整度和保障差异表达，让用户更快判断这项保障是否与自己相关、是否值得购买。
问题主视觉占比过大，影响购买判断的保障范围与价值被推迟到首屏之外。
迭代压缩 Banner 高度，提前露出 Drop/spill protection、1-year coverage、赔付上限与 Easy claims。
收益用户进入页面后能快速判断保障是否相关，再决定是否继续了解细节。
问题Benefits、How to claim 与 T&C 依赖用户主动点击，导航状态和连续阅读彼此割裂。
迭代保留可点击切换，同时让滚动位置驱动 Tab 自动高亮和切换，持续反馈当前阅读章节。
收益减少重复操作，用户按自然滚动节奏阅读时也不会失去位置感。
问题初版偏重理赔入口，提交后的审核、补件、结果和赔付节点表达不完整。
迭代补齐提交、审核、材料补充、获批与赔付等关键状态，并在每个节点说明下一步。
收益降低跳转第三方后的不确定感，让保险承诺从购买延续到理赔完成。
问题保障对比出现较晚且混入低价值信息，用户难以理解保险与品牌自带保修的区别。
迭代把对比表提前，精简字段，集中强调屏幕损坏、跌落、意外与液体损坏等差异化覆盖。
收益减少重复保障疑虑，并明确保障从签收后开始，提升透明度与信任感。
这次升级没有增加更多营销信息，而是重新排序用户做决定所需的证据：先说明保障价值，再解释与品牌保修的差异，最后用连续导航和完整理赔状态承接深度理解。
这一轮不再让一条进度线同时承担保单生命周期和理赔处理状态。页面先回答保障是否生效、现在能否发起理赔，再通过独立的 Claim status 入口承接理赔进度，让保险信息更结构化、可感知，也更值得信任。
用户视角的成功标准是：通过状态分离、结构简化与操作集中，进入页面后立刻知道“我现在处于哪个状态、能否理赔、去哪里理赔”。
把保单资格与理赔进度分开表达，从后台“系统进度”改为用户可理解的状态告知。
以 Claim status 承载 My Claim 模块，将提交、查看、补件和结果确认集中在同一条路径。
按保险名称、生效时间、保障内容、保单号和其他信息排序，先呈现影响判断的证据。
初版用 Processing 时间轴解释后台出单过程，但用户更关心现在是否受保、是否可以理赔。迭代后直接显示 Waiting for delivery，并解释保障从签收后开始。
初版先展示生命周期时间轴，再将商品、保障、保单信息与理赔入口分散在页面中。迭代后以 Active 和到期日作为首要状态，并把四个高频动作集中呈现。
到期不是页面终点。迭代将 Expired 与具体日期直接关联，关闭不再适用的 Submit claim，同时保留 Claim status、Coverage details 与 E-policy，方便用户核对既有记录。
初版把“正在理赔”放进保单生命周期主卡，用户容易误以为保单状态也随理赔改变。新方案保持 Policy status 为 Active，在操作区单独展示当前 Claim status，并将审核、补件、核准、付款完整收拢到理赔详情页。
保单有效性与理赔处理被压在同一条时间轴上，用户难以判断这是保障变化，还是某一笔理赔正在审核。
进入 Claim status 后，每个页面只突出当前阶段最重要的信息：预计等待时间、待办动作、核准金额或实际付款凭证。
迭代上线后，NPS 呈现提升，与状态更清晰、等待更可预期的设计目标方向一致。
迭代上线后，保单与理赔相关客服咨询量下降，与状态分离和入口集中的设计方向一致。
由卖家为店铺包裹承担服务费，保障运输中的丢失、损坏与未收到风险。设计重点从“促进购买”切换为“支持经营决策”：在履约场景中建立风险感知，再用透明的覆盖、赔付、适用范围与费率帮助商家完成投保。
B 端物流保障不是结账附加项，而是商家的长期经营配置。方案在两个高关联场景建立入口：Order 页面向正在处理包裹风险的商家，Fulfilment settings 面向主动管理履约规则的商家。两条路径最终汇入同一个方案列表与详情页，确保保障范围、赔付金额、适用门槛、服务费和服务商信息保持一致。
Order 页强调运输事故带来的现实损失，适合在履约任务中建立首次认知；Fulfilment settings 则把 Insurance setting 与其他店铺规则并列，便于商家随时返回查看和调整。
列表页支持快速比较覆盖、赔付、适用门槛与服务费；详情页再补充保障拆解、第三方服务商与常见问题，避免商家只看到 Register 按钮，却无法判断成本与责任边界。
Order page 负责在风险发生附近建立动机，Fulfilment settings 负责提供可返回的管理入口；后续列表与详情使用同一套保障字段，避免商家在不同入口看到不一致的费率、覆盖或赔付承诺。
以包裹损坏场景为例：退款/退货申请被通过后，由快递公司确认损坏情况，系统随即自动发起保险理赔。卖家不需要另找入口或重复上传同一组材料，只需在熟悉的订单工作台查看处理进度与结果；丢失、未收到等其他保障事件沿用同一套状态回写原则。
售后申请成为理赔链路的业务触发点，沿用既有订单与包裹上下文。
承接人工审核与自动通过两种售后模式，不要求卖家额外启动保险流程。
物流侧确认包裹损坏，为保险理赔提供可复用、可追溯的事实依据。
在原订单内写入 Claim in progress，并在理赔成功后同步更新结果。
理赔状态同时出现在 Manage Orders 与 Manage Return & Refund。卖家可以从履约或售后任务进入，并看到 Claim in progress → Protection claim success 的一致反馈；退款完成与保险理赔进度分开展示，避免把“已退款”误解为“已获赔”。
点击订单或退款退货列表中的理赔状态后，页面不跳离当前任务，而是从右侧打开 Shipping protection details。抽屉复用同一套保单与订单上下文，并根据处理结果切换说明、历史记录与恢复动作。
平台复用订单、售后决策与物流举证，自动完成理赔发起；再把同一状态回写到两个高频工作台，并通过右侧抽屉补充证据、金额、历史与恢复动作，实现“无需重复操作、随处可查、结果可解释”。
由于保险交易、机构对接和控赔数据敏感，页面不展示绝对值。可公开结果包括两项上线后趋势，以及一套支持双端旅程和跨市场复用的产品能力。
保险页面只是承诺的起点。体验质量取决于购买前的保障表达，能否在出险后的理赔流程中被一致兑现。
用户看到的信息越轻量，越需要产品、商家与保险公司对权益、责任和理赔状态形成统一表达。
保险体验最脆弱的时刻不是购买，而是出险、提交材料、等待审核和状态变化。把异常场景设计成可预期流程，同样是信任体验的一部分。
从页面、产品模型、商家后台到理赔运营，保险建设要求设计不仅优化界面，也要理解付费关系、责任边界与状态如何被系统驱动。
This case covers two separate products inside TikTok Shop. Product protection is an optional, buyer-paid add-on at checkout. Shipping protection is a seller-paid service for eligible parcels. I designed the distinct buyer and seller journeys while aligning the shared eligibility, transaction, policy, claim, and partner states behind them.
The two products do not share one customer journey. They share a platform model. The buyer needs a clear, informed purchase; the seller needs a clear cost-benefit decision and fewer manual steps when a parcel incident occurs.
Accidental damage can deter buyers from higher-risk categories. Lost, damaged, or undelivered parcels create fulfilment and support costs for sellers. Insurance addresses these risks through different payers, eligibility rules, and service flows.
I combined competitor benchmarks, experience audits, and end-to-end journey evidence from Southeast Asia and the US. The review followed three stages: purchase, policy, and claim. It revealed that concise purchase messaging only works when coverage, eligibility, status, and next steps remain clear after payment.
At first touch, show the product, term, and price. Explain exclusions and claim mechanics only when the buyer requests detail.
Warranty covers product defects; insurance covers specified incidents during use or delivery. The distinction needs concrete scenarios, not legal terminology.
Policy eligibility and claim progress are independent state machines. Combining them creates false alarms and unclear next steps.
Paid GWP tracks the value of paid policies. It is a business-scale metric, not a standalone measure of experience quality.
Shows how much of the total paid-order base is covered by an insurance product.
Shows how often eligible orders convert into paid policies. I paired both rates with NPS, support contacts, and claim quality.
Product protection is optional. The journey therefore needs to communicate coverage without disrupting the main purchase task, preserve the buyer's selection at checkout, and provide a reliable policy and claim record afterward.
The product detail page establishes awareness, a bottom sheet explains coverage on demand, and checkout confirms price and selection. After purchase, the order retains access to protection details. Policy and claim statuses are displayed separately so that a valid policy can coexist with an open claim without appearing contradictory.
The first touch uses familiar service language and defers detailed financial information until the buyer chooses to explore it.
Protection stays grouped with the covered item so the buyer can review and change the selection before payment.
A dedicated claim status shows review, required action, approval, and payment while the policy page continues to describe coverage.
Shipping protection is a recurring business configuration rather than a checkout add-on. Sellers need to compare coverage, eligible orders, payout, fee, and provider. When an eligible delivery incident occurs, the platform can reuse order, logistics, and after-sales evidence to initiate a claim automatically.
A contextual entry in Manage Orders builds awareness when parcel risk is salient; a persistent entry in Fulfilment Settings supports ongoing management. Both lead to the same plan list and detail model. Claim states are written back to the seller's existing workbenches, with a drawer for evidence, payout, history, and recovery actions.
Orders, policies, claims, evidence, and partner responses use one source of truth. The interface adapts that state to the buyer, seller, or operations context without changing its meaning.
Absolute commercial and claim-control figures are confidential. The public evidence is limited to directional post-launch signals and the product capability delivered.
Coverage language before payment must remain consistent with policy eligibility and claim handling after an incident.
A short status label is trustworthy only when product, operations, legal, and insurance partners agree on its meaning.
Failed issuance, missing evidence, review delays, rejection, and payment are not edge cases. They are where trust is tested.
Payer, eligibility, liability, evidence, and partner response determine what the interface can promise and when it can act.