(萬字長文)關于攜程酒店業務的思考
這篇文章里,作者以攜程為參照對象進行了業務分析,一起來看看本文作者關于攜程酒店業務的思考。想了解OTA、或者酒店業務的同學們,或許可以來看看本文的思路。
本文是以攜程為參照對象做的一個業務分析,系列一共有三期,本篇為第一期。
社會的發展離不開經濟,經濟是由商業活動而來的,而之前的商業活動主要圍繞著衣食住行,哪怕是當前以及未來,這些都是根基,是不會變化的,這也是所有企業都在向之靠攏的原因,因為只有靠上這幾類才能賺錢,賺錢才能更好的擁有這幾類。
而當下我覺得還應該再加幾類,因為隨著生活水平的提高,有新的需求點被放大,這幾類分別是人安樂。那么加在一起就是七項:衣食住行人安樂,肯定還會有其他需求項我所沒有想到的,更多的是垂直類的,這也是機會的所在,切入更細的賽道更細分的領域的時候,發現更多細節的時候,所能做的差異化就體現出來了,優勢也就明顯了。一個人或者一個企業不太可能做完所有的東西,他們在康莊大道上行使,而一些狹小的弄堂、胡同也可以溫飽滋養一批人/企業。
攜程是OTA領域無愧的老大哥了,在該領域依舊占據半壁江山。但隨著新星企業和商業模式的誕生,雖然不是直接競爭,但要穩固商業帝國就要不停擴張,停下來意味著將城池拱手相讓,都在找自己的第二增長曲線,那么后面大型公司都會圍繞自己的業務形成一個生態圈,或者強強聯合。
攜程在自己的票務領域也遭遇了很多外來競爭者,如美團的票務(出行+住宿+門票),短視頻內容平臺(抖音/小紅書等)對于門票和住宿的資源搶奪,畢竟文字不如圖片,圖片不如視頻,視頻不如人說,這是攜程在國內的危機。
攜程包含了衣食住行人安樂中的住行人安樂,其中住行樂為最主要的業務,當然也可能有朋友說是游,我個人認為游包含了出行和門票業務,游更多的是為了樂,因此并到樂中。
我們在這一期先來講講住。
我們這里講到的住有個特點是臨時性的,流動性大,因此單價相對長租來講也是比較貴的。
插個題外話,如果發展租房領域,按照短租的模式來推廣,可能會掀起一股熱潮,短期住沒有太多壓力,也方便,不好就換,還能提高租房領域服務,又能解決房多人少的問題,大多數情況下是房多人少的,只有在集中幾個日子才會出現供不應求的情況,當然上述只是題外話,如果真的需要做的話,還要設計價位(比長租貴,比酒店便宜),還要定位相應人群,因為搬家很累的,除非是做成酒店似的,只需要簡單的行李即可,那這樣成本就高了。
言歸正傳,上面講了住的特點,那么針對住的特點,會產生三種類型:酒店、民宿、短租。
酒店:這個無需多講,一直以來出門在外住個一兩天的都是旅館酒店,只是這種也分為單一的旅館和連鎖酒店,就像小賣部和連鎖超市的區別。
民宿:近幾年火起來的,主要住的是一個特色和感受,因為酒店千篇一律,沒有多少煙火氣息。就像我們去其他地方,想要體驗的也是這個地方的風土人情,在酒店中是很難體驗到的,現在人與人交流越來越少了(指的是當面的),那就需要從其他地方來補充這些人氣。這塊在旅游景點比較多,搭配著旅游景點,讓自己和景點融合在一起,在景點下棲息,真正做一回短暫的當地人。
短租:上面講到了,這塊如果純按上面兩種來做的話其實是一樣的,只是住的時間長短不一樣罷了,如果真的要當作一塊事業來做的話,那么中間的難點和困難就需要在做之前先了解大概,可以小范圍試運行,真等到想清楚了,可能機會也沒了,當然這么多年以來沒有人大力發展這塊領域,也肯定有其局限性,這是我們要深思的,自己是否比前人更懂這塊,是否能夠應對前人踩過的雷。因此這里把短租這類歸集為待開發的領域。
那么我們回到最初的問題,人們為什么會要求住,最直接的需求是什么?我們回想下我們為什么會住,那是因為方便,方便大致是兩點:
離得近:我們一定是趕不上或者不想起早要去的目的地才會選擇就近住下(當然也不排除是先休息再出發,只是作為中途補給下,那可能就是鐘點房這種),不然為啥不住家里呢,花這冤枉錢干嘛。
回不來:我們在外面,在我們完成我們的事情后,想要回到自己家里,發現回不來,要么太累了不想動了,要么沒有交通工具,總之想休息下。
當然也有一些可能就是想要在外面體驗下,主要還是上面兩種。
那么近是唯一的嗎?顯然不是,真正讓我們選擇的是天時地利人和,這個近(地利)也是相對的近,不是絕對的,幾百米的距離,大部分人還是可以接受的。刨除近這個因素,還會有什么因素會讓我們選擇呢?我覺得還有下面兩方面,分別對應天時和人和。
風景:對應天時,這里不是講的時間,是時機,在這邊看到的風景,感受到的最舒適,也可以說是環境。因為很少人會去一家臟亂差但是近的地方住。
價格:對應人和,這是商家給出的價格,是商家和客戶交朋友的一種方式,那么對于不同的人群,對價格的敏感度是比較高的,所以現在人們都追求性價比。
價格這塊還需要多說一點,因為現在殺熟宰客現象時常發生,會影響信譽,那么我們也分兩方面來說,一方面是酒店和酒店之間的價格,只要不太離譜,同段位的酒店價格出入不要太大即可;另一方面是平臺之間的價格,同一個酒店,在不同平臺上的價格如果相差很大的話,那么會被特意拿出來對比,即使在特殊時間段,供不應求的時候,也應該要節制,可以上漲點,因此價格競對機制也需要做好,不要讓自己成為眾矢之的。
01
在這里,我會使用人事物務法來分解這塊內容。
我們要了解這里的人具體包含了哪些人(或者是組織,特指以人為單位的個人或集體):
1. 人
- 享受方
- 住宿人(消費者)
- 服務方
酒店服務方:酒店人員(前臺、大堂經理、客服、保潔、維修人員等)。
平臺服務方:平臺人員(平臺客服,這是主要面對住宿人的,當然還有后面默默付出的產研人員、財務人員、業務人員等)。
我們要了解我們提到的相應的人員要做什么事情(其實也是結果,要做成什么事情),人和事加起來在特定的時間,就是場景,這也是我們解決問題,提供方案的一種考慮,不能脫離人事來做事。
2.?事
享受方:
簡單來講是住宿,那么住宿他需要做什么,預訂酒店、登記信息、支付住宿費、退房,當然他也可以做逆向操作,比如取消預訂、退房、退款、投訴(不開心)、推薦(開心)等。
服務方:
酒店服務方:
- 大堂經理/店長:管理整個酒店,為酒店整體負責,要看酒店的入住情況、安全情況、客訴情況、衛生情況、收支情況、評價情況等等。
- 前臺/客服:要為客戶辦理預訂、入住、登記、退房、結算、客戶疑問解答、客戶入住期間服務(如要洗漱用品等)。
- 保潔:在上一任客戶退房后,下一任客戶入住前的房間衛生打掃整理,為客戶提供一個干凈整潔的環境。
- 維修:可能是請外面的臨時工,一旦發現房間有物品損壞的,需要及時更換,以免客戶產生不滿,甚至產生危害。
平臺服務方:如果是不在第三方平臺入住的,是自有的平臺則平臺服務費即酒店服務方。
- 平臺客服:需要解答客戶在平臺上的操作問題,需要與酒店方進行溝通客戶的問題。
- 平臺業務/運營:需要與酒店溝通,邀請其入住,并幫助推廣。
- 平臺財務:需要對客戶的賬(支付/退款),需要與酒店進行結算對賬。
- 平臺產研:需要接到需求優化平臺,優化酒店端的系統,優化客戶端的系統,優化平臺自己的系統
了解了人和事情,那么需要了解相應操作的人依托什么進行操作,會有什么實物對操作有影響。
3. 物
享受方:
首先預訂的渠道,可以是線下(到前臺)、可以是線上(電話預約、手機在線預約、電腦在線預約或其他設備在線預約),這是和平臺酒店交互的內容,行李則是用戶自己的物品,那么這個物品會不會有另一種可能呢,我們后面會提到。
服務方:
酒店服務方:
- 大堂經理/店長:在管理人員的時候在什么設備上查看。
- 前臺/客服:他們接聽客戶需求是用話機還是呼叫系統,他們處理用戶事務是在電腦還是手機,他們在登記入住的時候使用的是什么設備,發票是如何開具。
- 保潔:有哪些房間需要打掃、使用什么工具、酒店物品排查,這些都需要用到庫存管理。
- 維修:特指酒店自己的,有哪些房間需要打掃、使用什么工具。
平臺服務方:
- 平臺業務/運營:酒店商家的錄入在哪些設備上可以操作。
- 平臺客服:應對消費者和酒店服務人員的語音通話是話機還是呼叫系統。
- 平臺財務:對于賬目核對在什么設備,發票開具在什么設備。
- 平臺產研:工作交流在什么系統或設備,以及產品所需要的一些硬件設備(如機房)。
我們在知道了有哪些人要做什么事,會用到什么工具的時候,接下來我們要把前面所講的事串起來的線以及最終產出的結果。務包含了兩層,一層是事務流,我們做一件事情,整體流程是怎么樣的,流程中包含哪些人和操作,分別會產生什么影響或結果;第二層是財務(或者叫數據),做一個企業,最終或者最好的結果是盈利,這樣才能夠持續經營,而如何體現這一結果,我們就需要有報表進行展示公司的盈虧情況,我們可以了解到人員成本、固定成本、營銷費用、產品銷量、客戶數量等等。有了這些數據分析出內容后,又可以很好指導我們的人員做相應的優化。
4. 事務流
享受方:
從預訂、入駐、退房、評價等相關節點與酒店平臺之間的交互。
服務方:
酒店服務方:
- 客服/前臺:協助客戶預訂、入駐、改簽、退房及其他服務的操作流程。
- 保潔:客戶退房、保潔維護、完成保潔、評價的流程。
- 維修:發現酒店設施問題,上報問題、預約維修、進行維修,完成維修、評價。
平臺服務方:
- 平臺業務/運營:客戶獲取,客戶簽約入駐,營銷活動推廣發布等流程。
- 平臺客服:客戶通話流程的記錄,問題工單的提交。
- 平臺財務:對賬流程,結算流程,開票流程。
- 平臺產研:工單流程。
5. 財務流(數據流)
享受方:
用戶查看自己的入駐記錄、自己的消費情況、自己的榮譽(等級或積分等)。
服務方:
酒店服務方:
- 大堂經理/店長:查看客戶數據(含新老客戶),入住數據(入住率比較),收入數據(含應收應付),訂單數據(含訂單來源,退單情況等),客訴數據,保潔數據,門店營銷數據,值班數據等。
- 前臺/客服:訂單數據,入住數據,保潔數據,維修數據,退房數據,客戶需求處理情況數據,值班數據。
- 保潔:退房數據,保潔數據,值班數據。
- 維修:維修數據,值班數據。
平臺服務方:
- 平臺業務/運營:門店數據,業績數據,活動數據。
- 平臺客服:客訴數據,工單處理數據。
- 平臺財務:賬單數據,結算數據,開票數據。
- 平臺產研:工單處理數據,客戶操作數據(埋點)。
02
攜程作為國內第一的票務服務平臺,他本身也投資酒店,有豐富的酒店管理經驗,也有大量的酒店預訂的數據。那么與攜程合作的酒店就有兩種合作方式:第一種直接入駐攜程的平臺,用戶在攜程客戶端或網上就可以預訂;第二種是攜程將自己的能力延伸,把自己的這套標準化的酒店管理系統做成SaaS來租給酒店,酒店使用攜程的酒店SaaS管理系統來進行自己酒店服務的售賣和推廣。
不管是入駐攜程還是使用攜程的SaaS系統,核心的目的和功能是不變的,只是形式上的變化,核心還是為客戶提供住房需求,那么我們圍繞這個核心訴求,畫一下客戶預訂到退房的整個流程,如下圖:
1. 流程解析
服務/商品上架:
從上述流程中我們可以看到,酒店要先上架自己的產品/服務,這里其實就是我們的客房,可能有些酒店還有其他的產品/服務可以提供,比如餐飲,上架這些產品/服務供客戶選擇。
瀏覽查詢服務/商品:
用戶可以在線查看客房信息,了解客房的價格、位置、室內裝飾、評價等。
預訂:
用戶經過一番對比,最終選擇一家滿意的酒店進行預訂操作,有了這個預訂動作后,客房的庫存將會被鎖定住,如果不被鎖定的話,那么可能出現多用戶預訂同一間(這個在后面會作為創新點提出),為了避免不必要的麻煩,在客戶選擇預訂后即鎖定庫存。除非用戶取消訂單或者長時間未支付或者管理員操作解鎖,庫存才會被釋放。
支付:
在預訂后,需要進行支付,只有支付完成后才算是真正的預訂了房間,錢落袋了才能讓商家心中安定。(這里也有一個變數點在后續提出)。
退款:
就算真正支付了,也不見得一定會入駐,也會有一定的幾率發生退款,用戶可以在訂單列表發起退款,那么一旦用戶發生了退款,有兩種方式:一種是直接退(無理由),另一種是需要審核通過(具體審核流程可設置)才可以退,那么要不要手續費呢?這個也是看酒店自己的意愿。
更改:
上述講的是用戶退款,其實也是用戶變卦的一種情況,另一種情況是用戶不退,但是要求變更預訂信息,時間或者房間或者其他,那么我們就需要提供這么一個口子給到用戶,那么是否有時間限制和變更手續費呢?這個也在酒店自身意愿。我們需要的是記錄好每一次操作。
入?。?/b>
終于到了開心的入住了,客人來了,那么這個入住也分為兩種,一種是之前在網上或者電話預約過的,這時只需要做人員登錄身份信息即可;另一種是沒有提前預約的,那么需要前臺工作人員手動將客戶信息錄入。
當然后續還有一個續約的環節,也放到這邊來講了,用戶可能會增加自己的入住時間,那么可以使用續約的功能,續約是繼續在該房間還是換房間,這個客戶自己選擇,酒店不會干預,因為如果干預不允許的話,客戶可以先退再訂,反而給大家都造成麻煩,但是換房間需要把房卡進行更新,不然會出事情。除非續約有優惠,才可能不允許更換的條件存在。
退房:
終于懸著的心落下來了,客戶安然離開酒店了,那么這個時候可能會有款項的退還(如押金),可能會有費用的補差(如使用某些產品)。
一切妥當后,可以說基本結束本次的訂單,后續要做的就是維護客戶,爭取回頭客(如果是連鎖的,那么品牌意識要強,不僅僅是自己這家)。
還有小插曲是,用戶可能會遺漏東西在住的地方,那么還沒有斷聯系,可以聯系交流,看如何處置。
雖然大部分是一次性客戶,可以要知道他不來住,不代表他認識的人不來住,口碑要打好。
講完了主流程,那么我們要來看看上面流程中所使用的包含哪些系統哪些模塊。
2. 系統模塊
我們首先講來給到酒店的系統。
首頁:
針對不同的角色展示不同的內容,比如針對管理員,那么他關心的數據有房間的入住率,會員的增長率,訂單的數據,收入的數據,客訴的數據,這些都是有時間的環比的,當然如果是連鎖酒店,那么管理員看到的將是所有酒店的數據,排名情況;如果是前臺人員,那么需要看到房間的情況(空置、入住、保潔、維修),可以快捷辦理入住,登記客戶信息,需要看到客戶數量(預訂未入住、預訂入住),看到押金退還數據,以及服務消息提示(如送餐、叫醒服務等)。
訂單管理:
預約:
用戶預約的訂單,包含未支付、已支付、已退單、部分退單(看實際是否需要)、改單,是以下單人為單位的數據,需要的信息:下單人的信息、房間信息、入住信息、價格信息、支付信息,可辦理退單,退單需同步至入住和退單;可以操作改單,需同步至入住和改單;前臺人員需要給預約的客戶安排房間。
入住:
展示的是已支付的訂單數據,包含待入住、入住中、已退房,是以房間為單位的數據,與預約是多對一的關系(一個訂單可以預訂多個房間),需要的信息:房間信息、入住人信息、關聯預約信息、可辦理退單,需同步到預約和退單。
退單:
展示的是退單信息,數據由用戶處或者工作人員在預約和入住中操作退單而來,退單是否允許部分退可根據酒店或者平臺規則來,是否需要審核也根據平臺自己的規則來。
改單:
改單信息來源于用戶在平臺上操作或者工作人員在后臺操作,手續費啥的也是根據每個酒店自身情況決定的。
押金:
有些時候是有押金的概念存在的,那么在客戶退房的時候,需要將押金退還給客戶,而如果客戶在入住期間使用了房間的一些物品,那么會有抵扣,退多少錢就需要記錄了并關聯到【其他】中。
其他:
除開入住這個大頭,還有些零散的消費,比如說餐飲、酒水等也是需要下單收費的。
房間管理:
房間列表:
需要看到酒店所有的房間,房間的入住情況、創收情況、保潔情況、維修情況,房間的基本信息。
在我們創建房間的時候,需要批量創建,批量創建有兩種形式,只是操作上的區別,一種是創建的時候,所有信息一起創建,包括房型、圖片、介紹、服務、價格等等,然后把房間號段區間寫入后批量生成,當然導入表格生成也行;第二種是提前設置好房型及服務信息,然后在創建房間的時候,只需要填寫房間號段區間即可。
這里還需要一個使用記錄,包含房間的創建、修改、預訂、入住、退房、退單、保潔、維修等,根據時間順序展示,或者根據不同類型模塊化展示,因為一般情況是創建修改屬于房間的基本信息修改模塊,客戶的預訂到退房到保潔屬于一整套房間使用的模塊,維修是單獨的模塊或者客戶在入住期間發現問題進行維修的,可以和客戶入住期間的使用放在一塊。
房間保潔:
記錄的是每次房間保潔的數據,包含房間信息、保潔人信息、保潔時間、上任退房人員信息(如果這邊不展示,那么在房間列表中房間使用記錄中要有明確的操作記錄)。
保潔數據是基于客戶反饋和退房,安排的保潔人員是根據排班進行分配。
房間維修:
記錄的是每次房間維修的數據,包含房間信息、維修人員、維修時間、維修事項。
維修數據來源:用戶在平臺上反饋,保潔在打掃時反饋,可以由前臺進行分配維修人員,可以是維修人員搶單,這在系統中又有不同的功能。
物品管理:
房間物品:
房間物品包含四件套、毛巾牙刷、拖鞋、洗發水、沐浴露等及其他房間的設施,酒店在布置好整個房間后,會有物品的盈余,用作后備,當四件套之類的保潔拿去換洗的時候,肯定要用備用的物品替換上,這個時候,物品的庫存就要相應的變化,或者物品損壞了要丟棄,則需要修改庫存,不僅僅現有庫存要修改,總庫存也需要修改。
房間商品:
房間里面的一些飲料泡面啥的,或者其他的商品也是需要進行庫存管理的,在退房時需要盤點下物品是否被使用,一方面是要補充物品,另一方面是要收取一定費用。
保潔物品:
保潔人員在打掃衛生使用的工具,也可以納入管理,畢竟整個酒店這么大,所需要的清潔劑等也是大量的,也需要進行維護。
維修物品:
這個看酒店需要是否納入維護,如果難得維修,那么也就不需要維修人員和維修材料了,可以臨時請專業維修人員進行維修。
失物列表:
這個主要管理的是客戶在酒店遺失的物品,這需要匹配好丟失物件信息和丟失地點和時間,以防冒領。
采購列表:
針對上述房間物品、房間商品、保潔物品和維修物品做采購申請,采購后需要將庫存同步到相應類型的物品庫存中。
客戶管理:
客戶列表:
主要記錄客戶的信息,包含基本信息(個人姓名、昵稱、手機號、身份證、性別等)、客戶的賬戶信息(是否有充值,是否有余額,是否有積分);客戶身份/等級;客戶消費情況(入住次數、消費金額)。
客訴列表:
記錄客戶投訴/反饋。
客戶等級與積分:
在這塊需要設置客戶等級的晉升條件,以及獲取積分的渠道和數值。
營銷管理:
活動列表:
這里講了營銷活動的管理,包含平時的打折促銷分享獲利活動,拉新活動,客戶關懷活動(如生日)等,活動是一種快速積累人氣和資本的手段,針對不同客群設置不同的活動主題和內容,用于拉新、留存等。
也有像平臺申請的營銷功能,如搜索關鍵詞,首頁推薦等等。
套餐列表:
涵蓋了住宿、餐飲、活動等,可以與出行、景點結合打包售賣,還有一些針對家庭的,針對團體的套餐,根據不同客戶的需求可打造適合客戶的套餐。
營銷當濃妝重抹說下,營銷有主動營銷和被動營銷。
主動營銷現在在市面上有很多玩法,基本可以參考電商的玩法,如拼團、優惠券、秒殺、老帶新、會員充值等等,只需要關注電商即可,不能盲目照抄,要看是否適合自身的產品以及要想如何與自身的特點結合起來。
被動營銷也分為兩類,一類是逆營銷,一類是順營銷。
逆營銷是同行在做的營銷活動且做得蠻不錯,那么對于自身的市場份額和品牌知名度會有所營銷,這時可能需要跟著對方來做相同的策略或者需要策劃一場在他人之上的營銷策略。
順營銷則是口碑相傳,這個就在于自身的品牌和服務或者價格讓消費者極度滿意后他們會在自己的圈子中分享自己享受到的待遇。這種營銷是可遇不可求的,指不定哪天誰分享了一下就爆了,所以我們要時刻做準備,只要在認真服務消費者這條道路上走,遲早會有驚喜的一天。
報表管理:
報表管理是最終交的一份答卷,在這里面可以從上到下,從粗到細一覽整個酒店的盈虧情況,然后從盈虧情況再逐個細項展開分析原因,可以直觀感受到經營情況,也可使用可視化大屏展示。
入住報表:
酒店業務最主要的就是客戶入住,從入住報表中就要看到不同時間段(日周月年,節假日)的數據,并與往期進行對比,可以是環比。
需要看到整個酒店的入住率的變化,不同房型入住率的排名。
客戶入住來自不同的平臺下單,可以看到各個來源的數據,后期知道在哪里加大推廣力度。
客戶報表:
客戶是經濟命脈,那么就需要對客戶全方面的了解,來打造自己的產品,從各個方面深挖客戶的基本信息。
收入報表:
收入是酒店(企業)能夠一直經營下去的動力,利潤來源于收入。我們要了解收入的版塊來自哪里,從而找到明星產品。
支出列表:
上面講的是收入的內容,隨之而來的就是支出(含成本),作為經營者,需要了解自己的錢花在了什么地方,花的值不值。
客訴報表:
這是服務調整優化的一步,上面已經講了客戶的重要性,那么針對客戶的問題顯然是比較重要的,那么我們需要分析客戶在哪些地方產生了不滿,是對我們的人還是服務還是價格等不滿,這也是酒店變好的關鍵一步。
財務管理:
財務環節就需要對資金進行盤點、對賬和清結算了,這里面涉及各種扣點費率以及從各個支付通道收來錢的通道手續費。
利潤表:
統算所有的收入和支出,形成最終的利潤表,如果要做成資產表的話還需要折算當前酒店內的所有的固定資產。
應收賬款:
展示各個渠道所服務沒有到賬的金額,有些與平臺簽約有定時結算的。
應付賬款:
有些酒店與平臺簽約的是平臺抽傭,但是收款方是酒店,那么會定期給平臺分傭;還有些是給客戶退款或者是采購物品的錢。
開票管理:
酒店會給客戶進行開票,如果他們需要的話。開票方式的話可以是老式的盤開,現在也有數控發票,由付款方進行申請。
開票整個流程也要進行記錄確認,不能重復開票,開票可以自己接開票系統,可以使用平臺的。
組織架構:
組織架構不需要弄的太復雜,正常的樹形結構,包含部門和人員(含負責人)即可。這里有個排班,酒店業務需要每天有人值班和打掃,因此需要有24小時值守的,也就需要有排班,三班倒或者兩班倒這個看酒店自己安排。
配置管理:
酒店一些設施需要進行配置,像房型、短信、標簽等,配置管理的功能不僅限于此,要發現常規活動中哪些節點上或頁面上的字段是經常變動的,是有差異性的,那么可以將其納入可配置的范圍。配置其實是最直觀的最淺層的無代碼了,當所有可配時就是真無代碼。
系統管理:
權限管理:
可以選用市面上比較完善的RBAC模式進行設計,從頁面層面、操作層面、數據層面進行設置,配以角色或者角色組,能適用于90%以上的企業使用。
酒店信息維護:
酒店信息一方面是為了入駐平臺使用(如果是自研的則不包含本項),另一方面是給消費者看的,一方面增加消費者的信心,消費者是很怕三無產品的,另一方面如果是品牌連鎖,則會大大增加消費者的好感,因此酒店的信息就是酒店的一張名片,需要突出特色。
字段有酒店名稱、logo、營業時間、簡介、客服電話、負責人、負責人電話、地址、營業執照、身份證、圖片/視頻、標簽、詳情(亮點、服務、注意事項等)。
系統日志:
每個系統都需要日志維護,在關鍵時刻可以找到歷史記錄和人員操作記錄,對于系統的容錯有比較大的作用,畢竟當一個系統沒有記錄時,做錯了反正也沒人知道,那樣就容易松懈。
其實還有數據字典、安全設置、集成設置、支付設置等等,這個看具體酒店規模和平臺是否有,有些注重主體使用功能,當做大了會在很多細節層面以及底層架構應用層面進行展示和設置。
以上講的是基于酒店后臺管理系統相關的功能模塊,如果是加盟的平臺,那么平臺的功能和酒店的有什么區別呢?
平臺的功能布局:
除開上述酒店管理后臺自身的功能,這些平臺都需要有,而自身作為多酒店入住的平臺,更需要的是對酒店客戶的維護,數據的維護,系統的維護,以及作為中間平臺對酒店和消費者起到承上啟下作用。
酒店的維護也是對于平臺業務人員進行考核的一個指標,應該有一套CRM系統才承接這塊功能,消費者也會為我們發現優質和不好的客戶,那么平臺會多扶持優質客戶,劣質客戶則可以勸退,以免影響消費者的體驗。
對于消費者的維護,則可以使用統一的會員數據,因為在平臺上不僅僅是酒店業務還有其他的業務,那么消費者是同一個,因此在不同業務之間,消費者的數據是可以抽出來作為公共數據庫,可能在不同的業務中,消費者的標簽是不一樣的,但基礎信息是一樣的,可以從一個地方取和存,各自業務的不同點,可以自己維護客戶的信息。
當然還有一些公共的組件和應用可以抽離出來,像push、CallCenter、msg、支付等等,這些在最后一期的企業級架構中體現出來。
最關鍵的也是數據這塊,作為一個平臺,擁有多應用,也需要衡量哪些業務掙錢,那些業務虧損,哪些業務值得做下去,哪些業務需要及時止損。
對于一個龐大的平臺,做改造是不容易的,另起爐灶開創一個新條線可能是第二增長曲線,一般酒店買一套系統或者定做一套系統花不了幾個錢,但是他們的業務深度不一定夠,所考慮的場景和功能可能不齊全,因此,大型平臺會將自身的優勢做進一步延伸——提供SaaS服務,為酒店賦能。
平臺上流量的穩定和增長是開發各種變現項目的資本,所以一方面平臺要穩固自己的消費者(流量)和商戶,一方面要做深自己的業務(行業壁壘)。再向周邊產品延伸,擴大自己的生態圈,不一定全部要自己做,一部分要學會合作,把別人研究多年的技術和經驗結合在自己的產品服務上,實現共贏。
一些小思路
送餐/送東西:
目前大部分酒店是含早餐的,但有一種現象,雖然訂的房間含早餐,但是有時間限制,這個時候是否可以有預訂服務,客戶把自己想吃的提前點好,然后工作人員幫忙準備好,并放在保溫箱中,等用戶要吃的時候,可以拿出來給到用戶。當然現在人工智能的發展,可以交代機器人進行送餐。
一些客戶在酒店的時候,也會有外賣或者快遞進來。而有一個固定的點進行配送,對于客戶來講是一件便利的事情。
當然不是白干活,配套優惠(工作人員如果想多掙點錢,可以在空余時間去幫客戶拿東西),因為外賣應該不可以進入酒店內部,只能放在前臺,那酒店的工作人員是可以完成這最后10米。也如上面講的,一些大的酒店是有機器人服務的,這就更省力了。
先住后付:
這也是前面講到的,沒有付款,酒店心中不踏實,也不排除有些酒店開始了先住后付,這是有風險了,是一種大膽的嘗試,那如果實行這種操作的話,就需要在付款訂單這塊做改變以及對客戶信用做記錄,可以效仿打車支付的套路,未支付前不能再次下單。
可選擇房間號:
目前我們在選擇酒店的時候,只有房型,沒有房號和布局圖,一開始買火車票也是沒有座位號的,后面就有了,這樣讓客戶感覺很好,選擇自己想要的位置,那么有些客戶對數字敏感的,也許選到自己心儀的房間號,會增加入住的好感。
那么選擇房間號可能就比火車座位復雜點了,這個就可以效仿電影票選座位的形式了,還能知道哪些被預定了,房間在哪個位置等等。當然酒店經營慘淡的話,可以不顯示哪些被預定了,只展示可選擇哪些房間號即可。
快遞業務:
這個可能是增收的項目,大部分用戶在外出住酒店會有大包小包的東西,那么對于客戶來說是比較繁重的,這個時候如果可以直接將東西郵寄到酒店,客戶只需要輕裝前往即可。
用戶的行李托運,郵寄內容,可以直接郵寄到客戶預訂的酒店,酒店安排好直接放入房間或者由客戶自己拿上去。方便客戶出行的便捷。
這是一方面,另一方面用戶出來旅游的,難免會有禮物需要帶回去,這個時候也可以在酒店直接寄出,甚至不需要自己手動寄(等快遞員來)。
當然現在一些購物門店是可以留下地址幫忙把禮物寄回去的,有些則不可以。而為了方便,客戶的東西可以安排自己住的酒店幫忙郵寄,客戶只需要下好單后(直接在平臺上下單),由工作人員幫忙給到快遞就行,那么快遞員到來,詢問驗證碼,客戶可以授權給酒店。
而平臺去談快遞業務的話,會比個人談下來的價格便宜,這個既是給客戶減少快遞費,也是自身的一個盈利渠道,酒店幫忙寄快遞的呢也可以分成,一單多少錢,這可能是多贏的局面。
競價機制:
之前在網上看到去年五一的黃金周,旅游業迎來了復蘇,住宿也是水漲船高,那么各大平臺上的酒店都被預定空了,甚至出現了商家退款漲錢再租的現象,吃相不好,而平臺之間針對同一酒店的房間,價格也層次不齊,在幾十塊錢以內還好,現在出現了差價幾百,在網上也引起了一陣熱鬧。
攜程雖然是最早從事這一行的,也有酒店資源,但現在慢慢被后起之秀(美團)趕上,后面還有飛豬等環伺,在價格方面處理不好容易對平臺受損,大多數消費者是多平臺參考選擇價格更低的,因此在價格上要做好與競爭對手同步。
本文描述的主要是站在酒店層面考慮的功能,平臺層面的涉及不多,里面還有很多細節是值得推敲的和打磨的,這些優點在于對業務的深入,對實踐的操作,對以往的分析,對當下的思考和對未來的判斷。
大廈不是一蹴而就的,也不是頃刻倒塌的,都會經歷一個過程,在起來的時候是步步為營,是站在了問題上出手解決了問題;倒下的時候一定也是一步步做錯,最后潰于蟻穴。
酒店業務的我們都在關注的是如何舒適,如何差異化,我們都忽略的點其實至關重要——安全和隱私,就像我們平常的呼吸一樣,這個會在第三期中講解。
不正之處,請不吝指教!
本文由 @詩憶錄 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!