汽車APP購車板塊產品設計
產品經理需要充分了解業務的內容,面對不同的產品所做的工作內容也該做出一些變動。下面這篇文章是筆者要介紹的關于購車項目中涉及到的留資(預約咨詢)功能以及預售(小訂)功能的產品設計的相關內容,對此感興趣的同學一起接著往下看看叭!
我在智能穿戴行業從業3年,轉行到汽車行業,接近一年半的時間里,我將一款汽車APP從0-1進行了落地,并且進行了10+版本的迭代。其中,APP/小程序購車板塊的項目是我主導的項目中,參與比較深的板塊之一,現在給大家進行分享。
一、項目背景
根據整個品牌的發布節奏,以及進行大量的需求調研以后,我們初步將車型上市節奏分為:預售/大定兩個環節,用3個月時間籌備了整個車型預售環節的產品設計開發,4個月時間籌備了車型上市的產品設計開發。
在前期剛接觸購車項目時,認為只是一個常規的用戶填寫信息/支付金額的功能,并不會涉及到比較復雜的功能。后面項目接觸的越深,逐漸意識到整個購車板塊涉及到相當復雜的業務流,本篇文章就由我來介紹涉及到的留資(預約咨詢)功能以及預售(小訂)功能的產品設計。
二、留資功能設計
在接觸一個板塊時,首先需要理解業務背景,為什么要做留資功能。
汽車新品牌的發布,除了品牌/市場側對品牌/產品的傳播,吸引了第一波對于品牌有吸引力的用戶入場,從生命旅程來說,從了解到主動接觸,在這個業務場景中,就會有主動進行留資的需求,將用戶的從各個端口的線索匯集到線索管理系統中。
基于以上的業務場景以及對應的用戶需求,就要考慮產品層面,對于留資這個功能需要做什么。
首先車系車型可以作為用戶對某一具體車型的意向表示,其次就是用戶的基本信息:姓名/所在地/手機號。姓名和手機號可以作為用戶的基本聯系信息,所在地可以確認用戶的線索所在城市,在這個基礎上,我在姓名字段旁邊特意加上了“先生”/“女士”的勾選項,這可以作為銷售顧問聯系客戶在收到此線索信息時,電聯客戶的招呼語。
如果單純的只看前端的留資字段,會發現這個功能很簡單,無非就是把一些用戶關注的基本信息落到線索管理系統中。作為產品經理,還是需要有一些全局化的思考,線索管理系統的產品經理在承接這些字段,會做什么處理。
在前期,全國還沒有門店建設,為了跟進線索,已經招聘了很多銷售顧問,正常線索管理系統的銷售顧問,是一定需要掛靠在某一家門店,在全國沒有門店的情況下,需要建設一家虛擬門店來承接。當用戶在前端留資的線索落入到線索管理系統,常規的字段不再贅述,著重講一講所在地字段的數據流向。
如果只考慮前期的線索流入,可以考慮的方案就是按照虛擬門店內銷售顧問輪詢的方案。從長期看,銷售顧問是會被分配到全國各門店,虛擬門店輪詢的方案只適用于沒有門店的情況。
對于線索分配,有兩種情況考慮。
- 用戶所在地的省市只有一家門店時,會在此門店的銷售顧問中輪詢匹配銷售顧問。
- 用戶所在地的省市有多家門店時,首先會做門店的輪詢匹配,輪詢命中門店后,再從門店銷售顧問中輪詢。
針對于第二種情況,為什么不考慮用戶就近匹配門店,這里有3個考慮的點。
- 目前渠道建設全部采用直營模式,由總部直管,秉承對所有用戶一視同仁的基礎上,前期對門店的資源分配也應該是相同待遇,如果采用門店就近分配,會導致偏向省市中心地段的門店會獲得更多的資源。
- 如果有用戶本身距離更近有門店,而被分配到了同省市比較遠的門店,客檔轉移功能可以給客戶轉移到意向門店。
- 從銷售顧問的角度來說,同一個省市每個銷售顧問通過分配獲得客戶資源的幾率是相等的,如果銷售顧問能說服客戶到自己的門店進行溝通,是銷售顧問自己的能力,如果客戶有強烈意向要就近門店提供服務,直營模式可以滿足客戶的需求,銷售顧問有義務幫客戶跨店轉移。
總結:如果單看留資功能的前端字段,留資功能非常簡單,從業務層面理解思路才是真正明白功能設計的意義。
三、預售功能設計
首先說明一下需求背景,我們在預售階段總共發布了兩個車系,其中一個車系發布了兩款車型,現在需要對兩款車型進行預售。
回歸到需求分析,我們做預售的目的是什么,總結有以下四點。
- 在品牌發布會以后,品牌的已經在大眾中留下了一個基本印象,無論品牌如何宣傳,最終的目的還是賣車,在品牌發布以后,產品/品牌的預熱之下,順理成章推出預售功能。
- 預售本身除了收取用戶的意向金以外,還有一個很重要的目的是留資,對于數據分析來說,愿意支付意向金的客戶,比常規預約咨詢留資的用戶權重更高。
- 想知道用戶對兩款車型的傾向性,這個能為產品研發進度的傾向性以及為后續排產計劃作指導。
- 為了促進客戶自愿去下意向金訂單,為意向用戶提供特殊的權益禮包。
基于以上的需求背景,進行需求分析。
意向金支付需要接通支付平臺,問題是如何選擇合適的支付平臺,選擇一般來說,選擇支付平臺有幾個標準。
- 有過車企行業的案例,對收款/退款/分賬等業務熟悉。
- 手續費低。
- 配合度高,運維人力投入大。
常規的預售下單流程為購車首頁-購車詳情頁-車型選擇-確認訂單-支付-支付成功-訂單詳情頁,這次主要探討預售的是訂單中的留資/權益/支付/退款四塊內容。
預售的留資和常規的留資有少許不同的地方。首先常規留資手機號是不用做校驗的,常規留資的場景相對來說是比較輕度的,但是預售確認訂單中,我們有三種選擇,第一是使用手機號+驗證碼登錄,第二種是一鍵獲取微信手機號授權。
先說結論,我們當時采用了一鍵獲取微信手機號授權。考慮的點有以下幾個。
- 我們開發了APP/小程序,在購車功能邏輯上,兩者是沒有區別的。大部分用戶都是使用微信小程序下單,原因是在沒有成為真正車主的時候,用戶進入微信小程序下單的成本比下載APP要低很多,考慮主要在小程序上使用一鍵獲取微信手機號授權。
- 一鍵獲取微信手機號授權交互方式更加簡單,手機驗證碼需要等三方供應商返回短信,考慮到首次預售,并發量高,且現場參展人員過多,導致部分用戶收不到短信,導致無法第一時間下訂。
- 當然一鍵授權也有一定的缺陷,首先app是不能使用這個功能的,用戶直接手機號,微信綁定的手機號也有一定幾率不是正在使用的手機號,可能是以前申請的,而且用戶自己填寫的時候,沒做校驗,是有可能出現亂填手機號的情況。
綜合評估后,我們考慮意向金用戶只是初步意向,且是隨時可退款,用戶在大定的時候是可以重新填寫手機號,最終采用了一鍵獲取微信手機號方案。
關于權益,也是比較重度的一個板塊,實際上,預售到大定,會繼承的只有權益和意向金,所有用戶在預售過程中的留資信息都不會作為繼承內容,原因是用戶在預售的留資,只是會作為意向,用戶在預售期間是隨時可退的,整體的留資不用特別重度。
至于為什么說權益是一個比較重度的功能,對業務側來說,涉及到激勵用戶下預售訂單的動力。對產品側來說,預售權益和大定權益是涉及到繼承/退坡機制的。解釋一下,繼承和退坡之間的區別,以及它們所對應的業務場景。
繼承表示的是,用戶在預售下單后,有一部分權益是預售客戶專屬的,如果用戶正常下大定,是不會擁有預售權益的,小訂(預售)轉大定的用戶,會將預售部分的權益繼承到大定訂單中。
在同一車系下,有A/B兩個車型,制定的規則中,A和B車型的預售訂單是可以互相轉為大定訂單的。當時現狀是A車型會先行上市,B車型后上市,這個場景就會是A車型大定,B車型仍然是預售,我們設計預售的目的讓一部分嘗鮮用戶享受權益,如果沒有做任何限制,用戶在A車型上市后,下B車型的小訂訂單,直接可以轉大定獲得權益,這和原本目的相違背。
我們考慮以上場景的時候,必須給一個限制,就是A車型上市后,下的B車型小訂訂單,直接轉A車型大定是不享受大定權益的,這就是我們所說的退坡機制,也就是:車型上市后,下的同車系不同車型的小訂訂單,轉大定的時候,不享有原本的小訂權益。
關于退款,我們在退款上做了一些機制,由于預售是隨時可退,我們在用戶退款中,設計了引導用戶填寫退款原因的選項,以方便我們做回歸分析。
同樣的,在進行完所有字段以及功能設計后,考慮怎么樣和后端系統進行交互,針對預售相對比較簡單,用戶資料部分和預約咨詢的邏輯基本一致,這里需要注意的是,用戶如果在確認訂單頁面,未支付訂單,我們也會考慮保留用戶在確認訂單頁填寫的資料,作為留資線索。
這里需要考慮一個業務問題,為什么不把用戶的注冊手機號作為線索來源。我們從業務側做了以下兩個考慮。
- 用戶的注冊手機號如果作為留資線索,流向線索管理系統,由銷售顧問進行跟進,真正的意向用戶占比不高,轉化率較低。
- 用戶體驗不佳,對于新注冊用戶,只是想對品牌有初步了解,就被銷售顧問電話聯系,這會讓用戶感受到壓力,且用戶會懷疑自己的身份信息被平臺泄露,導致品牌口碑下降。
針對每個企業、每個業務背景、每個車型打法都存在差異性,不能使用同一套方法論來應對所有的產品設計,需要充分理解業務,不過多聚焦在功能側,才能成為一名合格的產品經理。
本文由 @Byron 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
那么,收款/退款/分賬等業務,應該怎么處理呢
學到了!