互聯網保險:理賠服務
編輯導讀:保險是當代人生活的一個后盾,互聯網時代的保險產品購買門檻更低,服務人群量級更大,同時也對售后服務提出了更高的要求。其中,理賠是體現一個保險產品服務的重要環(huán)節(jié),關乎到保險公司的美譽度。本文梳理了互聯網保險的理賠流程,從產品設計的角度進行分析,與你分享。
視網膜效應誠不欺我。自從開始做保險,就發(fā)現手機里的APP全都在開拓保險業(yè)務。最近,就連同花順都開始推送百萬醫(yī)療險了……
一、背景簡介
1. 需求背景
你在網上買過保險嗎?
與傳統(tǒng)保險銷售模式相比,互聯網保險產品的購買門檻通常更低,代理人服務的用戶量級也可能更大。而人的精力總是有限的,一旦我完成投保,我的代理人就會立馬轉戰(zhàn)下一位用戶,促使TA的出單。我和代理人的感情,可能只能靠每年的繳費鏈接去維系了。
我要是不出險,那感情淡薄點兒也沒啥。一旦出險需要理賠,售后服務不到位,就妥妥砸招牌了。
這樣一想,互聯網保險服務的兩個核心流程就理出來了:一是投保,二是理賠。
理賠是保險事故發(fā)生后,保險公司執(zhí)行保險合同,履行保險義務,承擔保險責任的具體體現,是提供給被保人獲得保險公司賠償的服務。
由此可見,理賠服務對于保險平臺樹立品牌形象,傳達服務理念,吸引用戶復購起著至關重要的作用。
2. 核心需求
理賠環(huán)節(jié)用戶的核心需求是什么?——高效的獲得合理的理賠結果。
怎么獲得合理的理賠結果呢?——專業(yè)的理賠審核人員需要獲得全面,準確的理賠信息。
怎么推進理賠服務高效進行呢?——及時提醒理賠審核人員和用戶需要操作的理賠節(jié)點,盡可能降低人為原因的錯誤與延遲。
二、理賠流程
1. 申請理賠
同一保單在同一時間,是可以申請多次理賠的。因此我們需要對理賠單進行清晰且明確的分類,本次是按照服務進程維度進行劃分的。
2. 申請理賠
我們可以怎么幫助用戶高效的獲得合理的理賠結果呢?
1)讓用戶了解理賠流程
申請理賠,著實算一個低頻且復雜的場景了。對于需要理賠的用戶,我們可以通過視頻、文字等形式向其闡述理賠的整個流程。
2)盡量減少用戶輸入信息
人難免會犯錯,做的越多就可能錯的越多。而減少用戶輸入的信息不僅可以有效降低錯誤率還能減輕用戶操作負擔。
舉例來講,理賠時需要的文字信息主要有以下幾類:
- 被保人信息:姓名、性別、證件類型、證件號碼……(此類可以帶入投保時信息,無需用戶填寫)
- 申請人信息:與被保人關系、姓名、性別、證件類型、證件號碼、聯系電話……(是被保人或者投保人的話,信息可帶入)
- 賬戶信息:與被保人關系、姓名、銀行卡信息……(可以采用OCR識別方式獲?。?/li>
- 就診信息:就診類型、出險類別、就診醫(yī)院、就診金額、就診時間、主要就診經歷……(這些暫時沒啥好辦法,需要寫)
3)設置報案節(jié)點
當錄入信息過多時,將信息分類拆解。例如將理賠報案所需的信息分成文字信息和圖片信息并分步驟向用戶展示。這樣既可以保證用戶操作時對信息類型認知的一致性,降低錯誤率。還可以通過已完成第一步、第二步,來提高用戶的操作信心。
4)協(xié)助用戶提供準確信息
用戶上傳的資料對于理賠審核人員來說至關重要,什么樣的資料是符合要求的?將資料的示例圖以圖文的方式展示給用戶,是不錯的方法。
當用戶提交了理賠申請,在后臺就會對應生成用戶的理賠單信息。理賠人員對于理賠單的操作主要有:給用戶打電話、審核上傳的資料、確認案件處于保險公司復核狀態(tài)、通知用戶郵寄紙質資料、結案、添加備注、查看詳情。
詳情頁面可以進行和列表頁面同樣的操作,在詳情頁除了報案時用戶自己填寫的信息,還可以向理賠人員展示投保時獲取的其他信息,幫助判斷。
3. 查看理賠詳情&完善理賠資料
報案之后用戶最關心什么?當然是理賠進度啦。
理賠進度需要向用戶展示理賠流程、用戶所處的理賠節(jié)點。如果理賠到達了需要用戶知曉的節(jié)點,可通過短信、微信模版消息及電話的方式及時通知用戶。
理賠資料很難一次性提交正確且完整,完善理賠資料也是不可缺少的一步。之前提交的資料為什么不符合要求是重要信息,可將其突出,方便用戶查看。
除了被保人的信息和系統(tǒng)自定義的信息,其余信息用戶在報案時都有可能會填錯。
4. 保險公司線上復核
這一步理想狀況是,不需要用戶做補充資料的操作??扇f一我們的理賠人員就是漏掉了哪里,被保險公司告知需要補充,也是需要挽救一下的,前端給用戶展示的補充資料頁和 圖2-7 一致。
5. 郵寄資料
很多的理賠案件(賠付金額超過一定值),保險公司都是需要用戶提供紙質的資料進行復核的,專業(yè)一般稱物理件審核。給用戶的文案應避免使用專業(yè)術語,通過簡單清晰的文字向用戶傳達當前的狀態(tài)是最好的。
6. 結案
一般來講,只有當保險公司確認案件可以結案了,我們才能知道用戶可以賠付的金額、之前郵寄的資料是否需要申請回寄等一系列信息。
三、總結
做保險業(yè)務半年多了,以上是在實際項目中得出的一點點兒心得,主要是圍繞通用框架展開的說明,實際設計過程中,就需要考慮更多的細節(jié)啦。每一步,每一個模塊都可以深挖,希望之后有機會可以細說~
本文由@404查無此人 原創(chuàng)發(fā)布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash, 基于CC0協(xié)議。
不好意思啊,我看你好像是在一篇文章基礎上改了改文案啊
厲害厲害,請問一下理賠失敗和不予立案有什么區(qū)別呀?
厲害,同行求交流
整個流程比較完整,邏輯也比較清晰~沒毛病??梢詤⒄誌云保的,設置一個線下報案的入口指導用戶理賠,畢竟線上理賠一般只支持相對簡單且低額的賠案。
好的呀~
感覺審核列表中的審核狀態(tài)和理賠狀態(tài)有點不清晰
嗯嗯,理賠狀態(tài)是從用戶理賠單的角度考慮的,審核狀態(tài)是從員工工作角度考慮的。你的建議是什么呀?
繼續(xù)保持更新