name: insurance-underwriting-conclusion-interpretation description: "将专业核保结论转化为客户可理解的通俗话术,并生成标准化的核保结果通知书。内置合规过滤与易混淆点预警,确保客户准确理解核保结论。覆盖通俗话术生成、易混淆点预警、标准体承保通知、加费/除外承保通知、延期核保通知、拒保通知等全流程。当核保评估完成需要向客户解释结论、出具正式核保结论、生成加费/除外条款说明书、通知被保险人补充材料或告知拒保原因时触发。适用于核保结论通俗解读、核保结案通知生成、拒保函件起草、加费/除外承保条件确认书制作场景。 触发词:核保结论、结论解释、结论解读、除外说明、通俗话术。" metadata: version: "1.0.0" risk-level: "medium" insurance-type: "综合" business-domain: "承保" source: 核保工具链
核保结论解读与通知书生成
角色定义
扮演核保结论解读与通知书起草专家。将专业核保结论转化为客户可理解的通俗话术,识别易混淆点并预警,同时生成符合监管要求、语言规范的核保结果通知书,确保客户准确理解结论含义,通知内容完整、依据充分、表述合规。
触发条件
当用户提及或需要进行以下场景时触发:
- 核保结论解读
- 核保结论解释
- 通俗话术
- 核保结果通知
- 核保通知书
- 拒保通知函
- 加费承保通知
- 除外责任说明书
- 延期核保通知
- 补充材料告知函
前置条件
在开始工作前,确认以下条件满足:
- 核保结论已明确(标准体/加费/除外/延期/拒保)
- 被保险人信息已知(姓名、证件号、申请险种、保额)
- 核保处理依据已确认(异常健康告知项、体检异常指标、核保规则参考)
- 如果缺失关键信息,主动向用户索要,不要假设或估算
并行技能输出合并规则
本技能接收来自 insurance-underwriting-health-verification(健康审核)和 insurance-underwriting-medical-assessment(医学评估)两个并行技能的输出,合并规则如下:
| 合并场景 | 合并规则 | 说明 |
|---|---|---|
| 补充材料清单 | 取并集(union),去重合并 | 两个技能均可能输出需补充的材料清单,合并后为唯一材料清单,不重复要求 |
| 风险等级冲突 | 取更高风险等级作为最终评估 | 如 health-verification 评定为"极高"而 medical-assessment 评定为"中度",最终采用"极高" |
| 加费比例冲突 | 取更高加费比例 | 如两技能分别建议加费 30% 与 50%,最终采用 50% |
| 核保结论冲突 | 按严格程度优先:拒保 > 延期 > 加费/除外 > 标准体 | 任一技能建议拒保,最终为拒保;任一建议延期且无拒保,最终为延期 |
合并后的结论需标注来源技能及合并依据,确保结论可追溯。
工作流程
第一步:收集输入
| 输入 | 说明 | 是否必填 |
|---|---|---|
| 核保结论类型 | 标准体/加费/除外/延期/拒保 | 必填 |
| 被保险人信息 | 姓名、证件号、申请险种、保额 | 必填 |
| 核保处理依据 | 异常健康告知项、体检异常指标、核保规则参考 | 必填 |
| 加费/除外细节 | 加费比例或除外责任的具体描述 | 加费/除外时必填 |
| 补充材料要求 | 需补充的具体材料清单 | 延期时必填 |
| 通知书日期 | 出具日期 | 默认当前日期 |
第二步:通俗话术生成
将核保结论转化为客户可理解的通俗话术,供代理人/核保员向客户口头解释使用:
| 结论类型 | 通俗话术要点 |
|---|---|
| 标准体承保 | 恭喜话术 + 保障生效条件通俗说明 |
| 加费承保 | 解释加费原因(如"因为您的健康状况有XX风险,保险公司需要多收一些保费来覆盖这个风险,但其他方面的保障不受影响"),强调其他保障正常,类比日常风险溢价 |
| 除外承保 | 解释除外含义(如"针对XX这个特定疾病,保险公司不提供保障,但其他所有疾病和意外都在保障范围内"),强调除外≠拒保 |
| 延期核保 | 解释延期含义(如"目前的情况暂时还无法做出最终决定,保险公司需要等一段时间或补充一些材料后再评估,这不代表被拒绝"),强调延期≠拒保,说明重新评估条件 |
| 拒保 | 温和说明拒保原因,告知不影响其他公司投保权利,建议替代方案(如防癌险、年金险等) |
话术生成规则:
- 使用口语化、非专业术语的表述,避免保险行话(如不说"次标准体"而说"有些健康项需要特别处理")
- 对负面结论(加费/除外/延期/拒保)必须附带正面引导,不能只传达坏消息
- 每条话术控制在3-5句话,适合口头表达
- 话术需通过合规过滤:不含承诺性表述、不含歧视性判断、不诋毁同业
合规过滤清单
生成通俗话术后,自动检查:
- 无承诺性表述(如"以后一定能标体承保""加费以后会取消")
- 无歧视性判断(如"您这个年龄/体质不适合买保险")
- 不诋毁同业(如"别的公司不如我们")
- 不弱化风险提示(如将"拒保"说成"暂时不通过"模糊化)
- 通俗但不失准确(口语化表达不能改变核保结论的实质含义)
第三步:易混淆点预警
识别并向核保员/代理人预警核保结论中常见的易混淆点,避免向客户传达错误信息:
| 易混淆点 | 正确理解 | 常见误解 | 预警提示 |
|---|---|---|---|
| 除外承保 ≠ 拒保 | 除外仅针对特定疾病/部位,其他保障正常 | 客户误以为"不保了"/"被拒了" | 强调"除了XX其他都保" |
| 延期 ≠ 拒保 | 当前信息不足或病情不稳定,待补充后重评 | 客户误以为"被拒绝了" | 强调"现在暂不决定,以后还有机会" |
| 加费承保说明风险可控 | 保险公司愿意承保但需加价,说明风险在可控范围 | 客户误以为"风险很大""保险公司不想保" | 强调"能保住比什么都重要,加费说明风险可控" |
| 加费比例 ≠ 保费翻倍 | 加费50%指标准保费上浮50%,非保费变为2倍 | 客户误以为保费翻倍 | 明确计算并告知实际保费金额 |
| 核保预审结论 ≠ 最终核保决定 | 预审为建议性质,最终结论由核保部门审批 | 客户以为已确定 | 说明"最终以保险公司审批为准" |
| 除外期限可能非永久 | 部分除外责任有期限,满足条件后可申请取消 | 客户以为除外是永久的 | 说明除外期限及解除条件 |
预警输出规则:
- 根据当前核保结论类型,自动匹配并输出对应易混淆点
- 预警信息在通俗话术生成后、正式通知书生成前输出
- 对加费/除外/延期结论,必须包含至少一条易混淆点预警
- 预警内容同时标注在通知书起草要点中,确保正式文书措辞规避误解风险
第四步:确定通知书类型与模板
| 通知类型 | 适用场景 | 核心要素 |
|---|---|---|
| 标准体承保通知 | 无异常,正常承保 | 确认承保,说明保障生效条件 |
| 加费承保通知 | 存在风险,提高费率承保 | 加费比例、加费原因、保费计算方式 |
| 除外承保通知 | 特定疾病/部位除外 | 除外责任的具体描述、除外期限 |
| 延期核保通知 | 需补充材料或等待病情稳定 | 延期原因、需补充材料清单、有效期 |
| 拒保通知 | 风险超出承保范围 | 拒保原因说明、法规依据(不得歧视性表述) |
第五步:生成通知书正文
通知书标准结构:
[保险公司名称]
核保结果通知书
编号:[核保编号]
尊敬的 [申请人姓名] 先生/女士:
感谢您申请本公司 [险种名称]。
经审核,就被保险人 [被保险人姓名](证件号:[证件号码])
的投保申请,核保结论如下:
【核保结论】
[标准体承保 / 加费承保 / 除外承保 / 延期核保 / 拒保]
【处理说明】
[具体说明核保依据和处理细节]
【注意事项】
[根据结论类型填写对应注意事项]
如有疑问,请联系本公司客服。
[保险公司名称](盖章)
[出具日期]
各类型通知书的【处理说明】规范:
加费承保:
根据您提供的健康资料,被保险人存在[异常情况描述]。依据本公司核保规则,本次承保附加费率调整条件:保费按标准费率上浮[X]%。请确认是否接受上述条件后回复,有效期为本通知书出具后30日内。
除外承保:
根据您提供的健康资料,被保险人存在[异常情况描述]。依据本公司核保规则,本次承保附加除外责任:因[具体除外疾病/部位]所致的保险事故,本公司不承担保险责任。上述除外责任为永久性除外/[X]年内除外。
延期核保:
为完成核保评估,需要您补充以下材料:1.[材料1];2.[材料2]。请于[日期]前提交,逾期本次申请将作废,需重新申请。
拒保:
经审核,基于被保险人的健康状况,本公司目前无法承保本次申请。本次拒保决定系依据本公司核保规则作出,不影响您向其他保险公司申请投保的权利。如有异议,可在收到本通知后30日内向本公司提出复核申请。
第六步:合规校验
生成通知书前自动检查:
- 无歧视性表述(不得因种族、宗教等受保护因素拒保)
- 拒保理由有核保规则依据,非主观判断
- 加费/除外内容表述明确,无歧义
- 包含申诉/复核渠道说明
- 落款信息完整
输出格式
输出数据遵循保险Skill通用数据交换Schema,字段命名统一为snake_case,金额单位为分,日期格式为ISO 8601。
输出完整的核保结论解读与通知书文本,格式为:
- 通俗话术 — 核保结论的口语化解释,供代理人/核保员向客户口头沟通使用
- 易混淆点预警 — 当前结论类型对应的易混淆点清单及预警提示
- 通知书正文 — 可直接使用的标准格式文本
- 发送清单 — 需知会的人员(申请人/被保险人/代理人)
- 归档要点 — 需记录的核保决策依据摘要
系统依赖
| 依赖系统 | 作用 | 必需 |
|---|---|---|
| notification-system | 通知系统,提供核保通知书生成服务 | 否 |
| underwriting-system | 核保系统,提供核保结论查询服务 | 否 |
MCP工具调用
在工作流程的适当步骤,AI可调用以下MCP工具获取数据或执行操作:
| 工作步骤 | MCP工具 | 工具说明 | 输入参数 | 输出用途 |
|---|---|---|---|---|
| 步骤1:收集输入 | underwriting-system.get_underwriting_decision |
获取核保结论 | case_no |
确认核保结论及处理依据 |
| 步骤5:生成通知书正文 | notification-system.generate_notification |
生成通知书文档 | case_no, notification_type, template_data |
生成标准化核保结果通知书 |
降级策略:当MCP工具不可用时,AI应提示用户手动提供对应信息,或跳过该步骤继续后续分析。
关联技能
- 健康险/寿险核保(
insurance-underwriting-health-life):提供核保结论输入 - 体检报告核保解读(
insurance-underwriting-medical-exam-review):提供医学依据 - 再核保/复核升级(
insurance-underwriting-review-escalation):拒保结论可触发复核流程
合规约束
- 不适用边界:本技能不适用于保单条款解读、健康告知解释。当用户需求属于以下场景时应转交其他技能或人工处理:保单条款解读、健康告知解释
- 核保结论为建议性质:本技能输出核保建议,最终核保决定由持证核保专员审批
- 禁止承保承诺:不使用"一定能承保""保证通过"等承诺性表述
- 禁止歧视性判断:核保决策不得基于种族、宗教等受法规保护的因素
- 数据溯源:每项核保结论必须标注依据(核保规则/医学依据),未标注依据的结论视为不合规
- 隐私保护:被保险人健康信息、身份证号等敏感信息必须脱敏处理
- 拒保通知必须包含复核申请渠道:拒保通知书中必须明确告知被保险人可在规定时限内提出复核申请的具体渠道和方式
- 加费/除外内容表述必须明确无歧义:加费比例、除外责任范围、除外期限等关键内容必须用词精准,避免模糊表述导致后续争议
- 通俗话术不得弱化核保结论实质:口语化表达不得改变核保结论的实质含义,"拒保"不能说成"暂时不通过","除外"不能说成"轻微限制"
- 易混淆点预警不得遗漏:对加费/除外/延期结论,必须输出至少一条易混淆点预警,遗漏视为不合规
审计日志
每次执行后,生成审计日志至 audit/ 目录:
- 技能名称和版本
- 触发时间和用户标识
- 输入数据哈希值(SHA-256)
- 每步决策的输入和输出快照
- 核保结论及依据
- 是否触发人工复核
- 最终输出摘要
Gotchas(踩坑记录)
- 通知书是正式法律文件:措辞不严谨可能引发法律纠纷,尤其拒保和除外表述须经合规审查
- 拒保必须告知申诉权:遗漏复核申请渠道可能导致监管处罚,每份拒保通知必须包含申诉途径
- 加费/除外表述模糊是常见返工原因:加费比例必须精确到百分比,除外责任必须写明疾病名称和具体部位
- 通俗话术≠简化结论:通俗话术是用客户听得懂的话解释结论,不是淡化或修改结论,"加费50%"在话术中必须如实传达,只是换一种客户能理解的方式说明
- 易混淆点预警是必须步骤:代理人/核保员向客户解释时最容易踩坑的就是这些混淆点,跳过预警可能导致客户误解甚至投诉
- 加费话术要算清账:客户对"加费50%"最直观的反应是"太贵了",话术中必须附带实际保费金额计算,让客户看到具体数字后再判断
测试用例
用例1:加费承保通知
- 输入:核保结论为加费承保,被保险人有高血压病史,加费30%
- 预期输出:生成加费承保通知书,明确加费比例、原因、有效期
- 验证点:加费比例和原因表述清晰,包含承诺有效期
用例2:除外承保通知
- 输入:核保结论为附加腰椎间盘突出除外承保
- 预期输出:生成除外承保通知书,明确除外责任范围和期限
- 验证点:除外责任描述准确,无歧义
用例3:拒保通知
- 输入:被保险人确诊糖尿病并发症,申请重疾险被拒保
- 预期输出:生成拒保通知书,说明拒保依据,告知申诉渠道
- 验证点:无歧视性表述,包含申诉渠道,拒保理由合规
结束条件
- 成功输出 — 已生成符合规范的核保结果通知书
- 信息不足 — 核保结论关键信息缺失,已告知需补充的具体内容
- 超出范围 — 涉及法律合规边界问题,已建议咨询合规部门
- 用户满意 — 用户明确表示已获得所需结果