項目總結:做一款香港旅游產品時遇到的文化挑戰

1 評論 5864 瀏覽 28 收藏 14 分鐘

文章分享了作者在香港做旅游產品時,由于文化壁壘而面對的一系列挑戰。希望通過對作者心路歷程的了解能夠對你的產品工作帶來一些幫助。

我們都知道有各類膚色的人,知道有多種語言,但是我們卻未必知道或者體會到其實還有各種文化背景導致的不同思維邏輯和世界觀。在以前我以為所有人都會像我們身邊的人那樣去思考去處理問題,但是不然,等你走出與生俱來的文化背景后,可能得重新來審視你以前的認知。

1.初見

我接觸香港的產品是2011年底,當時混混沌沌進入了ctrip,其之前收購了一家香港旅游公司,這個新搭建的團隊正是為這家旅游公司搭建網站,一切都從0開始。

這個團隊的文檔都得用繁體字或者英文,當時我有點沒底,因為以前接觸繁體字少,英文也菜,其實身邊同事情況也差不多,但是他們大多是開發人員,影響沒那么大。

隨著時間的推移,還是碰到了糾結的問題:

  • 一個是在開發過程中開發人員輸入法沒切換到繁體字,系統的頁面總有簡體字和繁體字摻雜在一起的情況;
  • 另一個問題就是:有些語句的用詞我們把握不準。

對于第一個問題我當時也覺得是小問題,因為我們都看得懂,直到有一天我在使用國內一家比較有名的網站時發現他們的提示里有錯別字,我突然覺得這家網站太不嚴謹,自言自語說了句“也不過如此”,那時我才意識到我們系統簡繁摻雜的問題一定在貶低我們想給消費者帶來的驚喜,因此我請求上級強制開發人員把繁體輸入作為默認輸入法,加大頁面檢查力度,同時把我的那個感受分享給團隊,讓他們不要因為一點可以避免的過失而讓消費者否定其他的努力。

第二個問題,這也只能“怪”中國文化博大精深,有很多的用詞國內和香港是不一樣的,我們經常把我們認為很正確的描述展示給香港的消費者,結果他們不知所云,例如我們在很多地方用“您”但是香港卻只有“你”字 ,頁面上出現“離店”這樣的文字他們也會認為不吉利,還有一些用法我們也把握不準,如:是次=這次,介面=界面or頁面,手提電話=手機號,更多著數=更多好處,閣下,勁減,嘅,抵玩等等。

2.領略

14年的時候部門開始規劃移動端項目,這個時期我開始接觸產品規劃,當時香港還不怎么流行旅游類APP,但是facebook 和 whatsAPP等社交類的已經流行起來了,從群體上來說facebook 和 whatsapp應該是偏年輕人,旅游不是高頻也不專屬特定年齡段因此沒有大面積推廣。

旅游產品預訂的流程比較長,要展示的內容比較多,但是受到手機屏幕大小的制約,在產品規劃時就覺得內容要精簡,流程要壓縮,有些步驟要默認處理,受這一思想指導,加上香港OP那邊也沒什么建議,又是從0開始。

上級決定先嘗試開發一個業務系統,邊走邊改進,積累點經驗,當時也沒考慮流量的問題,那時只好參考Ctrip的APP風格,結合我們web網站的業務邏輯,同開發人員還有上級確認后,定了三個產品目標:

  1. 主流程的頁面要控制在6個頁面內,精簡內容;
  2. 盡量減少用戶輸入;
  3. 盡可能符合香港人使用習慣;

但是這個項目卻歷時大半年,原因很多,一個是我們這邊也剛起步在摸索階段;另一個香港那邊的重視程度不夠,經???。1.0版本上線后反應也平平,一天最多七、八單,但是APP/H5是公司確定的大方針,因此在沒有充分經過市場檢驗的情況下,我們還是開啟了另一個業務系統的APP/H5的需求設計,產品目標還是那三個。

兩個項目上線后已經的2015年3~4月份了,在一番游說后,香港那邊開始為推廣APP/H5做促銷活動,那時移動端的訂單也只有幾十單,不過比剛開始要多,并且慢慢在增長,但是后來就發現問題了,投訴的人開始多了。

從投訴的情況來看問題出現在3方面:

  • 一個用戶資料錯誤,做產品時默認設置性別=男,但是有些用戶是女的,沒注意這個欄位,也就沒去修改,導致出票時信息對不上;
  • 另一個是由于APP要控制頁面數,刪除掉了web有的訂單核對頁,客人在提交訂單后才發現日期選擇錯了;
  • 還有人投訴在他沒看條款時系統默認給他勾選了條款;

在當時我覺得都是客人的問題,跟產品經理是沒關系的,但是一次一次的賠款促使我必須面對和解決問題。因此開啟了產品的一次次優化,不默認勾選性別,在不增加頁面的情況下多增加一些彈出蒙版,取消勾選協議……

后來在做其他系統時還是問題不斷,有些訂單出行人必須有保險的但是客人卻要求自備保險,做產品時沒考慮到自備保險勾選項,被投訴。

酒店房間顯示的面積跟客人入住時面積有一點點出入(如系統顯示有20平方,但是客人入住時量得是17平方)又投訴,這塊我們只好要求ctrip 確保數據錄入的準確性。

展示圖里的床型有大床和雙床,而下面的房型沒有大床或者雙床又投訴,原因是沒加一句(請以實際房型為準),早餐份數沒有詳細到每一天,只有部分早餐時客人又投訴,又只好加蒙版詳細展示每一天的早餐情況。

當時真的覺得香港人太喜歡投訴了,后來想想我們做產品就是幫助消費者解決需求,我們不能因為自己毛躁和所謂精簡去犧牲消費者全面了解信息的訴求。大陸人自身權益維護問題的淡薄不正是大陸很多產品質量不過關卻能大行于世的一個重要“幫兇”嗎,如果我們都像香港人那樣去維護自身權益,我想企業就會加強自己的監管和產品的改進。其實這些經驗攜程也吸取了,所以后來James梁提出精益服務,在拓展海外業務時也更注重細節,記得剛開始時還專門拿出一筆錢用來支付投訴導致的賠款。這也是ctrip在國際化過程中遇到的一些文化認知的挑戰。

3.主動出擊

在后來的產品規劃和優化中,我們團隊都尊重香港的文化因素,盡可能多的站在香港用戶的角度去感受產品。不是等待投訴后才去優化,而是主動出擊。主要是有三個方面:

以前系統訂單的客人資料信息都是沒有加密的,包括電話,電郵,證件號碼,原因是這些信息要在預訂過程中展示給客人確保資料無誤;但是在一次系統掃描中,發現這些信息可能會被外界獲取,這樣會帶來危害,如果是競爭對手獲取那么就可以通過電話挖走用戶;黑客獲取會招致更大問題。但是預訂時就優化客人可能無法檢查填寫信息是否正確。

當時我注意到我們系統的訂單基本可以在24小時內處理完成,只有個別系統的處理時間比較長,那時我提出了優化方案就是在下單完成后對用戶資料進行頁面加密,在下單完成24小時后對數據庫用戶資料進行徹底加密。

邏輯考慮是頁面加密時數據庫數據并沒進行加密可以不影響訂單處理,在24小時后訂單基本處理完成后對數據庫進行徹底加密,其實當時對徹底加密有反對聲音,因為徹底加密會使系統的用戶資料都加密,包括日志里的用戶資料都加密,可能會影響一些訂單日后的跟進處理,在單個業務系統實驗一段時間后發現沒什么問題就在全系統鋪開了,后來擔心競爭對手分析訂單數據,上級要求對超過6個月的訂單進行了訂單號加密。這樣我們保證了用戶信息的安全。這一招后來攜程也借鑒了,但是他們的后臺邏輯具體如何我是不清楚的。

另一個優化是Moto支付,當時系統監控到同一聯系人在多個城市預訂同一天的酒店,并且訂單金額非常大,當時我們是覺得很高興的,把這情況反映給香港op,他們的反應卻很不安。

后來他們通過一些手段發現是有人盜刷信用卡,并且連續幾天出現這情況。當時我們認為信用卡是客人自己丟的,為什么要我們系統承擔盜刷風險,但是香港的法律就是維護用戶,要求旅游公司賠償一部分損失。

在這之后我們引入了風控系統,風控的規則是上海ctrip定義,我們只是調接口傳數據,上海返回風控結果,這時又出現問題了,風控有誤判也有沒擋住的盜刷,之后又做了3D支付,把風險轉嫁一部分給銀行。這一塊還在不斷優化,就是想給用戶一個安全的支付環境。

最后一個是打點系統,這個是開發人員做的,不算產品但是提升了產品的防御能力。香港的法律十分注重維護個人權益,客人一投訴就得給客人賠錢。之前有些投訴我們覺得很奇怪,因為按照客人的那種處理模式,我們反復的驗證都不會出現客人那種投訴的情況,但是客人堅持是系統問題,客人還有截圖,我們沒反駁機會。所以每次一投訴就是折騰一番,沒找到原因還得賠錢。

聰明的開發人員也是為了盡早找出問題,因此開發了一個打點系統,記錄用戶的操作(當然敏感信息沒記錄),以便分析。在后來的日子里這套系統的確找到了一下遺漏的業務流程,但也給那些通過修改頁面腳本進行投訴然后來騙賠款的用戶當頭一棒。

有幾次用戶投訴的內容與其在APP預訂的流程不一致,其還保留了截圖,認為是我們系統問題,要求賠款金額也比較高,后來就是通過我們的打點系統的數據對客人的說辭進行反駁,客人才從不依不饒中安靜下來,不要求請求法律處理,因為我們也有證據。

以上就是個人在香港項目中的一點體驗,淺聞小見,盼諸君多多指教。不勝感謝!

 

本文由 @飄雪的南方小城 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自PEXELS,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 大陸在法律和政府層面要做更多的完善,人民大眾也要多出力,不過這些都不是一朝一夕能解決的問題,只要事情在朝好的方面發展那就應該相信明天會更好。

    來自廣東 回復