UED用戶體驗調研:酒店訂單開發票
文章為作者根據自身用戶體驗調研后的感受總結,希望能夠給你帶來幫助。
我是一個研發,但是近一年準備轉產品,于是在為轉產品做著各種準備。這是我參加公司內部的一次用戶體驗調研,調研結束后我根據參加的感受總結出用戶體驗調研的一些流以及我的思考。
調研目的
這次參加的是酒店UED的調研,調研目的是觀察用戶定完酒店能否順利的完成開發票的操作。
調研對象
我作為調研對象參加了這次的調研,近一年我雖然定了國內和國外的酒店,但是我作為自由行用戶,并沒有開發票的需求,嚴格來說,我并不是這次調研最完美的調研對象,開發票的一般是商旅出差人士用來公司報銷,所以調研對象應該選擇經常出差經常開發票的人。
酒店訂單開發票的基本情況
酒店的訂單我們這樣分類:國內酒店訂單和國外酒店訂單。如果是國外酒店訂單,我們是只能給電子發票,郵件發到用戶郵箱;如果是國內酒店訂單,我們可以有三種,電子發票,紙質發票和增值稅發票。
紙質發票快遞給客戶,用戶需要付快遞費或者用積分抵扣快遞費,我覺得這個是一個亮點,積分的用處得到了體現,并且積分用來抵扣這種小額的東西,對利潤的影響應該不是很大,但是在商旅客戶的心中留下了一個亮點。
用戶體驗調研流程
開發票的入口
UED同學首先關心的是用戶是否能便捷的找到開發票的入口,這點app做的挺好的,在訂單點開的地方有很清楚的按鈕可以看到補開發票,用戶應該可以不費吹灰之力就可以找到訂單開發票的入口。
補開發票的入口是在已點評和再次預定中間有一個補開發票的按鈕,當我們發票開完以后,這個頁面的補開發票按鈕就會消失,這點我覺得非常好,我們應該盡可能得減少用戶誤操作的可能性。
但是同時這個補開發票按鈕的消失也帶來了一個問題,就是如果我們第一次補開發票填寫的信息有誤,然后我們現在想變更補開發票的信息,但是現在補開發票的按鈕已經消失了,下面的我要開發票點開來也不能開發票了,這樣用戶只能去騷擾客服了,這個問題我覺得UED同學并沒有考慮很周全。
我自己給出的處理方案是這樣的:我們每個訂單開發票,是不是可以有一次的修改機會,就像火車票一樣,好歹可以改簽一次。我覺得發票可以修改一次這個功能不錯!
但是這樣會不會帶來其他的問題,就是說我們可能電子發票已經發出去了,或者紙質的發票已經寄出去了,這時候用戶才來更改發票?
我們總不可能專門在后臺搞一個訂單發票的按鈕,我們人工寄出去發票我們就把發票的按鈕置灰。這樣人工成本實在太大了。
我自己給出的解決方案是這樣的:我們可以設定這樣的規則,比如在每個訂單只能修改一次開發票,并且在第一次開發票后的幾小時內才可以修改,這個具體的時間需要討論和調研,然后當客戶第一次完成了補開發票這個流程,消息發到了后臺運營或者客服那邊,會有一個倒計時時間顯示,我們客服或者運營人員在這個時間倒計時還沒有結束的時候,我們不會郵件發電子發票或者郵寄紙質發票,當倒計時結束,說明客戶已經不能修改我們的發票了,這時候我們運營直接在后臺篩選一下倒計時結束的訂單,就可以去給客戶發發票了。
這里還有一個問題:我們這個幾小時的時間要經過調研才能決定不能拍腦袋,如果時間過長,萬一客戶等得及的話,就會耽誤事,所以我們的時間應該定在合適的時長,我覺得兩到三個小時的時間挺合適的(這是我拍腦袋憑感覺)。
按鈕話術表達意思是否清晰
緊接著UED童鞋問了我是怎么理解補開發票這個按鈕上面字的意思?是當時沒有開現在想開了?
首先我覺得UED童鞋這個問題就問的不好了,我們在進行用戶調研的時候,不應該給用戶傳達一個指向性的意思,所以UED童鞋可以問我是怎么理解補開發票這個意思的,但是之后的那句話就不應該說,不應該解釋一下補開發票的字面意思,而應該讓用戶來解釋,看看用戶是怎么理解補開發票這個意思的。
補開發票和我要開發票的區別
其實這個地方設計的是有問題的,因為在我作為一個用戶看來,補開發票和我要開發票能有什么區別,這不是一樣的嗎?但是這個地方設計者其實想表達兩個不同的用意。
補開發票按鈕,點開來直接進入補開發票的流程,而我要開發票是一個客服機器人,點擊這里可以進入補開發票按鈕點擊后一樣的流程開發票(這邊這里的話術我覺得不好,應該直接換成補開發票),點擊下面的咨詢更多問題可以向客服機器人咨詢訂單問題。
補開發票填寫頁
在補開發票填寫頁,我們發票抬頭那塊有個我覺得是亮點的功能。如果客戶以前開過發票,那么我們就會記住以前這個抬頭,然后客戶這次可以直接選擇上次填寫過的抬頭,我覺得這個功能挺好的,就像火車票或者飛機的乘坐人一樣,如果我們填寫過了,那么下次我們買票的時候就會可以讓我們自己選擇上次填寫的。
補開發票填寫頁是需要填寫郵箱地址的,因為電子發票的需要。
這里我提出一個問題:為什么需要填寫郵箱地址但是不需要填寫電話號碼?
UED童鞋和我說的是訂單填寫的時候客戶是會留電話的。
這里我提出一個建議,如果我們給客人發了發票,不管是電子的郵件還是紙質的郵寄,同時我們給可以發一條短信,打電話不太好,通知客人比如你的發票已經郵寄啊或者郵件已經發送啊什么的會不會更好。這個建議是為了防止發給客人的郵件被淹沒,雖然短信也是有可能被淹沒的,所以這個建議提出來需要再進行思考和討論,而且訂單量太大,發這么多短信成本也是一個問題,都需要進行討論,這里只是提出一個發散性的建議。
還有一個功能是一個亮點:就是當我們選擇好抬頭,會將個人或者公司這個抬頭顯示在名字前面,這個功能我覺得不錯的。
這里我有一個問題:當我們在IM里面點擊這里,然后發票填寫結束的時候,點擊完成,直接返回IM,但是我并不知道這個發票填寫是不是完成了,我覺得應該有一個toast告訴我開票完成。
當我們再次點擊我要開發票進入IM的時候,IM知道你已經開過發票了,就會變成這樣。
這個功能我覺得也是一個亮點:就是當我們已經開過發票然后再進入IM的時候,點擊這里可以開發票的鏈接就消失了,我們就只能咨詢問題了,但是如果我們以后客戶是可以修改發票,那么這個地方也是要進行同步的再設計。
開發票的幾種情況全覆蓋
上面贅述的大段文字其實是這樣的情況,就是入住結束了,然后補開發票。
但是我們做用戶調研的時候,最好進行場景的全覆蓋,那么還有以下兩種情況,一個是我們預付了酒店的款項,但是還沒有入住,也可以開發票;還有一種情況是有些酒店必須要在酒店開發票,我們公司是不能給客戶開發票的。
我現在針對第二種情況做一個說明。
第二種情況是用戶只能在酒店開發票我們公司并不能給用戶開發票。這時候在訂單詳情頂部會有一個補充說明,但是我作為用戶下完訂單以后其實并不會怎么看這個補充說明,這時候用戶可能就不知道這個訂單發票只能在酒店開,一旦離開酒店,就不能在訂單詳情自助開發票了。
而且在進行用戶調研的時候,這個UED童鞋已經給我把開發票的幾種情況分得很清楚了,但是用戶并不知道這幾種開發票的情況,所以這個問題設置是有問題的。我們應該站在用戶的角度而不是把我們設計的幾種情況直接了當的告訴用戶。
問一下用戶最喜歡的開發票方式
最后就自助填寫開發票和打電話給客服開發票和IM客服機器人開發票三種,用戶最喜歡哪一種,就像索尼經典的案例,最后問用戶你們可以帶走一款顏色的產品,雖然用戶嘴上說喜歡黃色,但是最后大多數人選擇了黑色的產品拿走。
本文由 @夸父逐日 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自unsplash,基于CC0協議
其實所有OTA公司都是有修改發票的客服系統。
開具發票模塊一般在成單頁(成單前),補開發票按鈕一般在訂單頁(成單后)
其中正如你提到的,補開發票按鈕是有展示邏輯的。一般都是根據訂單狀態、可開票狀態來判斷。
還有一點需要糾正,不可能出現郵寄了用戶才修改發票的情況,正常邏輯是訂單狀態由已經支付變更為已經入住,郵寄中心才會進行發票郵寄,此時可以將修改發票按鈕會隱藏掉。一般OTA不愿意加修改發票是因為需要單獨接口傳遞信息,涉及情景頻次低,需要重新將發票信息等綁定到訂單上,并且存在如果電子發票更改為紙質發票郵寄費用問題等等。
您好。能否加個微信,想了解一下關于電子發票的問題?微信:lt666888321
看完文章我有幾個問題想一起討論一下,
1.為啥在訂單詳情頁增加開票入口?而不是獨立開票管理?
2.為啥要在幾小時后提供給用戶修改發票的機會?
3.發票填寫頁為啥不直接默認上次已開發票信息?
1.我由于沒有放出圖片可能你理解錯誤了,開票入口有兩個,一個是在點擊訂單出現的頁面有一個按鈕是補開發票,這個按鈕是沒問題的,用戶肯定開發票首先都會去找到那個訂單去訂單詳情頁開發票,獨立的開票管理有增加這個頻道的必要嗎?我覺得完全沒有,這個開票功能本來就是屬于訂單的一個功能,而且不是所有人都有開票需要,為什么要提出來單獨的頻道管理這個功能。
2.不是在幾小時之后,是在幾小時之內,因為客戶可能會修改訂單,這個是我提出的建議,需要再進行調研,看現有的客戶開票更改率多少,一切還要根據數據來。
3.你這個問題就很不好,本來填寫頁就只需要填寫兩個欄并不多,其中一個點進去已經保存了上次的這一欄的填過的數據,實際上用戶需要自己填的只有一欄而已,如果默認,用戶更改反而更加麻煩。
1.為啥獨立開票呢?原因三點,一是下單過程中提交開票需求會增加用戶操作量和訂單接口的復雜度,二是企業是不太想用戶開票的,獨立開票過濾那些非必須要發票的用戶。三是獨立開票可以整合多個業務線開票需求的提交。(訂單詳情頁開票的提示可以保留)
2.修改訂單一般是把原訂單取消,生成新訂單所以發票的信息也要重新選擇。一般情況下,用戶都是在收到發票時才會意識到自己之前填寫的發票信息有誤需要修改。這部分用戶是極少數的,可以讓用戶咨詢客服處理。
3.為了便于用戶操作的話,對于新用戶來說,是調稅控接口模糊查找用戶開票公司的名稱和稅號信息可以減少用戶操作;對于老用戶來說,已有發票信息是否默認,可以看一下同個用戶不同訂單的發票信息重合度有多大的數據量再進行考慮。
可以加我qq578208298慢慢討論
1.開票是訂單完成后再去開票,不打斷訂單流程,你的立論依據不成立;獨立會過濾用戶的說法更是無從談起,你直接站立在企業不想用戶開票這個未經推敲點上,卻不是獨立開票是否有必要增加這個頻道點;開票這種事在多BU架構的情況下,想整合難度太大,畢竟有的公司多BU結構是獨立的財務。
2.這點我說過了,關于是否需要提供修改的功能,需要拿到現在客服人員關于客人重新開票的比例。
3.你這個調稅控接口差公司名稱,聽起來就不是那么好實現,這個接口應該是工商那邊的,我們能不能拿得到這里打個問號;老用戶,本來就是可以選擇上次的填寫內容,現在的操作就是這樣的。