0
评论

hg3399.com|官方网站助力传统商业转型电商的客服升级之路:从产品上网到服务上网

beyond 发表了文章 ? 3014 次浏览 ? 2016-04-25 15:35 ? 来自相关话题

垂直类电商无疑是当前互联网经济的耀眼明星。即使是在当前人人喊冷的资本寒冬中,找钢网、找塑料网这类垂直电商仍然被资本市场所青睐。今年1月,找钢网宣布完成E轮战略融资,融资额超10亿元人民币。资本市场真金白银投入的背后,是以“互联网+”、“分享经济”、“供给测改革”为导向的整体经济转型。可以预见,随着以天猫、京东为代表的互联网原生电商平台的流量饱和,以传统行业为主角的垂直类电商正坐在开往春天的列车上,成为电商行业“新常态”。





从产品上网到服务上网?
?
传统行业触网电子商务,要解决的第一个问题,便是平台搭建。对垂直类电商而言,贯通上下游的供应链管理是运营重点,而天猫、京东这类以流量运营为主的综合电商平台显然不适合。因此自己搭建独立网店或交易平台,成为垂直类电商的首选。目前,国内提供电商平台解决方案的服务商已为数不少。例如,APP端有有赞、微店、微盟萌店、微猫,PC端有Shopex、ECShop、Shop++、Javashop、千米、筑云等等,这些厂商的模块化解决方案帮助传统行业快速实现了产品上网和在线交易,完成了“触网”的第一步。

但我们看到,很多垂直电商虽然实现了“产品”上网,“服务”却迟迟没有上网。由于存在技术门槛,当前电商平台解决方案中,均没有集成客服功能,这导致很多垂直电商仍延用传统的客服方式。即使是规模较大的垂直电商,客户服务的渠道最多也就是营销QQ再加上400电话,这与电商的商业理念背道而驰。效率是电子商务对传统商业的重要革命,电商的本质即在于通过信息流动实现对供需关系的高效率匹配。电商的服务也应当像产品一样,进行效率革命。这也是“SaaS客服”、“全媒体服务”在互联网经济中蓬勃发展的重要原因。传统行业触网垂直电商,继产品上网之后,服务上网将是迈出的第二步。本文围绕服务效率和用户体验,为转型电子商务的传统行业商家介绍移动互联网下的客服形态——全媒体客服。

什么是全媒体客服?
?
全媒体客服是指通过SaaS服务平台,客服人员可同时为来自各种渠道的用户提供实时和一致的服务,服务渠道包括APP、微信、微博、Web,以及传统呼叫中心等。用户和客服之间采用文字、图片、音视频等多媒体消息或是电话语音进行交互。通过覆盖多种渠道媒体,全媒体服务的理念是“用户在哪,服务在哪”。和传统客服相比,全媒体客服的核心价值在于能够大幅提高商家的服务效率,并且实现服务式营销,同时也为商家的客户带来了更好的体验。?
?
从部署角度来看,基于云端SaaS平台的全媒体客服是一种极轻量部署模式。用户无需采购任何专用硬件设备,只需要普通PC,通过浏览器即可提供专业客户服务。实现的方式也极其简单,对于APP,只需要集成厂商提供的SDK,对于网页,微信或微博,更是一行代码即可开启全媒体客服。
?
?hg3399.com|官方网站是国内最早进军全媒体客服的厂商,根据易观智库的市场数据,在移动端SaaS客服市场,hg3399.com|官方网站市场占有率高达77.4%(数据来源:易观智库《2015中国SaaS客服市场专题研究报告》)。本文即是基于市场发展趋势和hg3399.com|官方网站的技术研究,介绍全媒体客服在提升效率和用户体验上的一些优势和关键技术。
?
?1:1 vs 1:N,集约化客户服务
?
传统企业的客户服务通常以呼叫中心为主。用户需要服务时,拨打企业400/800电话,再由客服人员提供服务。由于一名客服同一时间只能服务于一名客户,因此这是一种1:1独占式服务方式。转型电商后,客户来的渠道多样化,有从网页端来的,有从APP端来的,或是从社交媒体,如微博、微信来的。这时候显然无法按呼叫中心1:1的配置方式,为不同渠道的客户提供单独服务。全媒体客服则是通过云端系统,打通不同渠道,对所有渠道来的用户进行统一排队和会话分配。每一位客服,都可同时服务于多个渠道来的客户,这是一种1:N式的集约化服务。在hg3399.com|官方网站的案例——学而思的客户服务中心,每位客服人员最多时可同时服务20余名客户。在当前人口红利逐渐消失,人力成本急剧上升之时,任何对人力资源的高效率、集约化运用,都是在为企业创造效益。?
?
从IVR到ITR,可触摸的服务





Gartner在3月份发布的《2020年前用户关系中心应关注的5项技术》中,把ITR(Interactive Touch Response,交互式触摸响应)技术列为关键技术之一。ITR是移动互联网时代,触摸化的IVR。客户不再需要听完所有的服务菜单,只需要在手机屏幕上,直接选择需要的服务内容,即可获得服务。例如,神州专车在给司机端提供的“微客服”服务,司机直接在手机屏幕上选择需要的服务内容,不需要打电话听完漫长的语音提示,再选择服务内容联系相应的客服。通过移动客服和ITR技术,整个服务过程时间节约了80%,既提升了用户体验,同时也降低了客服压力。

自助式服务,让用户自己解决问题?
?
对于一些形式标准化,内容单一化的服务,可以通过自助式服务的方式,让用户自己解决问题。例如密码更改、订单管理、物流跟踪等等。自助式服务满足了用户碎片化的使用习惯。用户可以在车上闲暇时间,或是不方便电话沟通的场合即可完成服务,同时也降低了人工客服的需求量。
?





提供自助式服务,需要企业将IT系统前置,通过一些开放式接口,让用户在商城应用程序的客户端中,直接调用相应接口,完成服务过程。这是和传统呼叫中心封闭式系统部署的不同之处。?
?
随着智能技术的成熟,在开放接口上还可进一步增加智能客服插件。客户通过自然语言,例如“我想修改订单送达地址”,经过自然语言处理技术进行语义分析后,客服机器人返回订单修改入口,用户完成自服务。这个过程,结合人机融合,可以提供无差错的高质量服务。?
?
人机融合,用智能提高服务效率
?
虽然当前机器学习算法飞速发展,在客服领域也得到了广泛应用。但在自然语言处理,特别是中文语义的识别上,距离完全替代客服还有差距。用人机配合的方式,对于复杂问题,借助智能客服答复,辅以人工核验,既能提高效率,同时又保证了用户体验。?
?
hg3399.com|官方网站在坐席工作台界面中,增加了一个推荐答案窗口。当用户发出客服请求时,智能机器人在推荐窗口提供了若干个备选答案。坐席人员从中选择一个最合适的答案,只需要点击“发送”,用户立刻就可得到回复。如果需要修改,也只需要在推荐答案的基础上经过少量编辑即可。通过人机配合,在保证准确度的情况下,大幅提高了坐席的工作效率。?
?
服务式营销,从成本中心到利润中心?
?
在传统行业,客户服务中心通常是一个成本中心,以解决售后问题为主,难以和营销挂钩。以信息流动为基础的电子商务则为服务式营销提供了机会,客服人员可以接触到客户资料、历史购买商品以及消费习惯等关键信息。但要实现营销,关键之处在于如何利用这些信息。?
?
服务式营销的关键技术之一是大数据分析能力,通过数据挖掘找到热门商品和潜在客户的最佳匹配关系。为此hg3399.com|官方网站在全媒体客服产品提供了客户标签和热词分析功能。通过客户购买历史纪录、访问轨迹、基础资料等信息为客户打上标签,依靠热词分析及时发现热门商品,两者之间的匹配程度越高,商品销售的成功率越高。?
?
服务式营销的另一关键技术是无干扰的消息推送技术。电话外呼之所以日渐淘汰,除了缺乏精准性外,对用户干扰大、体验差也是重要原因。hg3399.com|官方网站全媒体客服采用基于长连接的消息通知方式。客服人员的营销信息,以后台通知的方式发送到用户端。用户可以在闲暇时间打开,这种方式给客户充分的主动权,不会对客户体验带来影响。此外,长连接技术的另一优势是不会丢失消息。通过大数据分析和无干扰的消息推送,客服能前置到销售链前端,实施主动的服务式营销,从成本中心转变为利润中心。?
?
传统呼叫中心的升级之路?
?
转型电商的传统行业商家升级至全媒体客服,根据不同情况有两种可行解决方案。对于当前没有大规模呼叫中心的中小企业,可以采用直接切换的方式,一步到位,用全媒体客服替代传统电话客服。这种方案成本低廉,简单易行。
?
?对于已经建设了大规模呼叫中心的大型企业,以增量部署的方式,使全媒体客服嵌入呼叫中心,保护用户既有投资。这种方案通过开放式接口,可以实现“三统一”:?
?统一排队与路由分配。不论何种渠道来的客户,统一进行排队,共享客服资源;??统一话单记录。同一个客户,不论从哪种渠道访问,话单记录都只有一份,客服人员可查看完整历史会话信息;??统一后台数据。通过开放式接口,可以对接现有CRM、工单系统、知识库,打通后台数据,消除数据壁垒。?
?更加高效、更好体验、服务营销,这是全媒体客服对于传统呼叫中心的核心竞争力。转型全媒体客服,是传统呼叫中心的必然趋势。在这个过程中,既需要传统行业商家转变思路,拥抱移动互联网,更需要行业生态链的共建共赢。
? 查看全部
垂直类电商无疑是当前互联网经济的耀眼明星。即使是在当前人人喊冷的资本寒冬中,找钢网、找塑料网这类垂直电商仍然被资本市场所青睐。今年1月,找钢网宣布完成E轮战略融资,融资额超10亿元人民币。资本市场真金白银投入的背后,是以“互联网+”、“分享经济”、“供给测改革”为导向的整体经济转型。可以预见,随着以天猫、京东为代表的互联网原生电商平台的流量饱和,以传统行业为主角的垂直类电商正坐在开往春天的列车上,成为电商行业“新常态”。

5300003a1e906fe42e6.jpg


从产品上网到服务上网?
?
传统行业触网电子商务,要解决的第一个问题,便是平台搭建。对垂直类电商而言,贯通上下游的供应链管理是运营重点,而天猫、京东这类以流量运营为主的综合电商平台显然不适合。因此自己搭建独立网店或交易平台,成为垂直类电商的首选。目前,国内提供电商平台解决方案的服务商已为数不少。例如,APP端有有赞、微店、微盟萌店、微猫,PC端有Shopex、ECShop、Shop++、Javashop、千米、筑云等等,这些厂商的模块化解决方案帮助传统行业快速实现了产品上网和在线交易,完成了“触网”的第一步。

但我们看到,很多垂直电商虽然实现了“产品”上网,“服务”却迟迟没有上网。由于存在技术门槛,当前电商平台解决方案中,均没有集成客服功能,这导致很多垂直电商仍延用传统的客服方式。即使是规模较大的垂直电商,客户服务的渠道最多也就是营销QQ再加上400电话,这与电商的商业理念背道而驰。效率是电子商务对传统商业的重要革命,电商的本质即在于通过信息流动实现对供需关系的高效率匹配。电商的服务也应当像产品一样,进行效率革命。这也是“SaaS客服”、“全媒体服务”在互联网经济中蓬勃发展的重要原因。传统行业触网垂直电商,继产品上网之后,服务上网将是迈出的第二步。本文围绕服务效率和用户体验,为转型电子商务的传统行业商家介绍移动互联网下的客服形态——全媒体客服。

什么是全媒体客服?
?
全媒体客服是指通过SaaS服务平台,客服人员可同时为来自各种渠道的用户提供实时和一致的服务,服务渠道包括APP、微信、微博、Web,以及传统呼叫中心等。用户和客服之间采用文字、图片、音视频等多媒体消息或是电话语音进行交互。通过覆盖多种渠道媒体,全媒体服务的理念是“用户在哪,服务在哪”。和传统客服相比,全媒体客服的核心价值在于能够大幅提高商家的服务效率,并且实现服务式营销,同时也为商家的客户带来了更好的体验。?
?
从部署角度来看,基于云端SaaS平台的全媒体客服是一种极轻量部署模式。用户无需采购任何专用硬件设备,只需要普通PC,通过浏览器即可提供专业客户服务。实现的方式也极其简单,对于APP,只需要集成厂商提供的SDK,对于网页,微信或微博,更是一行代码即可开启全媒体客服。
?
?hg3399.com|官方网站是国内最早进军全媒体客服的厂商,根据易观智库的市场数据,在移动端SaaS客服市场,hg3399.com|官方网站市场占有率高达77.4%(数据来源:易观智库《2015中国SaaS客服市场专题研究报告》)。本文即是基于市场发展趋势和hg3399.com|官方网站的技术研究,介绍全媒体客服在提升效率和用户体验上的一些优势和关键技术。
?
?1:1 vs 1:N,集约化客户服务
?
传统企业的客户服务通常以呼叫中心为主。用户需要服务时,拨打企业400/800电话,再由客服人员提供服务。由于一名客服同一时间只能服务于一名客户,因此这是一种1:1独占式服务方式。转型电商后,客户来的渠道多样化,有从网页端来的,有从APP端来的,或是从社交媒体,如微博、微信来的。这时候显然无法按呼叫中心1:1的配置方式,为不同渠道的客户提供单独服务。全媒体客服则是通过云端系统,打通不同渠道,对所有渠道来的用户进行统一排队和会话分配。每一位客服,都可同时服务于多个渠道来的客户,这是一种1:N式的集约化服务。在hg3399.com|官方网站的案例——学而思的客户服务中心,每位客服人员最多时可同时服务20余名客户。在当前人口红利逐渐消失,人力成本急剧上升之时,任何对人力资源的高效率、集约化运用,都是在为企业创造效益。?
?
从IVR到ITR,可触摸的服务

52e00039e3744d94a91.jpg


Gartner在3月份发布的《2020年前用户关系中心应关注的5项技术》中,把ITR(Interactive Touch Response,交互式触摸响应)技术列为关键技术之一。ITR是移动互联网时代,触摸化的IVR。客户不再需要听完所有的服务菜单,只需要在手机屏幕上,直接选择需要的服务内容,即可获得服务。例如,神州专车在给司机端提供的“微客服”服务,司机直接在手机屏幕上选择需要的服务内容,不需要打电话听完漫长的语音提示,再选择服务内容联系相应的客服。通过移动客服和ITR技术,整个服务过程时间节约了80%,既提升了用户体验,同时也降低了客服压力。

自助式服务,让用户自己解决问题?
?
对于一些形式标准化,内容单一化的服务,可以通过自助式服务的方式,让用户自己解决问题。例如密码更改、订单管理、物流跟踪等等。自助式服务满足了用户碎片化的使用习惯。用户可以在车上闲暇时间,或是不方便电话沟通的场合即可完成服务,同时也降低了人工客服的需求量。
?

52c00039bec2249d142.jpg


提供自助式服务,需要企业将IT系统前置,通过一些开放式接口,让用户在商城应用程序的客户端中,直接调用相应接口,完成服务过程。这是和传统呼叫中心封闭式系统部署的不同之处。?
?
随着智能技术的成熟,在开放接口上还可进一步增加智能客服插件。客户通过自然语言,例如“我想修改订单送达地址”,经过自然语言处理技术进行语义分析后,客服机器人返回订单修改入口,用户完成自服务。这个过程,结合人机融合,可以提供无差错的高质量服务。?
?
人机融合,用智能提高服务效率
?
虽然当前机器学习算法飞速发展,在客服领域也得到了广泛应用。但在自然语言处理,特别是中文语义的识别上,距离完全替代客服还有差距。用人机配合的方式,对于复杂问题,借助智能客服答复,辅以人工核验,既能提高效率,同时又保证了用户体验。?
?
hg3399.com|官方网站在坐席工作台界面中,增加了一个推荐答案窗口。当用户发出客服请求时,智能机器人在推荐窗口提供了若干个备选答案。坐席人员从中选择一个最合适的答案,只需要点击“发送”,用户立刻就可得到回复。如果需要修改,也只需要在推荐答案的基础上经过少量编辑即可。通过人机配合,在保证准确度的情况下,大幅提高了坐席的工作效率。?
?
服务式营销,从成本中心到利润中心?
?
在传统行业,客户服务中心通常是一个成本中心,以解决售后问题为主,难以和营销挂钩。以信息流动为基础的电子商务则为服务式营销提供了机会,客服人员可以接触到客户资料、历史购买商品以及消费习惯等关键信息。但要实现营销,关键之处在于如何利用这些信息。?
?
服务式营销的关键技术之一是大数据分析能力,通过数据挖掘找到热门商品和潜在客户的最佳匹配关系。为此hg3399.com|官方网站在全媒体客服产品提供了客户标签和热词分析功能。通过客户购买历史纪录、访问轨迹、基础资料等信息为客户打上标签,依靠热词分析及时发现热门商品,两者之间的匹配程度越高,商品销售的成功率越高。?
?
服务式营销的另一关键技术是无干扰的消息推送技术。电话外呼之所以日渐淘汰,除了缺乏精准性外,对用户干扰大、体验差也是重要原因。hg3399.com|官方网站全媒体客服采用基于长连接的消息通知方式。客服人员的营销信息,以后台通知的方式发送到用户端。用户可以在闲暇时间打开,这种方式给客户充分的主动权,不会对客户体验带来影响。此外,长连接技术的另一优势是不会丢失消息。通过大数据分析和无干扰的消息推送,客服能前置到销售链前端,实施主动的服务式营销,从成本中心转变为利润中心。?
?
传统呼叫中心的升级之路?
?
转型电商的传统行业商家升级至全媒体客服,根据不同情况有两种可行解决方案。对于当前没有大规模呼叫中心的中小企业,可以采用直接切换的方式,一步到位,用全媒体客服替代传统电话客服。这种方案成本低廉,简单易行。
?
?对于已经建设了大规模呼叫中心的大型企业,以增量部署的方式,使全媒体客服嵌入呼叫中心,保护用户既有投资。这种方案通过开放式接口,可以实现“三统一”:?
  • ?统一排队与路由分配。不论何种渠道来的客户,统一进行排队,共享客服资源;?
  • ?统一话单记录。同一个客户,不论从哪种渠道访问,话单记录都只有一份,客服人员可查看完整历史会话信息;?
  • ?统一后台数据。通过开放式接口,可以对接现有CRM、工单系统、知识库,打通后台数据,消除数据壁垒。?

?更加高效、更好体验、服务营销,这是全媒体客服对于传统呼叫中心的核心竞争力。转型全媒体客服,是传统呼叫中心的必然趋势。在这个过程中,既需要传统行业商家转变思路,拥抱移动互联网,更需要行业生态链的共建共赢。
?
0
评论

Android V3.1.2 release

beyond 发表了文章 ? 1102 次浏览 ? 2016-04-25 12:06 ? 来自相关话题

新功能:
1.视频通话增加切换摄像头API:EMClient.getInstance().callManager().switchCamera();
2.新增消息搜索API:conversation.searchMsgFromDB();
3.支持设置和获取long类型的扩展字段;
4.加快app从后台切到前台时的重连速度;
5.优化GCM推送;


Bug fix:
1.修复某些手机发送系统表情时对方接到为乱码或空白的bug;
2.修复上一个版本发送图片消息时,如果是小图会删除原图的bug;
?
版本历史:Android sdk 更新日志
下载地址:SDK下载 查看全部
新功能:
1.视频通话增加切换摄像头API:EMClient.getInstance().callManager().switchCamera();
2.新增消息搜索API:conversation.searchMsgFromDB();
3.支持设置和获取long类型的扩展字段;
4.加快app从后台切到前台时的重连速度;
5.优化GCM推送;


Bug fix:
1.修复某些手机发送系统表情时对方接到为乱码或空白的bug;
2.修复上一个版本发送图片消息时,如果是小图会删除原图的bug;
?
版本历史:Android sdk 更新日志
下载地址:SDK下载
0
评论

iOS sdk 3.1.2 release

beyond 发表了文章 ? 1171 次浏览 ? 2016-04-25 10:45 ? 来自相关话题

新功能:

增加消息搜索功能,可以根据消息类型或者关键字搜索
优化绑定deviceToken逻辑
bug fix:

Fix 修复发送系统表情时对方接到为乱码或空白的问题
?
SDK下载http://www.easemob.com/download 查看全部
新功能:

增加消息搜索功能,可以根据消息类型或者关键字搜索
优化绑定deviceToken逻辑
bug fix:

Fix 修复发送系统表情时对方接到为乱码或空白的问题
?
SDK下载http://www.easemob.com/download
0
回复

实时回调接口,java服务端收到颜文字emoji为???解析不出来 emoji hg3399.com|官方网站_RestAPI

回复

parker 发起了问题 ? 1 人关注 ? 3632 次浏览 ? 2016-04-25 08:41 ? 来自相关话题

0
回复

集成hg3399.com|官方网站2.xSDK后的各种困扰,要疯了!!! hg3399.com|官方网站_iOS

回复

Sanchain 发起了问题 ? 2 人关注 ? 1868 次浏览 ? 2016-04-22 15:28 ? 来自相关话题

0
回复

有个朋友项目想集成hg3399.com|官方网站,求熟手帮集成 ,合作形式可谈 hg3399.com|官方网站

回复

fat1 发起了问题 ? 1 人关注 ? 2050 次浏览 ? 2016-04-20 16:02 ? 来自相关话题

0
评论

SDWebImage下载网络图片之提升用户体验

beyond 发表了文章 ? 2633 次浏览 ? 2016-04-18 17:22 ? 来自相关话题

Number one

描述: 使用UIImage+ webImageCache下载网络图片, 自带内存缓存, 以及沙盒缓存;
基本方法: [self.imageView sd_setImageWithURL: placeholderImage:];方法描述:

1.根据提供的url下载网络图片,并设置到imageView; 此时内存中会有一份缓存, 沙河中也会写入备份;

2. 当再次用到该图片时, 首先去内存中获取该图片, 内存中没有则去沙盒中加载, 如果都没有就会去网络下载;

注意:该方法底层会首先取消imageView之前的任务, 防止数据错乱. // 取消iamgeView之前的下载任务
[self.imageView sd_cancelCurrentImageLoad];

解析: 因为该方法有一个完成回调block, 当有网络延时时,
下载图片太慢, imageview循环利用显示其他图片, 但此时前面的下载任务下载好了,
就会拿到imageView直接设置图片, 会导致数据错乱;

故在之前调用该方法, 可以防止数据引用;方法总结

1.0 取消当前imageView之前关联的请求
2.0 设置占位图片到当前的imageview
3.0 如果缓存(内存, 沙盒)中有图片则直接设置, 不使用占位图片
4.0 如果没有,则发送请求下载图片

Number two
怎么实现缓存,以及获取对应的图片

无论是内存缓存, 还是沙盒缓存都是以字典的形式保存图片, 因为SDImageCache使用了NSCache类
key : 图片的url; value: 下载的图片

Number three
代码实现:
核心概念:

根据不同网络,下载不同图片(省流量)

内存缓存中, 只保存当前显示的图片

其他只保存到沙盒, 用到时才会缓存到内存 (提高内存性能)

1.0 监听用户网络状态

AFNetworkReachabilityManager// 程序启动的时候调用
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

// 监控网络状态
[[AFNetworkReachabilityManager sharedManager] startMonitoring];

return YES;
}2.0 根据不同网络状态, 下载不同图片// 占位图片
UIImage *placeholder = nil;

// 1.0 从缓存中获得原图
// 该方法会首先去内存找, 再去沙盒
UIImage *originalImage = [[SDImageCache sharedImageCache] imageFromDiskCacheForKey:originalImageUrl];

if (originalImage) { // 如果缓存有原图,那么就直接显示原图(不管现在是什么网络状态)
[self.imageView sd_setImageWithURL:[NSURL URLWithString:originalImageUrl] placeholderImage:placeholder];

} else {
// 2.0 缓存没有原图, 根据网络下载
AFNetworkReachabilityManager *mgr = [AFNetworkReachabilityManager sharedManager]
// 在使用Wifi, 下载原图
if (mgr.isReachableViaWiFi) {

[self.imageView sd_setImageWithURL:[NSURL URLWithString:originalImageUrl] placeholderImage:placeholder];

// 在使用手机自带网络
} else if (mgr.isReachableViaWWAN) {
// 下载小图
[self.imageView sd_setImageWithURL:[NSURL URLWithString:thumbnailmageUrl] placeholderImage:placeholder];
} else {
// 3.0 没有网络
UIImage *thumbnailImage = [[SDImageCache sharedImageCache] imageFromDiskCacheForKey:thumbnailImageUrl];
if (thumbnailImage) { // 缓存中有小图
[self.imageView sd_setImageWithURL:[NSURL URLWithString:thunmnailImage] placeholderImage:placeholder];
} else {// 没有小图
[self.imageView sd_setImageWithURL:nil placeholderImage:placeholder];
}
}
}3.0 处理缓存图片, 内存飙升问题
首先:

SDImageCache怎么处理内存问题?// 清空沙盒过期图片 (七天为限)
- (void)cleanDisk;

// 清空沙盒内所有图片
- (void)clearDisk;

// 清空内存缓存所有图片
- (void)clearMemory;什么时候处理 // 获取自动清理缓存对象
_memCache = [[AutoPurgeCache alloc] init];

// 当接收到内存警告, 才会处理缓存
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(removeAllObjects) name:UIApplicationDidReceiveMemoryWarningNotification object:nil];只有内存警告时才会处理?

为了用户体验故需我们手动释放:- (void)scrollViewDidScroll:(UIScrollView *)scrollView
{
// 滚动时, 清除缓存
[[SDImageCache sharedImageCache] clearMemory];
}解析: 为什么缓存中所有图片都清空了, imageView还能显示图片?

图片字典的形式保存在缓存中, NSCache有保存所有的key, 每个key指向一个图片对象

[self.memCache removeAllObjects]会把指向图片的key清掉, 则没有强引用的图片会被释放;

但是当把图片设置到imageview上时, image指针会强引用图片, 故还能显示图片

图示:




另外一个问题:
由于使用模拟器测试,发现在滚动过程中, 释放内存造成有时卡顿效果, 故在具体使用时, 还得各自思量;

tips: 建议把该方法抽取为(UIImageView)一个分类, 以便代码复用;

有问题, 请留言... 查看全部
Number one

描述: 使用UIImage+ webImageCache下载网络图片, 自带内存缓存, 以及沙盒缓存;
基本方法:
    [self.imageView sd_setImageWithURL: placeholderImage:];
方法描述:

1.根据提供的url下载网络图片,并设置到imageView; 此时内存中会有一份缓存, 沙河中也会写入备份;

2. 当再次用到该图片时, 首先去内存中获取该图片, 内存中没有则去沙盒中加载, 如果都没有就会去网络下载;

注意:该方法底层会首先取消imageView之前的任务, 防止数据错乱.
  // 取消iamgeView之前的下载任务
[self.imageView sd_cancelCurrentImageLoad];

解析: 因为该方法有一个完成回调block, 当有网络延时时,
下载图片太慢, imageview循环利用显示其他图片, 但此时前面的下载任务下载好了,
就会拿到imageView直接设置图片, 会导致数据错乱;

故在之前调用该方法, 可以防止数据引用;
方法总结

1.0 取消当前imageView之前关联的请求
2.0 设置占位图片到当前的imageview
3.0 如果缓存(内存, 沙盒)中有图片则直接设置, 不使用占位图片
4.0 如果没有,则发送请求下载图片

Number two
怎么实现缓存,以及获取对应的图片


无论是内存缓存, 还是沙盒缓存都是以字典的形式保存图片, 因为SDImageCache使用了NSCache类
key : 图片的url; value: 下载的图片

Number three
代码实现:

核心概念:

根据不同网络,下载不同图片(省流量)

内存缓存中, 只保存当前显示的图片

其他只保存到沙盒, 用到时才会缓存到内存 (提高内存性能)

1.0 监听用户网络状态

AFNetworkReachabilityManager
// 程序启动的时候调用
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

// 监控网络状态
[[AFNetworkReachabilityManager sharedManager] startMonitoring];

return YES;
}
2.0 根据不同网络状态, 下载不同图片
// 占位图片
UIImage *placeholder = nil;

// 1.0 从缓存中获得原图
// 该方法会首先去内存找, 再去沙盒
UIImage *originalImage = [[SDImageCache sharedImageCache] imageFromDiskCacheForKey:originalImageUrl];

if (originalImage) { // 如果缓存有原图,那么就直接显示原图(不管现在是什么网络状态)
[self.imageView sd_setImageWithURL:[NSURL URLWithString:originalImageUrl] placeholderImage:placeholder];

} else {
// 2.0 缓存没有原图, 根据网络下载
AFNetworkReachabilityManager *mgr = [AFNetworkReachabilityManager sharedManager]
// 在使用Wifi, 下载原图
if (mgr.isReachableViaWiFi) {

[self.imageView sd_setImageWithURL:[NSURL URLWithString:originalImageUrl] placeholderImage:placeholder];

// 在使用手机自带网络
} else if (mgr.isReachableViaWWAN) {
// 下载小图
[self.imageView sd_setImageWithURL:[NSURL URLWithString:thumbnailmageUrl] placeholderImage:placeholder];
} else {
// 3.0 没有网络
UIImage *thumbnailImage = [[SDImageCache sharedImageCache] imageFromDiskCacheForKey:thumbnailImageUrl];
if (thumbnailImage) { // 缓存中有小图
[self.imageView sd_setImageWithURL:[NSURL URLWithString:thunmnailImage] placeholderImage:placeholder];
} else {// 没有小图
[self.imageView sd_setImageWithURL:nil placeholderImage:placeholder];
}
}
}
3.0 处理缓存图片, 内存飙升问题
首先:

SDImageCache怎么处理内存问题?
// 清空沙盒过期图片 (七天为限)
- (void)cleanDisk;

// 清空沙盒内所有图片
- (void)clearDisk;

// 清空内存缓存所有图片
- (void)clearMemory;
什么时候处理
 // 获取自动清理缓存对象
_memCache = [[AutoPurgeCache alloc] init];

// 当接收到内存警告, 才会处理缓存
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(removeAllObjects) name:UIApplicationDidReceiveMemoryWarningNotification object:nil];
只有内存警告时才会处理?

为了用户体验故需我们手动释放:
- (void)scrollViewDidScroll:(UIScrollView *)scrollView
{
// 滚动时, 清除缓存
[[SDImageCache sharedImageCache] clearMemory];
}
解析: 为什么缓存中所有图片都清空了, imageView还能显示图片?

图片字典的形式保存在缓存中, NSCache有保存所有的key, 每个key指向一个图片对象

[self.memCache removeAllObjects]会把指向图片的key清掉, 则没有强引用的图片会被释放;

但是当把图片设置到imageview上时, image指针会强引用图片, 故还能显示图片

图示:

1710913-53919159cb9bb0e5.png

另外一个问题:
由于使用模拟器测试,发现在滚动过程中, 释放内存造成有时卡顿效果, 故在具体使用时, 还得各自思量;

tips: 建议把该方法抽取为(UIImageView)一个分类, 以便代码复用;

有问题, 请留言...
0
评论

JS区分浏览器中页面刷新与关闭标签页

beyond 发表了文章 ? 4941 次浏览 ? 2016-04-18 17:04 ? 来自相关话题

文章摘要:js刷新当前页面,Web开发者在系统开发中经常要面对产品经理各式各样的需求,当然,大部分对产品体验还是有帮助的,例如我们今天提到的刷新页面,前进后退,关闭浏览器标签时,为了避免用户误操作,需给出二次确认提示框,这个相信大家都非常熟悉了,采用浏览器提供的BOM事件机制就可以...

?? Web开发者在系统开发中经常要面对产品经理各式各样的需求,当然,大部分对产品体验还是有帮助的,例如我们今天提到的刷新页面,前进后退,关闭浏览器标签时,为了避免用户误操作,需给出二次确认提示框,这个相信大家都非常熟悉了,采用浏览器提供的BOM事件机制就可以解决,使用window对象的onbeforeunload事件即可,如果产品经理只提出这样的需求,那确实无可厚非,然而其需要的不仅仅是这些...

例如,我们一次项目开发中,产品经理就针对我们的实现提出了“改进方案”:
你们这弹出框太丑了,跟系统整体风格不搭调啊,不能使用咱们自己组件库中的Dialog吗?很好的问题...我只想说,you can you up...你们这刷新和关闭标签页中展示的文案一样啊,需要区分对待下,刷新提示XXX,关闭时提示SSS,这样用户才能更明确。恩,考虑到了用户的体验,很好,我还是想说,you can you up...其实,浏览器在关闭和刷新时,本身已经区别对待了,提示是不同的,只不过我们自定义的部分并不能显示不同的文案而已;当然,也有一些hack的方法,但是很难适应多个浏览器,各浏览器内部对于关闭标签页和刷新的实现机制会有所不同;你们每次登录进来,为什么要延时10秒,才让坐席签入电话系统啊(我们做的是客服系统)?能不能把这个限制去掉啊,用户体验太不好了!我们也想去掉啊,但是电话系统频繁签入签出会有问题,用户刷新了浏览器,再次签入,如果相隔时间很短的话,电话系统会出现故障,为了避免这个问题,我们才加上了这个限制,但是回过头来思考,就可以进入我们今天讨论的主题了;


区分刷新与关闭标签页

我们无法根据浏览器事件区分刷新还是关闭标签页,进而在相应动作触发前,执行不同的动作,但是对于上文中产品提出的第三点意见,其实还是可以考虑优化一下的,就是只有在刷新的时候延时10秒,新登录或关闭标签页一段时间之后再进来时不延时;

要做到这点其实也很简单,使用浏览器的本地存储机制就可以实现,例如cookie,LocalStorage等,这里就不能使用SessionStorage了,因为本次回话结束后,该缓存就失效了;由于在cookie中存储会增加cookie的字节数,每次请求中相应的网络传输量会增加,因此,我们采用了LocalStorage;其操作很简单,我们使用的前端框架是AngularJS,具体如下:const MAX_WAIT_TIME = 10;
const currentDate = new Date().getTime();
const lastestLeaveTime = parseInt(this.$window.localStorage.getItem('lastestLeaveTime'), 10) || currentDate;
this.secondCounter = Math.max(MAX_WAIT_TIME - Math.ceil((currentDate - lastestLeaveTime) / 1000), 0);
if (this.secondCounter > 0) {
this.logoutTimeInterval = this.$interval(()=> {
this.secondCounter--;
this.$scope.$digest();
}, 1000, this.secondCounter, false).then(() => {
this.updateByStatus(this.AvayaService.status.OFFLINE);
});
} else {
this.updateByStatus(this.AvayaService.status.OFFLINE);
}上面代码主要作用是,进入系统后,会先去LocalStorage中获取上次退出时的时间,再获取当前时间,两个时间进行减法,如果值小于10秒,我们就认为这是刷新,如果值大于10秒,我们认为是关闭标签页或新登录,进而可以执行不同的方法,让客服有更好的体验,不用每次进入系统都要等待10秒才能签入电话系统了,产品经理还是很重要的,吼吼,要不是他的疑问,可能我们也不会来优化这个地方了...当然,其实RD也要逐渐培养这种用户体验至上的思维,哪怕有一点可提升客服效率的地方,都值得我们花时间来优化;

下面把相关退出的代码也贴一下吧,前面忘说了,不管是刷新,还是关闭标签页,只要是页面销毁,我们都会去执行登出电话系统的操作,所以每次进来后需要重新签入;//刷新页面或者关闭页面
$window.onbeforeunload = () => {
return '操作将会导致页面数据清空,请谨慎操作...';
};//每次页面unload时,设置LocalStorage时间;
$window.onunload = () => {
$window.localStorage.setItem('lastestLeaveTime', new Date().getTime());
};我们可能还注意到一些问题,那就是刷新,关闭页面,前进后退,你需要跳出浏览器默认二次确认框,但是用户点击退出系统按钮,则必须弹出自己组件库中的Dialog了,还必须不能两个都弹出,具体代码如下:onStatusClick(index, name) {
if (name === '退出') {
this.mgDialog.openConfirm({
showClose: false,
template: 'app/header/logoutDialog.html',
controller: 'HeaderDialogController as dialog',
data: {
'title': '您确定要退出系统吗?'
}
}).then(() => {
this.$window.location.href = '/logout';
this.$window.onbeforeunload = null;
});
} else {
// 内部操作,大家不用管
...
}
} 查看全部
文章摘要:js刷新当前页面,Web开发者在系统开发中经常要面对产品经理各式各样的需求,当然,大部分对产品体验还是有帮助的,例如我们今天提到的刷新页面,前进后退,关闭浏览器标签时,为了避免用户误操作,需给出二次确认提示框,这个相信大家都非常熟悉了,采用浏览器提供的BOM事件机制就可以...

?? Web开发者在系统开发中经常要面对产品经理各式各样的需求,当然,大部分对产品体验还是有帮助的,例如我们今天提到的刷新页面,前进后退,关闭浏览器标签时,为了避免用户误操作,需给出二次确认提示框,这个相信大家都非常熟悉了,采用浏览器提供的BOM事件机制就可以解决,使用window对象的onbeforeunload事件即可,如果产品经理只提出这样的需求,那确实无可厚非,然而其需要的不仅仅是这些...

例如,我们一次项目开发中,产品经理就针对我们的实现提出了“改进方案”:
  1. 你们这弹出框太丑了,跟系统整体风格不搭调啊,不能使用咱们自己组件库中的Dialog吗?很好的问题...我只想说,you can you up...
  2. 你们这刷新和关闭标签页中展示的文案一样啊,需要区分对待下,刷新提示XXX,关闭时提示SSS,这样用户才能更明确。恩,考虑到了用户的体验,很好,我还是想说,you can you up...其实,浏览器在关闭和刷新时,本身已经区别对待了,提示是不同的,只不过我们自定义的部分并不能显示不同的文案而已;当然,也有一些hack的方法,但是很难适应多个浏览器,各浏览器内部对于关闭标签页和刷新的实现机制会有所不同;
  3. 你们每次登录进来,为什么要延时10秒,才让坐席签入电话系统啊(我们做的是客服系统)?能不能把这个限制去掉啊,用户体验太不好了!我们也想去掉啊,但是电话系统频繁签入签出会有问题,用户刷新了浏览器,再次签入,如果相隔时间很短的话,电话系统会出现故障,为了避免这个问题,我们才加上了这个限制,但是回过头来思考,就可以进入我们今天讨论的主题了;



区分刷新与关闭标签页

我们无法根据浏览器事件区分刷新还是关闭标签页,进而在相应动作触发前,执行不同的动作,但是对于上文中产品提出的第三点意见,其实还是可以考虑优化一下的,就是只有在刷新的时候延时10秒,新登录或关闭标签页一段时间之后再进来时不延时;

要做到这点其实也很简单,使用浏览器的本地存储机制就可以实现,例如cookie,LocalStorage等,这里就不能使用SessionStorage了,因为本次回话结束后,该缓存就失效了;由于在cookie中存储会增加cookie的字节数,每次请求中相应的网络传输量会增加,因此,我们采用了LocalStorage;其操作很简单,我们使用的前端框架是AngularJS,具体如下:
const MAX_WAIT_TIME = 10;
const currentDate = new Date().getTime();
const lastestLeaveTime = parseInt(this.$window.localStorage.getItem('lastestLeaveTime'), 10) || currentDate;
this.secondCounter = Math.max(MAX_WAIT_TIME - Math.ceil((currentDate - lastestLeaveTime) / 1000), 0);
if (this.secondCounter > 0) {
this.logoutTimeInterval = this.$interval(()=> {
this.secondCounter--;
this.$scope.$digest();
}, 1000, this.secondCounter, false).then(() => {
this.updateByStatus(this.AvayaService.status.OFFLINE);
});
} else {
this.updateByStatus(this.AvayaService.status.OFFLINE);
}
上面代码主要作用是,进入系统后,会先去LocalStorage中获取上次退出时的时间,再获取当前时间,两个时间进行减法,如果值小于10秒,我们就认为这是刷新,如果值大于10秒,我们认为是关闭标签页或新登录,进而可以执行不同的方法,让客服有更好的体验,不用每次进入系统都要等待10秒才能签入电话系统了,产品经理还是很重要的,吼吼,要不是他的疑问,可能我们也不会来优化这个地方了...当然,其实RD也要逐渐培养这种用户体验至上的思维,哪怕有一点可提升客服效率的地方,都值得我们花时间来优化;

下面把相关退出的代码也贴一下吧,前面忘说了,不管是刷新,还是关闭标签页,只要是页面销毁,我们都会去执行登出电话系统的操作,所以每次进来后需要重新签入;
//刷新页面或者关闭页面
$window.onbeforeunload = () => {
return '操作将会导致页面数据清空,请谨慎操作...';
};
//每次页面unload时,设置LocalStorage时间;
$window.onunload = () => {
$window.localStorage.setItem('lastestLeaveTime', new Date().getTime());
};
我们可能还注意到一些问题,那就是刷新,关闭页面,前进后退,你需要跳出浏览器默认二次确认框,但是用户点击退出系统按钮,则必须弹出自己组件库中的Dialog了,还必须不能两个都弹出,具体代码如下:
onStatusClick(index, name) {
if (name === '退出') {
this.mgDialog.openConfirm({
showClose: false,
template: 'app/header/logoutDialog.html',
controller: 'HeaderDialogController as dialog',
data: {
'title': '您确定要退出系统吗?'
}
}).then(() => {
this.$window.location.href = '/logout';
this.$window.onbeforeunload = null;
});
} else {
// 内部操作,大家不用管
...
}
}
0
评论

一乐 :煎饼果子与架构模式

beyond 发表了文章 ? 2533 次浏览 ? 2016-04-18 12:13 ? 来自相关话题

编者按:本文由一乐在高可用架构群分享,转载请注明来自高可用架构「 ArchNotes 」。



一乐是我,也是梁宇鹏。现任hg3399.com|官方网站首席架构师兼 IM 技术总监,负责即时通讯云平台的整体研发和管理。曾任新浪微博通讯技术专家,负责微博通讯系统的设计与研发。一直专注在即时通讯领域,熟悉 XMPP 协议和相关的开源实现(包括 Jabberd2、EJabberd、Openfire)。关注分布式系统和高性能服务,关注 Erlang、Golang 和各种浪。

?煎饼的故事
有一段时间住在花园路,最难忘的就是路边的煎饼果子。老板每天晚上出来,正好是我加班回去的时间。

一勺面糊洒在锅上,刮子转一圈,再打一个蛋,依然刮平。然后啪的一下反过来,涂上辣酱,撒上葱花。空出手来,剥一根火腿肠。最后放上薄脆,咔咔咔三铲子断成三边直的长方形,折起来正好握在手中。烫烫的,一口咬下去,蛋香、酱辣、肠鲜,加上薄脆的声音和葱花的惊喜,所有的疲劳都一扫而光。




这种幸福感让我如此迷恋,以至于会在深宅的周末,穿戴整齐跑出去,就为了吃上一个。也因为理工科的恶习,我也情不自禁地开始思考这份执迷的原因,直到最后,我发现了它的秘密。
?
作为街头小吃的杰出代表,能够经历众口的挑剔而长盛不衰的秘密是什么?
?
?所有的一切全因为其模式。
而这模式与大多数互联网服务的架构如出一辙,那就是分层架构。

分层的设计意味着,每一层都独立承担单一的职责。

这在根本上降低了制作的难度。做饼的时候专心控制火候,做酱的时候专注在味道。每层职责的单一化也让优化变得简单,因为它是自然可伸缩的。你要是想多吃点蛋就多加一个,你要多吃点肠就多加一根,完全取决于你的胃口。
?
它又是可以扩展的。你可以不要蛋,你可以加根肠,你可以不要薄脆,你可以加上辣酱。而且每一层又是可定制的。葱花可以少一点,辣酱可以多一点,肠可以要两根,鸡蛋可以加三个。

你也可以把面饼换成面包,把鸡蛋换成煎蛋,把辣酱换成甜酱。你已经知道这是什么了吧?是的,你好,这里是赛百味,请问你要什么口味的三明治?

煎饼果子和三明治,其实本质上是相通的。而加一个蛋更香,也不是因为对蛋的追求,在根本上是因为煎饼果子模式的强大。

因为这种模式,一千个人可以有一千种煎饼果子。
而有了对模式的理解,对小吃的评估也就变得更加容易。比如肉夹馍只有馍和肉,二维切换单调不可长久;比如烤冷面,干脆就是满嘴的热烈混在一起,没有煎饼这样的表现层,整个面都散发着原始的不讲究。

这种对比上的简化,也让我们有了新的选择,保存宝贵的精力,并且可以随时放弃对细节的追究。




就像在我们谈论女人时,

(抱歉博主是男人)

我们在意胸、

在意腿、

在意风情、

在意温柔,

因为女人是有区别的。

当我们欣赏电影的时候,

我们在意男人、

在意女人、

在意老人、

在意孩子,

因为角色是有区别的。

当我们走在路上的时候,

我们在意行人、

在意车辆、

在意商店、

在意餐厅,

因为物体是有区别的。
我们在设计和优化系统的时候,其中的每个服务都是自行运转,做着自己份内的事,但是在不同的维度里,作用却变得不尽相同。

这也是我们讲优化要分层次和级别,架构、算法、库和 OS,而讲架构的时候,我们首先讲的是整体的模式,然后是具体的权衡,实现的细节则是最不重要的。

架构的模式
谈起这个,是因为 Mark Richards 写了一本架构模式的书《Software Architecture Pattens》。

书中总结对比了五种模式的优缺点,包括了 Layered、Event-Driven、Microkernel、Microservices、Space-Based。

书写得简单精致,推荐大家去阅读,地址见文末。

还有一种模式,因为在越来越多的系统中用到,是书中没有的(与 Space-Based 有所区别),但我觉得也有必要专门介绍下。我们开始在群发系统中实现,后来的抢购、红包和火车票的场景中也屡屡看到它的身影。


2013 年的时候,我们在微博做粉丝服务平台,一个类似微信公众号的群发系统。然而比后者更困难的是,当时在产品设计上并没有像微信一样新建用户体系,而是直接基于微博的粉丝关系,这就意味着一篇文章要能能在很短时间内支持亿级的用户推送。这个数量级的订阅用户,即使看今天的微信公众号依然是难以想象的。
当时有一套老的群发系统,都是基于 MySQL 的收件箱设计,在更换了 SSD 硬盘,又批量化数据库操作之后,整体写入性能依然只在每秒几万的级别,这就意味着一亿用户只能在 17 分钟内发完,我们意识到这套系统需要进行重新设计。

最终我们我们使用了一种新的架构方式,达到了每秒百万级别的速度,而且还可以更高。这种模式就是单元化架构。

下文介绍我参照了架构模式的说明方式,希望能够让大家有个对比,喜欢你可一定要说好!

单元化架构
如前所述,我们选择单元化的一个重要目的是为了性能,为了极高的性能。这比起一般的分层架构来讲,会获得更经济的结果,但也因此,牺牲了分层架构的一些特性,因为它的容量取决于单元的大小(关于单元等名词介绍,我会在下文介绍)。

虽然它支持按照单元扩容,但在单元内基本上每层的性能都是固定的。这更适合容量可预期的场景,比如大多数已经趋于稳定的业务。像前面的粉丝服务平台,虽然他下发消息量级巨大,但是在整体层面,使用平台的用户由于是 VIP 用户,其规模基本在在数百万级别,而粉丝量级也不太可能过亿。

重要的是,基于当时的业务数据,我们已经知道平均粉丝数在什么量级。而业务数据是架构选型的重要依据。商品秒杀、火车抢票等等都是一样。
?
当然也有例外。因为单元化架构作为一种思想,它不会局限在一台机器,一个机架,它也适用一个机房。当它的层次变大时,单元内自然就可以有变化的空间。每一层服务都可以分开伸缩。而到了这个层面,它的追求可能就完全不一样了。像阿里的双十一服务改造,会为了流量的分离,像 QQ 的聊天,会为了接入的速度。它们的基本思想是一致的。

至于单元化架构和煎饼果子的关系,我会在文后回答。




核心概念 Key Concepts
分区(Shard)是整体数据集的一个子集。如果你用尾号来划分用户,那么相同尾号的用户可以认为是同一分区。

单元(Cell)是满足某个分区所有业务操作的自包含的安装。我们从并行计算领域里借鉴了这个思想,也就是计算机体系结构里的 Celluar Architecture,在那里一个 Cell 是一个包含了线程部件、内存以及通讯组件的计算节点。?https://en.m.wikipedia.org/wik ... cture

单元化(Cellize)这是我的自造词,描述一个服务改造成单元架构的过程。

模式描述 Patten Description
单元架构最重要的概念,就是单元和单元的自治。

你可以将其想象成细胞,如之前所述,每个细胞都是自成一体,功能明确。你也可以将其想象成小隔间,就像你去了一个按摩院,每个隔间里都有技师和所有设备。我没有用前面那个名字,因为其有太强的生物学含义,也没有用后者,因为其有太多的服务性暗示。但是如果你有足够的想象力,其实什么名字都可以的。

说到单元的自治,即单元的自我协调和之间的隔离。单元既然做到了自包含,那么其中的所有组件,不管是否在物理上分离成了独立的服务,都是在一个单元内互相支持的,也就是跟其他单元内的同类和非同类组件都不会有任何交流。这也是跟基于空间的架构的重要区别,后者的处理单元之间还是会互相通信并同步信息。

这里的挑战就在于分区的算法。一个单元内的组件会很多,如果业务复杂,涉及到的数据也会很多,为了隔离,每一个组件都要能按照同样的算法进行分区。

本质上每个单元都是相似的,单元之间的区别或者取决于请求,或者取决于数据。而且越到大的层面,区分度越低,用户甚至是可以在不同单元间漫游的。

模式动力学?Patten Dynamics
单元架构的最典型目的,还是为了极高的性能,为了获得经济的高速度。这里一方面,是因为我们发现其他架构实际上是浪费了很多资源,每一层服务都运行在单独的操作系统上,而且都要通过局域网或者城域网中转。

与此同时,传统的互联网服务还是希望用一堆计算能力普通的节点来服务大量用户,而随着摩尔定律的推进,单机性能越来越高,网络通讯的成本随之变得耗费显着。这使得我们有机会也有动力在垂直方向进行扩展。

当你把更多的组件放在同一个地方的时候,你也在物理上获得了计算本地化的优势。这是我们获得性能提升的根本原因。

服务分成了很多单元,但总要跟外界通讯,这个事情是交给协调者 Coordinator 的。你可以在内部增加存储、缓存,增加队列和处理机,这些所有不交互的组件,理论上都不是外部资源可以访问的。

前面我们提到,单元化过程也是分区算法的应用过程。而这个分区算法放在哪里就是个问题。

我们可以封装运行库交给客户端,也可以做个代理层,内置算法。也有一些服务因为业务需要,请求需要复制到每个单元去。这就是典型的 Scatter-Gatter 模型,那么你还可能需要一个作业管理系统。这些都是可选择的使用方式。

模式分析 Patten Analysis
总体敏捷度低,易部署性低,可测试性高,性能高,伸缩性高,易开发性低。

基于篇幅原因,不再详述每一个方面,相信大家都能自行分析。唯一需要强调的是运维要求比较高。

单元化之后,所有的服务放在一起,在请求失败的情况下需要快速定位某个单元,这跟分层排除的思路是不一样的。如果运维团队不够高效,面对这样集群数量的暴涨(每个单元的服务数量相当于原来一个集群的服务数量),有可能是会被大量的工作压垮;如果运维团队分离比较明显,每种组件都是专门的团队来维护(这是我们在微博遇到的),那就会有排异反应的风险,因为每一个团队都有自己的权限和服务管理习惯,这里需要相当的协调工作来防止相互干扰。
后记

前面留的一个问题,煎饼果子跟单元化架构的关系。答案说起来很简单,你问问煎饼摊就知道了。

煎饼是分层的,煎饼摊是单元的。消息发送服务是单元的,但是索引维护是分层的。看模式要确定系统的范畴,从不同角度看,同样的东西是有不同意义的。这也是架构师要做的思考。

其实 IT 系统千百万,模式肯定不会止于这几种。但有了基础的模式,了解它们之间的相似和区别,对于我们设计自己的系统,思考其中的权衡都是有帮助的。
Q & A

1.?单元化设计与 Docker 的容器化思路是否相通?又有何差异呢?

一乐:应该是关注的点不一样,但不冲突。Docker 一般是在微服务架构下会使用的措施,但并不意味着不能用在其他架构上。一个单元内的各种组件,使用什么样的技术,都是新的选择。用 Docker 不错。

2.?对于分布式服务,单元化架构可能会带来数据一致性问题,这个一般如何解决?

一乐:可能我没有理解你场景,单元化一般不会带来一致性问题。因为 Sharding 之后,一块分区数据相当于完全属于一个单元,其他单元是被隔离访问的。


3.?单元化架构最小情况是单台机部署整体服务,资源方面如何规划?

一乐:这方面就要计算了,也就是进行容量规划,相信大家在这方面都很熟悉。一个需要注意的点是,单元化的架构应用在可预期的总体容量上时会省很多事。鉴于分区算法的固定,扩容方面,其实可以通过预先规划,在单机上再进行多单元混部的方式。

4.?单元与 app cluster(总服务器)之间是怎么进行关联的,是通过注册服务还是按照 hash 分派的,如果是 hash 分派,那么挂了怎么接回的,如果是注册服务,是怎么对应分派服务呢?

一乐:简单做就是 hash 分派,高级点就是注册服务,可以直接参照成熟的 Sharding 算法。任务只要到了单元内,就是单元自己的事了。如果你的 Job 有阶段性,可能要考虑 Job 状态记录以及请求处理的幂等性

5.?你觉得单元化架构的问题是什么?如果让你重新设计你会做哪些改进?

一乐:这个问题太聪明了,谢谢!单元化架构的问题,如之前所说,有一个扩容难题,有一个运维难题,有一个单点问题。扩容问题刚才说了,在三年前我们还没有 Docker 的时候,我们的服务隔离难度很大,现在已经今非昔比。一刀(Docker)在手,天下我有!单元的单点问题,你得考虑单元级别的主从同步,这方面常见的互联网技术就行。

6.?分布式架构经常讲究服务器无状态,这样可以单台服务器异常对整体服务无影响。但单元化意味着服务是有状态,如何保障高可用?

一乐:无状态只能是业务层,涉及到数据的不会无状态,因为数据就是状态的记录。保障高可用嘛,前面说了,先把主从做了吧。

7.?单元细胞内依然采用分层架构设计还是 ALL IN ONE 即可?

一乐:在讲单元化的时候,其实不要求单元内的组织模式,所以回答是都行。

8.?“每秒百万级的推送” 除了采用这种单元化的架构模式使之成为可能对于基础的中间件如 队列 db 等的架构如何规划的?还要额外考虑哪些技术点或问题?

一乐:队列主要用来防峰,在高速服务里,如果再想扩容,肯定先走批量的路子。db 的规划其实是重点,单元化架构实际上算是以数据为中心的一种模式。额外的考虑其实跟之前都很像,不过要做一些特殊的处理,比如冷热数据的分离。
参考阅读

一个单元化架构的例子 http://t.cn/RqM5Ns0

Software Architecture Patterns?http://www.oreilly.com/program ... s.csp

校长:技术成长四个阶段需要的架构知识
?
支撑微博千亿调用的轻量级RPC框架:Motan

Upsync:微博开源基于Nginx容器动态流量管理方案

小编:一乐最近也开了公众号,内容非常有特色,将复杂的道理说得如煎饼这么通透,所以别忘了识别二维码关注,错过这次小编琢磨最短都要再等一年。




本文策划庆丰,编辑王杰,想讨论更多架构设计,请关注公众号获取进群机会。转载请注明来自高可用架构「ArchNotes」微信公众号及包含以下二维码。 查看全部

640.webp_.jpg

编者按:本文由一乐在高可用架构群分享,转载请注明来自高可用架构「 ArchNotes 」。

640.webp_(1)_.jpg
一乐是我,也是梁宇鹏。现任hg3399.com|官方网站首席架构师兼 IM 技术总监,负责即时通讯云平台的整体研发和管理。曾任新浪微博通讯技术专家,负责微博通讯系统的设计与研发。一直专注在即时通讯领域,熟悉 XMPP 协议和相关的开源实现(包括 Jabberd2、EJabberd、Openfire)。关注分布式系统和高性能服务,关注 Erlang、Golang 和各种浪。


?煎饼的故事

有一段时间住在花园路,最难忘的就是路边的煎饼果子。老板每天晚上出来,正好是我加班回去的时间。

一勺面糊洒在锅上,刮子转一圈,再打一个蛋,依然刮平。然后啪的一下反过来,涂上辣酱,撒上葱花。空出手来,剥一根火腿肠。最后放上薄脆,咔咔咔三铲子断成三边直的长方形,折起来正好握在手中。烫烫的,一口咬下去,蛋香、酱辣、肠鲜,加上薄脆的声音和葱花的惊喜,所有的疲劳都一扫而光。


640.webp_(2)_.jpg

这种幸福感让我如此迷恋,以至于会在深宅的周末,穿戴整齐跑出去,就为了吃上一个。也因为理工科的恶习,我也情不自禁地开始思考这份执迷的原因,直到最后,我发现了它的秘密。
?
作为街头小吃的杰出代表,能够经历众口的挑剔而长盛不衰的秘密是什么?


?
?所有的一切全因为其模式。

而这模式与大多数互联网服务的架构如出一辙,那就是分层架构。

分层的设计意味着,每一层都独立承担单一的职责。

这在根本上降低了制作的难度。做饼的时候专心控制火候,做酱的时候专注在味道。每层职责的单一化也让优化变得简单,因为它是自然可伸缩的。你要是想多吃点蛋就多加一个,你要多吃点肠就多加一根,完全取决于你的胃口。
?
它又是可以扩展的。你可以不要蛋,你可以加根肠,你可以不要薄脆,你可以加上辣酱。而且每一层又是可定制的。葱花可以少一点,辣酱可以多一点,肠可以要两根,鸡蛋可以加三个。

你也可以把面饼换成面包,把鸡蛋换成煎蛋,把辣酱换成甜酱。你已经知道这是什么了吧?是的,你好,这里是赛百味,请问你要什么口味的三明治?

煎饼果子和三明治,其实本质上是相通的。而加一个蛋更香,也不是因为对蛋的追求,在根本上是因为煎饼果子模式的强大。



因为这种模式,一千个人可以有一千种煎饼果子。

而有了对模式的理解,对小吃的评估也就变得更加容易。比如肉夹馍只有馍和肉,二维切换单调不可长久;比如烤冷面,干脆就是满嘴的热烈混在一起,没有煎饼这样的表现层,整个面都散发着原始的不讲究。

这种对比上的简化,也让我们有了新的选择,保存宝贵的精力,并且可以随时放弃对细节的追究。


640.webp_(1)_.jpg

就像在我们谈论女人时,

(抱歉博主是男人)

我们在意胸、

在意腿、

在意风情、

在意温柔,

因为女人是有区别的。

当我们欣赏电影的时候,

我们在意男人、

在意女人、

在意老人、

在意孩子,

因为角色是有区别的。

当我们走在路上的时候,

我们在意行人、

在意车辆、

在意商店、

在意餐厅,

因为物体是有区别的。

我们在设计和优化系统的时候,其中的每个服务都是自行运转,做着自己份内的事,但是在不同的维度里,作用却变得不尽相同。

这也是我们讲优化要分层次和级别,架构、算法、库和 OS,而讲架构的时候,我们首先讲的是整体的模式,然后是具体的权衡,实现的细节则是最不重要的。



架构的模式

谈起这个,是因为 Mark Richards 写了一本架构模式的书《Software Architecture Pattens》。

书中总结对比了五种模式的优缺点,包括了 Layered、Event-Driven、Microkernel、Microservices、Space-Based。

书写得简单精致,推荐大家去阅读,地址见文末。

还有一种模式,因为在越来越多的系统中用到,是书中没有的(与 Space-Based 有所区别),但我觉得也有必要专门介绍下。我们开始在群发系统中实现,后来的抢购、红包和火车票的场景中也屡屡看到它的身影。


2013 年的时候,我们在微博做粉丝服务平台,一个类似微信公众号的群发系统。然而比后者更困难的是,当时在产品设计上并没有像微信一样新建用户体系,而是直接基于微博的粉丝关系,这就意味着一篇文章要能能在很短时间内支持亿级的用户推送。这个数量级的订阅用户,即使看今天的微信公众号依然是难以想象的。
当时有一套老的群发系统,都是基于 MySQL 的收件箱设计,在更换了 SSD 硬盘,又批量化数据库操作之后,整体写入性能依然只在每秒几万的级别,这就意味着一亿用户只能在 17 分钟内发完,我们意识到这套系统需要进行重新设计。

最终我们我们使用了一种新的架构方式,达到了每秒百万级别的速度,而且还可以更高。这种模式就是单元化架构。

下文介绍我参照了架构模式的说明方式,希望能够让大家有个对比,喜欢你可一定要说好!



单元化架构

如前所述,我们选择单元化的一个重要目的是为了性能,为了极高的性能。这比起一般的分层架构来讲,会获得更经济的结果,但也因此,牺牲了分层架构的一些特性,因为它的容量取决于单元的大小(关于单元等名词介绍,我会在下文介绍)。

虽然它支持按照单元扩容,但在单元内基本上每层的性能都是固定的。这更适合容量可预期的场景,比如大多数已经趋于稳定的业务。像前面的粉丝服务平台,虽然他下发消息量级巨大,但是在整体层面,使用平台的用户由于是 VIP 用户,其规模基本在在数百万级别,而粉丝量级也不太可能过亿。

重要的是,基于当时的业务数据,我们已经知道平均粉丝数在什么量级。而业务数据是架构选型的重要依据。商品秒杀、火车抢票等等都是一样。
?
当然也有例外。因为单元化架构作为一种思想,它不会局限在一台机器,一个机架,它也适用一个机房。当它的层次变大时,单元内自然就可以有变化的空间。每一层服务都可以分开伸缩。而到了这个层面,它的追求可能就完全不一样了。像阿里的双十一服务改造,会为了流量的分离,像 QQ 的聊天,会为了接入的速度。它们的基本思想是一致的。

至于单元化架构和煎饼果子的关系,我会在文后回答。


640.webp_(3)_.jpg

核心概念 Key Concepts

分区(Shard)是整体数据集的一个子集。如果你用尾号来划分用户,那么相同尾号的用户可以认为是同一分区。

单元(Cell)是满足某个分区所有业务操作的自包含的安装。我们从并行计算领域里借鉴了这个思想,也就是计算机体系结构里的 Celluar Architecture,在那里一个 Cell 是一个包含了线程部件、内存以及通讯组件的计算节点。?https://en.m.wikipedia.org/wik ... cture

单元化(Cellize)这是我的自造词,描述一个服务改造成单元架构的过程。



模式描述 Patten Description

单元架构最重要的概念,就是单元和单元的自治

你可以将其想象成细胞,如之前所述,每个细胞都是自成一体,功能明确。你也可以将其想象成小隔间,就像你去了一个按摩院,每个隔间里都有技师和所有设备。我没有用前面那个名字,因为其有太强的生物学含义,也没有用后者,因为其有太多的服务性暗示。但是如果你有足够的想象力,其实什么名字都可以的。

说到单元的自治,即单元的自我协调和之间的隔离。单元既然做到了自包含,那么其中的所有组件,不管是否在物理上分离成了独立的服务,都是在一个单元内互相支持的,也就是跟其他单元内的同类和非同类组件都不会有任何交流。这也是跟基于空间的架构的重要区别,后者的处理单元之间还是会互相通信并同步信息。

这里的挑战就在于分区的算法。一个单元内的组件会很多,如果业务复杂,涉及到的数据也会很多,为了隔离,每一个组件都要能按照同样的算法进行分区。

本质上每个单元都是相似的,单元之间的区别或者取决于请求,或者取决于数据。而且越到大的层面,区分度越低,用户甚至是可以在不同单元间漫游的。



模式动力学?Patten Dynamics

单元架构的最典型目的,还是为了极高的性能,为了获得经济的高速度。这里一方面,是因为我们发现其他架构实际上是浪费了很多资源,每一层服务都运行在单独的操作系统上,而且都要通过局域网或者城域网中转。

与此同时,传统的互联网服务还是希望用一堆计算能力普通的节点来服务大量用户,而随着摩尔定律的推进,单机性能越来越高,网络通讯的成本随之变得耗费显着。这使得我们有机会也有动力在垂直方向进行扩展。

当你把更多的组件放在同一个地方的时候,你也在物理上获得了计算本地化的优势。这是我们获得性能提升的根本原因。

服务分成了很多单元,但总要跟外界通讯,这个事情是交给协调者 Coordinator 的。你可以在内部增加存储、缓存,增加队列和处理机,这些所有不交互的组件,理论上都不是外部资源可以访问的。

前面我们提到,单元化过程也是分区算法的应用过程。而这个分区算法放在哪里就是个问题。

我们可以封装运行库交给客户端,也可以做个代理层,内置算法。也有一些服务因为业务需要,请求需要复制到每个单元去。这就是典型的 Scatter-Gatter 模型,那么你还可能需要一个作业管理系统。这些都是可选择的使用方式。



模式分析 Patten Analysis

总体敏捷度低,易部署性低,可测试性高,性能高,伸缩性高,易开发性低。

基于篇幅原因,不再详述每一个方面,相信大家都能自行分析。唯一需要强调的是运维要求比较高。

单元化之后,所有的服务放在一起,在请求失败的情况下需要快速定位某个单元,这跟分层排除的思路是不一样的。如果运维团队不够高效,面对这样集群数量的暴涨(每个单元的服务数量相当于原来一个集群的服务数量),有可能是会被大量的工作压垮;如果运维团队分离比较明显,每种组件都是专门的团队来维护(这是我们在微博遇到的),那就会有排异反应的风险,因为每一个团队都有自己的权限和服务管理习惯,这里需要相当的协调工作来防止相互干扰。


后记

前面留的一个问题,煎饼果子跟单元化架构的关系。答案说起来很简单,你问问煎饼摊就知道了。

煎饼是分层的,煎饼摊是单元的。消息发送服务是单元的,但是索引维护是分层的。看模式要确定系统的范畴,从不同角度看,同样的东西是有不同意义的。这也是架构师要做的思考。

其实 IT 系统千百万,模式肯定不会止于这几种。但有了基础的模式,了解它们之间的相似和区别,对于我们设计自己的系统,思考其中的权衡都是有帮助的。


Q & A

1.?单元化设计与 Docker 的容器化思路是否相通?又有何差异呢?

一乐:应该是关注的点不一样,但不冲突。Docker 一般是在微服务架构下会使用的措施,但并不意味着不能用在其他架构上。一个单元内的各种组件,使用什么样的技术,都是新的选择。用 Docker 不错。

2.?对于分布式服务,单元化架构可能会带来数据一致性问题,这个一般如何解决?

一乐:可能我没有理解你场景,单元化一般不会带来一致性问题。因为 Sharding 之后,一块分区数据相当于完全属于一个单元,其他单元是被隔离访问的。


3.?单元化架构最小情况是单台机部署整体服务,资源方面如何规划?

一乐:这方面就要计算了,也就是进行容量规划,相信大家在这方面都很熟悉。一个需要注意的点是,单元化的架构应用在可预期的总体容量上时会省很多事。鉴于分区算法的固定,扩容方面,其实可以通过预先规划,在单机上再进行多单元混部的方式。

4.?单元与 app cluster(总服务器)之间是怎么进行关联的,是通过注册服务还是按照 hash 分派的,如果是 hash 分派,那么挂了怎么接回的,如果是注册服务,是怎么对应分派服务呢?

一乐:简单做就是 hash 分派,高级点就是注册服务,可以直接参照成熟的 Sharding 算法。任务只要到了单元内,就是单元自己的事了。如果你的 Job 有阶段性,可能要考虑 Job 状态记录以及请求处理的幂等性

5.?你觉得单元化架构的问题是什么?如果让你重新设计你会做哪些改进?

一乐:这个问题太聪明了,谢谢!单元化架构的问题,如之前所说,有一个扩容难题,有一个运维难题,有一个单点问题。扩容问题刚才说了,在三年前我们还没有 Docker 的时候,我们的服务隔离难度很大,现在已经今非昔比。一刀(Docker)在手,天下我有!单元的单点问题,你得考虑单元级别的主从同步,这方面常见的互联网技术就行。

6.?分布式架构经常讲究服务器无状态,这样可以单台服务器异常对整体服务无影响。但单元化意味着服务是有状态,如何保障高可用?

一乐:无状态只能是业务层,涉及到数据的不会无状态,因为数据就是状态的记录。保障高可用嘛,前面说了,先把主从做了吧。

7.?单元细胞内依然采用分层架构设计还是 ALL IN ONE 即可?

一乐:在讲单元化的时候,其实不要求单元内的组织模式,所以回答是都行。

8.?“每秒百万级的推送” 除了采用这种单元化的架构模式使之成为可能对于基础的中间件如 队列 db 等的架构如何规划的?还要额外考虑哪些技术点或问题?

一乐:队列主要用来防峰,在高速服务里,如果再想扩容,肯定先走批量的路子。db 的规划其实是重点,单元化架构实际上算是以数据为中心的一种模式。额外的考虑其实跟之前都很像,不过要做一些特殊的处理,比如冷热数据的分离。


参考阅读

一个单元化架构的例子 http://t.cn/RqM5Ns0

Software Architecture Patterns?http://www.oreilly.com/program ... s.csp

校长:技术成长四个阶段需要的架构知识
?
支撑微博千亿调用的轻量级RPC框架:Motan

Upsync:微博开源基于Nginx容器动态流量管理方案



小编:一乐最近也开了公众号,内容非常有特色,将复杂的道理说得如煎饼这么通透,所以别忘了识别二维码关注,错过这次小编琢磨最短都要再等一年。

640.webp_(4)_.jpg

本文策划庆丰,编辑王杰,想讨论更多架构设计,请关注公众号获取进群机会。转载请注明来自高可用架构「ArchNotes」微信公众号及包含以下二维码。

640.webp_(5)_.jpg

0
评论

hg3399.com|官方网站:全媒体智能客服时代的最佳实践 cti论坛 新闻资讯 hg3399.com|官方网站

beyond 发表了文章 ? 1809 次浏览 ? 2016-04-15 15:33 ? 来自相关话题

随着企业信息化需求的复杂多变,客户服务和体验理念的人性化和智能化,企业通信以及呼叫中心一直是ICT市场上不容忽视的领域。4月14日-15日,由CTI论坛主办的“2016中国呼叫中心及企业通信大会”在北京盛大召开,本次会议以“联络中心的数字化DNA”为主题,围绕企业通信、呼叫中心、下一代通信架构等内容为话题,继续推动ICT产业发展。包括hg3399.com|官方网站等40余家领先的行业供应商展出了其最新产品和服务。同时,hg3399.com|官方网站CEO刘俊彦受邀发表主题演讲,用hg3399.com|官方网站的真实用户案例来诠释什么才是全媒体智能客服时代的最佳实践!





hg3399.com|官方网站移动客服特装展台人头攒动,现场签约成功数单






hg3399.com|官方网站CEO主题演讲,全程无尿点


随着云计算、大数据、移动互联网以及社交媒体的兴起,传统通信模式、企业和客户的交互方式和沟通形态,以及服务理念正面临着前所未有的问题和挑战,新的行业格局也正在形成。2015年作为中国企业级服务元年,同时也是SaaS服务元年,尤其在客服领域诞生了一大批以产品体验和技术创新驱动的SaaS公司,而以全媒体、智能化、移动化为主打的hg3399.com|官方网站移动客服更是其中的翘楚,不到一年时间内服务了1万多家企业,并且在融资额和市场份额上也遥遥领先。

什么是全媒体客服??
?
hg3399.com|官方网站CEO总结到:“来自不同媒体的服务请求均可以统一接入,一键回复,打造跨网、跨界、跨平台的极致客户服务体验。”链家自如客使用hg3399.com|官方网站实现了全媒体客服,hg3399.com|官方网站帮助链家自如客打通了来自App端的客服入口+网页端客服入口+微信端客服入口,不仅可以统一接入回复且后台数据打通共享。帮助链家自如客优化了客服团队,极大的提升了效率,节省了成本。





链家自如客使用hg3399.com|官方网站实现全媒体客服






同时,hg3399.com|官方网站还提供“一体化”客服工作台,支持从APP、微信公众号、微博、网页、呼叫中心等渠道接入,且每个不同渠道均有不同标识进行识别。


从传统呼叫中心到全媒体客服,一场“效率”革命?
?
随着人口红利消失,呼叫中心的升级转型将越来越普遍,2015年中国劳动力规模由2012年的9.37亿降至9.11亿人。中国劳动力人口连续4年绝对值下降企业客服面临的“用工荒”将持续扩大,运营成本将越来越高,越来越多的企业将复制hg3399.com|官方网站客户“学而思”的客服转型之路,从语音呼叫中心为主转而采用全媒体客服,拥抱移动互联网。?
?
学而思以前部署有4套客服产品包括:1,呼叫中心。2,网页客服。3,新媒体客服。4,APP客服。同时对应4个客服团队支持,相互数据不打通,尤其自开通微信客服后,咨询量增长明显,由用户数据不打通带来的用户投诉增多。而且每年10—11月是教育行业的交费季,以前主要靠呼叫中心外呼,工作量巨大,效果不满意。学而思在2015年集成hg3399.com|官方网站移动客服以后,服务模式改为APP内缴费,并在APP内提供客服支持。整个2015年缴费季,APP客服部门数十人完美解决了往年数百个语音客服的工作。hg3399.com|官方网站CEO刘俊彦认为:“APP客服相比电话客服大幅度提供服务效率,全渠道客服也已经成为企业刚需。”
?
?IVR进入触摸时代,自助服务的未来,智能机器人将大显神通?
?
传统IVR,用户需要听完所有菜单再做选择。而现在主流的ITR导航,用户只需在手机上直接选择关注的问题,简单方便。其中神州租车就采购hg3399.com|官方网站移动客服,其中的智能ITR大大缓解了人工客服压力。Gartner预测到2020年,ITR将完全取代IVR全面进入触摸时代。





神州租车使用hg3399.com|官方网站智能ITR缓解人工客服压力


近期李世石1:4不敌AlphaGo的事件又将人工智能推上了风口浪尖。而hg3399.com|官方网站是客服行业少数自主开发智能应答机器人产品的公司,hg3399.com|官方网站知识库+智能聊天机器人可以帮助人工坐席挡住80%的常见问题。同时具有以下特性:1,灵活可定制的智能会话、自定义菜单导航功能。2,预置的行业知识库,行业相关的常见问答可以一键拥有。3,与现有知识库系统对接,机器学习,智能优化知识库。4,人机无缝配合,更少的成本,更好的客户体验 。





hg3399.com|官方网站首推的人机混合服务极大提高客服应答效率

hg3399.com|官方网站CEO表示“人机混合服务”将是现阶段最适合也是最具效率的客户服务方式。


服务式营销,从成本中心转向利润中心?
?
随着客服中心不断的被新时代赋予新的含义,传统的客服中心也正逐渐从成本中心向营销中心和利润中心转化。其中移动电商标杆企业楚楚街就使用hg3399.com|官方网站APP IM长连接技术实现了精准商品推荐。楚楚街精准营销四步走:1,通过“客户标签”功能+“大数据分析”找到目标群体。2,通过hg3399.com|官方网站移动客服的精准营销推送接口,将富媒体商品信息定向推送给目标客户。3,只要APP没被卸载,哪怕APP在后台,用户手机都能收到消息推送。4,客户选择咨询或直接购买。





移动互联网的电话外呼——金融界为电话销售配置hg3399.com|官方网站APP主动营销平台







近期,hg3399.com|官方网站还上线了业界首个“客户声音”产品,可以通过热点话题分析发现新畅销商品,通过情感度分析发现服务问题,来帮助企业更好的来倾听客户的声音。?
?
最后,hg3399.com|官方网站CEO预测:“随着国内SaaS客服产品的逐渐成熟完善,中小企业将全面拥抱SaaS客服,建设全媒体客户关系中心。而传统大型企业也将增量部署全媒体客服,保护已有投资,拥抱移动互联网。”SaaS客服也将逐渐成长为一个千亿级市场。同时,hg3399.com|官方网站CEO认为未来远程办公,移动办公和众包客服将解决客服行业人力资源不足的问题,而hg3399.com|官方网站移动客服的手机端工作后台将提供很大的助力。?
?
hg3399.com|官方网站移动客服简介
?
hg3399.com|官方网站移动客服是全球首创的全媒体智能云客服平台。支持全媒体接入,包括网页在线客服、社交媒体客服(微博、微信)、移动端客服和呼叫中心等多种渠道。hg3399.com|官方网站移动客服基于hg3399.com|官方网站业界领先的IM长连接技术保证消息必达,并通过强大的智能机器人技术极大降低人工客服工作量。?
?
hg3399.com|官方网站移动客服于2014年12月上线,截至2015年底,hg3399.com|官方网站移动客服共服务了12000家企业用户,现已覆盖包括电商、O2O、互联网金融、在线教育、在线旅游、移动医疗、智能硬件、游戏等20大领域的Top10客户,典型用户包括国美在线、58到家、楚楚街、随手记、海尔、51talk,链家自如客等众多互联网和传统企业。根据易观国际发布的《中国SaaS客服市场专题研究报告2015》显示:截至2015年第三季度,hg3399.com|官方网站移动客服在SaaS移动端客服用户覆盖占比为77.4%,以绝对优势稳居行业第一。


? 查看全部

随着企业信息化需求的复杂多变,客户服务和体验理念的人性化和智能化,企业通信以及呼叫中心一直是ICT市场上不容忽视的领域。4月14日-15日,由CTI论坛主办的“2016中国呼叫中心及企业通信大会”在北京盛大召开,本次会议以“联络中心的数字化DNA”为主题,围绕企业通信、呼叫中心、下一代通信架构等内容为话题,继续推动ICT产业发展。包括hg3399.com|官方网站等40余家领先的行业供应商展出了其最新产品和服务。同时,hg3399.com|官方网站CEO刘俊彦受邀发表主题演讲,用hg3399.com|官方网站的真实用户案例来诠释什么才是全媒体智能客服时代的最佳实践!


4840007ba6db56ef75e.jpg

hg3399.com|官方网站移动客服特装展台人头攒动,现场签约成功数单


4830007860cb78fb188.jpg

hg3399.com|官方网站CEO主题演讲,全程无尿点


随着云计算、大数据、移动互联网以及社交媒体的兴起,传统通信模式、企业和客户的交互方式和沟通形态,以及服务理念正面临着前所未有的问题和挑战,新的行业格局也正在形成。2015年作为中国企业级服务元年,同时也是SaaS服务元年,尤其在客服领域诞生了一大批以产品体验和技术创新驱动的SaaS公司,而以全媒体、智能化、移动化为主打的hg3399.com|官方网站移动客服更是其中的翘楚,不到一年时间内服务了1万多家企业,并且在融资额和市场份额上也遥遥领先。

什么是全媒体客服??
?
hg3399.com|官方网站CEO总结到:“来自不同媒体的服务请求均可以统一接入,一键回复,打造跨网、跨界、跨平台的极致客户服务体验。”链家自如客使用hg3399.com|官方网站实现了全媒体客服,hg3399.com|官方网站帮助链家自如客打通了来自App端的客服入口+网页端客服入口+微信端客服入口,不仅可以统一接入回复且后台数据打通共享。帮助链家自如客优化了客服团队,极大的提升了效率,节省了成本。


4840007bb08434213c5.jpg

链家自如客使用hg3399.com|官方网站实现全媒体客服


48600077a10fe4bb80d.jpg

同时,hg3399.com|官方网站还提供“一体化”客服工作台,支持从APP、微信公众号、微博、网页、呼叫中心等渠道接入,且每个不同渠道均有不同标识进行识别。


从传统呼叫中心到全媒体客服,一场“效率”革命?
?
随着人口红利消失,呼叫中心的升级转型将越来越普遍,2015年中国劳动力规模由2012年的9.37亿降至9.11亿人。中国劳动力人口连续4年绝对值下降企业客服面临的“用工荒”将持续扩大,运营成本将越来越高,越来越多的企业将复制hg3399.com|官方网站客户“学而思”的客服转型之路,从语音呼叫中心为主转而采用全媒体客服,拥抱移动互联网。?
?
学而思以前部署有4套客服产品包括:1,呼叫中心。2,网页客服。3,新媒体客服。4,APP客服。同时对应4个客服团队支持,相互数据不打通,尤其自开通微信客服后,咨询量增长明显,由用户数据不打通带来的用户投诉增多。而且每年10—11月是教育行业的交费季,以前主要靠呼叫中心外呼,工作量巨大,效果不满意。学而思在2015年集成hg3399.com|官方网站移动客服以后,服务模式改为APP内缴费,并在APP内提供客服支持。整个2015年缴费季,APP客服部门数十人完美解决了往年数百个语音客服的工作。hg3399.com|官方网站CEO刘俊彦认为:“APP客服相比电话客服大幅度提供服务效率,全渠道客服也已经成为企业刚需。”
?
?IVR进入触摸时代,自助服务的未来,智能机器人将大显神通?
?
传统IVR,用户需要听完所有菜单再做选择。而现在主流的ITR导航,用户只需在手机上直接选择关注的问题,简单方便。其中神州租车就采购hg3399.com|官方网站移动客服,其中的智能ITR大大缓解了人工客服压力。Gartner预测到2020年,ITR将完全取代IVR全面进入触摸时代。


483000786baec35b6f9.jpg

神州租车使用hg3399.com|官方网站智能ITR缓解人工客服压力


近期李世石1:4不敌AlphaGo的事件又将人工智能推上了风口浪尖。而hg3399.com|官方网站是客服行业少数自主开发智能应答机器人产品的公司,hg3399.com|官方网站知识库+智能聊天机器人可以帮助人工坐席挡住80%的常见问题。同时具有以下特性:1,灵活可定制的智能会话、自定义菜单导航功能。2,预置的行业知识库,行业相关的常见问答可以一键拥有。3,与现有知识库系统对接,机器学习,智能优化知识库。4,人机无缝配合,更少的成本,更好的客户体验 。


4850007c51a7cfd3781.jpg

hg3399.com|官方网站首推的人机混合服务极大提高客服应答效率

hg3399.com|官方网站CEO表示“人机混合服务”将是现阶段最适合也是最具效率的客户服务方式。


服务式营销,从成本中心转向利润中心?
?
随着客服中心不断的被新时代赋予新的含义,传统的客服中心也正逐渐从成本中心向营销中心和利润中心转化。其中移动电商标杆企业楚楚街就使用hg3399.com|官方网站APP IM长连接技术实现了精准商品推荐。楚楚街精准营销四步走:1,通过“客户标签”功能+“大数据分析”找到目标群体。2,通过hg3399.com|官方网站移动客服的精准营销推送接口,将富媒体商品信息定向推送给目标客户。3,只要APP没被卸载,哪怕APP在后台,用户手机都能收到消息推送。4,客户选择咨询或直接购买。


4870007c4fb88cecca9.jpg

移动互联网的电话外呼——金融界为电话销售配置hg3399.com|官方网站APP主动营销平台


483000787311ce78569.jpg



近期,hg3399.com|官方网站还上线了业界首个“客户声音”产品,可以通过热点话题分析发现新畅销商品,通过情感度分析发现服务问题,来帮助企业更好的来倾听客户的声音。?
?
最后,hg3399.com|官方网站CEO预测:“随着国内SaaS客服产品的逐渐成熟完善,中小企业将全面拥抱SaaS客服,建设全媒体客户关系中心。而传统大型企业也将增量部署全媒体客服,保护已有投资,拥抱移动互联网。”SaaS客服也将逐渐成长为一个千亿级市场。同时,hg3399.com|官方网站CEO认为未来远程办公,移动办公和众包客服将解决客服行业人力资源不足的问题,而hg3399.com|官方网站移动客服的手机端工作后台将提供很大的助力。?
?
hg3399.com|官方网站移动客服简介
?
hg3399.com|官方网站移动客服是全球首创的全媒体智能云客服平台。支持全媒体接入,包括网页在线客服、社交媒体客服(微博、微信)、移动端客服和呼叫中心等多种渠道。hg3399.com|官方网站移动客服基于hg3399.com|官方网站业界领先的IM长连接技术保证消息必达,并通过强大的智能机器人技术极大降低人工客服工作量。?
?
hg3399.com|官方网站移动客服于2014年12月上线,截至2015年底,hg3399.com|官方网站移动客服共服务了12000家企业用户,现已覆盖包括电商、O2O、互联网金融、在线教育、在线旅游、移动医疗、智能硬件、游戏等20大领域的Top10客户,典型用户包括国美在线、58到家、楚楚街、随手记、海尔、51talk,链家自如客等众多互联网和传统企业。根据易观国际发布的《中国SaaS客服市场专题研究报告2015》显示:截至2015年第三季度,hg3399.com|官方网站移动客服在SaaS移动端客服用户覆盖占比为77.4%,以绝对优势稳居行业第一。


?
0
评论

客户世界专访hg3399.com|官方网站CEO:选择长赛道、主打全媒体、拥抱黑科技 新闻资讯 hg3399.com|官方网站

beyond 发表了文章 ? 1512 次浏览 ? 2016-04-14 18:58 ? 来自相关话题

SaaS(Software as a Service)技术在国内呼叫中心领域已兴起多年,但直到近两年才形成风暴式的发展。当前,不仅新型互联网企业愿意采用这种布署灵活、低成本、高效率的云端技术,大量传统企业也在服务升级的推动下向SaaS模式的客服系统过渡。据行业估测国内客服软件市场需求在200亿人民币左右,未来几年中国SaaS市场将保持30%以上的年复合增长率。2015年以来,随着2B市场被资本引爆,客服行业涌现出一批专注于多渠道、智能化一体的SaaS型企业,在激烈角逐的同时也为行业带来更多创新活力。







hg3399.com|官方网站创立于2013年,经过不到三年的发展,其产品已从最初的即时通迅云平台,发展到智能移动客服系统、全渠道智能客服平台。2015年,hg3399.com|官方网站的移动客服产品荣获工信部颁发“最具成长性APP应用奖”;同年10月,荣获第十一届“金耳唛杯”中国最佳客户中心技术产品奖。2015年底,在易观发布的《2015中国SaaS客服市场专题研究报告》中,hg3399.com|官方网站移动客服在SaaS客服移动端用户覆盖占比77.4%,居国内市场第一。目前hg3399.com|官方网站已经获得四轮,总计2200万美元的融资,成为即时通迅云和SaaS客服领域融资最快、资金最充裕的平台。?
?
近期,《客户世界》杂志对hg3399.com|官方网站即时通信云CEO刘俊彦进行了专访,刘俊彦先生畅谈了hg3399.com|官方网站过去3年的成长历程及对未来市场的展望。?
?
一、创造风口与把握机遇?
?
2013年,现在已更名为中关村创业大街的海淀图书城里有一家远近闻名的“车库咖啡”,是当时IT创业者的聚集地,hg3399.com|官方网站即起步于此。
?
?2013年陌陌上市前后,社交软件的需求一时间变得非常之火,刘俊彦是这个领域的专家,当时找他咨询如何为APP开发聊天功能的人特别多,而单独开发一套APP聊天功能非常费时费力,于是他想到将即时通讯功能做成云服务的形式让用户自主集成,这样可以高效地帮助创业者发展。?
?
“即时通迅云”作为即时通迅领域的创新概念由hg3399.com|官方网站首次提出,产品推出后,随即获得了创业者和众多企业的认可和追捧,很短的时间内平台上就发展出上万家企业用户。“风口”的效应其实是无意间被创造出来的。
?
?据刘俊彦介绍,hg3399.com|官方网站的四位联合创始人都是技术出身,他本人曾就职于RedHat(红帽)公司,有着多年开源社区项目的开发经验。创业团队平均年龄在四十岁左右,算是中年创业,因为之前都在外企工作收入比较高,所以在创业之初没有太多经济压力,也非常清楚自己的优势。选择好了产品方向,大家就本着务实的原则向前努力,最初的办公地点就在“车库咖啡”,“七八个人占两张桌子,每天早晨来上班还要占座。”
?
?2014年5月,车库咖啡对面开了一家叫“36氪”的孵化器。开业的前一天刘俊彦和伙伴儿们过去转了转,就碰到氪空间负责人,一番交流后对方马上邀请他们入驻“氪空间”。他们周一搬家刚入驻,下午就来了两拔VC,其中就有经纬的投资人,聊了两个小时后,第二天就签署了协议。
?
?“第一次融资可以说是一个非常偶然、随意的过程,”刘俊彦说,“我们在创业的时候并没有融资的想法,也没想到以后要怎么挣钱,会有什么样的商业模式。唯一可以想象的是,如果有几万个APP在用我们的产品,每天有几亿人连接到我们的服务器上,用我们的聊天功能谈论社会热点,交友,购物,到那个时间点价值一定会显现出来。”
?
?在资本的支持下,公司很快走上正轨。2014年10月起,hg3399.com|官方网站投入大量资源开发移动客服产品,也即从原有的PasS(PlatformasaService)平台向上延伸,做SaaS产品。 “从即时通迅云上线的第一天起,就不断有用户来找我们,希望把聊天功能做成像淘宝旺旺那样的可以嵌入到APP里的客服工具。因此,移动端的客服产品可以说是在用户真实需求的趋动下自然而然地开发出来的。开始的时候你其实不知道商业模式,当你每天接触几百个用户,有几千个公司、几万个人在用你的产品的时候,商业模式自然而然就形成了。”?
?
2015年4月hg3399.com|官方网站移动客服上线,在当时的时间点上,APP中有内置客服的产品只有“淘宝旺旺”和京东的“叮咚”。通过把PaaS平台的老用户成功转化为SaaS平台的新客户,hg3399.com|官方网站在自己创造的风口上再次成为了移动端客服软件的领跑者。2015年5月hg3399.com|官方网站获得B轮1250万美金融资,签约付费客服席位4万个,典型用户包括国美在线、58到家、楚楚街9块9等上百家互联网知名企业。?
?
2016年伊始,hg3399.com|官方网站基于当前客服市场对统一解决方案的需求再次推出全渠道智能客服产品。
?
?二.以机器人、大数据确立竞争优势
?
据2015年“双十一”天猫的销售统计数据,接近70%的订单来自移动客户端,这意味着客户服务未来会越来越多地向移动端倾斜。同时,社交媒体的发展不仅连接了人与人、人与商业,未来还将连接一切,因此这种连接的价值一定要在未来的客服软件中体现出来,而客户不仅仅是通过微博、微信等社交工具向企业寻求帮助,还会有更多的用户之间的互动与互助需求需要被满足。刘俊彦认为移动化、社交化、智能化与个性化是未来客服软件产品应该具备的特性。未来客服工具不仅要具备全渠道接入、质检、统计、知识库查询等基础功能,还需要智能化和大数据的能力来帮助客户更好地提升服务效率并进行精准的二次营销,帮助企业客服中心成为真正的利润中心和价值中心。此外,SaaS客服软件具有的定制化优势可以很好地满足客户个性化需求,企业用户可根据自己的特点和需求自定义设置系统模块。
?
?针对未来客服产品的发展趋势,hg3399.com|官方网站产品目前除了拥有完善的基础功能外,还在机器人研发及大数据分析方面做了大量的投入和部署。据刘俊彦介绍,目前人机混合的智能机器人问答、客户画像等先进技术已进入生产内测环节。未来hg3399.com|官方网站产品的差异化优势除了原有IM长连接技术外,将更多体现在商业化智能分析、智能机器人问答、大数据分析与挖掘等方面。黑科技领域的技术优势将在下半年的竞争中逐渐显现出来。?
?
“我们现在做人机混和,当机器人回答不了客户问题时,会转人工座席,人工座席回答的同时,我们会把会话同时‘喂’给机器人,机器人不断的自动学习人工坐席的回答,并根据知识库和以前的知识积累,自动提示座席回答内容,座席看到提示靠谱,只要点击一下就可以发送给客户,这对工作效率是极大的提高。”
?
?刘俊彦说:“资本投入上的差异是非常关键的,研发上的投入一定能从产品上体现出来。我们花了大力气和大价钱找到最优秀的人才加入我们。像人工智能、机器学习领域的顶尖人才,说服他们加入,光靠好的待遇是不够的,更重要的是用愿景来打动他们。”hg3399.com|官方网站目前拥有180名员工,其中90是研发人员,是一支技术导向型的团队。?
?
统计资料显示,中国目前企业总数5000万家,而IT普及率不及5%。对标美国市场,美国的企业总数不及中国企业数量多,但IT普及率达到50%。在企业服务领域,美国有四五家几千亿美金市值的巨头公司,如微软、SAP、ORACLE等,但在中国SaaS领域还没有大型公司出现。当前中国大量的企业在做“互联网+” ,谁来满足这批用户的需求,就有可能成为中国企业级服务市场的巨头。“这是一个非常大的增量市场,我们能吃下十个亿就是一个很好的公司了。”刘俊彦对市场未来充满信心。?
?
有人把未来世界的产业格局划分为三个维度,一维:传统产业;二维:互联网产业;三维:智能科技产业。而将二维产业升级为三维产业的关键力量是大数据的崛起。未来一切竞争归结到最后都是数据的竞争。当前,智能客服机器人和大数据技术是带动整个服务产业升极的核心技术。
?
?从用户需求出发,选择长赛道、拥抱尖端技术,做市场的引领者是hg3399.com|官方网站始终的选择。
?
?三.访谈实录?
?
Q:目前的很多大型传统型企业已经有了成型的传统呼叫中心平台,您如何看待他们对全渠道平台的引入?
?
A:这些企业之前自建投入非常大,我们的策略是让他们在继续保留这些投资的同时,帮助他们拥抱移动互联网。我们提供一套在线客服系统,让他们可以连接微博微信网页和APP,不仅有KPI考核、统计等常用功能,还有先进的机器人客服,可以和原有呼叫中心无缝打通,比如一个人以前通过电话找过你,再通过微信,网页等渠道进来,你依然可以识别他,并且知道之前的交互记录,数据是完全互通的。而且还能做统一排队,比如一个服务交互在微信上没有解决问题,客服人员提示客户电话接入,这时电话再次接入到的一定是刚才服务过你的那个座席。因此客户可以在投入不大的情况下就可完成“互联网+”的升级。
?
?Q:您提到统一排队的概念,我想深入问一下,这也是我在很多客户那里遇到的问题 。因为在线渠道是即时的,语音渠道是实时的,比如一个提供三种服务的座席,也叫全技能座席,正在接听一通电话,这时有一个实时的微信推送过来。正常来讲排队系统应该能识别到座席的状态不能接入这个业务,对于这个问题,您是怎么解决的??
?
A:这是很多做客服软件的厂家遇到的一个特别大的困扰。我们针对大型用户的解决方案一般会把语音座席和即时座席分开,因为实时和即时不可能做到统一排队,这是两个互斥的行为。我们提供一种最佳解决方法,软件是一个全技能的座席软件,座席也是一个全技能的座席,但是状态可以切换,比如企业准备在晚上6点多做一个促销活动,预测6点半从微信、APP渠道会接入大量客户请求,那么这个企业6点25分把十个座席从语音状态全部切换到在线座席的状态,同一组人、同一台PC、同一个软件实现渠道间的切换。我们认为做到这点就很好了。
?
?Q:您的 SaaS平台,如何保障客户的数据安全??
?
A:我们从以下几个层面保护:首先我们和每个用户都有签署严格的法律协议,公有云上客户的数据全部是客户自己的,我们不会碰,客户有完全的处理权。第二从技术架构上进行运维监控,我们内部的运维人员分层,公司里目前只有两个人,不包括我在内能进入到数据库,其他运维人员只有服务的运维权限没有数据权限。而他们也和公司签定了严格的法律协定,任何一举一动都会被系统监控。出了未经授权的问题会承担法律责任。第三,我们是一个多租户系统,租户间的数据都是完全隔离的。第四我们长期聘请第三方安全公司对公有云平台做扫描,进行服务升级,确保不出现任何安全上的漏洞。?
?
Q:关于“客户画像”,你们在具体服务中是帮助客户做一些分析还只是把数据给到客户让他自己去分析?
?
?A:用户画像是主动营销的核心技术,举个例子,我们有个规模很大的电商用户,在后台做了一个大数据挖掘,找到2万名妈妈,打上标签,然后再从中找到所有2-4岁小孩的妈妈2千名打上标签,通过我们客服软件的群发接口给目标用户推送儿童汽车坐椅的消息。客户点击后并不是进入一个广告页面,而是进入一个和真人对话的一对一的聊天页面。这种营销方式比企业之前毫无差异地群发广告提高了20多倍的客户转化率。这项技术有两个核心点,一是基于大数据的用户精准画像和标签;二是APP主动营销,这是对过去外呼时代呼叫中心主流营销模式一个质的改变。可以理解为它是一种APP的外呼技术,代替了以往的电话通道,但对用户干扰非常小。
?
?Q:我们的产品可否满足运营人员对于管理工具的定制化需求?在使用中客制化是否方便、速度如何?
?
?A:我理解这个问题的核心是报表和统计,再往上说是数据和挖掘。以前的软件产品会提供很多报表,但这个时代过去了,因为对于太多的报表客户经常会不知道怎么用,而且用户永远都有层出不穷的新报表需求,那种写死的报表无法与时俱进。我们现在所有的数据分析和报表都是基于发现式的BI和大数据挖掘。以前的报表改不了,而发现式BI则是根据大数据引擎不断挖掘出各种结果。用户可以自行灵活配制界面,你需要什么指标,什么图都可以自行配制。新时代的大数据公司全是做这种发现式的报表,这是一项非常核心的技术。
?
?Q:我们能满足企业自建平台的需求吗?
?
?A:会满足,因为中国现状是这样,尤其是投资、金融、印刷等行业有严格规定,数据就是不能出公司。我们也是可以做私有云。私有云客单价高。
?
?Q:我看到hg3399.com|官方网站经常发布一些交流活动信息,比如组织iGEEK GAMP沙龙、APP运营沙龙?这些活动举办的初衷是什么?影响如何?
?
?A:我们的PaaS产品(即时通迅云)为我们的SaaS产品贡献了很多优质客户流量,我们需要用这种社区的方式来维护和构建深度的开发者关系。我们认为,未来客户管理产品将是一个生态体系中的产品,SaaS产品只是一个基础软件,上边会长出很多小的分支,比如一些定制化需求,由其它的第三方团队来做,我们给他们提供API接口,进行定制化开发。我们通过hg3399.com|官方网站的这些社区活动聚集了一批开发者团队,这也是为我们未来生态圈的布局做积累,做蓄水池,这是其他行业竞品所不具备的。 从产品角度来说,做客服软件最大的痛点就是刚才提到的高级和大型用户的复杂定制化需求,如何解决,就是通过hg3399.com|官方网站的PaaS平台,把基础功能开放出来,不仅做自己的产品也让合作伙伴在这个平台上做二次开发,比如开发者可以在我们平台上做一个专门的报表模块。这应该是所有的SaaS厂商的必由之路,但这需要底层的平台有很好的扩展性和开放性,这在技术上的门槛非常高。?
?
这实际就是生态圈的玩法。生态圈相当于一个核武器,超越产品是有可能的,但想超越生态圈难度太大了。

? 查看全部

SaaS(Software as a Service)技术在国内呼叫中心领域已兴起多年,但直到近两年才形成风暴式的发展。当前,不仅新型互联网企业愿意采用这种布署灵活、低成本、高效率的云端技术,大量传统企业也在服务升级的推动下向SaaS模式的客服系统过渡。据行业估测国内客服软件市场需求在200亿人民币左右,未来几年中国SaaS市场将保持30%以上的年复合增长率。2015年以来,随着2B市场被资本引爆,客服行业涌现出一批专注于多渠道、智能化一体的SaaS型企业,在激烈角逐的同时也为行业带来更多创新活力。



484000662ee615d61f3.jpg



hg3399.com|官方网站创立于2013年,经过不到三年的发展,其产品已从最初的即时通迅云平台,发展到智能移动客服系统、全渠道智能客服平台。2015年,hg3399.com|官方网站的移动客服产品荣获工信部颁发“最具成长性APP应用奖”;同年10月,荣获第十一届“金耳唛杯”中国最佳客户中心技术产品奖。2015年底,在易观发布的《2015中国SaaS客服市场专题研究报告》中,hg3399.com|官方网站移动客服在SaaS客服移动端用户覆盖占比77.4%,居国内市场第一。目前hg3399.com|官方网站已经获得四轮,总计2200万美元的融资,成为即时通迅云和SaaS客服领域融资最快、资金最充裕的平台。?
?
近期,《客户世界》杂志对hg3399.com|官方网站即时通信云CEO刘俊彦进行了专访,刘俊彦先生畅谈了hg3399.com|官方网站过去3年的成长历程及对未来市场的展望。?
?
一、创造风口与把握机遇?
?
2013年,现在已更名为中关村创业大街的海淀图书城里有一家远近闻名的“车库咖啡”,是当时IT创业者的聚集地,hg3399.com|官方网站即起步于此。
?
?2013年陌陌上市前后,社交软件的需求一时间变得非常之火,刘俊彦是这个领域的专家,当时找他咨询如何为APP开发聊天功能的人特别多,而单独开发一套APP聊天功能非常费时费力,于是他想到将即时通讯功能做成云服务的形式让用户自主集成,这样可以高效地帮助创业者发展。?
?
“即时通迅云”作为即时通迅领域的创新概念由hg3399.com|官方网站首次提出,产品推出后,随即获得了创业者和众多企业的认可和追捧,很短的时间内平台上就发展出上万家企业用户。“风口”的效应其实是无意间被创造出来的。
?
?据刘俊彦介绍,hg3399.com|官方网站的四位联合创始人都是技术出身,他本人曾就职于RedHat(红帽)公司,有着多年开源社区项目的开发经验。创业团队平均年龄在四十岁左右,算是中年创业,因为之前都在外企工作收入比较高,所以在创业之初没有太多经济压力,也非常清楚自己的优势。选择好了产品方向,大家就本着务实的原则向前努力,最初的办公地点就在“车库咖啡”,“七八个人占两张桌子,每天早晨来上班还要占座。”
?
?2014年5月,车库咖啡对面开了一家叫“36氪”的孵化器。开业的前一天刘俊彦和伙伴儿们过去转了转,就碰到氪空间负责人,一番交流后对方马上邀请他们入驻“氪空间”。他们周一搬家刚入驻,下午就来了两拔VC,其中就有经纬的投资人,聊了两个小时后,第二天就签署了协议。
?
?“第一次融资可以说是一个非常偶然、随意的过程,”刘俊彦说,“我们在创业的时候并没有融资的想法,也没想到以后要怎么挣钱,会有什么样的商业模式。唯一可以想象的是,如果有几万个APP在用我们的产品,每天有几亿人连接到我们的服务器上,用我们的聊天功能谈论社会热点,交友,购物,到那个时间点价值一定会显现出来。”
?
?在资本的支持下,公司很快走上正轨。2014年10月起,hg3399.com|官方网站投入大量资源开发移动客服产品,也即从原有的PasS(PlatformasaService)平台向上延伸,做SaaS产品。 “从即时通迅云上线的第一天起,就不断有用户来找我们,希望把聊天功能做成像淘宝旺旺那样的可以嵌入到APP里的客服工具。因此,移动端的客服产品可以说是在用户真实需求的趋动下自然而然地开发出来的。开始的时候你其实不知道商业模式,当你每天接触几百个用户,有几千个公司、几万个人在用你的产品的时候,商业模式自然而然就形成了。”?
?
2015年4月hg3399.com|官方网站移动客服上线,在当时的时间点上,APP中有内置客服的产品只有“淘宝旺旺”和京东的“叮咚”。通过把PaaS平台的老用户成功转化为SaaS平台的新客户,hg3399.com|官方网站在自己创造的风口上再次成为了移动端客服软件的领跑者。2015年5月hg3399.com|官方网站获得B轮1250万美金融资,签约付费客服席位4万个,典型用户包括国美在线、58到家、楚楚街9块9等上百家互联网知名企业。?
?
2016年伊始,hg3399.com|官方网站基于当前客服市场对统一解决方案的需求再次推出全渠道智能客服产品。
?
?二.以机器人、大数据确立竞争优势
?
据2015年“双十一”天猫的销售统计数据,接近70%的订单来自移动客户端,这意味着客户服务未来会越来越多地向移动端倾斜。同时,社交媒体的发展不仅连接了人与人、人与商业,未来还将连接一切,因此这种连接的价值一定要在未来的客服软件中体现出来,而客户不仅仅是通过微博、微信等社交工具向企业寻求帮助,还会有更多的用户之间的互动与互助需求需要被满足。刘俊彦认为移动化、社交化、智能化与个性化是未来客服软件产品应该具备的特性。未来客服工具不仅要具备全渠道接入、质检、统计、知识库查询等基础功能,还需要智能化和大数据的能力来帮助客户更好地提升服务效率并进行精准的二次营销,帮助企业客服中心成为真正的利润中心和价值中心。此外,SaaS客服软件具有的定制化优势可以很好地满足客户个性化需求,企业用户可根据自己的特点和需求自定义设置系统模块。
?
?针对未来客服产品的发展趋势,hg3399.com|官方网站产品目前除了拥有完善的基础功能外,还在机器人研发及大数据分析方面做了大量的投入和部署。据刘俊彦介绍,目前人机混合的智能机器人问答、客户画像等先进技术已进入生产内测环节。未来hg3399.com|官方网站产品的差异化优势除了原有IM长连接技术外,将更多体现在商业化智能分析、智能机器人问答、大数据分析与挖掘等方面。黑科技领域的技术优势将在下半年的竞争中逐渐显现出来。?
?
“我们现在做人机混和,当机器人回答不了客户问题时,会转人工座席,人工座席回答的同时,我们会把会话同时‘喂’给机器人,机器人不断的自动学习人工坐席的回答,并根据知识库和以前的知识积累,自动提示座席回答内容,座席看到提示靠谱,只要点击一下就可以发送给客户,这对工作效率是极大的提高。”
?
?刘俊彦说:“资本投入上的差异是非常关键的,研发上的投入一定能从产品上体现出来。我们花了大力气和大价钱找到最优秀的人才加入我们。像人工智能、机器学习领域的顶尖人才,说服他们加入,光靠好的待遇是不够的,更重要的是用愿景来打动他们。”hg3399.com|官方网站目前拥有180名员工,其中90是研发人员,是一支技术导向型的团队。?
?
统计资料显示,中国目前企业总数5000万家,而IT普及率不及5%。对标美国市场,美国的企业总数不及中国企业数量多,但IT普及率达到50%。在企业服务领域,美国有四五家几千亿美金市值的巨头公司,如微软、SAP、ORACLE等,但在中国SaaS领域还没有大型公司出现。当前中国大量的企业在做“互联网+” ,谁来满足这批用户的需求,就有可能成为中国企业级服务市场的巨头。“这是一个非常大的增量市场,我们能吃下十个亿就是一个很好的公司了。”刘俊彦对市场未来充满信心。?
?
有人把未来世界的产业格局划分为三个维度,一维:传统产业;二维:互联网产业;三维:智能科技产业。而将二维产业升级为三维产业的关键力量是大数据的崛起。未来一切竞争归结到最后都是数据的竞争。当前,智能客服机器人和大数据技术是带动整个服务产业升极的核心技术。
?
?从用户需求出发,选择长赛道、拥抱尖端技术,做市场的引领者是hg3399.com|官方网站始终的选择。
?
?三.访谈实录?
?
Q:目前的很多大型传统型企业已经有了成型的传统呼叫中心平台,您如何看待他们对全渠道平台的引入?
?
A:这些企业之前自建投入非常大,我们的策略是让他们在继续保留这些投资的同时,帮助他们拥抱移动互联网。我们提供一套在线客服系统,让他们可以连接微博微信网页和APP,不仅有KPI考核、统计等常用功能,还有先进的机器人客服,可以和原有呼叫中心无缝打通,比如一个人以前通过电话找过你,再通过微信,网页等渠道进来,你依然可以识别他,并且知道之前的交互记录,数据是完全互通的。而且还能做统一排队,比如一个服务交互在微信上没有解决问题,客服人员提示客户电话接入,这时电话再次接入到的一定是刚才服务过你的那个座席。因此客户可以在投入不大的情况下就可完成“互联网+”的升级。
?
?Q:您提到统一排队的概念,我想深入问一下,这也是我在很多客户那里遇到的问题 。因为在线渠道是即时的,语音渠道是实时的,比如一个提供三种服务的座席,也叫全技能座席,正在接听一通电话,这时有一个实时的微信推送过来。正常来讲排队系统应该能识别到座席的状态不能接入这个业务,对于这个问题,您是怎么解决的??
?
A:这是很多做客服软件的厂家遇到的一个特别大的困扰。我们针对大型用户的解决方案一般会把语音座席和即时座席分开,因为实时和即时不可能做到统一排队,这是两个互斥的行为。我们提供一种最佳解决方法,软件是一个全技能的座席软件,座席也是一个全技能的座席,但是状态可以切换,比如企业准备在晚上6点多做一个促销活动,预测6点半从微信、APP渠道会接入大量客户请求,那么这个企业6点25分把十个座席从语音状态全部切换到在线座席的状态,同一组人、同一台PC、同一个软件实现渠道间的切换。我们认为做到这点就很好了。
?
?Q:您的 SaaS平台,如何保障客户的数据安全??
?
A:我们从以下几个层面保护:首先我们和每个用户都有签署严格的法律协议,公有云上客户的数据全部是客户自己的,我们不会碰,客户有完全的处理权。第二从技术架构上进行运维监控,我们内部的运维人员分层,公司里目前只有两个人,不包括我在内能进入到数据库,其他运维人员只有服务的运维权限没有数据权限。而他们也和公司签定了严格的法律协定,任何一举一动都会被系统监控。出了未经授权的问题会承担法律责任。第三,我们是一个多租户系统,租户间的数据都是完全隔离的。第四我们长期聘请第三方安全公司对公有云平台做扫描,进行服务升级,确保不出现任何安全上的漏洞。?
?
Q:关于“客户画像”,你们在具体服务中是帮助客户做一些分析还只是把数据给到客户让他自己去分析?
?
?A:用户画像是主动营销的核心技术,举个例子,我们有个规模很大的电商用户,在后台做了一个大数据挖掘,找到2万名妈妈,打上标签,然后再从中找到所有2-4岁小孩的妈妈2千名打上标签,通过我们客服软件的群发接口给目标用户推送儿童汽车坐椅的消息。客户点击后并不是进入一个广告页面,而是进入一个和真人对话的一对一的聊天页面。这种营销方式比企业之前毫无差异地群发广告提高了20多倍的客户转化率。这项技术有两个核心点,一是基于大数据的用户精准画像和标签;二是APP主动营销,这是对过去外呼时代呼叫中心主流营销模式一个质的改变。可以理解为它是一种APP的外呼技术,代替了以往的电话通道,但对用户干扰非常小。
?
?Q:我们的产品可否满足运营人员对于管理工具的定制化需求?在使用中客制化是否方便、速度如何?
?
?A:我理解这个问题的核心是报表和统计,再往上说是数据和挖掘。以前的软件产品会提供很多报表,但这个时代过去了,因为对于太多的报表客户经常会不知道怎么用,而且用户永远都有层出不穷的新报表需求,那种写死的报表无法与时俱进。我们现在所有的数据分析和报表都是基于发现式的BI和大数据挖掘。以前的报表改不了,而发现式BI则是根据大数据引擎不断挖掘出各种结果。用户可以自行灵活配制界面,你需要什么指标,什么图都可以自行配制。新时代的大数据公司全是做这种发现式的报表,这是一项非常核心的技术。
?
?Q:我们能满足企业自建平台的需求吗?
?
?A:会满足,因为中国现状是这样,尤其是投资、金融、印刷等行业有严格规定,数据就是不能出公司。我们也是可以做私有云。私有云客单价高。
?
?Q:我看到hg3399.com|官方网站经常发布一些交流活动信息,比如组织iGEEK GAMP沙龙、APP运营沙龙?这些活动举办的初衷是什么?影响如何?
?
?A:我们的PaaS产品(即时通迅云)为我们的SaaS产品贡献了很多优质客户流量,我们需要用这种社区的方式来维护和构建深度的开发者关系。我们认为,未来客户管理产品将是一个生态体系中的产品,SaaS产品只是一个基础软件,上边会长出很多小的分支,比如一些定制化需求,由其它的第三方团队来做,我们给他们提供API接口,进行定制化开发。我们通过hg3399.com|官方网站的这些社区活动聚集了一批开发者团队,这也是为我们未来生态圈的布局做积累,做蓄水池,这是其他行业竞品所不具备的。 从产品角度来说,做客服软件最大的痛点就是刚才提到的高级和大型用户的复杂定制化需求,如何解决,就是通过hg3399.com|官方网站的PaaS平台,把基础功能开放出来,不仅做自己的产品也让合作伙伴在这个平台上做二次开发,比如开发者可以在我们平台上做一个专门的报表模块。这应该是所有的SaaS厂商的必由之路,但这需要底层的平台有很好的扩展性和开放性,这在技术上的门槛非常高。?
?
这实际就是生态圈的玩法。生态圈相当于一个核武器,超越产品是有可能的,但想超越生态圈难度太大了。

?
0
评论

hg3399.com|官方网站直播课堂第七期--3.xSDK实时音视频的集成

beyond 发表了文章 ? 1258 次浏览 ? 2016-04-12 19:16 ? 来自相关话题

日期与时间:2016年4月14日15:00

持续时间:半小时

描述:教你如何从零开始,用hg3399.com|官方网站ios?sdk实现即时视频和聊天

本期hg3399.com|官方网站直播课堂将由hg3399.com|官方网站IOS工程师fudh给大家详细讲解集成3.0?SDK实时音视频

直播观看地址:?http://www.imgeek.org/video/15?

视频回放地址:http://www.imgeek.org/video/24 查看全部
日期与时间:2016年4月14日15:00

持续时间:半小时

描述:教你如何从零开始,用hg3399.com|官方网站ios?sdk实现即时视频和聊天

本期hg3399.com|官方网站直播课堂将由hg3399.com|官方网站IOS工程师fudh给大家详细讲解集成3.0?SDK实时音视频

直播观看地址:?http://www.imgeek.org/video/15?

视频回放地址:http://www.imgeek.org/video/24
0
回复

急求: 从安卓接收到的语音消息 看看问题是在安卓还是在iOS iOS和安卓 语音消息

回复

石头城 发起了问题 ? 1 人关注 ? 2289 次浏览 ? 2016-04-12 17:56 ? 来自相关话题

0
评论

hg3399.com|官方网站CEO:从传统呼叫中心到全媒体客服,一场“效率”革命

beyond 发表了文章 ? 2104 次浏览 ? 2016-04-12 16:01 ? 来自相关话题

2016年4月8日,由江苏智恒发起的《企业通信与呼叫中心技术发展论坛》在江苏南京圆满落幕。hg3399.com|官方网站做为全媒体智能云客服倡领者受邀参加了本次行业盛会,hg3399.com|官方网站CEO刘俊彦在大会与现场的数百位行业精英一起分享了题为《全媒体智能客服时代的最佳实践》的主题演讲。

本次论坛活动旨在促进新兴通信技术在企业通信呼叫中心领域的推广、提高企业的通信能力、提高企业部署通信和客户服务平台时的策划水平。包括开源软交换技术,基于浏览器模式的实时通信技术,视频直播技术,呼叫中心领域中的智能化和多渠道客户体验技术。

2015年作为中国企业级服务元年,同时也是SaaS服务元年,尤其在客服领域诞生了一大批以产品技术驱动的SaaS公司,而以全媒体、智能化、移动化为主打的hg3399.com|官方网站移动客服更是其中的翘楚,不到一年时间内服务了1万多家企业,并且在融资额和市场份额上也遥遥领先。

从传统呼叫中心到全媒体客服,一场“效率”革命

随着人口红利消失,呼叫中心的升级转型将越来越普遍,2015年中国劳动力规模由2012年的9.37亿降至9.11亿人。中国劳动力人口连续4年绝对值下降企业客服面临的“用工荒”将持续扩大,运营成本将越来越高,越来越多的企业将复制hg3399.com|官方网站客户“学而思”的客服转型之路,从语音呼叫中心为主转而采用全媒体客服,拥抱移动互联网。

学而思以前部署有4套客服产品包括:1,呼叫中心。2,网页客服。3,新媒体客服。4,APP客服。同时对应4个客服团队支持,相互数据不打通,尤其自开通微信客服后,咨询量增长明显,由用户数据不打通带来的用户投诉增多。而且每年10—11月是教育行业的交费季,以前主要靠呼叫中心外呼,工作量巨大,效果不满意。学而思在2015年集成hg3399.com|官方网站移动客服以后,服务模式改为APP内缴费,并在APP内提供客服支持。整个2015年缴费季,APP客服部门数十人完美解决了往年数百个语音客服的工作。hg3399.com|官方网站CEO刘俊彦认为:“APP客服相比电话客服大幅度提供服务效率,全渠道客服也已经成为企业刚需。”

IVR进入触摸时代,自助服务的未来,智能机器人将大显神通

传统IVR,用户需要听完所有菜单再做选择。而现在主流的ITR导航,用户只需在手机上直接选择关注的问题,简单方便。其中神州租车就采购hg3399.com|官方网站移动客服,其中的智能ITR大大缓解了人工客服压力。Gartner预测到2020年,ITR将完全取代IVR全面进入触摸时代。

近期李世石1:4不敌AlphaGo的事件又将人工智能推上了风口浪尖。而hg3399.com|官方网站是客服行业少数自主开发智能应答机器人产品的公司,hg3399.com|官方网站知识库+智能聊天机器人可以帮助人工坐席挡住80%的常见问题。同时具有以下特性:1,灵活可定制的智能会话、自定义菜单导航功能。2,预置的行业知识库,行业相关的常见问答可以一键拥有。3,与现有知识库系统对接,机器学习,智能优化知识库。4,人机无缝配合,更少的成本,更好的客户体验?。

最后,hg3399.com|官方网站CEO预测:“随着国内SaaS客服产品的逐渐成熟完善,中小企业将全面拥抱SaaS客服,建设全媒体客户关系中心。而传统大型企业也将增量部署全媒体客服,保护已有投资,拥抱移动互联网。”SaaS客服也将逐渐成长为一个千亿级市场。

hg3399.com|官方网站移动客服简介

hg3399.com|官方网站移动客服是全球首创的全媒体智能云客服平台。支持全媒体接入,包括网页在线客服、社交媒体客服(微博、微信)、移动端客服和呼叫中心等多种渠道。hg3399.com|官方网站移动客服基于hg3399.com|官方网站业界领先的IM长连接技术保证消息必达,并通过强大的智能机器人技术极大降低人工客服工作量。

hg3399.com|官方网站移动客服于2014年12月上线,截至2015年底,hg3399.com|官方网站移动客服共服务了12000家企业用户,现已覆盖包括电商、O2O、互联网金融、在线教育、在线旅游、移动医疗、智能硬件、游戏等20大领域的Top10客户,典型用户包括国美在线、58到家、楚楚街、随手记、海尔、51talk,链家自如客等众多互联网和传统企业。根据易观国际发布的《中国SaaS客服市场专题研究报告2015》显示:截至2015年第三季度,hg3399.com|官方网站移动客服在SaaS移动端客服用户覆盖占比为77.4%,以绝对优势稳居行业第一。 查看全部

kefu.jpg

2016年4月8日,由江苏智恒发起的《企业通信与呼叫中心技术发展论坛》在江苏南京圆满落幕。hg3399.com|官方网站做为全媒体智能云客服倡领者受邀参加了本次行业盛会,hg3399.com|官方网站CEO刘俊彦在大会与现场的数百位行业精英一起分享了题为《全媒体智能客服时代的最佳实践》的主题演讲。

本次论坛活动旨在促进新兴通信技术在企业通信呼叫中心领域的推广、提高企业的通信能力、提高企业部署通信和客户服务平台时的策划水平。包括开源软交换技术,基于浏览器模式的实时通信技术,视频直播技术,呼叫中心领域中的智能化和多渠道客户体验技术。

2015年作为中国企业级服务元年,同时也是SaaS服务元年,尤其在客服领域诞生了一大批以产品技术驱动的SaaS公司,而以全媒体、智能化、移动化为主打的hg3399.com|官方网站移动客服更是其中的翘楚,不到一年时间内服务了1万多家企业,并且在融资额和市场份额上也遥遥领先。

从传统呼叫中心到全媒体客服,一场“效率”革命

随着人口红利消失,呼叫中心的升级转型将越来越普遍,2015年中国劳动力规模由2012年的9.37亿降至9.11亿人。中国劳动力人口连续4年绝对值下降企业客服面临的“用工荒”将持续扩大,运营成本将越来越高,越来越多的企业将复制hg3399.com|官方网站客户“学而思”的客服转型之路,从语音呼叫中心为主转而采用全媒体客服,拥抱移动互联网。

学而思以前部署有4套客服产品包括:1,呼叫中心。2,网页客服。3,新媒体客服。4,APP客服。同时对应4个客服团队支持,相互数据不打通,尤其自开通微信客服后,咨询量增长明显,由用户数据不打通带来的用户投诉增多。而且每年10—11月是教育行业的交费季,以前主要靠呼叫中心外呼,工作量巨大,效果不满意。学而思在2015年集成hg3399.com|官方网站移动客服以后,服务模式改为APP内缴费,并在APP内提供客服支持。整个2015年缴费季,APP客服部门数十人完美解决了往年数百个语音客服的工作。hg3399.com|官方网站CEO刘俊彦认为:“APP客服相比电话客服大幅度提供服务效率,全渠道客服也已经成为企业刚需。”

IVR进入触摸时代,自助服务的未来,智能机器人将大显神通

传统IVR,用户需要听完所有菜单再做选择。而现在主流的ITR导航,用户只需在手机上直接选择关注的问题,简单方便。其中神州租车就采购hg3399.com|官方网站移动客服,其中的智能ITR大大缓解了人工客服压力。Gartner预测到2020年,ITR将完全取代IVR全面进入触摸时代。

近期李世石1:4不敌AlphaGo的事件又将人工智能推上了风口浪尖。而hg3399.com|官方网站是客服行业少数自主开发智能应答机器人产品的公司,hg3399.com|官方网站知识库+智能聊天机器人可以帮助人工坐席挡住80%的常见问题。同时具有以下特性:1,灵活可定制的智能会话、自定义菜单导航功能。2,预置的行业知识库,行业相关的常见问答可以一键拥有。3,与现有知识库系统对接,机器学习,智能优化知识库。4,人机无缝配合,更少的成本,更好的客户体验?。

最后,hg3399.com|官方网站CEO预测:“随着国内SaaS客服产品的逐渐成熟完善,中小企业将全面拥抱SaaS客服,建设全媒体客户关系中心。而传统大型企业也将增量部署全媒体客服,保护已有投资,拥抱移动互联网。”SaaS客服也将逐渐成长为一个千亿级市场。

hg3399.com|官方网站移动客服简介

hg3399.com|官方网站移动客服是全球首创的全媒体智能云客服平台。支持全媒体接入,包括网页在线客服、社交媒体客服(微博、微信)、移动端客服和呼叫中心等多种渠道。hg3399.com|官方网站移动客服基于hg3399.com|官方网站业界领先的IM长连接技术保证消息必达,并通过强大的智能机器人技术极大降低人工客服工作量。

hg3399.com|官方网站移动客服于2014年12月上线,截至2015年底,hg3399.com|官方网站移动客服共服务了12000家企业用户,现已覆盖包括电商、O2O、互联网金融、在线教育、在线旅游、移动医疗、智能硬件、游戏等20大领域的Top10客户,典型用户包括国美在线、58到家、楚楚街、随手记、海尔、51talk,链家自如客等众多互联网和传统企业。根据易观国际发布的《中国SaaS客服市场专题研究报告2015》显示:截至2015年第三季度,hg3399.com|官方网站移动客服在SaaS移动端客服用户覆盖占比为77.4%,以绝对优势稳居行业第一。
0
评论

hg3399.com|官方网站视频直播在线技术支持下周正式上线

beyond 发表了文章 ? 1749 次浏览 ? 2016-04-11 17:28 ? 来自相关话题

为了给使用hg3399.com|官方网站产品的同学们提供更好的服务,自2016年3月31起,我们启动视频直播答疑(试运行)。
?
详情如下




在咨询问题的过程中,描述不清楚问题怎么办?
解决问题的过程中,工程师给出的解决方案自己看不懂怎么办?

hg3399.com|官方网站视频直播答疑已开启,面对面交流,工程师还通过分享桌面的形式演示,以后再也不用担心交流困难,看不懂解决方案了。
不知道小伙伴们去体验了没有?反正用过了都说好用哈!
?
这里要做一个公告:“视频直播技术支持暂停一周,下周正式上线!”
?
这周我们在做界面还有内容优化,保证下次上线时给各位开发者童鞋更好的体验!
?
当然如果小伙伴们上班过程中因为环境限制不能观看直播,也可以去原有的渠道联系hg3399.com|官方网站技术支持哈。
?
最后就是欢迎大家吐槽啦,对视频直播技术支持有任何问题建议欢迎评论留言,老规矩,直接现金打赏! 查看全部
为了给使用hg3399.com|官方网站产品的同学们提供更好的服务,自2016年3月31起,我们启动视频直播答疑(试运行)。
?
详情如下

45e86b6e3f8ae495578f847ff1f0676b.png

在咨询问题的过程中,描述不清楚问题怎么办?
解决问题的过程中,工程师给出的解决方案自己看不懂怎么办?

hg3399.com|官方网站视频直播答疑已开启,面对面交流,工程师还通过分享桌面的形式演示,以后再也不用担心交流困难,看不懂解决方案了。

不知道小伙伴们去体验了没有?反正用过了都说好用哈!
?
这里要做一个公告:“视频直播技术支持暂停一周,下周正式上线!
?
这周我们在做界面还有内容优化,保证下次上线时给各位开发者童鞋更好的体验!
?
当然如果小伙伴们上班过程中因为环境限制不能观看直播,也可以去原有的渠道联系hg3399.com|官方网站技术支持哈。
?
最后就是欢迎大家吐槽啦,对视频直播技术支持有任何问题建议欢迎评论留言,老规矩,直接现金打赏
0
评论

hg3399.com|官方网站荣获2015开发工具及服务年度最佳品牌影响力奖

beyond 发表了文章 ? 897 次浏览 ? 2016-04-11 14:30 ? 来自相关话题

2015开发工具及服务年度大奖评选结果已于近日正式出炉,由国内多位知名技术专家组成的专家评审团最终确认了 “最佳技术创新奖”、“最佳行业竞争力奖”、“最佳用户服务奖”、“最佳品牌影响力奖”、“最佳成长潜力奖”、“最佳影响力人物奖”六大奖项的50家获奖单位和5位获奖人员名单。

即将于2016年1月15日举办的【2015开发工具及服务年度大奖评选颁奖典礼】上,除各个获奖厂商前来领奖外,主办方还为所有获奖厂商制作珍藏版纪念奖杯,表彰其过去一年来的卓越成绩,以期鼓励开发工具及服务从业者在2016年继续耕耘,为行业贡献更全面细致的服务、更夯实稳健的工具。





随着开发工具及服务不断涌现,从云服务、即时通讯、安全到统计监测、人工智能、物联网平台等,越来越多的从业者提供了优质的服务,也有越来越多的开发者从中受益,综合提高了开发效率。2015开发工具及服务年度大奖评选是CSDN创立的针对开发工具及服务的评选大奖,目的在于推动开发服务及工具质量的提升,提高行业的专业性,表彰行业内的优秀的工具/服务提供商,从而激励整个行业的从业者,促进行业的发展。
?
最佳品牌影响力奖




【hg3399.com|官方网站】
入选理由:2015年,hg3399.com|官方网站进击移动客服领域,由PaaS到SaaS。旗下拥有两个产品,IM云和移动客服,一个是PaaS一个是SaaS,两个产品的技术跨度比较大,但基于自身PaaS的SaaS产品的优势也不言而喻,hg3399.com|官方网站未来会将移动客服推向两个方向:一是更智能,二是建立生态圈和平台。 查看全部
2015开发工具及服务年度大奖评选结果已于近日正式出炉,由国内多位知名技术专家组成的专家评审团最终确认了 “最佳技术创新奖”、“最佳行业竞争力奖”、“最佳用户服务奖”、“最佳品牌影响力奖”、“最佳成长潜力奖”、“最佳影响力人物奖”六大奖项的50家获奖单位和5位获奖人员名单。

即将于2016年1月15日举办的【2015开发工具及服务年度大奖评选颁奖典礼】上,除各个获奖厂商前来领奖外,主办方还为所有获奖厂商制作珍藏版纪念奖杯,表彰其过去一年来的卓越成绩,以期鼓励开发工具及服务从业者在2016年继续耕耘,为行业贡献更全面细致的服务、更夯实稳健的工具。

568f2a2311866.jpg

随着开发工具及服务不断涌现,从云服务、即时通讯、安全到统计监测、人工智能、物联网平台等,越来越多的从业者提供了优质的服务,也有越来越多的开发者从中受益,综合提高了开发效率。2015开发工具及服务年度大奖评选是CSDN创立的针对开发工具及服务的评选大奖,目的在于推动开发服务及工具质量的提升,提高行业的专业性,表彰行业内的优秀的工具/服务提供商,从而激励整个行业的从业者,促进行业的发展。
?
最佳品牌影响力奖

568f474640dec.png

【hg3399.com|官方网站】


入选理由:
2015年,hg3399.com|官方网站进击移动客服领域,由PaaS到SaaS。旗下拥有两个产品,IM云和移动客服,一个是PaaS一个是SaaS,两个产品的技术跨度比较大,但基于自身PaaS的SaaS产品的优势也不言而喻,hg3399.com|官方网站未来会将移动客服推向两个方向:一是更智能,二是建立生态圈和平台。
0
评论

hg3399.com|官方网站首席架构师:一个单元化架构的例子

beyond 发表了文章 ? 1804 次浏览 ? 2016-04-11 14:14 ? 来自相关话题

微博粉丝服务平台在单元化架构方面的实践已经在QCon讲过,这次重又写起文章,我想传播知识已经不那么重要(单元化架构不是创新,稍后会详细介绍),更重要的是还是希望能够借此引起诸位的思考,能够在架构层面多投入精力思考和尝试。
?
为什么要有架构实践?

很多人喜欢的是细节,因为有句名言叫魔鬼在细节里,于是都去细节里寻找魔鬼。但是打败了魔鬼就能看到天使么?未必。细节其实是最容易掌握的部分,细节之外还有很多。就像有了水泥和沙子,你能够做出混凝土,但是离建成高楼大厦还有很长的路要走一样,你要学着去设计架构。

但是事情并没有完,就像没有唯一的真理一样,架构也并不是只有一种。你不可能一朝学会,从此天下无敌。如果要赈灾,你需要的是帐篷,如果要重建,你需要的是瓦房。不同的住所需要的是不同的架构。
?
不同的服务也需要不同的架构设计,这也就是我们需要架构实践的重要原因。在这之后的原因,是我们做任何服务,都要考虑服务的性能和成本。

但优化有很多方式,为什么是架构呢?诚然,从硬件到操作系统,从共享库到应用软件,从算法到架构,每一层都可以优化,但每一层所做的工作量和收益也都是不同的。架构可能是需要投入最多精力的,但在很多时候却也是很少的可以提供超过数量级的提升方式。

所以,思维方式的转变才是你最应该在意的部分,单元化只是一个例子,而粉丝服务平台只是这个例子的例子,而已。

言归正传,接下来本文将从三个问题来介绍这次实践,单元化是什么,为什么要用以及我们如何做到的。

?
1. 单元化是什么

单元化架构是从并行计算领域发展而来。在分布式服务设计领域,一个单元(Cell)就是满足某个分区所有业务操作的自包含的安装。而一个分区(Shard),则是整体数据集的一个子集,如果你用尾号来划分用户,那同样尾号的那部分用户就可以认为是一个分区。单元化就是将一个服务设计改造让其符合单元特征的过程。




图 1 :洋葱细胞的显微镜截图,单元化要达到的目的就是让每个单元像细胞一样独立工作
在传统的服务化架构下(如下图),服务是分层的,每一层使用不同的分区算法,每一层都有不同数量的节点,上层节点随机选择下层节点。当然这个随机是比较而言的。




图 2 :传统的服务化架构,为伸缩性设计,上层节点随机选择下层节点
与其不同的是,在单元化架构下,服务虽然分层划分,但每个单元自成一体。按照层次来讲的话,所有层使用相同的分区算法,每一层都有相同数量的节点,上层节点也会访问指定的下层节点。因为他们已经在一起。




图 3 :单元化架构,为性能和隔离性而设计,上层节点访问指定下层节点
?
?2. 为什么要用单元化

在性能追求和成本限制的情况下,我们需要找到一种合适的方法来满足服务需求。在传统的分布式服务设计,我们考虑的更多是每个服务的可伸缩性,当各个服务独立设计时你就要在每一层进行伸缩性的考虑。这是服务化设计(SOA)流行的原因,我们需要每个服务能够单独水平扩展。
但是在摩尔定律下,随着硬件的不断升级,计算机硬件能力已经越来越强,CPU越来越快,内存越来越大,网络越来越宽。这让我们看到了在单台机器上垂直扩展的机会。尤其是当你遇到一个性能要求和容量增长可以预期的业务,单元化给我们提供另外的机会,让我们可以有效降低资源的使用,提供更高性能的服务。

总体而言,更高性能更低成本是我们的主要目标,而经过单元化改造,我们得以用更少(约二分之一)的机器,获得了比原来更高(接近百倍)的性能。性能的提升很大部分原因在于服务的本地化,而服务的集成部署又进一步降低了资源的使用。

当然除了性能收益,如果你做到了,你会发现还有很多收益,比如更好的隔离性,包括请求隔离和资源隔离,比如更友好的升级,产品可以灰度发布等。单元化改造后对高峰的应对以及扩容方式等问题,各位可以参考#微博春节技术保障系列#中的单元化架构文章,也不在此一一赘述。


3. 我们如何做到

此次单元化改造基于微博现有的业务,因此这里也先行介绍一下。粉丝服务平台是微博的内容推送系统(代号Castalia),可为V用户提供向其粉丝推送高质量内容的高速通道(单元化之后已到达百万条每秒)。整个服务涉及用户筛选、发送计费、屏蔽检查、限流控制和消息群发等多个子服务。由于改造思想相通,这里以用户筛选和消息群发两个服务为例,下面两图分别为商业群发在服务化思想和单元化思想下不同的架构。




图 4: 服务化思想下的商业群发架构设计(旧版)




图 5 :商业群发在单元化思想下的架构设计(新版)
对于筛选服务,在服务化架构里,需要去粉丝服务获取粉丝关系,然后去特征服务进行用户特征筛选,最后将筛选结果传输到群发服务器上;而在单元化架构里,粉丝关系直接就在本地文件中,用户特征服务也在本地,最后的筛选结果再不需要传输。服务本地化(粉丝关系和用户特征存储)减去了网络开销,降低了服务延时,还同时提高了访问速度和稳定性,而筛选结果本地存储又进一步节省了带宽并降低了延迟。以百万粉丝为例,每次网络操作的减少节省带宽8M左右,延时也从400ms降为0。

群发服务同样如此。由于在服务化架构里,我们使用MySQL和Memcache的方案,由于关系数据库的写入性能问题,中间还有队列以及相应的队列处理机,所有四个模块都有单独的机器提供服务,而在单元化架构里,四合一之后,只需要一套机器。当然机器的配置可能会有所提升,但真正计算之后你就会发现其实影响微乎其微。原因除了前面介绍的硬件增长空间外,上架机器的基本配置变高也是一个原因。而且,在单元化方案里,当我们把缓存部署在本地之后,其性能还有了额外的20%提升。


一些业务特有问题

不过群发这个场景,我们也遇到了一些特定的问题,一是分区问题,一是作业管理。这里也与各位分享下我们的解决方法。

分区问题分区问题其实是每个服务都会遇到的,但单元化后的挑战在于让所有服务都适配同一分区算法,在我们的场景下,我们按照接收者进行了分区,即从底层往上,每一层都来适配此分区算法。这里有特例的是用户特征和屏蔽服务,由于总体容量都很小,我们就没有对数据进行分区,所有单元内都是同一套全量数据,都是一个外部全量库的从库。不过由于本单元内的上层服务的关系,只有属于本分区的用户数据被访问到。所以,适配同一分区算法在某种程度上讲,可以兼容即可。

作业管理按照前面的分区方式,将群发服务的整体架构变成了一个类似Scatter-Gather+CQRS的方案,因为Gather不是一个请求处理的必须要素。也就是说,一个群发请求会被扩散到所有单元中,每个单元都要针对自己分区内的用户处理这个群发请求。广播方式的引入,使得我们首先需要在前端机进行分单元作业的处理监控,我们在此增加了持久化队列来解决。同时,由于单元内每个服务也都是单独维护的,作业可能在任何时间中断,因此每个作业在单元内的状态也都是有记录的,以此来达到作业的可重入和幂等性,也就可以保证每个作业都可以在任何时间重做,但不会重复执行。

除此之外,我们还对服务器进行了更为精细的控制,使用CPU绑定提高多服务集成部署时的整体效率,使用多硬盘设计保证每个服务的IO性能,通过主从单元的读写分离来提高整体服务等等。

后记

我平时不善文章,现在要成文发表,还是有一点紧张的。不过想到或许可以抛砖引玉,有机会向各位大牛学习,或者跟各位同学一起交流,内心又有些许期待。关于微博或者其他任何网站的设计,欢迎大家一起探讨,随时在微博恭候。





? 查看全部
微博粉丝服务平台在单元化架构方面的实践已经在QCon讲过,这次重又写起文章,我想传播知识已经不那么重要(单元化架构不是创新,稍后会详细介绍),更重要的是还是希望能够借此引起诸位的思考,能够在架构层面多投入精力思考和尝试。
?
为什么要有架构实践?

很多人喜欢的是细节,因为有句名言叫魔鬼在细节里,于是都去细节里寻找魔鬼。但是打败了魔鬼就能看到天使么?未必。细节其实是最容易掌握的部分,细节之外还有很多。就像有了水泥和沙子,你能够做出混凝土,但是离建成高楼大厦还有很长的路要走一样,你要学着去设计架构。

但是事情并没有完,就像没有唯一的真理一样,架构也并不是只有一种。你不可能一朝学会,从此天下无敌。如果要赈灾,你需要的是帐篷,如果要重建,你需要的是瓦房。不同的住所需要的是不同的架构。
?
不同的服务也需要不同的架构设计,这也就是我们需要架构实践的重要原因。在这之后的原因,是我们做任何服务,都要考虑服务的性能和成本。

但优化有很多方式,为什么是架构呢?诚然,从硬件到操作系统,从共享库到应用软件,从算法到架构,每一层都可以优化,但每一层所做的工作量和收益也都是不同的。架构可能是需要投入最多精力的,但在很多时候却也是很少的可以提供超过数量级的提升方式。

所以,思维方式的转变才是你最应该在意的部分,单元化只是一个例子,而粉丝服务平台只是这个例子的例子,而已。

言归正传,接下来本文将从三个问题来介绍这次实践,单元化是什么,为什么要用以及我们如何做到的。

?
1. 单元化是什么

单元化架构是从并行计算领域发展而来。在分布式服务设计领域,一个单元(Cell)就是满足某个分区所有业务操作的自包含的安装。而一个分区(Shard),则是整体数据集的一个子集,如果你用尾号来划分用户,那同样尾号的那部分用户就可以认为是一个分区。单元化就是将一个服务设计改造让其符合单元特征的过程。

640.webp_.jpg

图 1 :洋葱细胞的显微镜截图,单元化要达到的目的就是让每个单元像细胞一样独立工作

在传统的服务化架构下(如下图),服务是分层的,每一层使用不同的分区算法,每一层都有不同数量的节点,上层节点随机选择下层节点。当然这个随机是比较而言的。

640.webp_(1)_.jpg

图 2 :传统的服务化架构,为伸缩性设计,上层节点随机选择下层节点

与其不同的是,在单元化架构下,服务虽然分层划分,但每个单元自成一体。按照层次来讲的话,所有层使用相同的分区算法,每一层都有相同数量的节点,上层节点也会访问指定的下层节点。因为他们已经在一起。

640.jpg

图 3 :单元化架构,为性能和隔离性而设计,上层节点访问指定下层节点

?
?2. 为什么要用单元化

在性能追求和成本限制的情况下,我们需要找到一种合适的方法来满足服务需求。在传统的分布式服务设计,我们考虑的更多是每个服务的可伸缩性,当各个服务独立设计时你就要在每一层进行伸缩性的考虑。这是服务化设计(SOA)流行的原因,我们需要每个服务能够单独水平扩展。
但是在摩尔定律下,随着硬件的不断升级,计算机硬件能力已经越来越强,CPU越来越快,内存越来越大,网络越来越宽。这让我们看到了在单台机器上垂直扩展的机会。尤其是当你遇到一个性能要求和容量增长可以预期的业务,单元化给我们提供另外的机会,让我们可以有效降低资源的使用,提供更高性能的服务。

总体而言,更高性能更低成本是我们的主要目标,而经过单元化改造,我们得以用更少(约二分之一)的机器,获得了比原来更高(接近百倍)的性能。性能的提升很大部分原因在于服务的本地化,而服务的集成部署又进一步降低了资源的使用。

当然除了性能收益,如果你做到了,你会发现还有很多收益,比如更好的隔离性,包括请求隔离和资源隔离,比如更友好的升级,产品可以灰度发布等。单元化改造后对高峰的应对以及扩容方式等问题,各位可以参考#微博春节技术保障系列#中的单元化架构文章,也不在此一一赘述。


3. 我们如何做到

此次单元化改造基于微博现有的业务,因此这里也先行介绍一下。粉丝服务平台是微博的内容推送系统(代号Castalia),可为V用户提供向其粉丝推送高质量内容的高速通道(单元化之后已到达百万条每秒)。整个服务涉及用户筛选、发送计费、屏蔽检查、限流控制和消息群发等多个子服务。由于改造思想相通,这里以用户筛选和消息群发两个服务为例,下面两图分别为商业群发在服务化思想和单元化思想下不同的架构。

640.webp_(2)_.jpg

图 4: 服务化思想下的商业群发架构设计(旧版)
640.webp_(3)_.jpg

图 5 :商业群发在单元化思想下的架构设计(新版)

对于筛选服务,在服务化架构里,需要去粉丝服务获取粉丝关系,然后去特征服务进行用户特征筛选,最后将筛选结果传输到群发服务器上;而在单元化架构里,粉丝关系直接就在本地文件中,用户特征服务也在本地,最后的筛选结果再不需要传输。服务本地化(粉丝关系和用户特征存储)减去了网络开销,降低了服务延时,还同时提高了访问速度和稳定性,而筛选结果本地存储又进一步节省了带宽并降低了延迟。以百万粉丝为例,每次网络操作的减少节省带宽8M左右,延时也从400ms降为0。

群发服务同样如此。由于在服务化架构里,我们使用MySQL和Memcache的方案,由于关系数据库的写入性能问题,中间还有队列以及相应的队列处理机,所有四个模块都有单独的机器提供服务,而在单元化架构里,四合一之后,只需要一套机器。当然机器的配置可能会有所提升,但真正计算之后你就会发现其实影响微乎其微。原因除了前面介绍的硬件增长空间外,上架机器的基本配置变高也是一个原因。而且,在单元化方案里,当我们把缓存部署在本地之后,其性能还有了额外的20%提升。


一些业务特有问题

不过群发这个场景,我们也遇到了一些特定的问题,一是分区问题,一是作业管理。这里也与各位分享下我们的解决方法。

分区问题分区问题其实是每个服务都会遇到的,但单元化后的挑战在于让所有服务都适配同一分区算法,在我们的场景下,我们按照接收者进行了分区,即从底层往上,每一层都来适配此分区算法。这里有特例的是用户特征和屏蔽服务,由于总体容量都很小,我们就没有对数据进行分区,所有单元内都是同一套全量数据,都是一个外部全量库的从库。不过由于本单元内的上层服务的关系,只有属于本分区的用户数据被访问到。所以,适配同一分区算法在某种程度上讲,可以兼容即可。

作业管理按照前面的分区方式,将群发服务的整体架构变成了一个类似Scatter-Gather+CQRS的方案,因为Gather不是一个请求处理的必须要素。也就是说,一个群发请求会被扩散到所有单元中,每个单元都要针对自己分区内的用户处理这个群发请求。广播方式的引入,使得我们首先需要在前端机进行分单元作业的处理监控,我们在此增加了持久化队列来解决。同时,由于单元内每个服务也都是单独维护的,作业可能在任何时间中断,因此每个作业在单元内的状态也都是有记录的,以此来达到作业的可重入和幂等性,也就可以保证每个作业都可以在任何时间重做,但不会重复执行。

除此之外,我们还对服务器进行了更为精细的控制,使用CPU绑定提高多服务集成部署时的整体效率,使用多硬盘设计保证每个服务的IO性能,通过主从单元的读写分离来提高整体服务等等。

后记

我平时不善文章,现在要成文发表,还是有一点紧张的。不过想到或许可以抛砖引玉,有机会向各位大牛学习,或者跟各位同学一起交流,内心又有些许期待。关于微博或者其他任何网站的设计,欢迎大家一起探讨,随时在微博恭候。

640.webp_(4)_.jpg

?
0
回复

各位大神,求一个Android3.0以上的单聊的demo,18713341988@163.com,完事有大红包相送 求单聊Demo

回复

James240141392 发起了问题 ? 1 人关注 ? 1637 次浏览 ? 2016-04-10 11:01 ? 来自相关话题

0
评论

Android Studio 2.0 导入hg3399.com|官方网站Demo3.10 问题

beyond 发表了文章 ? 3847 次浏览 ? 2016-04-08 10:43 ? 来自相关话题

第一步解压后的SDK文件夹?




在这里主要介绍后面四个文件夹内容:doc文件夹:SDK相关API文档
examples文件夹:ChatDemoUI(为开发者能够更深入理解SDK而提供的一个demo)
libs文件夹:拥有实时语音,实时视频功能的SDK(大小在1.34M左右)包和.so文件
libs.without.audio文件夹:无实时语音,实时视频功能的SDK包(大小在900多K)
tools官网没给解释(未知)第二步我们要导入的是examples文件夹里的内容?




接下来删除两个文件夹下的build.gradle?




第三步导入项目 我是在打开项目的基础上又重新打开一个界面,导入方式就不多说了?




导入后项目的运行可能是灰色的 我们通过进入Project Structure来先删除mod,在次导入mod 导入时选择easeUIDemo?




第四步导入jar和io文件

在自行开发的应用中,集成hg3399.com|官方网站聊天需要把libs文件夹下的easemobchat_2.1.6.jar和armeabi目录导入到你的项目的libs文件夹底下,如果不需要语音和视频通话功能,导入libs.without.audio下的jar文件即可。(这是hg3399.com|官方网站文档)由于我是集成即时通讯,真实文件是下面这两个,复制粘贴到libs文件夹下?









报错:

Error:Execution failed for task ‘:easeUIDemo:compileDebugNdk’.Error: NDK integration is deprecated in the current plugin. Consider trying the new experimental plugin. For details, see http://tools.android.com/tech- ... ntal. Set “android.useDeprecatedNdk=true” in gradle.properties to continue using the current NDK integration.解决方法 项目build.gradle下图对应位置加入如下代码 ( 可复制粘贴)sourceSets.main {
jni.srcDirs =
}




然后就可以了,自己遇到的问题,希望能帮到面临这些问题的人
?
本篇Android studio集成由hg3399.com|官方网站热心开发者提供,博客请点击Crazy丶code 查看全部
第一步解压后的SDK文件夹?

20160307175502011.png

在这里主要介绍后面四个文件夹内容:
doc文件夹:SDK相关API文档
examples文件夹:ChatDemoUI(为开发者能够更深入理解SDK而提供的一个demo)
libs文件夹:拥有实时语音,实时视频功能的SDK(大小在1.34M左右)包和.so文件
libs.without.audio文件夹:无实时语音,实时视频功能的SDK包(大小在900多K)
tools官网没给解释(未知)
第二步我们要导入的是examples文件夹里的内容?

20160307175539636.png

接下来删除两个文件夹下的build.gradle?

20160307175617371.png

第三步导入项目 我是在打开项目的基础上又重新打开一个界面,导入方式就不多说了?

20160307175704872.png

导入后项目的运行可能是灰色的 我们通过进入Project Structure来先删除mod,在次导入mod 导入时选择easeUIDemo?

20160307175803123.png

第四步导入jar和io文件

在自行开发的应用中,集成hg3399.com|官方网站聊天需要把libs文件夹下的easemobchat_2.1.6.jar和armeabi目录导入到你的项目的libs文件夹底下,如果不需要语音和视频通话功能,导入libs.without.audio下的jar文件即可。(这是hg3399.com|官方网站文档)由于我是集成即时通讯,真实文件是下面这两个,复制粘贴到libs文件夹下?

20160307175903453.png


20160307180006013.png

报错:

Error:Execution failed for task ‘:easeUIDemo:compileDebugNdk’.
Error: NDK integration is deprecated in the current plugin. Consider trying the new experimental plugin. For details, see http://tools.android.com/tech- ... ntal. Set “android.useDeprecatedNdk=true” in gradle.properties to continue using the current NDK integration.
解决方法 项目build.gradle下图对应位置加入如下代码 ( 可复制粘贴)
sourceSets.main { 
jni.srcDirs =
}

20160307180056545.png

然后就可以了,自己遇到的问题,希望能帮到面临这些问题的人
?
本篇Android studio集成由hg3399.com|官方网站热心开发者提供,博客请点击Crazy丶code
0
评论

hg3399.com|官方网站直播课堂第六期--2.x和3.x的单聊的集成

beyond 发表了文章 ? 1465 次浏览 ? 2016-04-06 12:14 ? 来自相关话题

日期与时间:2016年4月7日15:00
http://www.imgeek.org/video/23
持续时间:半小时

描述:集成hg3399.com|官方网站2.x?3.x?sdk怎么选?怎么用最简便的方法集成聊天功能?

本期hg3399.com|官方网站直播课堂将由hg3399.com|官方网站ios工程师shenc给大家带来ios 2.x和3.x集成介绍,并详细讲解头像昵称的实现,大家有其他问题也可以直接提问哦!?
?
PS:这是一份史上最全的hg3399.com|官方网站iOS?2.x?and?3.x?SDK单聊的集成方案!

直播观看地址: http://www.imgeek.org/video/15
?
视频回放地址:http://www.imgeek.org/video/23 查看全部
日期与时间:2016年4月7日15:00
http://www.imgeek.org/video/23
持续时间:半小时

描述:集成hg3399.com|官方网站2.x?3.x?sdk怎么选?怎么用最简便的方法集成聊天功能?

本期hg3399.com|官方网站直播课堂将由hg3399.com|官方网站ios工程师shenc给大家带来ios 2.x和3.x集成介绍,并详细讲解头像昵称的实现,大家有其他问题也可以直接提问哦!?
?
PS:这是一份史上最全的hg3399.com|官方网站iOS?2.x?and?3.x?SDK单聊的集成方案!

直播观看地址: http://www.imgeek.org/video/15
?
视频回放地址:http://www.imgeek.org/video/23
0
评论

“App增长加速度”主题分享会:听hg3399.com|官方网站解读”APP如何提升造血能力“

beyond 发表了文章 ? 1330 次浏览 ? 2016-04-05 16:27 ? 来自相关话题

一、 活动介绍

? ? ? ? ?随着移动互联网的发展,加上政府的鼓励和扶持,一股轰轰烈烈的全民创业大浪潮正席卷全国。然而,万众创新下的创业者们却面临着流量被垄断和马太效应等重重创业关卡。

? ? ? ? 2016年,如何突围缺钱、缺人、缺流量关卡,加速App内增长,提升企业业务竞争力及商业价值?或许可以用共享经济法则和移动应用新技术mLink切入万亿级App市场,或许可以借力大数据揭秘资本寒冬下的增长之道,又或许可以试试用户人群精细化运营的正确姿势……本期“App增长加速度”主题分享会邀您一起发现改变力!

【时间】2016年4月9日下午13:00—17:00

【地点】成都高新区软件园A9 3楼(十分咖啡·投资家)

【人数】300人

【人群】欢迎移动端App创业者、研发人员、架构师、产品经理报名参加!

二、活动福利

?尝鲜硅谷最新创业创新理念及实操干货经验

?和来自北京上海增长最快的技术创业团队面对面探讨创业经

?免费获得魔窗价值30000元/月的VIP账号

?免费获得GrowingIO企业版代金券4000元

?免费获得猿团周边礼品包1份
?
三、活动流程

13:00-13:15 ?签到、交换名片

13:15-13:30 ?主持人:初笋科技创始人冷治福

13:30-14:00 ?魔窗创始人兼CEO 姜孟君:《如何用共享经济法则切入万亿级App市场》

14:00-14:30 ?GrowingIO创始人、CEO 张溪梦:《数据驱动增长——GrowingIO》

14:30-15:00 ?Testin西南区技术总监李小川:《APP全生命周期质量》

15:00-15:30 ?hg3399.com|官方网站高级产品市场经理谢韩:《资本寒冬,APP如何提升造血能力》

15:30-16:00 ?猿团科技创始人&CEO谢恩明:《App+》

16:00-16:10 ?休息

16:10-16:40 ?圆桌会议:现场提问+嘉宾答疑

16:40- ? ? ? 自由交流


四、分享嘉宾&主题
1、分享嘉宾:魔窗创始人兼CEO姜孟君




?企业级和互联网解决方案双料专家,多年大数据资深从业者,O2O经验咨询平台“在行”资深行家。从业15年+,拥有大型企业级SAAS解决方案及多年营销大数据经验,擅长软件云化与服务化、大数据处理与应用、社会化倾听、电子商务、互联网精准营销相关及团队建设等方面。曾在一年半内从零组建一支30多人规模的互联网创业团队,并交付4个明星级别产品,单一产品线第一年收入超过500万。

?曾担任惠普中国、惠普美国数据管理平台和新一代数据中心核心负责人;SAP首席工程师,SAP云加速特别行动小组首位中国区代表;AdMaster研发副总裁及上海研发中心总经理。

?两年前加入互联网创业浪潮,开创App Growth Engine——魔窗(MagicWindow),为App提供变革式的面向服务的开发方式,1天让APP变本地开放平台,提升App用户体验及转化率,让每一个App都可以轻松情景式相连,让创业更加轻松愉悦!

分享主题:《如何用共享经济法则切入万亿级App市场》
?探讨共享经济理念在APP创业者当中能否成立
?阻断App创业者协同创业最大的瓶颈是什么
?如何打破资源和流量的马太效应完成有机增长
?2016移动端应用的变革——mLink

2、分享嘉宾:GrowingIO创始人、CEO张溪梦




?GrowingIO创始人、CEO。前LinkedIn美国商业分析部高级总监,美国Data Science Central评选其为“世界前十位前沿数据科学家”,亲手建立了LinkedIn将近90人百人商业数据分析和数据科学团队,支撑了LinkedIn公司所有与营收相关业务的高速增长。2015年5月,从硅谷创办基于用户行为的新一代数据分析产品GrowingIO,提供全球领先的数据采集和分析技术。企业无需在网站或app中埋点,即可获取并分析全面、实时的用户行为数据,以优化产品体验,实现精益化运营,用数据驱动用户和营收的增长。2015年12月,荣获DOIT评选的2015中国十大数据英雄,由他创办GrowingIO并获得《快公司》评选的2015年中国最佳创新公司50。
分享主题:《数据驱动增长——GrowingIO》

?来自硅谷增长黑客秘密
?海盗法则 Pirates AARRR
?增长黑客实现方法
?如何衡量?建立合理的KPI体系
?GrowingIO案例分享

3、分享嘉宾:Testin西南区技术总监李小川




? 八年互联网产品测试及质量管理经验,曾任北京邮电大学信息安全中心研究员、华为测试经理、北京云蜘蛛科技副总,曾担任过6个运营商级项目的测试经理,对于产品质量控制和自动化测试有丰富的经验。


分享主题:《APP全生命周期质量》

?互联网的根本是用户,APP产品如何留住用户?红利、互联网推广还是好的用户体验?根据Testin数据分析,随着移动互联网人口红利的逐步消失,新用户的比例在逐步减少,相反,老用户的比例攀升。这一变化预示着用户对于应用的选择将越来越苛刻,部分用户体验较差、运营不佳的应用将被迅速淘汰。因此,如何做好APP质量,提升用户体验是重点。
?如何做好APP产品质量,Testin分享APP质量之APP全生命周期测试:功能、兼容、性能、体验、压力、安全。

4、分享嘉宾:hg3399.com|官方网站高级产品市场经理谢韩




?IT行业跨领域市场研究者,先后从事网络、安全、互联网领域的市场研究与分析工作,对商业技术趋势有较深理解。
分享主题:《资本寒冬,APP如何提升造血能力》
?随着外部资金渠道的趋紧,依靠APP自身实现内源性增长成为必然的选择,这就需要App能够自我造血,具备吸引用户和转化用户的能力。在这个过程中,连接人与人的IM技术,连接人与商业的移动客服,是帮助App建立社区,实现商业变现过程中的有力助手。在此基础上,基于连接属性所进行的人群和内容大数据分析,也能够推动App实现精准化营销和精细化运营。

5、分享嘉宾:猿团科技创始人&CEO谢恩明




80后青年创业者,十年连锁企业负责人。08年加入互联网行业,曾任职于金山、腾讯,具备丰富的客户服务、企业培训、企业管理等经验。之后创立猿团科技,担任CEO,猿团科技在他的带领下,半年时间从估值两千万到两个亿,随后创立猿团投资公司,猿团传媒公司,目前已经帮助40+个项目进行创业。
分享主题:《App+》
?
报名请点击阅读原文
?
? 查看全部
一、 活动介绍

? ? ? ? ?随着移动互联网的发展,加上政府的鼓励和扶持,一股轰轰烈烈的全民创业大浪潮正席卷全国。然而,万众创新下的创业者们却面临着流量被垄断和马太效应等重重创业关卡。

? ? ? ? 2016年,如何突围缺钱、缺人、缺流量关卡,加速App内增长,提升企业业务竞争力及商业价值?或许可以用共享经济法则和移动应用新技术mLink切入万亿级App市场,或许可以借力大数据揭秘资本寒冬下的增长之道,又或许可以试试用户人群精细化运营的正确姿势……本期“App增长加速度”主题分享会邀您一起发现改变力!

【时间】2016年4月9日下午13:00—17:00

【地点】成都高新区软件园A9 3楼(十分咖啡·投资家)

【人数】300人

【人群】欢迎移动端App创业者、研发人员、架构师、产品经理报名参加!

二、活动福利

?尝鲜硅谷最新创业创新理念及实操干货经验

?和来自北京上海增长最快的技术创业团队面对面探讨创业经

?免费获得魔窗价值30000元/月的VIP账号

?免费获得GrowingIO企业版代金券4000元

?免费获得猿团周边礼品包1份
?
三、活动流程

13:00-13:15 ?签到、交换名片

13:15-13:30 ?主持人:初笋科技创始人冷治福

13:30-14:00 ?魔窗创始人兼CEO 姜孟君:《如何用共享经济法则切入万亿级App市场》

14:00-14:30 ?GrowingIO创始人、CEO 张溪梦:《数据驱动增长——GrowingIO》

14:30-15:00 ?Testin西南区技术总监李小川:《APP全生命周期质量》

15:00-15:30 ?hg3399.com|官方网站高级产品市场经理谢韩:《资本寒冬,APP如何提升造血能力》

15:30-16:00 ?猿团科技创始人&CEO谢恩明:《App+》

16:00-16:10 ?休息

16:10-16:40 ?圆桌会议:现场提问+嘉宾答疑

16:40- ? ? ? 自由交流


四、分享嘉宾&主题
1、分享嘉宾:魔窗创始人兼CEO姜孟君

30342286476709304.jpg

?企业级和互联网解决方案双料专家,多年大数据资深从业者,O2O经验咨询平台“在行”资深行家。从业15年+,拥有大型企业级SAAS解决方案及多年营销大数据经验,擅长软件云化与服务化、大数据处理与应用、社会化倾听、电子商务、互联网精准营销相关及团队建设等方面。曾在一年半内从零组建一支30多人规模的互联网创业团队,并交付4个明星级别产品,单一产品线第一年收入超过500万。

?曾担任惠普中国、惠普美国数据管理平台和新一代数据中心核心负责人;SAP首席工程师,SAP云加速特别行动小组首位中国区代表;AdMaster研发副总裁及上海研发中心总经理。

?两年前加入互联网创业浪潮,开创App Growth Engine——魔窗(MagicWindow),为App提供变革式的面向服务的开发方式,1天让APP变本地开放平台,提升App用户体验及转化率,让每一个App都可以轻松情景式相连,让创业更加轻松愉悦!

分享主题:《如何用共享经济法则切入万亿级App市场》
?探讨共享经济理念在APP创业者当中能否成立
?阻断App创业者协同创业最大的瓶颈是什么
?如何打破资源和流量的马太效应完成有机增长
?2016移动端应用的变革——mLink

2、分享嘉宾:GrowingIO创始人、CEO张溪梦

30372286477679388.jpg

?GrowingIO创始人、CEO。前LinkedIn美国商业分析部高级总监,美国Data Science Central评选其为“世界前十位前沿数据科学家”,亲手建立了LinkedIn将近90人百人商业数据分析和数据科学团队,支撑了LinkedIn公司所有与营收相关业务的高速增长。2015年5月,从硅谷创办基于用户行为的新一代数据分析产品GrowingIO,提供全球领先的数据采集和分析技术。企业无需在网站或app中埋点,即可获取并分析全面、实时的用户行为数据,以优化产品体验,实现精益化运营,用数据驱动用户和营收的增长。2015年12月,荣获DOIT评选的2015中国十大数据英雄,由他创办GrowingIO并获得《快公司》评选的2015年中国最佳创新公司50。
分享主题:《数据驱动增长——GrowingIO》

?来自硅谷增长黑客秘密
?海盗法则 Pirates AARRR
?增长黑客实现方法
?如何衡量?建立合理的KPI体系
?GrowingIO案例分享

3、分享嘉宾:Testin西南区技术总监李小川

30332286478139420.jpg

? 八年互联网产品测试及质量管理经验,曾任北京邮电大学信息安全中心研究员、华为测试经理、北京云蜘蛛科技副总,曾担任过6个运营商级项目的测试经理,对于产品质量控制和自动化测试有丰富的经验。


分享主题:《APP全生命周期质量》

?互联网的根本是用户,APP产品如何留住用户?红利、互联网推广还是好的用户体验?根据Testin数据分析,随着移动互联网人口红利的逐步消失,新用户的比例在逐步减少,相反,老用户的比例攀升。这一变化预示着用户对于应用的选择将越来越苛刻,部分用户体验较差、运营不佳的应用将被迅速淘汰。因此,如何做好APP质量,提升用户体验是重点。
?如何做好APP产品质量,Testin分享APP质量之APP全生命周期测试:功能、兼容、性能、体验、压力、安全。

4、分享嘉宾:hg3399.com|官方网站高级产品市场经理谢韩

30262286478949487.jpg

?IT行业跨领域市场研究者,先后从事网络、安全、互联网领域的市场研究与分析工作,对商业技术趋势有较深理解。
分享主题:《资本寒冬,APP如何提升造血能力》
?随着外部资金渠道的趋紧,依靠APP自身实现内源性增长成为必然的选择,这就需要App能够自我造血,具备吸引用户和转化用户的能力。在这个过程中,连接人与人的IM技术,连接人与商业的移动客服,是帮助App建立社区,实现商业变现过程中的有力助手。在此基础上,基于连接属性所进行的人群和内容大数据分析,也能够推动App实现精准化营销和精细化运营。

5、分享嘉宾:猿团科技创始人&CEO谢恩明

30122286479889547.jpg

80后青年创业者,十年连锁企业负责人。08年加入互联网行业,曾任职于金山、腾讯,具备丰富的客户服务、企业培训、企业管理等经验。之后创立猿团科技,担任CEO,猿团科技在他的带领下,半年时间从估值两千万到两个亿,随后创立猿团投资公司,猿团传媒公司,目前已经帮助40+个项目进行创业。
分享主题:《App+》
?
报名请点击阅读原文
?
?
0
评论

【活动报名】HTML5 app轻架构高性能开发交流会,4月9日北京 行业活动

beyond 发表了文章 ? 1394 次浏览 ? 2016-04-05 11:56 ? 来自相关话题

?H5 app已成趋势!


? ? ? ?如果认为这是危言耸听,那么你危险了。在W3C宣布html5正式定稿一年半以来,h5技术带来的产业变革已经不再停留在“干打雷”,而是掀起了“疾风骤雨”:

? ? ? ?Adobe支持用户放弃Flash,鼓励使用html5;

? ? ? ?微信即将推出应用号;

? ? ? ?Facebook、谷歌、微软、BAT等纷纷全面支持html5;

? ? ? ?html5病毒式疯狂传播案例的频频出现;

? ? ? ?… …

? ? ? ?移动应用开发领域亦受到html5技术风暴的“席卷”。

? ? ? ?然而,面对HTML5带来的变革机遇,你是否因为对h5 app的种种担心,放缓了抢占市场先机的步伐?

? ? ? ?——担心h5 app性能不稳定,交互体验效果差,影响用户体验感

? ? ? ?——担心自身技术不过硬,无法快速进入h5 app开发者行列

? ? ? ?——担心开发平台限制多,应用源码及产权难保障

? ? ? ?… …

? ? ? ?4月9日13点30分,北京百川创业营,由WeX5移动应用开发平台主办的html5 app轻架构高性能开发交流会(北京)将给你答案!。

? ? ? ?届时,WeX5首席技术运营官将为您的问题进行解答,并与您分享诸多干货:

? ? ? ?h5 app为何成为颠覆App既有行业格局的力量;

? ? ? ?如何规避h5 app开发中的各种坑;

? ? ? ?WeX5开发平台为开发者带来哪些极致体验;

? ? ? ?深入交流探讨html5 app轻架构、高性能开发的技术问题和案例现场讲解;

? ? ? ?WeX5开发app过程视频展示。? ? ?

? ? ? ?此外,本次技术交流活动不仅为各位开发者准备了技术盛宴,还提供有各种精美礼品,幸运者更可享受WeX5产品VIP服务,让您领航h5 app开发之路。

【活动时间】

? ? ? ? 2016年4月9日(周六)下午13:30—16:30

【报名入口】

? ? ? ? 点击“阅读原文”,即可免费报名。

【活动地点】

? ? ? ??北京市海淀区长春桥路11号万柳亿城中心C2裙房B1百川创业营

? ? ? ?(C2楼北侧进,电梯下往B1层即到)





【主办方】





【合作伙伴】





阅读原文 查看全部
?H5 app已成趋势!


? ? ? ?如果认为这是危言耸听,那么你危险了。在W3C宣布html5正式定稿一年半以来,h5技术带来的产业变革已经不再停留在“干打雷”,而是掀起了“疾风骤雨”:

? ? ? ?Adobe支持用户放弃Flash,鼓励使用html5;

? ? ? ?微信即将推出应用号;

? ? ? ?Facebook、谷歌、微软、BAT等纷纷全面支持html5;

? ? ? ?html5病毒式疯狂传播案例的频频出现;

? ? ? ?… …

? ? ? ?移动应用开发领域亦受到html5技术风暴的“席卷”。

? ? ? ?然而,面对HTML5带来的变革机遇,你是否因为对h5 app的种种担心,放缓了抢占市场先机的步伐?

? ? ? ?——担心h5 app性能不稳定,交互体验效果差,影响用户体验感

? ? ? ?——担心自身技术不过硬,无法快速进入h5 app开发者行列

? ? ? ?——担心开发平台限制多,应用源码及产权难保障

? ? ? ?… …

? ? ? ?4月9日13点30分,北京百川创业营,由WeX5移动应用开发平台主办的html5 app轻架构高性能开发交流会(北京)将给你答案!。

? ? ? ?届时,WeX5首席技术运营官将为您的问题进行解答,并与您分享诸多干货:

? ? ? ?h5 app为何成为颠覆App既有行业格局的力量;

? ? ? ?如何规避h5 app开发中的各种坑;

? ? ? ?WeX5开发平台为开发者带来哪些极致体验;

? ? ? ?深入交流探讨html5 app轻架构、高性能开发的技术问题和案例现场讲解;

? ? ? ?WeX5开发app过程视频展示。? ? ?

? ? ? ?此外,本次技术交流活动不仅为各位开发者准备了技术盛宴,还提供有各种精美礼品,幸运者更可享受WeX5产品VIP服务,让您领航h5 app开发之路。

【活动时间】

? ? ? ? 2016年4月9日(周六)下午13:30—16:30

【报名入口】

? ? ? ? 点击“阅读原文”,即可免费报名。

【活动地点】

? ? ? ??北京市海淀区长春桥路11号万柳亿城中心C2裙房B1百川创业营

? ? ? ?(C2楼北侧进,电梯下往B1层即到)


640.webp_.jpg


【主办方】


QQ图片20160405115529.png


【合作伙伴】


640.webp_(1)_.jpg


阅读原文
0
回复
0
评论

Android 3.1.1, iOS3.1.1 release

beyond 发表了文章 ? 913 次浏览 ? 2016-04-03 12:19 ? 来自相关话题

新功能:

音视频增加弱网/断网检测功能;
音视频增加音频、视频流暂停、恢复功能;
音视频增加录制功能;
发送图片默认压缩图片,节约流量;

bug fix:

Fix iOS demo退到后台后某些情况下crash的bug。
点击下载:http://www.easemob.com/download
? 查看全部
Img387233141.jpg

新功能:

音视频增加弱网/断网检测功能;
音视频增加音频、视频流暂停、恢复功能;
音视频增加录制功能;
发送图片默认压缩图片,节约流量;

bug fix:

Fix iOS demo退到后台后某些情况下crash的bug。


点击下载:http://www.easemob.com/download
?
0
评论

Uber弃用email客服改用应用内客服,App内置客服将成趋势?

beyond 发表了文章 ? 2006 次浏览 ? 2016-04-03 11:26 ? 来自相关话题

Uber的用户求助服务一直是通过Email沟通,而近日Uber将该服务切换到了应用内部。这么做理由何在呢? 因为在Uber一直希望获取大量市场份额的部分国家,例如中国和印度,用户并不像西方人那样习惯使用Email。




 我们从上世纪90年代中叶开始就习惯了往来的电子邮件传达信息,而中国的大部分用户甚至连Email地址都没有。因为互联网不那么让人觉得靠得住,在中国和印度,人们更喜欢使用微信这样的聊天软件进行交流。在2015年,微信已拥有超过10亿用户。




Uber的“用户沉迷”产品经理Michael York说,虽然新的应用内服务去年晚些时候在美国铺开,实际上为了从Email交流转变为应用内沟通,Uber已潜心研究数年。Uber现在正在将其业务拓展到这样一些国家——为留住用户,Uber需要帮助用户找回不小心落下的东西、或处理其他投诉,这些工作需要牵涉到乘客和司机两个方面。

York说“(这种转变)对于中国、印度及其他更喜欢即时聊天的地区用户而言是巨大的。”而这种转变也同样减轻了客服部门的压力。Uber专家以往需要同时处理无礼乘客、失物找回等各类投诉Email,而这已成为过去式,因为彼时Uber还没有这么多用户。

Uber还一直因为不提供电话协助服务而饱受批评,因为有的时候发邮件几乎是不可能的。而且Uber的客服邮件一般都是自动回复的统一信息,之后才会有人工回复。

在过去的几年,Uber开始投入“数百万”的资金建立其支持中心的网络以加快反应速度。中心已建立在包括芝加哥(美国)、凤凰城(美国)、利默里克(爱尔兰)、克拉科夫(波兰)、武汉(中国)、海德拉巴(印度)、马尼拉(菲律宾)等许多地方。然而公司与用户之间的沟通需要比用Email更接地气的方式。

Uber的全球运营主管Michael Mizrahi说,为应对这样的改变,工程师不得不在后端重写整个支持系统,新的Uber应用将会在未来几周内推出。美国市场将最先获得更新,然后再陆续推广至全球其他地区。

如果您的公司也有和Uber一样的客服困境,那么现在市场上主流的SaaS移动客服是您的不二选择:1,极简快速集成,一天时间即可让您的APP拥有应用类客服功能。2,按需付费。3,弹性扩容。4,智能机器人提高效率降低成本。5,全媒体接入,包括微博、微信、网页、H5、APP、呼叫中心等一键集成一网打尽。

hg3399.com|官方网站移动客服是全球首创的全媒体智能云客服平台。支持全媒体接入,包括网页在线客服、社交媒体客服(微博、微信)、移动端客服和呼叫中心等多种渠道。hg3399.com|官方网站移动客服基于hg3399.com|官方网站业界领先的IM长连接技术保证消息必达,并通过强大的智能机器人技术极大降低人工客服工作量。

截至2015年底,hg3399.com|官方网站移动客服共服务了12000家企业用户,现已覆盖包括电商、O2O、互联网金融、在线教育、在线旅游、移动医疗、智能硬件、游戏等20大领域的Top10客户,典型用户包括国美在线、58到家、楚楚街、随手记、海尔、51talk,链家自如客等众多互联网和传统企业。根据易观国际发布的《中国SaaS客服市场专题研究报告2015》显示:截至2015年第三季度,hg3399.com|官方网站移动客服在SaaS移动端客服用户覆盖占比为77.4%,以绝对优势稳居行业第一。

此番Uber弃用传统email客服改用应用内客服其实是一个必然趋势,那么是否会对亚太乃至整个客服市场造成影响?我们拭目以待。
?
hg3399.com|官方网站编译自“techcrunch美国”,请点击“阅读原文”跳转至英文链接。
?
阅读原文 查看全部

640.webp_.jpg

Uber的用户求助服务一直是通过Email沟通,而近日Uber将该服务切换到了应用内部。这么做理由何在呢? 因为在Uber一直希望获取大量市场份额的部分国家,例如中国和印度,用户并不像西方人那样习惯使用Email。

640.webp_(1)_.jpg

 我们从上世纪90年代中叶开始就习惯了往来的电子邮件传达信息,而中国的大部分用户甚至连Email地址都没有。因为互联网不那么让人觉得靠得住,在中国和印度,人们更喜欢使用微信这样的聊天软件进行交流。在2015年,微信已拥有超过10亿用户。

0.webp_.jpg

Uber的“用户沉迷”产品经理Michael York说,虽然新的应用内服务去年晚些时候在美国铺开,实际上为了从Email交流转变为应用内沟通,Uber已潜心研究数年。Uber现在正在将其业务拓展到这样一些国家——为留住用户,Uber需要帮助用户找回不小心落下的东西、或处理其他投诉,这些工作需要牵涉到乘客和司机两个方面。

York说“(这种转变)对于中国、印度及其他更喜欢即时聊天的地区用户而言是巨大的。”而这种转变也同样减轻了客服部门的压力。Uber专家以往需要同时处理无礼乘客、失物找回等各类投诉Email,而这已成为过去式,因为彼时Uber还没有这么多用户。

Uber还一直因为不提供电话协助服务而饱受批评,因为有的时候发邮件几乎是不可能的。而且Uber的客服邮件一般都是自动回复的统一信息,之后才会有人工回复。

在过去的几年,Uber开始投入“数百万”的资金建立其支持中心的网络以加快反应速度。中心已建立在包括芝加哥(美国)、凤凰城(美国)、利默里克(爱尔兰)、克拉科夫(波兰)、武汉(中国)、海德拉巴(印度)、马尼拉(菲律宾)等许多地方。然而公司与用户之间的沟通需要比用Email更接地气的方式。

Uber的全球运营主管Michael Mizrahi说,为应对这样的改变,工程师不得不在后端重写整个支持系统,新的Uber应用将会在未来几周内推出。美国市场将最先获得更新,然后再陆续推广至全球其他地区。

如果您的公司也有和Uber一样的客服困境,那么现在市场上主流的SaaS移动客服是您的不二选择:1,极简快速集成,一天时间即可让您的APP拥有应用类客服功能。2,按需付费。3,弹性扩容。4,智能机器人提高效率降低成本。5,全媒体接入,包括微博、微信、网页、H5、APP、呼叫中心等一键集成一网打尽。

hg3399.com|官方网站移动客服是全球首创的全媒体智能云客服平台。支持全媒体接入,包括网页在线客服、社交媒体客服(微博、微信)、移动端客服和呼叫中心等多种渠道。hg3399.com|官方网站移动客服基于hg3399.com|官方网站业界领先的IM长连接技术保证消息必达,并通过强大的智能机器人技术极大降低人工客服工作量。

截至2015年底,hg3399.com|官方网站移动客服共服务了12000家企业用户,现已覆盖包括电商、O2O、互联网金融、在线教育、在线旅游、移动医疗、智能硬件、游戏等20大领域的Top10客户,典型用户包括国美在线、58到家、楚楚街、随手记、海尔、51talk,链家自如客等众多互联网和传统企业。根据易观国际发布的《中国SaaS客服市场专题研究报告2015》显示:截至2015年第三季度,hg3399.com|官方网站移动客服在SaaS移动端客服用户覆盖占比为77.4%,以绝对优势稳居行业第一。

此番Uber弃用传统email客服改用应用内客服其实是一个必然趋势,那么是否会对亚太乃至整个客服市场造成影响?我们拭目以待。
?
hg3399.com|官方网站编译自“techcrunch美国”,请点击“阅读原文”跳转至英文链接。
?
阅读原文