标签归档:快捷酒店管家

#我的错误案例#一个关于提醒的设计

先简单交代一下业务逻辑:

在快捷酒店行业,因为有结算时间存在,加之某些酒店的IT系统不够完备,会出现一个这样的问题:

一般而言,0-4点属于快捷酒店的结算时间,在这个时间中,部分酒店的预订系统无法接单,但是,前台可以接单。

就用户而言,0-4点预订,大部分是希望可以立刻入住的;

就酒店而言,0-4点预订,默认是10点之后才能入住;

就产品而言,需要帮助用户订到可以入住的房间

 

举个例子:

现在是5月8号的凌晨1点。

张三跟朋友喝完酒出来,张三现在点击预订,张三的需求是立刻就住进去。

但是,这个时候,出现2个问题:

1、手机系统显示时间是5月8日,很多APP默认显示的房态是5月8日

2、凌晨1点的订单,对酒店而言,默认也是认为是5月8日的

3、凌晨1点的订单,张三的意思是立刻入住,酒店把这个订单算作5月7日的

这就是所谓的「凌晨房态」。这是一个快捷酒店IT系统的顽疾,也是一个业务问题,当然,更是一个快捷酒店管家需要解决的问题。

 

解决方案:

从需求入手。

假设95%的用户在0-4点预订,立刻就需要入住。(该假设无需论证,我也不想论证)

所以,产品上需要做的是:

1、0-4点,默认给用户看的是立刻就能入住的房间的房态

2、0-4点,默认用户点击预订的是立刻就能入住的房间

3、0-4点,不能在线预订的房间,切换到电话预订

 

具体实现:

1、0-4点,默认显示5月7日的房态,即用户可以立刻入住 。(之前解释过)

2、0-4点,用户点击预订的时候,弹出提示。「请注意入住时间」

3、0-4点,用户切换了日期到5月8日, 弹出提示。「请注意入住时间」

4、0-4点,用户切换了日期,但不是5月8日,不弹出提示。(不属于凌晨房态范畴)

 

情况叙述完,2分钟时间感受一下,具体实现这里是否存在问题,为什么?

 

这个功能内测上线之后,我特意去体验了1次凌晨订房。出差,坚持不订房,0:30的时候掏出手机预订。

操作流程:

1、选择酒店,进入到酒店详情。

2、看到有房,立刻点击预订了,没注意时间什么的。

3、看到弹出提示,「注意入住时间」。

下意识的,我觉得哪里出了问题,点击了知道了,然后,点击了返回按钮,然后拨打了电话。电话告诉前台,我立刻就要去住的房间有没有,得到了肯定答案之后,继续回来预订了。

 

这里,是有问题的:

1)这个提示,出现在没有完成操作之前,让用户产生疑惑,打断了操作。既然标注了房态,就该为房态负责,不应该甩给用户。

2)一旦用户需要拨打电话确认,这个事情就不酷了。他变的笨重了,失去了这个产品的意义,不如直接就放电话预订。

后来,我将这个情况说给一个朋友,朋友说了一段更直接的话:

「我只想马上睡觉,和,你能让我马上睡觉」,一语中的!

后来,我们对这个提醒的设计做了修改:

1、0-4点,默认进去显示前1天的房态;点击预订按钮,默认不给提醒;收到酒店预订成功短信,直接去入住

2、0-4点,切换了时间到当日之后,弹出提示。

 

—向任何一个总结一样,需要有个启示的部分

 

1、不去实际使用,永远不会发现痛点。

如果不是某次出差,在凌晨2点,用7天的客户端预订了一个酒店,到了前台被告知早上10点才可以住,现在满房。我只能又跑了2条街才找到另一家店,我不会对「凌晨房态」如此在意。

如果不是产品上线之后,我再次感受一遍,也不会发现这个问题。

2、用户不需要提示。

提示,是一个让人很不舒服的东西,用户,不需要提示。

这也是我之前为什么那么反感与痛恨「新手引导」 的原因。

3、感谢那个不了解我们产品的朋友。

你帮助我跳出了思维围城。

 

我们是如何利用微信来辅助产品的

注:这是IT经理世界与搜狐IT联合做的一个关于微信开发者调查的专题,其中对来自快捷酒店管家的公号“订酒店”做了报道。原载:搜狐IT

文/快捷酒店管家产品经理 朱坤(kentzhu)

现在,只要看到一个APP,需要用户之间产生信息交互,比如导航信息、航班信息、酒店信息、餐厅信息等,但是却不支持微信分享的,我看着都很捉急。这就好比,用户已经处在了信息的高速公路上,但是你还只让他骑着单车,这是有点反人类的。

对于产品而言,我们的目标用户在哪儿,他们在使用什么样的工具,我们的设计就应该跟到哪儿,巧妙的利用用户常用的工具,可以更好的赢得用户的好感,从而触动他们。

在快捷酒店的预订上,存在1个很典型的场景。我出差到一个陌生的城市,住进了宾馆之后,想找朋友出来聚聚,我需要告诉朋友我当前的位置。所以,我们在很早的时候就在快捷酒店管家中加入了分享的功能,用户可以分享酒店的地址、电话信息到短信和微博,帮助用户完成这个需求。我们以前认为微博是一个很多人在的地方,分享功能应该来引流不少用户,但是,我们错了。除了店长,很少有人使用这个功能。因为,住酒店是个很私人的事情,用户不那么愿意公开。同时,分享到微博的信息并不能直接为用户调起导航。

微信的出现,将这个问题很好的解决了。现在,我出差去深圳,我可以将我的酒店信息通过微信分享给我的朋友,朋友在微信上打开这个信息,可以直接调起快捷酒店管家APP,然后通过导航功能找到我。从数据上看,我们接入了微信分享之后,用户的使用率及回流比率是之前微博的数十倍,相应的,短信分享的使用率也相应下降了超过50%。

在快捷酒店管家的产品中,我们将微信的分享看作是一种病毒。我通过微信分享我在快捷酒店管家上预订的酒店,传播了快捷酒店管家的品牌,同时也吸引了新用户来安装这个APP,然后这个新用户又成为了病毒。而病毒的根源就是,他提高了信息流通的效率。我们的兄弟产品航班管家在这点上做的更加深入,他们直接把微信分享独立出来显示,同时在分享到微信的缩略信息中就展示了航班号及起飞机场与时间,更好的帮助了用户。

在很多时候,用户其实并不太在意这个产品由什么来承载,他们只在乎这个产品能不能帮助他解决问题。

有次有个朋友被困在昆明机场,通过微信问我,附近有没有快捷酒店,我说,你直接用我们快捷酒店管家查呗,他说没来得及下载,没流量了。最后,我用快捷酒店管家帮助他完成了预订。这个事情之后,我开始思考,APP是否是唯一的移动解决方案?对于快捷酒店管家,我们要做的是帮助用户解决如何预订快捷酒店的问题,而APP只是一个载体,显然,他不是唯一的。

正好,微信的4.0版本开始支持发送当前位置给好友,当时我就在想,如果用户主动将当前位置发送给公众平台,我们完全可以根据他的位置返回给他当前位置的快捷酒店。这样的话,那些低频使用的用户,一样可以在需求的时候享受快捷酒店管家的优质服务了!从产品逻辑上看,都是根据用户当前位置,找到用户当前的快捷酒店并完成预订,这跟快捷酒店管家的产品理念完全一致。

于是,我将这个想法做成原型发布到了微博上,之后开始联系微信开放平台的同学。他们听到这个想法的时候也很支持,于是快捷酒店管家成为第一家内测公号平台自动回复功能的公号。我们注册了innteam这个微信公号,我们的CTO花了大概2小时完成了调试,上线了一个比较粗糙的版本。最初的订酒店公号(微信ID:innteam),只能实现共享位置,我们根据位置的x,y坐标查找酒店。后来,我们的CTO继续深入,调用了一些第三方的API,可以实现按照地点来查找,按照店名来查找,按照品牌来查找等。现在,这种形式几乎成了生活类服务微信公号的样板模式了。

完成之后,我只是在微博上发布了一条消息,第二天正好腾讯科技的一个专题中提到了这个公号,于是第一批用户就这么来了。之后,我们没再做过任何的宣传与推广,一来是因为创业团队人力不足,二来是觉得只是个辅助业务。但是,在接下来的几周里,来自订酒店公号的订单量一直在上涨,我终于意识到这不是用户在测试,而是,用户发现这是一种更低门槛的订酒店的方式了!

于是,我们开始想办法把老用户与微信也结合起来,可以让老用户直接在通过这个微信公号来管理自己的订单。打开一个微信公号,输入一个命令就可以取消订单,相比打开APP,等待启动再切换到订单管理而言,无疑效率又提高了。

这一切,受到了用户的肯定,在公号的后台里,很多用户留言说,原来微信还可以这么玩,原来订酒店可以这样简单,这太酷了!

在后续,我们将订酒店升级到了3.0版本。增加了这样几个功能:利用微信的自定义菜单,一键查找周边的酒店 ; 直接在微信中完成预订 ;不管是APP和微信公号都可以将你选择的酒店信息再次分享出去,然后你的好友直接完成预订,更好的解决了『替人订房』这个需求 ;跟第三方合作,增加了一个有趣的随机糗事功能,因为我本身是糗友,同时,我始终觉得搞个客服让人调戏,是个很低级的产品行为,另外作为一个小团队,我们也没人可供调戏。

从微信订酒店3.0版本开始,我们已经完成了微信上的产品循环构建。用户可以通过不同途径生产出『酒店卡片』,这个卡片通过微信进行传播,然后产生出更多的卡片,最终实现帮助用户解决酒店预订的需求。

当然,对于很多实体酒店而言,他们利用自身的优势在运作微信公号,通过微信公号发布优惠和吸引新的会员,也进一步培养了用户的使用习惯。这让我们对微信公众平台的前景进一步的看好,我们正在对订酒店微信公号做升级,会进一步的提高用户查找酒店、预订酒店、与好友分享酒店信息的效率。

作为开发者,我很少看外界对微信公众平台的评价与预测,这些对我来说毫无意义。在快捷酒店管家,我们最关心的是我们的用户会因为微信的出现发生怎样的改变,他们对APP的看法,他们对手机生活的看法,我们会根据这些看法去发现可以跟微信的结合点,然后将这个需求提给微信,一起来满足用户。