互聯網保險:理賠資料配置

1 評論 14367 瀏覽 80 收藏 10 分鐘

編輯導語:如何在互聯網保險中為用戶提供方便、順暢的理賠服務呢?這篇文章便基于這一點向我們展示了一些理賠服務的具體設計。如果你也想要了解如何完善保險理賠服務的話,那就一起看一下吧!

用戶買保險的心理,是想為未來的風險求一份心安,一般不會盼著自己去理賠。不過,一旦真的出險了,那用戶要理賠成功的需求就會非常強烈。

一、背景

線上理賠的流程可以簡單概括為:報案、審核、結案。以理賠成功為例,用戶關注的大致有以下幾點:

互聯網保險:理賠資料配置

能否理賠成功,主要是保險公司決定的,我們暫且不討論。審核流程咱們也之后再說,本文主要討論的是報案:

  1. 順利找到報案入口:入口明顯一些,多一些曝光;
  2. 及時得到理賠指導:這個主要靠業務(理賠專員)的專業性和積極性;
  3. 準確高效提交所需理賠資料:用戶端順利提交資料其實有一個隱藏的基礎條件,我們展示給用戶的、需要他們提交的資料是及時的、準確的、全面的。

二、問題分析

1. 問題來源

理賠時所需用戶提交的資料是與用戶購買的保險產品相對應的,不同的保險產品所需不完全相同,當用戶出險,可以選擇按照頁面提示上傳理賠所需資料。

如果每一個保險產品所需要的理賠資料都讓研發寫死在頁面上,那顯然是不合理的,成百上千的保險產品的理賠流程頁會導致:

  • 代碼無意義重復
  • 研發時間的浪費

2. 解決方案

通過管理后臺,實現理賠流程動態配置。既可以支持業務人員在管理后臺靈活配置用戶端的頁面內容,也可以減少開發成本、提高開發人員的工作性價比。方便業務隨時調整內容,不用因研發資源排期而耽誤用戶理賠。

三、功能設計

1. 理賠流程頁面拆解

每個理賠產品的理賠資料內容都不會完全不一樣,頁面上主要需要配置的信息有:是否可以理賠、支持的理賠類型、理賠資料、理賠資料提示、理賠資料示例圖……

這些內容之所以出現在我們的眼前,都是通過管理后臺進行配置上傳。

2. 管理后臺

理賠流程的頁面是由業務人員在管理后臺新增理賠產品并配置相關內容后產生的。

1)申請理賠入口出現的條件

  • 后臺理賠產品處于啟用狀態;
  • 用戶購買了保險產品;
  • 用戶已過保障責任的等待期(取多個保障責任的最小值)。

2)理賠產品狀態切換

  • 啟用——禁用:新購買產品的用戶不能看到申請理賠的入口,原先申請理賠的用戶仍然可以進行后續流程。
  • 禁用——啟用:新創建的理賠產品默認都是禁用狀態,審核無誤方可啟用,用戶可見申請入口。

3)編輯模版

雖然理賠所需要的內容因保險產品而異,但是大致也是有一個框架的。理賠的類型跑不出:醫療理賠、津貼理賠、重疾理賠、身故理賠、傷殘理賠。

每一個理賠類型所需的理賠資料(項目、提示、示例圖)也很少會變化。

因此我們完全可以內置一個理賠類型和理賠項目的模版,方便業務編輯。

當然了,內置的模版是支持業務二次編輯的。

4)復制功能

畫重點!一個內容配置后臺,不可缺少的功能。可以有效減少業務人員重復勞動以降低運營成本。

5)用戶信息聯動

理賠流程大致分為「填寫信息」和「提交資料」兩部分。

用戶在「填寫信息」時選擇的理賠類型需要和「提交資料」所需內容相一致。

用戶投保時填寫的信息需要在「填寫信息」對應展示。

6)保障額度計算

由基本保額與計算公式得出的保障額度,方便業務人員查詢和結案。

7)理賠特別說明

  • 當用戶住院未出院,不方便開始理賠操作時,我們可以通過理賠特別說明提示用戶申請理賠時所需的材料,方便用戶提前準備。
  • 當用戶方便操作理賠時,賠特別說明頁也可以起到一次性告知用戶理賠所需材料的義務。

8)信息輸入優化

  • 就診醫院:初期可以填寫,在建立了平臺自己的理賠醫院信息后可優化為篩選。
  • 銀行卡、身份證識別:初期可以填寫,之后可對接三方OCR服務。

四、迭代方向

動態頁面配置是內容管理系統(CMS)關于如何更靈活地呈現內容的解決方案,現在的理賠流程動態頁面配置只是一個很簡單的功能??梢酝暾捏w驗一遍配置流程,為之后的迭代找尋方向。以理賠特別說明頁為例:

1. 配置前

1)要配置的這個頁面,目的是什么?

讓用戶能夠更自主的完成理賠材料的提交。

2)為了實現這個目的,需要呈現哪些內容?

  • 理賠流程的講解;
  • 告知理賠所需準備的資料;
  • 提示理賠的注意事項;
  • 獲取用戶同意在平臺理賠的授權。

3)內容的呈現樣式是否需要調整?

  • 理賠并不是一個高頻的需求,大多數用戶都是第一次去做,因此有一個形象的指引是一個不錯的選擇——如果講解的內容較長,視頻是一種更容易被接受的展示形式。
  • 不同的保險產品可能有不同的理賠限制——可以做突出文案的樣式。

4)確認現有的布局是否滿足需求。

2. 配置中

可能真的去配置內容的人,都希望無論某一個頁面有多特殊的配置需求,最終都能夠被滿足。但是靈活配置也是一把雙刃劍,過于細化的配置項會導致研發的成本變高和,同時也會增加實際配置的復雜程度。

如非必要,勿增實體。

3. 配置后

1)預覽

預覽是一個可以有效自查的功能。

預覽從時間維度可以分為兩類:配置完成預覽和實時預覽。

這兩類預覽都可以起到一個作用:操作人在完成配置后進行發布前,對配置頁面進行自查,以確保最終呈現的內容頁符合足需求。

在配置和發布中間,如果有條件,還會存在一個預發布得到狀態,此時對應的預覽是——白名單預覽。

2)審核

審核也是配置完成后檢查內容準確度的流程之一,具體視業務情況決定是否需要。通常,初創團隊發布流程較為精簡,操作人員配置完成后即可發布,不會走到審核這一步。

五、總結

對于互聯網保險來說,能否為用戶提供快捷方便的理賠服務,是其樹立品牌形象和提高競爭力的有效手段。

 

本文由@404查無此人 原創發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自Pixabay, 基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 可以,很不錯。最近也在思考 不同類型的理賠申請 如何展示理賠資料的設計 ,以后多交流

    回復