【产品经理修炼之道】- 携程酒店业务

这篇文章里,作者以携程为参照对象进行了业务分析,一起来看看本文作者关于携程酒店业务的思考。想了解OTA、或者酒店业务的同学们,或许可以来看看本文的思路。

本文是以携程为参照对象做的一个业务分析,系列一共有三期,本篇为第一期。

社会的发展离不开经济,经济是由商业活动而来的,而之前的商业活动主要围绕着衣食住行,哪怕是当前以及未来,这些都是根基,是不会变化的,这也是所有企业都在向之靠拢的原因,因为只有靠上这几类才能赚钱,赚钱才能更好的拥有这几类。

而当下我觉得还应该再加几类,因为随着生活水平的提高,有新的需求点被放大,这几类分别是人安乐。那么加在一起就是七项:衣食住行人安乐,肯定还会有其他需求项我所没有想到的,更多的是垂直类的,这也是机会的所在,切入更细的赛道更细分的领域的时候,发现更多细节的时候,所能做的差异化就体现出来了,优势也就明显了。一个人或者一个企业不太可能做完所有的东西,他们在康庄大道上行使,而一些狭小的弄堂、胡同也可以温饱滋养一批人/企业。

携程是OTA领域无愧的老大哥了,在该领域依旧占据半壁江山。但随着新星企业和商业模式的诞生,虽然不是直接竞争,但要稳固商业帝国就要不停扩张,停下来意味着将城池拱手相让,都在找自己的第二增长曲线,那么后面大型公司都会围绕自己的业务形成一个生态圈,或者强强联合。

携程在自己的票务领域也遭遇了很多外来竞争者,如美团的票务(出行+住宿+门票),短视频内容平台(抖音/小红书等)对于门票和住宿的资源抢夺,毕竟文字不如图片,图片不如视频,视频不如人说,这是携程在国内的危机。

携程包含了衣食住行人安乐中的住行人安乐,其中住行乐为最主要的业务,当然也可能有朋友说是游,我个人认为游包含了出行和门票业务,游更多的是为了乐,因此并到乐中。

我们在这一期先来讲讲住。

我们这里讲到的住有个特点是临时性的,流动性大,因此单价相对长租来讲也是比较贵的。

插个题外话,如果发展租房领域,按照短租的模式来推广,可能会掀起一股热潮,短期住没有太多压力,也方便,不好就换,还能提高租房领域服务,又能解决房多人少的问题,大多数情况下是房多人少的,只有在集中几个日子才会出现供不应求的情况,当然上述只是题外话,如果真的需要做的话,还要设计价位(比长租贵,比酒店便宜),还要定位相应人群,因为搬家很累的,除非是做成酒店似的,只需要简单的行李即可,那这样成本就高了。

言归正传,上面讲了住的特点,那么针对住的特点,会产生三种类型:酒店、民宿、短租。

酒店:这个无需多讲,一直以来出门在外住个一两天的都是旅馆酒店,只是这种也分为单一的旅馆和连锁酒店,就像小卖部和连锁超市的区别。

民宿:近几年火起来的,主要住的是一个特色和感受,因为酒店千篇一律,没有多少烟火气息。就像我们去其他地方,想要体验的也是这个地方的风土人情,在酒店中是很难体验到的,现在人与人交流越来越少了(指的是当面的),那就需要从其他地方来补充这些人气。这块在旅游景点比较多,搭配着旅游景点,让自己和景点融合在一起,在景点下栖息,真正做一回短暂的当地人。

短租:上面讲到了,这块如果纯按上面两种来做的话其实是一样的,只是住的时间长短不一样罢了,如果真的要当作一块事业来做的话,那么中间的难点和困难就需要在做之前先了解大概,可以小范围试运行,真等到想清楚了,可能机会也没了,当然这么多年以来没有人大力发展这块领域,也肯定有其局限性,这是我们要深思的,自己是否比前人更懂这块,是否能够应对前人踩过的雷。因此这里把短租这类归集为待开发的领域。

那么我们回到最初的问题,人们为什么会要求住,最直接的需求是什么?我们回想下我们为什么会住,那是因为方便,方便大致是两点:

离得近:我们一定是赶不上或者不想起早要去的目的地才会选择就近住下(当然也不排除是先休息再出发,只是作为中途补给下,那可能就是钟点房这种),不然为啥不住家里呢,花这冤枉钱干嘛。

回不来:我们在外面,在我们完成我们的事情后,想要回到自己家里,发现回不来,要么太累了不想动了,要么没有交通工具,总之想休息下。

当然也有一些可能就是想要在外面体验下,主要还是上面两种。

那么近是唯一的吗?显然不是,真正让我们选择的是天时地利人和,这个近(地利)也是相对的近,不是绝对的,几百米的距离,大部分人还是可以接受的。刨除近这个因素,还会有什么因素会让我们选择呢?我觉得还有下面两方面,分别对应天时和人和。

风景:对应天时,这里不是讲的时间,是时机,在这边看到的风景,感受到的最舒适,也可以说是环境。因为很少人会去一家脏乱差但是近的地方住。

价格:对应人和,这是商家给出的价格,是商家和客户交朋友的一种方式,那么对于不同的人群,对价格的敏感度是比较高的,所以现在人们都追求性价比。

价格这块还需要多说一点,因为现在杀熟宰客现象时常发生,会影响信誉,那么我们也分两方面来说,一方面是酒店和酒店之间的价格,只要不太离谱,同段位的酒店价格出入不要太大即可;另一方面是平台之间的价格,同一个酒店,在不同平台上的价格如果相差很大的话,那么会被特意拿出来对比,即使在特殊时间段,供不应求的时候,也应该要节制,可以上涨点,因此价格竞对机制也需要做好,不要让自己成为众矢之的。

01

在这里,我会使用人事物务法来分解这块内容。

我们要了解这里的人具体包含了哪些人(或者是组织,特指以人为单位的个人或集体):

1. 人

  • 享受方
  • 住宿人(消费者)
  • 服务方

酒店服务方:酒店人员(前台、大堂经理、客服、保洁、维修人员等)。

平台服务方:平台人员(平台客服,这是主要面对住宿人的,当然还有后面默默付出的产研人员、财务人员、业务人员等)。

我们要了解我们提到的相应的人员要做什么事情(其实也是结果,要做成什么事情),人和事加起来在特定的时间,就是场景,这也是我们解决问题,提供方案的一种考虑,不能脱离人事来做事。

2. 事

享受方:

简单来讲是住宿,那么住宿他需要做什么,预订酒店、登记信息、支付住宿费、退房,当然他也可以做逆向操作,比如取消预订、退房、退款、投诉(不开心)、推荐(开心)等。

服务方:

酒店服务方:

  • 大堂经理/店长:管理整个酒店,为酒店整体负责,要看酒店的入住情况、安全情况、客诉情况、卫生情况、收支情况、评价情况等等。
  • 前台/客服:要为客户办理预订、入住、登记、退房、结算、客户疑问解答、客户入住期间服务(如要洗漱用品等)。
  • 保洁:在上一任客户退房后,下一任客户入住前的房间卫生打扫整理,为客户提供一个干净整洁的环境。
  • 维修:可能是请外面的临时工,一旦发现房间有物品损坏的,需要及时更换,以免客户产生不满,甚至产生危害。

平台服务方:如果是不在第三方平台入住的,是自有的平台则平台服务费即酒店服务方。

  • 平台客服:需要解答客户在平台上的操作问题,需要与酒店方进行沟通客户的问题。
  • 平台业务/运营:需要与酒店沟通,邀请其入住,并帮助推广。
  • 平台财务:需要对客户的账(支付/退款),需要与酒店进行结算对账。
  • 平台产研:需要接到需求优化平台,优化酒店端的系统,优化客户端的系统,优化平台自己的系统

了解了人和事情,那么需要了解相应操作的人依托什么进行操作,会有什么实物对操作有影响。

3. 物

享受方:

首先预订的渠道,可以是线下(到前台)、可以是线上(电话预约、手机在线预约、电脑在线预约或其他设备在线预约),这是和平台酒店交互的内容,行李则是用户自己的物品,那么这个物品会不会有另一种可能呢,我们后面会提到。

服务方:

酒店服务方:

  • 大堂经理/店长:在管理人员的时候在什么设备上查看。
  • 前台/客服:他们接听客户需求是用话机还是呼叫系统,他们处理用户事务是在电脑还是手机,他们在登记入住的时候使用的是什么设备,发票是如何开具。
  • 保洁:有哪些房间需要打扫、使用什么工具、酒店物品排查,这些都需要用到库存管理。
  • 维修:特指酒店自己的,有哪些房间需要打扫、使用什么工具。

平台服务方:

  • 平台业务/运营:酒店商家的录入在哪些设备上可以操作。
  • 平台客服:应对消费者和酒店服务人员的语音通话是话机还是呼叫系统。
  • 平台财务:对于账目核对在什么设备,发票开具在什么设备。
  • 平台产研:工作交流在什么系统或设备,以及产品所需要的一些硬件设备(如机房)。

我们在知道了有哪些人要做什么事,会用到什么工具的时候,接下来我们要把前面所讲的事串起来的线以及最终产出的结果。务包含了两层,一层是事务流,我们做一件事情,整体流程是怎么样的,流程中包含哪些人和操作,分别会产生什么影响或结果;第二层是财务(或者叫数据),做一个企业,最终或者最好的结果是盈利,这样才能够持续经营,而如何体现这一结果,我们就需要有报表进行展示公司的盈亏情况,我们可以了解到人员成本、固定成本、营销费用、产品销量、客户数量等等。有了这些数据分析出内容后,又可以很好指导我们的人员做相应的优化。

4. 事务流

享受方:

从预订、入驻、退房、评价等相关节点与酒店平台之间的交互。

服务方:

酒店服务方:

  • 客服/前台:协助客户预订、入驻、改签、退房及其他服务的操作流程。
  • 保洁:客户退房、保洁维护、完成保洁、评价的流程。
  • 维修:发现酒店设施问题,上报问题、预约维修、进行维修,完成维修、评价。

平台服务方:

  • 平台业务/运营:客户获取,客户签约入驻,营销活动推广发布等流程。
  • 平台客服:客户通话流程的记录,问题工单的提交。
  • 平台财务:对账流程,结算流程,开票流程。
  • 平台产研:工单流程。

5. 财务流(数据流)

享受方:

用户查看自己的入驻记录、自己的消费情况、自己的荣誉(等级或积分等)。

服务方:

酒店服务方:

  • 大堂经理/店长:查看客户数据(含新老客户),入住数据(入住率比较),收入数据(含应收应付),订单数据(含订单来源,退单情况等),客诉数据,保洁数据,门店营销数据,值班数据等。
  • 前台/客服:订单数据,入住数据,保洁数据,维修数据,退房数据,客户需求处理情况数据,值班数据。
  • 保洁:退房数据,保洁数据,值班数据。
  • 维修:维修数据,值班数据。

平台服务方:

  • 平台业务/运营:门店数据,业绩数据,活动数据。
  • 平台客服:客诉数据,工单处理数据。
  • 平台财务:账单数据,结算数据,开票数据。
  • 平台产研:工单处理数据,客户操作数据(埋点)。

02

携程作为国内第一的票务服务平台,他本身也投资酒店,有丰富的酒店管理经验,也有大量的酒店预订的数据。那么与携程合作的酒店就有两种合作方式:第一种直接入驻携程的平台,用户在携程客户端或网上就可以预订;第二种是携程将自己的能力延伸,把自己的这套标准化的酒店管理系统做成SaaS来租给酒店,酒店使用携程的酒店SaaS管理系统来进行自己酒店服务的售卖和推广。

不管是入驻携程还是使用携程的SaaS系统,核心的目的和功能是不变的,只是形式上的变化,核心还是为客户提供住房需求,那么我们围绕这个核心诉求,画一下客户预订到退房的整个流程,如下图:

1. 流程解析

服务/商品上架:

从上述流程中我们可以看到,酒店要先上架自己的产品/服务,这里其实就是我们的客房,可能有些酒店还有其他的产品/服务可以提供,比如餐饮,上架这些产品/服务供客户选择。

浏览查询服务/商品:

用户可以在线查看客房信息,了解客房的价格、位置、室内装饰、评价等。

预订:

用户经过一番对比,最终选择一家满意的酒店进行预订操作,有了这个预订动作后,客房的库存将会被锁定住,如果不被锁定的话,那么可能出现多用户预订同一间(这个在后面会作为创新点提出),为了避免不必要的麻烦,在客户选择预订后即锁定库存。除非用户取消订单或者长时间未支付或者管理员操作解锁,库存才会被释放。

支付:

在预订后,需要进行支付,只有支付完成后才算是真正的预订了房间,钱落袋了才能让商家心中安定。(这里也有一个变数点在后续提出)。

退款:

就算真正支付了,也不见得一定会入驻,也会有一定的几率发生退款,用户可以在订单列表发起退款,那么一旦用户发生了退款,有两种方式:一种是直接退(无理由),另一种是需要审核通过(具体审核流程可设置)才可以退,那么要不要手续费呢?这个也是看酒店自己的意愿。

更改:

上述讲的是用户退款,其实也是用户变卦的一种情况,另一种情况是用户不退,但是要求变更预订信息,时间或者房间或者其他,那么我们就需要提供这么一个口子给到用户,那么是否有时间限制和变更手续费呢?这个也在酒店自身意愿。我们需要的是记录好每一次操作。

入住:

终于到了开心的入住了,客人来了,那么这个入住也分为两种,一种是之前在网上或者电话预约过的,这时只需要做人员登录身份信息即可;另一种是没有提前预约的,那么需要前台工作人员手动将客户信息录入。

当然后续还有一个续约的环节,也放到这边来讲了,用户可能会增加自己的入住时间,那么可以使用续约的功能,续约是继续在该房间还是换房间,这个客户自己选择,酒店不会干预,因为如果干预不允许的话,客户可以先退再订,反而给大家都造成麻烦,但是换房间需要把房卡进行更新,不然会出事情。除非续约有优惠,才可能不允许更换的条件存在。

退房:

终于悬着的心落下来了,客户安然离开酒店了,那么这个时候可能会有款项的退还(如押金),可能会有费用的补差(如使用某些产品)。

一切妥当后,可以说基本结束本次的订单,后续要做的就是维护客户,争取回头客(如果是连锁的,那么品牌意识要强,不仅仅是自己这家)。

还有小插曲是,用户可能会遗漏东西在住的地方,那么还没有断联系,可以联系交流,看如何处置。

虽然大部分是一次性客户,可以要知道他不来住,不代表他认识的人不来住,口碑要打好。

讲完了主流程,那么我们要来看看上面流程中所使用的包含哪些系统哪些模块。

2. 系统模块

我们首先讲来给到酒店的系统。

首页:

针对不同的角色展示不同的内容,比如针对管理员,那么他关心的数据有房间的入住率,会员的增长率,订单的数据,收入的数据,客诉的数据,这些都是有时间的环比的,当然如果是连锁酒店,那么管理员看到的将是所有酒店的数据,排名情况;如果是前台人员,那么需要看到房间的情况(空置、入住、保洁、维修),可以快捷办理入住,登记客户信息,需要看到客户数量(预订未入住、预订入住),看到押金退还数据,以及服务消息提示(如送餐、叫醒服务等)。

订单管理:

预约:

用户预约的订单,包含未支付、已支付、已退单、部分退单(看实际是否需要)、改单,是以下单人为单位的数据,需要的信息:下单人的信息、房间信息、入住信息、价格信息、支付信息,可办理退单,退单需同步至入住和退单;可以操作改单,需同步至入住和改单;前台人员需要给预约的客户安排房间。

入住:

展示的是已支付的订单数据,包含待入住、入住中、已退房,是以房间为单位的数据,与预约是多对一的关系(一个订单可以预订多个房间),需要的信息:房间信息、入住人信息、关联预约信息、可办理退单,需同步到预约和退单。

退单:

展示的是退单信息,数据由用户处或者工作人员在预约和入住中操作退单而来,退单是否允许部分退可根据酒店或者平台规则来,是否需要审核也根据平台自己的规则来。

改单:

改单信息来源于用户在平台上操作或者工作人员在后台操作,手续费啥的也是根据每个酒店自身情况决定的。

押金:

有些时候是有押金的概念存在的,那么在客户退房的时候,需要将押金退还给客户,而如果客户在入住期间使用了房间的一些物品,那么会有抵扣,退多少钱就需要记录了并关联到【其他】中。

其他:

除开入住这个大头,还有些零散的消费,比如说餐饮、酒水等也是需要下单收费的。

房间管理:

房间列表:

需要看到酒店所有的房间,房间的入住情况、创收情况、保洁情况、维修情况,房间的基本信息。

在我们创建房间的时候,需要批量创建,批量创建有两种形式,只是操作上的区别,一种是创建的时候,所有信息一起创建,包括房型、图片、介绍、服务、价格等等,然后把房间号段区间写入后批量生成,当然导入表格生成也行;第二种是提前设置好房型及服务信息,然后在创建房间的时候,只需要填写房间号段区间即可。

这里还需要一个使用记录,包含房间的创建、修改、预订、入住、退房、退单、保洁、维修等,根据时间顺序展示,或者根据不同类型模块化展示,因为一般情况是创建修改属于房间的基本信息修改模块,客户的预订到退房到保洁属于一整套房间使用的模块,维修是单独的模块或者客户在入住期间发现问题进行维修的,可以和客户入住期间的使用放在一块。

房间保洁:

记录的是每次房间保洁的数据,包含房间信息、保洁人信息、保洁时间、上任退房人员信息(如果这边不展示,那么在房间列表中房间使用记录中要有明确的操作记录)。

保洁数据是基于客户反馈和退房,安排的保洁人员是根据排班进行分配。

房间维修:

记录的是每次房间维修的数据,包含房间信息、维修人员、维修时间、维修事项。

维修数据来源:用户在平台上反馈,保洁在打扫时反馈,可以由前台进行分配维修人员,可以是维修人员抢单,这在系统中又有不同的功能。

物品管理:

房间物品:

房间物品包含四件套、毛巾牙刷、拖鞋、洗发水、沐浴露等及其他房间的设施,酒店在布置好整个房间后,会有物品的盈余,用作后备,当四件套之类的保洁拿去换洗的时候,肯定要用备用的物品替换上,这个时候,物品的库存就要相应的变化,或者物品损坏了要丢弃,则需要修改库存,不仅仅现有库存要修改,总库存也需要修改。

房间商品:

房间里面的一些饮料泡面啥的,或者其他的商品也是需要进行库存管理的,在退房时需要盘点下物品是否被使用,一方面是要补充物品,另一方面是要收取一定费用。

保洁物品:

保洁人员在打扫卫生使用的工具,也可以纳入管理,毕竟整个酒店这么大,所需要的清洁剂等也是大量的,也需要进行维护。

维修物品:

这个看酒店需要是否纳入维护,如果难得维修,那么也就不需要维修人员和维修材料了,可以临时请专业维修人员进行维修。

失物列表:

这个主要管理的是客户在酒店遗失的物品,这需要匹配好丢失物件信息和丢失地点和时间,以防冒领。

采购列表:

针对上述房间物品、房间商品、保洁物品和维修物品做采购申请,采购后需要将库存同步到相应类型的物品库存中。

客户管理:

客户列表:

主要记录客户的信息,包含基本信息(个人姓名、昵称、手机号、身份证、性别等)、客户的账户信息(是否有充值,是否有余额,是否有积分);客户身份/等级;客户消费情况(入住次数、消费金额)。

客诉列表:

记录客户投诉/反馈。

客户等级与积分:

在这块需要设置客户等级的晋升条件,以及获取积分的渠道和数值。

营销管理:

活动列表:

这里讲了营销活动的管理,包含平时的打折促销分享获利活动,拉新活动,客户关怀活动(如生日)等,活动是一种快速积累人气和资本的手段,针对不同客群设置不同的活动主题和内容,用于拉新、留存等。

也有像平台申请的营销功能,如搜索关键词,首页推荐等等。

套餐列表:

涵盖了住宿、餐饮、活动等,可以与出行、景点结合打包售卖,还有一些针对家庭的,针对团体的套餐,根据不同客户的需求可打造适合客户的套餐。

营销当浓妆重抹说下,营销有主动营销和被动营销。

主动营销现在在市面上有很多玩法,基本可以参考电商的玩法,如拼团、优惠券、秒杀、老带新、会员充值等等,只需要关注电商即可,不能盲目照抄,要看是否适合自身的产品以及要想如何与自身的特点结合起来。

被动营销也分为两类,一类是逆营销,一类是顺营销。

逆营销是同行在做的营销活动且做得蛮不错,那么对于自身的市场份额和品牌知名度会有所营销,这时可能需要跟着对方来做相同的策略或者需要策划一场在他人之上的营销策略。

顺营销则是口碑相传,这个就在于自身的品牌和服务或者价格让消费者极度满意后他们会在自己的圈子中分享自己享受到的待遇。这种营销是可遇不可求的,指不定哪天谁分享了一下就爆了,所以我们要时刻做准备,只要在认真服务消费者这条道路上走,迟早会有惊喜的一天。

报表管理:

报表管理是最终交的一份答卷,在这里面可以从上到下,从粗到细一览整个酒店的盈亏情况,然后从盈亏情况再逐个细项展开分析原因,可以直观感受到经营情况,也可使用可视化大屏展示。

入住报表:

酒店业务最主要的就是客户入住,从入住报表中就要看到不同时间段(日周月年,节假日)的数据,并与往期进行对比,可以是环比。

需要看到整个酒店的入住率的变化,不同房型入住率的排名。

客户入住来自不同的平台下单,可以看到各个来源的数据,后期知道在哪里加大推广力度。

客户报表:

客户是经济命脉,那么就需要对客户全方面的了解,来打造自己的产品,从各个方面深挖客户的基本信息。

收入报表:

收入是酒店(企业)能够一直经营下去的动力,利润来源于收入。我们要了解收入的版块来自哪里,从而找到明星产品。

支出列表:

上面讲的是收入的内容,随之而来的就是支出(含成本),作为经营者,需要了解自己的钱花在了什么地方,花的值不值。

客诉报表:

这是服务调整优化的一步,上面已经讲了客户的重要性,那么针对客户的问题显然是比较重要的,那么我们需要分析客户在哪些地方产生了不满,是对我们的人还是服务还是价格等不满,这也是酒店变好的关键一步。

财务管理:

财务环节就需要对资金进行盘点、对账和清结算了,这里面涉及各种扣点费率以及从各个支付通道收来钱的通道手续费。

利润表:

统算所有的收入和支出,形成最终的利润表,如果要做成资产表的话还需要折算当前酒店内的所有的固定资产。

应收账款:

展示各个渠道所服务没有到账的金额,有些与平台签约有定时结算的。

应付账款:

有些酒店与平台签约的是平台抽佣,但是收款方是酒店,那么会定期给平台分佣;还有些是给客户退款或者是采购物品的钱。

开票管理:

酒店会给客户进行开票,如果他们需要的话。开票方式的话可以是老式的盘开,现在也有数控发票,由付款方进行申请。

开票整个流程也要进行记录确认,不能重复开票,开票可以自己接开票系统,可以使用平台的。

组织架构:

组织架构不需要弄的太复杂,正常的树形结构,包含部门和人员(含负责人)即可。这里有个排班,酒店业务需要每天有人值班和打扫,因此需要有24小时值守的,也就需要有排班,三班倒或者两班倒这个看酒店自己安排。

配置管理:

酒店一些设施需要进行配置,像房型、短信、标签等,配置管理的功能不仅限于此,要发现常规活动中哪些节点上或页面上的字段是经常变动的,是有差异性的,那么可以将其纳入可配置的范围。配置其实是最直观的最浅层的无代码了,当所有可配时就是真无代码。

系统管理:

权限管理:

可以选用市面上比较完善的RBAC模式进行设计,从页面层面、操作层面、数据层面进行设置,配以角色或者角色组,能适用于90%以上的企业使用。

酒店信息维护:

酒店信息一方面是为了入驻平台使用(如果是自研的则不包含本项),另一方面是给消费者看的,一方面增加消费者的信心,消费者是很怕三无产品的,另一方面如果是品牌连锁,则会大大增加消费者的好感,因此酒店的信息就是酒店的一张名片,需要突出特色。

字段有酒店名称、logo、营业时间、简介、客服电话、负责人、负责人电话、地址、营业执照、身份证、图片/视频、标签、详情(亮点、服务、注意事项等)。

系统日志:

每个系统都需要日志维护,在关键时刻可以找到历史记录和人员操作记录,对于系统的容错有比较大的作用,毕竟当一个系统没有记录时,做错了反正也没人知道,那样就容易松懈。

其实还有数据字典、安全设置、集成设置、支付设置等等,这个看具体酒店规模和平台是否有,有些注重主体使用功能,当做大了会在很多细节层面以及底层架构应用层面进行展示和设置。

以上讲的是基于酒店后台管理系统相关的功能模块,如果是加盟的平台,那么平台的功能和酒店的有什么区别呢?

平台的功能布局:

除开上述酒店管理后台自身的功能,这些平台都需要有,而自身作为多酒店入住的平台,更需要的是对酒店客户的维护,数据的维护,系统的维护,以及作为中间平台对酒店和消费者起到承上启下作用。

酒店的维护也是对于平台业务人员进行考核的一个指标,应该有一套CRM系统才承接这块功能,消费者也会为我们发现优质和不好的客户,那么平台会多扶持优质客户,劣质客户则可以劝退,以免影响消费者的体验。

对于消费者的维护,则可以使用统一的会员数据,因为在平台上不仅仅是酒店业务还有其他的业务,那么消费者是同一个,因此在不同业务之间,消费者的数据是可以抽出来作为公共数据库,可能在不同的业务中,消费者的标签是不一样的,但基础信息是一样的,可以从一个地方取和存,各自业务的不同点,可以自己维护客户的信息。

当然还有一些公共的组件和应用可以抽离出来,像push、CallCenter、msg、支付等等,这些在最后一期的企业级架构中体现出来。

最关键的也是数据这块,作为一个平台,拥有多应用,也需要衡量哪些业务挣钱,那些业务亏损,哪些业务值得做下去,哪些业务需要及时止损。

对于一个庞大的平台,做改造是不容易的,另起炉灶开创一个新条线可能是第二增长曲线,一般酒店买一套系统或者定做一套系统花不了几个钱,但是他们的业务深度不一定够,所考虑的场景和功能可能不齐全,因此,大型平台会将自身的优势做进一步延伸——提供SaaS服务,为酒店赋能。

平台上流量的稳定和增长是开发各种变现项目的资本,所以一方面平台要稳固自己的消费者(流量)和商户,一方面要做深自己的业务(行业壁垒)。再向周边产品延伸,扩大自己的生态圈,不一定全部要自己做,一部分要学会合作,把别人研究多年的技术和经验结合在自己的产品服务上,实现共赢。

一些小思路

送餐/送东西:

目前大部分酒店是含早餐的,但有一种现象,虽然订的房间含早餐,但是有时间限制,这个时候是否可以有预订服务,客户把自己想吃的提前点好,然后工作人员帮忙准备好,并放在保温箱中,等用户要吃的时候,可以拿出来给到用户。当然现在人工智能的发展,可以交代机器人进行送餐。

一些客户在酒店的时候,也会有外卖或者快递进来。而有一个固定的点进行配送,对于客户来讲是一件便利的事情。

当然不是白干活,配套优惠(工作人员如果想多挣点钱,可以在空余时间去帮客户拿东西),因为外卖应该不可以进入酒店内部,只能放在前台,那酒店的工作人员是可以完成这最后10米。也如上面讲的,一些大的酒店是有机器人服务的,这就更省力了。

先住后付:

这也是前面讲到的,没有付款,酒店心中不踏实,也不排除有些酒店开始了先住后付,这是有风险了,是一种大胆的尝试,那如果实行这种操作的话,就需要在付款订单这块做改变以及对客户信用做记录,可以效仿打车支付的套路,未支付前不能再次下单。

可选择房间号:

目前我们在选择酒店的时候,只有房型,没有房号和布局图,一开始买火车票也是没有座位号的,后面就有了,这样让客户感觉很好,选择自己想要的位置,那么有些客户对数字敏感的,也许选到自己心仪的房间号,会增加入住的好感。

那么选择房间号可能就比火车座位复杂点了,这个就可以效仿电影票选座位的形式了,还能知道哪些被预定了,房间在哪个位置等等。当然酒店经营惨淡的话,可以不显示哪些被预定了,只展示可选择哪些房间号即可。

快递业务:

这个可能是增收的项目,大部分用户在外出住酒店会有大包小包的东西,那么对于客户来说是比较繁重的,这个时候如果可以直接将东西邮寄到酒店,客户只需要轻装前往即可。

用户的行李托运,邮寄内容,可以直接邮寄到客户预订的酒店,酒店安排好直接放入房间或者由客户自己拿上去。方便客户出行的便捷。

这是一方面,另一方面用户出来旅游的,难免会有礼物需要带回去,这个时候也可以在酒店直接寄出,甚至不需要自己手动寄(等快递员来)。

当然现在一些购物门店是可以留下地址帮忙把礼物寄回去的,有些则不可以。而为了方便,客户的东西可以安排自己住的酒店帮忙邮寄,客户只需要下好单后(直接在平台上下单),由工作人员帮忙给到快递就行,那么快递员到来,询问验证码,客户可以授权给酒店。

而平台去谈快递业务的话,会比个人谈下来的价格便宜,这个既是给客户减少快递费,也是自身的一个盈利渠道,酒店帮忙寄快递的呢也可以分成,一单多少钱,这可能是多赢的局面。

竞价机制:

之前在网上看到去年五一的黄金周,旅游业迎来了复苏,住宿也是水涨船高,那么各大平台上的酒店都被预定空了,甚至出现了商家退款涨钱再租的现象,吃相不好,而平台之间针对同一酒店的房间,价格也层次不齐,在几十块钱以内还好,现在出现了差价几百,在网上也引起了一阵热闹。

携程虽然是最早从事这一行的,也有酒店资源,但现在慢慢被后起之秀(美团)赶上,后面还有飞猪等环伺,在价格方面处理不好容易对平台受损,大多数消费者是多平台参考选择价格更低的,因此在价格上要做好与竞争对手同步。

本文描述的主要是站在酒店层面考虑的功能,平台层面的涉及不多,里面还有很多细节是值得推敲的和打磨的,这些优点在于对业务的深入,对实践的操作,对以往的分析,对当下的思考和对未来的判断。

大厦不是一蹴而就的,也不是顷刻倒塌的,都会经历一个过程,在起来的时候是步步为营,是站在了问题上出手解决了问题;倒下的时候一定也是一步步做错,最后溃于蚁穴。

酒店业务的我们都在关注的是如何舒适,如何差异化,我们都忽略的点其实至关重要——安全和隐私,就像我们平常的呼吸一样,这个会在第三期中讲解。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.hqwc.cn/news/650919.html

如若内容造成侵权/违法违规/事实不符,请联系编程知识网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

【链表】Leetcode K个一组翻转链表

题目讲解 25. K 个一组翻转链表 算法讲解 虽然这道题是一道困难题,但是从代码层面很简单,只是一道简单的模拟:我们要先求出总共需要翻转的链表有多少组(链表的长度 / k),接下来就是翻转k的链表最链接的问…

【JAVA】PO、VO、DAO、BO、DTO、POJO你分得清吗?

在Java开发中,PO、VO、DAO、BO、DTO、POJO这些词汇是比较常见的,每个术语都有其特定的含义和用途。下面是它们的具体区别: 名称简要概况用途和特定PO (Persistence Object) 持…

SpringBoot+vue开发记录(二)

说明:本篇文章的主要内容为SpringBoot开发中后端的创建 项目创建: 1. 新建项目: 如下,这样简单创建就行了,JDK什么的就先17,当然1.8也是可以的,后面可以改。 这样就创建好了: 2. pom.xml…

JVM(Jvm如何管理空间?对象如何存储、管理?)

Jvm如何管理空间(Java运行时数据区域与分配空间的方式) ⭐运行时数据区域 程序计数器 程序计数器(PC),是一块较小的内存空。它可以看作是当前线程所执行的字节码的行号指示器。Java虚拟机的多线程是通过时间片轮转调…

bugfix: com.alibaba.druid.sql.parser.EOFParserException: EOF

前言 在日常的开发工作中,我们经常会遇到各种各样的问题,其中涉及数据库操作的接口联调尤其容易出现意想不到的状况。今天我就遇到了一个关于Druid SQL解析异常的问题,具体表现为com.alibaba.druid.sql.parser.EOFParserException: EOF。通过…

基于SpringBoot开发的同城租房系统租房软件APP小程序源码

项目背景 一、市场前景 随着城市化进程的加快和人口流动性的增强,租房市场正逐渐成为一个不可忽视的巨大市场。传统的租房方式往往存在着信息不对称、效率低下等问题,而同城租房软件的出现,则有效地解决了这些问题,为租房市场注…

为什么近年来机器学习这么火!!

机器学习(Machine Learning)是一种人工智能(AI)的分支,它让计算机能够通过数据学习和改进,而无需明确的编程。这意味着机器学习系统可以从经验中学习,逐步提高其性能。它基于统计学和数学算法&a…

《欢乐钓鱼大师》攻略,钓友入坑必备!

欢迎来到《欢乐钓鱼大师》!在这个游戏里,你可以尽情享受垂钓的乐趣,通过不断更换和升级高阶鱼竿,轻松地钓到各种稀有鱼类。因为许多玩家在挑战关卡时遇到了一些困难,所以今天我给大家带来了《欢乐钓鱼大师攻略指南》&a…

【产品经理修炼之道】- 消金支付体系

我们常听说“互联网的尽头是放贷”,而当支付与金融结合会衍生出各种场景。本文将给大家拆解下不同消费金融场景下的支付案例,一起来看看吧。 各位小伙伴,大家好! 我们常听说“互联网的尽头是放贷”,确实这说其实话糙…

Springboot 中RedisTemplate使用scan来获取所有的key底层做了哪些事情

直接上代码&#xff0c;围绕着代码来讨论 redisTemplate.execute((RedisCallback<Object>) (connection) -> {Cursor<byte[]> scan connection.scan(ScanOptions.scanOptions().count(2).match("*").build());scan.forEachRemaining((bytes) -> {…

通信原理(2)--随机过程

通信原理(2)–随机过程 3.1随机过程的基本概念 随机过程{x(t)}由一族时间函数 x i ( t ) x_i(t) xi​(t)&#xff0c;i1,2.3…组成&#xff0c;每一个时间函数 x i ( t ) x_i(t) xi​(t)称为随机过程{x(t)}的一个样本函数&#xff08;一个实现&#xff09; 每个样本函数在时间…

Java设计模式 _结构型模式_适配器模式

一、适配器模式 **1、适配器模式&#xff08;Adapter Pattern&#xff09;**是一种结构型设计模式。适配器类用来作为两个不兼容的接口之间的桥梁&#xff0c;使得原本不兼容而不能一起工作的那些类可以一起工作。譬如&#xff1a;读卡器就是内存卡和笔记本之间的适配器。您将…