项目总结:做一款香港旅游产品时遇到的文化挑战

1 评论 5636 浏览 27 收藏 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协议

给作者打赏,鼓励TA抓紧创作!
5人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 大陆在法律和政府层面要做更多的完善,人民大众也要多出力,不过这些都不是一朝一夕能解决的问题,只要事情在朝好的方面发展那就应该相信明天会更好。

    回复