环信Android/ios V3.3.3 SDK 已发布,支持多设备消息漫游及管理

TIM图片20170725145101.png

Android​版本 V3.3.3 2017-07-21
 
新功能
  • 新增加API请查看链接3.3.3api修改
  • 支持在多个设备登录同一个账号,多个设备间可以同步消息,好友及群组的操作(多设备登录属于增值服务,需要联系商务开通);
  • 添加群共享文件的大小属性;
  • 增加获取同一账号登录的设备列表的接口,并可以选择踢掉某个设备上的登录;


问题修复
  • 修复分页获取聊天室成员接口无法传入cursor的问题;
  • 修复邀请群成员时没有附带信息的bug;
  • 修复群组操作时必须获取所有已加入群组的问题;
  • 修复附件消息在web IM中右键另存时不能正确显示名字的问题;
  • 修复android 共享文件名为中文时显示乱码的问题;
  • 修复下载附件路径不存在或者打开错误时仍然下载成功的bug;
  • 修复切换账号时某些场景下崩溃的bug;
  • 修复获取群成员时最后一页cursor未更新的问题;

 
ios版本 V3.3.3 2017-07-21
新功能:
  • 新增:支持在多个设备登录同一个账号,多个设备间可以同步消息,好友及群组的操作(多设备登录属于增值服务,需要联系商务开通);
  • 新增:群共享文件的大小属性;
  • 新增:获取同一账号登录的设备列表的接口,并可以选择踢掉某个设备上的登录;


问题修复:
  • 修复邀请群成员时没有附带信息的bug;
  • 修复群组操作时必须获取所有已加入群组的问题;
  • 修复下载附件路径不存在或者打开错误时仍然下载成功的bug;
  • 修复切换账号时某些场景下崩溃的bug;
  • 修复获取群成员时最后一页cursor未更新的问题;
  • 修复调用异步删除好友接口,参数传“YES”不能删除会话。

 
 
版本历史Android SDK更新日志  ios SDK更新日志
下载地址SDK下载
继续阅读 »
TIM图片20170725145101.png

Android​版本 V3.3.3 2017-07-21
 
新功能
  • 新增加API请查看链接3.3.3api修改
  • 支持在多个设备登录同一个账号,多个设备间可以同步消息,好友及群组的操作(多设备登录属于增值服务,需要联系商务开通);
  • 添加群共享文件的大小属性;
  • 增加获取同一账号登录的设备列表的接口,并可以选择踢掉某个设备上的登录;


问题修复
  • 修复分页获取聊天室成员接口无法传入cursor的问题;
  • 修复邀请群成员时没有附带信息的bug;
  • 修复群组操作时必须获取所有已加入群组的问题;
  • 修复附件消息在web IM中右键另存时不能正确显示名字的问题;
  • 修复android 共享文件名为中文时显示乱码的问题;
  • 修复下载附件路径不存在或者打开错误时仍然下载成功的bug;
  • 修复切换账号时某些场景下崩溃的bug;
  • 修复获取群成员时最后一页cursor未更新的问题;

 
ios版本 V3.3.3 2017-07-21
新功能:
  • 新增:支持在多个设备登录同一个账号,多个设备间可以同步消息,好友及群组的操作(多设备登录属于增值服务,需要联系商务开通);
  • 新增:群共享文件的大小属性;
  • 新增:获取同一账号登录的设备列表的接口,并可以选择踢掉某个设备上的登录;


问题修复:
  • 修复邀请群成员时没有附带信息的bug;
  • 修复群组操作时必须获取所有已加入群组的问题;
  • 修复下载附件路径不存在或者打开错误时仍然下载成功的bug;
  • 修复切换账号时某些场景下崩溃的bug;
  • 修复获取群成员时最后一页cursor未更新的问题;
  • 修复调用异步删除好友接口,参数传“YES”不能删除会话。

 
 
版本历史Android SDK更新日志  ios SDK更新日志
下载地址SDK下载 收起阅读 »

Freshdesk母公司收购Joe Hukum进军聊天机器人市场

译者按:相对于国外智能聊天机器人市场的方兴未艾,国内智能聊天机器人的落地势头更是一浪高过一浪,以环信为首的智能客服厂商提供的服务包括单轮会话、多轮会话以及人工协作已经广泛应用于包括保险、教育、金融、电商等行业,借助于AI技术在包括主动营销方面也有了更深入的探索。

微信图片_20170725114409.jpg

   Freshworks(Freshdesk母公司)去年筹集5500万美元,用以建立超越现有帮助台服务。今天,Freshworks通过收购Joe Hukum来实现这一战略。Joe Hukum是一家印度创业公司,负责为企业提供建立自己的聊天机器人平台。

   虽有问询,但这些公司并没有透露任何交易条款。Joe Hukum, 之前为Speedy,最初侧重建立自己的个人助理或管理程序,帮助人们订购商品和服务,现转向为其他企业构建机器人服务平台。“Joe Hukum”是一种印地语的音译,意思是“按照你的意愿”。

   这是Freshworks在两年内的第八次收购,且在人工智能领域进行了一系列的收购,特别是“神经语言程序设计”(简称为“NLP”,注意不能与自然语言处理相混淆):另外两个收购是Chatimity和Frilp。Freshworks表示将利用三家创业公司的技术和人才,推出基于聊天机器人的解决方案。

   具体而言,Joe Hukum已经建立了知识树编码用以自动化销售、服务和支持工作流程。所以由联合创始人Arihant Jain,Ajeet Kushwaha和Rahul Agarwal领导的创业团队将在现有的Freshworks产品之上构建机器人产品。

   这笔交易强调了客户服务行业对聊天机器人的持续兴趣:公司正在寻找更有效率和更便宜的方式来提供基本信息和帮助客户。许多人认为聊天机器人是可行的解决方案,尽管目前正在建设的很多东西仍处于早期阶段。

   Freshworks创始人兼CEO Girish Mathrubootham在一份声明中说:“我们看到我们的客户对如何使用聊天机器人抱有浓厚兴趣,因为他们正在寻找与客户在网络和移动渠道上进行互动的新途径。随着客户偏好从传统的基于呼叫中心的电话树转移,聊天机器人提供了新的支持体验,同时也根本解决了对客户查询和途径进行分类的老式挑战,将其转为恰当的支持代理。这些仍属于聊天机器人的初期阶段,但Joe Hukum的创新团队和技术将帮助企业客户更好地吸引和支持其顾客。

   Freshworks引用了Gartner的研究,预测到2019年,40%的企业将使用自然语言聊天机器人来进行业务中(思考Slack风格的机器人)和对外的通信。

   这也正是Freshworks觉得它有潜力的地方。目前该公司为大约10万家公司提供Freshdesk,并在这一群体中开始销售这些机器人新服务。

   Joe Hukum的Jain在一份声明中表示:“作为Freshworks的一部分,对我们所有人来说都是激动人心的,因为它为我们提供了一个平台,为我们扩大了规模和覆盖面,并影响了成千上万的客户。

   相对于国外智能聊天机器人市场的方兴未艾,国内智能聊天机器人的落地势头更是一浪高过一浪,以环信为首的智能客服厂商提供的服务包括单轮会话、多轮会话以及人工协作已经广泛应用于包括保险、教育、金融、电商等行业,借助于AI技术在包括主动营销方面也有了更深入的探索。近期环信联合Gartner发布的业界首个智能客服机器人实践报告《Best Practice of Customer Service Bot In Customer Service Industry》更是给呼叫中心向在线客服转型的业客户注入了一剂强心针,客户们有充足的理由相信借助于智能聊天机器人的帮助可以利用有限的客服资源来应对移动互联时代海量客户咨询的暴涨。
 Gartner报告点击查看
继续阅读 »
译者按:相对于国外智能聊天机器人市场的方兴未艾,国内智能聊天机器人的落地势头更是一浪高过一浪,以环信为首的智能客服厂商提供的服务包括单轮会话、多轮会话以及人工协作已经广泛应用于包括保险、教育、金融、电商等行业,借助于AI技术在包括主动营销方面也有了更深入的探索。

微信图片_20170725114409.jpg

   Freshworks(Freshdesk母公司)去年筹集5500万美元,用以建立超越现有帮助台服务。今天,Freshworks通过收购Joe Hukum来实现这一战略。Joe Hukum是一家印度创业公司,负责为企业提供建立自己的聊天机器人平台。

   虽有问询,但这些公司并没有透露任何交易条款。Joe Hukum, 之前为Speedy,最初侧重建立自己的个人助理或管理程序,帮助人们订购商品和服务,现转向为其他企业构建机器人服务平台。“Joe Hukum”是一种印地语的音译,意思是“按照你的意愿”。

   这是Freshworks在两年内的第八次收购,且在人工智能领域进行了一系列的收购,特别是“神经语言程序设计”(简称为“NLP”,注意不能与自然语言处理相混淆):另外两个收购是Chatimity和Frilp。Freshworks表示将利用三家创业公司的技术和人才,推出基于聊天机器人的解决方案。

   具体而言,Joe Hukum已经建立了知识树编码用以自动化销售、服务和支持工作流程。所以由联合创始人Arihant Jain,Ajeet Kushwaha和Rahul Agarwal领导的创业团队将在现有的Freshworks产品之上构建机器人产品。

   这笔交易强调了客户服务行业对聊天机器人的持续兴趣:公司正在寻找更有效率和更便宜的方式来提供基本信息和帮助客户。许多人认为聊天机器人是可行的解决方案,尽管目前正在建设的很多东西仍处于早期阶段。

   Freshworks创始人兼CEO Girish Mathrubootham在一份声明中说:“我们看到我们的客户对如何使用聊天机器人抱有浓厚兴趣,因为他们正在寻找与客户在网络和移动渠道上进行互动的新途径。随着客户偏好从传统的基于呼叫中心的电话树转移,聊天机器人提供了新的支持体验,同时也根本解决了对客户查询和途径进行分类的老式挑战,将其转为恰当的支持代理。这些仍属于聊天机器人的初期阶段,但Joe Hukum的创新团队和技术将帮助企业客户更好地吸引和支持其顾客。

   Freshworks引用了Gartner的研究,预测到2019年,40%的企业将使用自然语言聊天机器人来进行业务中(思考Slack风格的机器人)和对外的通信。

   这也正是Freshworks觉得它有潜力的地方。目前该公司为大约10万家公司提供Freshdesk,并在这一群体中开始销售这些机器人新服务。

   Joe Hukum的Jain在一份声明中表示:“作为Freshworks的一部分,对我们所有人来说都是激动人心的,因为它为我们提供了一个平台,为我们扩大了规模和覆盖面,并影响了成千上万的客户。

   相对于国外智能聊天机器人市场的方兴未艾,国内智能聊天机器人的落地势头更是一浪高过一浪,以环信为首的智能客服厂商提供的服务包括单轮会话、多轮会话以及人工协作已经广泛应用于包括保险、教育、金融、电商等行业,借助于AI技术在包括主动营销方面也有了更深入的探索。近期环信联合Gartner发布的业界首个智能客服机器人实践报告《Best Practice of Customer Service Bot In Customer Service Industry》更是给呼叫中心向在线客服转型的业客户注入了一剂强心针,客户们有充足的理由相信借助于智能聊天机器人的帮助可以利用有限的客服资源来应对移动互联时代海量客户咨询的暴涨。
 Gartner报告点击查看 收起阅读 »

环信荣膺“2017未来独角兽企业”,做商业的连接器

 独角兽企业往往聚集了行业里大多的资源,随着技术、人才、资金的积累,其在行业里的地位与机会将逐步放大,前进愈发顺利,发展迎风而起。近日,由中国科学院《互联网周刊》杂志评选的“2017未来独角兽企业TOP150”榜单正式揭晓,有着国际领先的企业级软件服务提供商愿景的环信凭借在即时通讯云和SaaS客服领域的行业深耕和迅猛发展,以全国榜单第130名位居垂直行业第一。
ea790d9dly1fhv495ni8gj211j0pyn6b.jpg

“连接人与人”,“连接人与商业”的愿景支撑垂直行业第一

   企业服务市场是一块大蛋糕,练就的是技术内功,靠的是对市场趋势的准确把握,环信以用户需求为出发点近期推出客户互动云(CEC),环信CEC基于全球领先的即时通讯云技术,通过人工智能和大数据赋能,依托多渠道接入管理、精准用户画像、智能客服机器人、客户之声、智能质检、视频客服等SaaS客服体系为包括保险、证券、金融、教育、电商等行业提供了从客户互动渠道、到客户服务、再到精准营销的全流程客户互动解决方案。

   环信的起家产品“即时通讯云”,承担环信“连接人与人”的商业愿景,为开发者提供基于移动互联网的即时通讯能力,作为全球最大的即时通讯云厂商已经广泛应用服务13万余APP客户,环信全面支持Android、iOS、Web等多种平台,在流量、电量、长连接、语音、位置、安全等能力做了极致的优化,让移动开发者摆脱繁重的移动IM通讯底层开发,极大限度地缩短产品开发周期,二十四时间内即可让App拥有移动IM能力。目前环信即时通讯云已经拓展推出了包括直播、社交大数据、红包、鉴黄、视频人脸特效、短信验证码等增值服务。

   而“环信移动客服”是即时通讯云“连接人与人”场景的一个延伸到“连接人与商业”,包括网页在线客服、社交媒体客服(微博、微信)、APP内置客服、工单和呼叫中心等多种渠道均可一键接入。基于环信业界领先的IM长连接技术保证消息必达,并通过智能客服机器人技术降低人工客服工作量。同时,基于人工智能和大数据挖掘的客户旅程透析产品”环信客户声音”能够帮助企业优化运营,提高跨渠道客服体验。

   2016年,基于开发即时通讯云和移动客服的基础上,环信对已有产品进行了再次的研发和升级,针对已有在包括电商、保险、证券、金融、教育等优势行业的积累基础上,着手开发人工智能 —— “环信智能客服机器人”。他们希望在不降低用户体验的情况下,尽可能地解决商家日益增长的客服成本和海量客服请求之间的天然矛盾。

   比如,我们在移动端通过国美在线下单后,产品遇到的任何问题,通过IM窗口和客服咨询,这个沟通通道就是环信即时通讯云在提供底层通信服务。环信移动客服依托智能客服机器人很大程度上为企业节约了人力成本,众多保险公司已经通过部署环信智能客服机器人来提高客服效率。环信客户声音提高了跨渠道的客户服务体验,帮助企业优化运营,实现了客户中心完成从成本中心向价值中心的转化,国内某标杆教育机构已经在部署完环信客服声音以后尝到了客户转化率、客单价双升的甜头。

   与此同时,环信还一直利用自己的大数据平台产品给客户提供增值服务,让客户通过即时通讯云和移动客服等产品的后台数据,分析得出自己产品的适用人群、产品体验和活跃度等。让客户能更好地改善自己的产品,更好地服务消费者。

   环信的所有更新、改变与尝试,都是在围绕着一个行业,或者说是一个目标在努力。走上行业的顶峰之后,面临坦途时就会懈怠很多,但他们似乎仍然没有放弃向更高峰的攀登。

   2016年环信作为国内唯一的SaaS厂商荣膺Gartner 2016 Cool Vendor,2017年3月环信刚获得由经纬中国领投、银泰嘉禾跟投的1.03亿元C轮融资,显示出包括国际顶级研究机构和资本市场对于环信商业模式和发展前景的认可。正是得益于包括红杉资本、经纬中国、SIG和银泰嘉禾的鼎力支持,保障了环信持续巨额的研发投入,形成了公司业务发展的正向循环。

志存高远方能有所大成

   独角兽企业往往聚集了行业里大多的资源,随着技术、人才、资金的积累,其在行业里的地位与机会将逐步放大,前进愈发顺利,发展迎风而起。优势会被放大,引领、变革行业发展的责任则愈发凸显。换句话说,独角兽企业不仅仅是行业的佼佼者,更重要的,它是行业的领跑者、推动者。

   身为未来独角兽企业,要以行业推动者自居,以创新破迷局,以诚信守正心,以担当为己任。只有致力于市场需求的满足,行业发展瓶颈的突破,才会在纷乱的市场竞争中把握准方向,守得住初心,冲出迷雾,把握未来。

独角兽是一种荣耀的名片,更意味着一种担当与责任。
继续阅读 »
 独角兽企业往往聚集了行业里大多的资源,随着技术、人才、资金的积累,其在行业里的地位与机会将逐步放大,前进愈发顺利,发展迎风而起。近日,由中国科学院《互联网周刊》杂志评选的“2017未来独角兽企业TOP150”榜单正式揭晓,有着国际领先的企业级软件服务提供商愿景的环信凭借在即时通讯云和SaaS客服领域的行业深耕和迅猛发展,以全国榜单第130名位居垂直行业第一。
ea790d9dly1fhv495ni8gj211j0pyn6b.jpg

“连接人与人”,“连接人与商业”的愿景支撑垂直行业第一

   企业服务市场是一块大蛋糕,练就的是技术内功,靠的是对市场趋势的准确把握,环信以用户需求为出发点近期推出客户互动云(CEC),环信CEC基于全球领先的即时通讯云技术,通过人工智能和大数据赋能,依托多渠道接入管理、精准用户画像、智能客服机器人、客户之声、智能质检、视频客服等SaaS客服体系为包括保险、证券、金融、教育、电商等行业提供了从客户互动渠道、到客户服务、再到精准营销的全流程客户互动解决方案。

   环信的起家产品“即时通讯云”,承担环信“连接人与人”的商业愿景,为开发者提供基于移动互联网的即时通讯能力,作为全球最大的即时通讯云厂商已经广泛应用服务13万余APP客户,环信全面支持Android、iOS、Web等多种平台,在流量、电量、长连接、语音、位置、安全等能力做了极致的优化,让移动开发者摆脱繁重的移动IM通讯底层开发,极大限度地缩短产品开发周期,二十四时间内即可让App拥有移动IM能力。目前环信即时通讯云已经拓展推出了包括直播、社交大数据、红包、鉴黄、视频人脸特效、短信验证码等增值服务。

   而“环信移动客服”是即时通讯云“连接人与人”场景的一个延伸到“连接人与商业”,包括网页在线客服、社交媒体客服(微博、微信)、APP内置客服、工单和呼叫中心等多种渠道均可一键接入。基于环信业界领先的IM长连接技术保证消息必达,并通过智能客服机器人技术降低人工客服工作量。同时,基于人工智能和大数据挖掘的客户旅程透析产品”环信客户声音”能够帮助企业优化运营,提高跨渠道客服体验。

   2016年,基于开发即时通讯云和移动客服的基础上,环信对已有产品进行了再次的研发和升级,针对已有在包括电商、保险、证券、金融、教育等优势行业的积累基础上,着手开发人工智能 —— “环信智能客服机器人”。他们希望在不降低用户体验的情况下,尽可能地解决商家日益增长的客服成本和海量客服请求之间的天然矛盾。

   比如,我们在移动端通过国美在线下单后,产品遇到的任何问题,通过IM窗口和客服咨询,这个沟通通道就是环信即时通讯云在提供底层通信服务。环信移动客服依托智能客服机器人很大程度上为企业节约了人力成本,众多保险公司已经通过部署环信智能客服机器人来提高客服效率。环信客户声音提高了跨渠道的客户服务体验,帮助企业优化运营,实现了客户中心完成从成本中心向价值中心的转化,国内某标杆教育机构已经在部署完环信客服声音以后尝到了客户转化率、客单价双升的甜头。

   与此同时,环信还一直利用自己的大数据平台产品给客户提供增值服务,让客户通过即时通讯云和移动客服等产品的后台数据,分析得出自己产品的适用人群、产品体验和活跃度等。让客户能更好地改善自己的产品,更好地服务消费者。

   环信的所有更新、改变与尝试,都是在围绕着一个行业,或者说是一个目标在努力。走上行业的顶峰之后,面临坦途时就会懈怠很多,但他们似乎仍然没有放弃向更高峰的攀登。

   2016年环信作为国内唯一的SaaS厂商荣膺Gartner 2016 Cool Vendor,2017年3月环信刚获得由经纬中国领投、银泰嘉禾跟投的1.03亿元C轮融资,显示出包括国际顶级研究机构和资本市场对于环信商业模式和发展前景的认可。正是得益于包括红杉资本、经纬中国、SIG和银泰嘉禾的鼎力支持,保障了环信持续巨额的研发投入,形成了公司业务发展的正向循环。

志存高远方能有所大成

   独角兽企业往往聚集了行业里大多的资源,随着技术、人才、资金的积累,其在行业里的地位与机会将逐步放大,前进愈发顺利,发展迎风而起。优势会被放大,引领、变革行业发展的责任则愈发凸显。换句话说,独角兽企业不仅仅是行业的佼佼者,更重要的,它是行业的领跑者、推动者。

   身为未来独角兽企业,要以行业推动者自居,以创新破迷局,以诚信守正心,以担当为己任。只有致力于市场需求的满足,行业发展瓶颈的突破,才会在纷乱的市场竞争中把握准方向,守得住初心,冲出迷雾,把握未来。

独角兽是一种荣耀的名片,更意味着一种担当与责任。 收起阅读 »

北京大半个SaaS圈都来了|SaaS厂商的社群销售方案和云服务销售社群私享会

 哇!社群销售沙龙倒计时7天,SaaS品牌热情响应。已确认参会品牌商:致远、麦达、 销售易、纷享销客、六度人和、高速波、云代账、有序云、Ping++......

  更有客户和合作资源对接:畅捷通、环信、金融魔方3大资深SaaS品牌商,中国软件网海量渠道资源。届时将共同围绕“企业销售资源是否决定SaaS产品销售成败”话题激烈碰撞!

微信图片_20170720111910.jpg

没有销售员、销售员能力不足,如何做销售?


渠道招商乏力,伙伴能力不足,如何做销售?

社群销售:连接拥有专业知识、行业经验、社交关系等群体,用新规则整合社群生态体系,通过在线订购、直播订购、销售坐席促进转化。

私享会●北京站:邀请SaaS品牌商,拆解社群销售方案及运营模式,分享拥有30000个推客的云服务销售社群,帮助SaaS厂商实现销售增长。
 
私享会 活动看点  
大咖观点:增加销售员&干掉销售员 
出席嘉宾:用友助理总裁、金融魔方副总裁、CSaaS总裁
碰撞话题:企业销售资源是否决定SaaS产品销售成败
 
社群销售:让销售组织无边界 
推客发展:没有合伙人就没推客,合伙人为社群源动力
协同销售:厂商、渠道商、推客协同完成营销、销售
 
资源对接:3万推客资源状况及共享方案
推客构成:客户连接点,软件渠道商销售/服务工程师
推客能力:承接活动邀请、软件注册、产品销售等任务
品牌入驻:通过任务广场发任务,共享3万推客资源
 
案例分解:用友好会计社群&中驰车福车客社群1好会计社群概述
畅捷通出品好会计在线财务软件,招募100个合伙人,分别连接100名会计推客,形成万人销售社群,每月百套购买。2中驰车客社群概述
中驰车福为汽车后市场供应链服务商,采用B2b+B2r双模式,旨在全国招商9000汽配零售商,通过600个合伙人,分配连接50家汽配商,快速形成3万推客的销售社群。私享会 参会须知  
  
社群销售私享会 适合谁?
①软件/SaaS/在线教育等行业
②寻找企业增长新途径的企业管理者:如CEO、联合创始人、分管营销的VP、市场总监、运营总监、销售总监、渠道总监等
社群销售私享会 如何参加?
①时间:2017.7.27 14:30-17:00
②地址:北京●中关村软件园
③报名:点击下方进行报名

 点击此处立即报名 

 私享会 嘉宾团   于光辉 码客CEO
001.jpg


20余年营销服务一线经验,国内第一批CRM实践和传播者,码客社群销售方案及平台总设计师。曾任用友软件副总经理、MyCRM董事、红杉树高级副总裁、用友营销云事业部总经理。国家经贸委、中国电信/号百股份高级营销顾问、张艺谋《鸟巢图兰朵》在线营销总顾问。

程旭文 环信VP
微信图片_20170720153956.jpg



二十年企业服务老司机,重点关注即时通讯云/SaaS客服/协同OA等领域。

创建开源力量IT在线教育平台。在此之前曾就职于IONA Technologies、Progress Software、上海浩方等公司, 历任软件工程师、售前技术顾问 、销售经理、中国区销售总监等职位。
王学钧 用友集团助理总裁
002.jpg


用友畅捷通云业务总经理 投资总监,企业信息化资深专家,具有丰富的企业服务领域营销、 渠道、产品经验;畅捷通渠道支持体系创立人,曾实现用友集团千万级业务年增长5倍业绩。

杜永旺 金融魔方副总裁
TIM图片20170720112420.png

13年企业服务市场从业经验,曾任职TQ、中企动力、ZOHO中国企业应用软件、信息化服务公司,对SaaS产品和客户服务有较强方案设计能力和销售规划管理能力。

许卫国  中国软件网副总裁 合伙人
003.jpg


先后与近1000家软件企业交流,总结出中国企业级软件市场的销售模式和方法。武汉电视台《一飞冲天》导师。《大数据时代的移动营销》讲师;《传统软件企业转型》讲师;《云服务降维销售》讲师。

                 合作伙伴  
本期沙龙特别鸣谢以下合作伙伴鼎力支持!


TIM图片20170720112501.png


TIM图片20170720112530.png


TIM图片20170720112523.png


TIM图片20170720112542.png



主办方简介  
微信图片_20170720112126.jpg
继续阅读 »
 哇!社群销售沙龙倒计时7天,SaaS品牌热情响应。已确认参会品牌商:致远、麦达、 销售易、纷享销客、六度人和、高速波、云代账、有序云、Ping++......

  更有客户和合作资源对接:畅捷通、环信、金融魔方3大资深SaaS品牌商,中国软件网海量渠道资源。届时将共同围绕“企业销售资源是否决定SaaS产品销售成败”话题激烈碰撞!

微信图片_20170720111910.jpg

没有销售员、销售员能力不足,如何做销售?


渠道招商乏力,伙伴能力不足,如何做销售?

社群销售:连接拥有专业知识、行业经验、社交关系等群体,用新规则整合社群生态体系,通过在线订购、直播订购、销售坐席促进转化。

私享会●北京站:邀请SaaS品牌商,拆解社群销售方案及运营模式,分享拥有30000个推客的云服务销售社群,帮助SaaS厂商实现销售增长。
 
私享会 活动看点  
大咖观点:增加销售员&干掉销售员 
出席嘉宾:用友助理总裁、金融魔方副总裁、CSaaS总裁
碰撞话题:企业销售资源是否决定SaaS产品销售成败
 
社群销售:让销售组织无边界 
推客发展:没有合伙人就没推客,合伙人为社群源动力
协同销售:厂商、渠道商、推客协同完成营销、销售
 
资源对接:3万推客资源状况及共享方案
推客构成:客户连接点,软件渠道商销售/服务工程师
推客能力:承接活动邀请、软件注册、产品销售等任务
品牌入驻:通过任务广场发任务,共享3万推客资源
 
案例分解:用友好会计社群&中驰车福车客社群1好会计社群概述
畅捷通出品好会计在线财务软件,招募100个合伙人,分别连接100名会计推客,形成万人销售社群,每月百套购买。2中驰车客社群概述
中驰车福为汽车后市场供应链服务商,采用B2b+B2r双模式,旨在全国招商9000汽配零售商,通过600个合伙人,分配连接50家汽配商,快速形成3万推客的销售社群。私享会 参会须知  
  
社群销售私享会 适合谁?
①软件/SaaS/在线教育等行业
②寻找企业增长新途径的企业管理者:如CEO、联合创始人、分管营销的VP、市场总监、运营总监、销售总监、渠道总监等
社群销售私享会 如何参加?
①时间:2017.7.27 14:30-17:00
②地址:北京●中关村软件园
③报名:点击下方进行报名

 点击此处立即报名 

 私享会 嘉宾团   于光辉 码客CEO
001.jpg


20余年营销服务一线经验,国内第一批CRM实践和传播者,码客社群销售方案及平台总设计师。曾任用友软件副总经理、MyCRM董事、红杉树高级副总裁、用友营销云事业部总经理。国家经贸委、中国电信/号百股份高级营销顾问、张艺谋《鸟巢图兰朵》在线营销总顾问。

程旭文 环信VP
微信图片_20170720153956.jpg



二十年企业服务老司机,重点关注即时通讯云/SaaS客服/协同OA等领域。

创建开源力量IT在线教育平台。在此之前曾就职于IONA Technologies、Progress Software、上海浩方等公司, 历任软件工程师、售前技术顾问 、销售经理、中国区销售总监等职位。
王学钧 用友集团助理总裁
002.jpg


用友畅捷通云业务总经理 投资总监,企业信息化资深专家,具有丰富的企业服务领域营销、 渠道、产品经验;畅捷通渠道支持体系创立人,曾实现用友集团千万级业务年增长5倍业绩。

杜永旺 金融魔方副总裁
TIM图片20170720112420.png

13年企业服务市场从业经验,曾任职TQ、中企动力、ZOHO中国企业应用软件、信息化服务公司,对SaaS产品和客户服务有较强方案设计能力和销售规划管理能力。

许卫国  中国软件网副总裁 合伙人
003.jpg


先后与近1000家软件企业交流,总结出中国企业级软件市场的销售模式和方法。武汉电视台《一飞冲天》导师。《大数据时代的移动营销》讲师;《传统软件企业转型》讲师;《云服务降维销售》讲师。

                 合作伙伴  
本期沙龙特别鸣谢以下合作伙伴鼎力支持!


TIM图片20170720112501.png


TIM图片20170720112530.png


TIM图片20170720112523.png


TIM图片20170720112542.png



主办方简介  
微信图片_20170720112126.jpg
收起阅读 »

在线教育+直播,千亿市场的新入口

百度报告显示,互联网教育市场在2016年的增长率位居全行业第三,预计2017年的市场规模将突破2800亿元。AI、VR、AR等新技术的日趋成熟也给产品创新带来了新的可能。在激烈的竞争中,如何提高开发效率,快速将产品推向市场;如何借助前沿技术,给用户带来创新的体验,赢得市场成为企业关注的重点。
本次活动,APICloud将联合合作伙伴从在线教育类App的开发及创新技术应用等方向,跟大家聊聊直播给在线教育带来的新机会。
30102748471066586.png

【活动时间】2017年7月29日(周六),13:30-16:30

【活动地点】创业邦Demo Space(北京市海淀区中关村创业大街11号海置创投大厦7层)

【面向人群】在线教育企业管理层、产品负责人、技术负责人,其他在线教育从业者

【活动咨询/合作】请加微信:appdev1,备注729



01.png

【13:30-14:00】签到

【14:00-14:40】在线教育App开发面临的挑战

内容概要:如何冲破在线教育的技术壁垒;在线教育业务落地平台选型对比;在线教育类App实例分析

【14:40-15:20】视频内容版权保护技术在在线教育中的应用

内容概要:视频盗版的发现、防范及证据保存,以及如何保护视频内容的版权

【15:20-16:00】直播和在线教育结合的实践经验

内容概要:直播和在线教育相结合的特点与好处;直播与线下培训、图文、音频分享的区别与特点;线上直播分享的运营和推广经验;IT 在线教育的未来发展趋势

【16:00-】幸运抽奖&自由交流



02.png

03.jpg


04.png


05.jpeg


06.jpeg

活动报名:报名地址
继续阅读 »
百度报告显示,互联网教育市场在2016年的增长率位居全行业第三,预计2017年的市场规模将突破2800亿元。AI、VR、AR等新技术的日趋成熟也给产品创新带来了新的可能。在激烈的竞争中,如何提高开发效率,快速将产品推向市场;如何借助前沿技术,给用户带来创新的体验,赢得市场成为企业关注的重点。
本次活动,APICloud将联合合作伙伴从在线教育类App的开发及创新技术应用等方向,跟大家聊聊直播给在线教育带来的新机会。
30102748471066586.png

【活动时间】2017年7月29日(周六),13:30-16:30

【活动地点】创业邦Demo Space(北京市海淀区中关村创业大街11号海置创投大厦7层)

【面向人群】在线教育企业管理层、产品负责人、技术负责人,其他在线教育从业者

【活动咨询/合作】请加微信:appdev1,备注729



01.png

【13:30-14:00】签到

【14:00-14:40】在线教育App开发面临的挑战

内容概要:如何冲破在线教育的技术壁垒;在线教育业务落地平台选型对比;在线教育类App实例分析

【14:40-15:20】视频内容版权保护技术在在线教育中的应用

内容概要:视频盗版的发现、防范及证据保存,以及如何保护视频内容的版权

【15:20-16:00】直播和在线教育结合的实践经验

内容概要:直播和在线教育相结合的特点与好处;直播与线下培训、图文、音频分享的区别与特点;线上直播分享的运营和推广经验;IT 在线教育的未来发展趋势

【16:00-】幸运抽奖&自由交流



02.png

03.jpg


04.png


05.jpeg


06.jpeg

活动报名:报名地址 收起阅读 »

web IM的实现过程

web IM 聊天功能已实现,能够完成文本、emoji、图片、文件的收发。下面就以已完成的demo为中心,来说一下具体的实现方法。该demo已封装,能快速集成到项目中去。

1、demo展示:
chat 目录下有两个子文件,chat_hx、chat_hx2,两个文件代表俩个不同的用户,除im.js中用户配置不同其他代码均相同,可分别点击chat_hx、chat_hx2下的index.html运行该demo,会出现两个聊天界面,在此可以感受一下聊天功能。
 
2、demo目录结构:
chat_hx和chat_hx2下有 sdk、static、webrtc、im.js、index.html、main.html、pcChat.html。

sdk:目录下为环信官方提供的聊天聊天接口,strophe-1.2.8.min.js、webim.config.js、websdk-1.4.11.js;三个文件在index.html中均需要引入,webim.config.js文件中则需要我们配置应用的AppKey,是该应用的唯一标识;
static:有css、img、js 提供聊天界面的样式,图片、emoji表情库、jQuery库、underscore库;
webrtc:官方提供的的rtc聊天库,集成即时视频功能需要引用的文件;
index.html:手机web聊天界面入口,聊天窗口标签及相应的聊天模板;
pcChat.html:pc聊天界面,聊天窗口标签及相应的聊天模板;
main.html:pc聊天界面入口,通过iframe引入pcChat.html;
im.js:该文件中处理了所有聊天逻辑,提供用户登录接口,消息收发接口,采用localStorage来做消息的本地缓存,在html文件中只需要调用具体方法即可完成聊天功能。一下为具体的调用方法:
//初始化进去界面掉用该方法
getHxUser(login_account,send_to);
//发送图片调用方法  onClick("sendPrivateImg()")
sendPrivateImg();
//发送文件调用方法  onClick("sendPrivateFile()")
sendPrivateFile();
//发起视频聊天调用方法    onClick("videoCall()")
videoCall();
//发送文本消息调用方法    onClick("videoCall()")
sendPrivateText();

3、缓存逻辑:
缓存采用了没有时间限制的数据存储 localStorage 存储方式,以键值对的形式来存储一个聊天组。
(1)展示聊天信息:
key:"user1:user2" 以当前用户名和聊天对象的用户名作为key;
value:具体的聊天信息记录以数组形式存在。
每次登录后通过key来获取缓存中的聊天记录数组:
var group = "user1:user2";
var localContent = JSON.parse(localStorage[group]);
//遍历聊天数组
$(localContent).each(function(key , obj){
    var domstring = showBox(obj);//获取对应的聊天模板
    $(".chat-container").append($(domstring));//展示聊天信息
    text2bottom();//聊天记录滚动至底部展示最新的聊天信息
});
(2)接收信息的缓存处理:
接收消息将消息同样以键值对(登录用户名:接收者用户名)的的形式存储接收到的消息,存储前处理存储内容:
var group = "user1:user2";
var localContent = new Array();
if (localStorage[group]) {
    localContent = JSON.parse(localStorage[group]);
}
localContent[localContent.length] = {
    'time':crtTimeFtt(),//时间
    'data':data,//文本、emoji(符号)、图片(url)、文件(url)数据
    'from':from,//谁发的
    'type':type,//文本类型 text,emoji,file,picture
    'id':id//消息id
};
localStorage[group] = JSON.stringify(localContent);//存储本地;
(3)发送消息的缓存处理:
发送的消息同样以键值对的形式进行存储,同(2),图片文件,则是通过官方提供的方法当发送成功后会有对应的URL返回,即将URL作为数据存入data字段即可。

4、模板:
为控制方便模板写了六套,及左右聊天展示个三套 分别为文本、图片、文件。
 
 

00F7D790-2475-434B-9AEC-B86384B827C7.png


7AC59638-1719-4B4E-9015-461A25D5B039.png


CC744F4E-B6D4-4B4D-9ED9-31BA00AA651B.png

 
 
 

继续阅读 »
web IM 聊天功能已实现,能够完成文本、emoji、图片、文件的收发。下面就以已完成的demo为中心,来说一下具体的实现方法。该demo已封装,能快速集成到项目中去。

1、demo展示:
chat 目录下有两个子文件,chat_hx、chat_hx2,两个文件代表俩个不同的用户,除im.js中用户配置不同其他代码均相同,可分别点击chat_hx、chat_hx2下的index.html运行该demo,会出现两个聊天界面,在此可以感受一下聊天功能。
 
2、demo目录结构:
chat_hx和chat_hx2下有 sdk、static、webrtc、im.js、index.html、main.html、pcChat.html。

sdk:目录下为环信官方提供的聊天聊天接口,strophe-1.2.8.min.js、webim.config.js、websdk-1.4.11.js;三个文件在index.html中均需要引入,webim.config.js文件中则需要我们配置应用的AppKey,是该应用的唯一标识;
static:有css、img、js 提供聊天界面的样式,图片、emoji表情库、jQuery库、underscore库;
webrtc:官方提供的的rtc聊天库,集成即时视频功能需要引用的文件;
index.html:手机web聊天界面入口,聊天窗口标签及相应的聊天模板;
pcChat.html:pc聊天界面,聊天窗口标签及相应的聊天模板;
main.html:pc聊天界面入口,通过iframe引入pcChat.html;
im.js:该文件中处理了所有聊天逻辑,提供用户登录接口,消息收发接口,采用localStorage来做消息的本地缓存,在html文件中只需要调用具体方法即可完成聊天功能。一下为具体的调用方法:
//初始化进去界面掉用该方法
getHxUser(login_account,send_to);
//发送图片调用方法  onClick("sendPrivateImg()")
sendPrivateImg();
//发送文件调用方法  onClick("sendPrivateFile()")
sendPrivateFile();
//发起视频聊天调用方法    onClick("videoCall()")
videoCall();
//发送文本消息调用方法    onClick("videoCall()")
sendPrivateText();

3、缓存逻辑:
缓存采用了没有时间限制的数据存储 localStorage 存储方式,以键值对的形式来存储一个聊天组。
(1)展示聊天信息:
key:"user1:user2" 以当前用户名和聊天对象的用户名作为key;
value:具体的聊天信息记录以数组形式存在。
每次登录后通过key来获取缓存中的聊天记录数组:
var group = "user1:user2";
var localContent = JSON.parse(localStorage[group]);
//遍历聊天数组
$(localContent).each(function(key , obj){
    var domstring = showBox(obj);//获取对应的聊天模板
    $(".chat-container").append($(domstring));//展示聊天信息
    text2bottom();//聊天记录滚动至底部展示最新的聊天信息
});
(2)接收信息的缓存处理:
接收消息将消息同样以键值对(登录用户名:接收者用户名)的的形式存储接收到的消息,存储前处理存储内容:
var group = "user1:user2";
var localContent = new Array();
if (localStorage[group]) {
    localContent = JSON.parse(localStorage[group]);
}
localContent[localContent.length] = {
    'time':crtTimeFtt(),//时间
    'data':data,//文本、emoji(符号)、图片(url)、文件(url)数据
    'from':from,//谁发的
    'type':type,//文本类型 text,emoji,file,picture
    'id':id//消息id
};
localStorage[group] = JSON.stringify(localContent);//存储本地;
(3)发送消息的缓存处理:
发送的消息同样以键值对的形式进行存储,同(2),图片文件,则是通过官方提供的方法当发送成功后会有对应的URL返回,即将URL作为数据存入data字段即可。

4、模板:
为控制方便模板写了六套,及左右聊天展示个三套 分别为文本、图片、文件。
 
 

00F7D790-2475-434B-9AEC-B86384B827C7.png


7AC59638-1719-4B4E-9015-461A25D5B039.png


CC744F4E-B6D4-4B4D-9ED9-31BA00AA651B.png

 
 
 

收起阅读 »

android 集成环信 之后apk安装不了,打不开,打开之后就闪退的问题

之前做项目集成的是 环信的sdk ,环信的sdk 确实很好,客服 也很给力。但是在集成的过程中发现,apk 在手机上发布不了,要么就是,安装了 打不开,打开就闪退:问题有一下两方面

1.之前做过一个环信的即时通讯,集成好环信的sdk之后在4.x的手机上就打开就闪退,,只能在5.x和6.x手机上打开app

2.最近又碰到了同样的问题不过这次和上次不一样,这次是因为我的 as升级到了 2.3 之后出现的这个问题..所以经过了两次遇到这个问题今天决定记录一下.


这个问题的处理方法分三部:

1.把Android studio的 instant run给关掉,setting ----- 搜索instant run 如图:

20170330103930974.png


2.然后把as的所有缓存给清楚掉方法:删除build这两个文件

20170330104151895.png


3.clear project 清理一下项目 


20170330104254039.png


然后重新运行项目 :链接http://blog.csdn.net/wangrain1 ... 83976
 
继续阅读 »
之前做项目集成的是 环信的sdk ,环信的sdk 确实很好,客服 也很给力。但是在集成的过程中发现,apk 在手机上发布不了,要么就是,安装了 打不开,打开就闪退:问题有一下两方面

1.之前做过一个环信的即时通讯,集成好环信的sdk之后在4.x的手机上就打开就闪退,,只能在5.x和6.x手机上打开app

2.最近又碰到了同样的问题不过这次和上次不一样,这次是因为我的 as升级到了 2.3 之后出现的这个问题..所以经过了两次遇到这个问题今天决定记录一下.


这个问题的处理方法分三部:

1.把Android studio的 instant run给关掉,setting ----- 搜索instant run 如图:

20170330103930974.png


2.然后把as的所有缓存给清楚掉方法:删除build这两个文件

20170330104151895.png


3.clear project 清理一下项目 


20170330104254039.png


然后重新运行项目 :链接http://blog.csdn.net/wangrain1 ... 83976
  收起阅读 »

基于波特—劳勒综合激励模型对员工激励的几点思考

 
   员工作为企业的重要主体,其工作状态决定了他的工作绩效,员工的工作绩效则决定了企业的产出和绩效,因此员工管理也就成为企业管理者最为关注的问题之一。如何管理好员工并满足其需求、如何有效地激励员工提升其满意度、如何通过激励让员工产出最大化进而提升组织绩效,一直是企业管理者不断探索、力求攻克的难题。

   为此,各大企业都积极推出各种激励手段,包括工资奖金、各种评优评先等员工关怀激励措施,目的是让员工始终保持高效能的工作状态。有些措施取得了很好的成效,有的也会遇到一些瓶颈,比如激励资源虽然投放出去但出现激励措施失衡、激励效果未达到预期等问题,究其原因,可能是缺乏一些系统的激励理论思想的指导所致,以至于在激励的时候出现方法不对或是激励对象不对等情况。激励看似是一种非常有效的手段,但并不是可以泛用或滥用,如何通过激励手段让与员工达到更好的工作绩效,笔者通过对基于波特—劳勒综合激励模型中的一些理论的分享,浅谈个人的一些思考和见解。

一、波特—劳勒综合激励模型的理论指导模式

   波特—劳勒综合激励模型是管理学和组织行为学研究的重要内容之一, 在二十世纪六七十年代,劳勒—波特激励模式的提出确实产生了非常大的影响,直至今天仍有相当的现实意义。它是对激励过程的一个比较恰当的描述,让我们清楚地认识到,激励并不是一个简单的因果关系,不要以为设置了激励目标就一定能获得组织所需要的行动和努力,通过奖励,员工就一定会得到满意,激励是一个复杂的受外界许多因素干扰的循环过程(如图1)。
TIM图片20170714111207.png

   波特和劳勒将得到的奖励分为外在奖励和内在奖励。外在奖励指的是工资、提升、地位、安全感等, 按照马斯洛的需求层次论,它主要是满足一些低层次的需要。内在奖励是指一个人由于工作成绩良好而自己给予的报酬和奖励,如感到完成了一件有意义的工作,对社会做出了贡献等。它对应的是一些高层次需要的满足,与工作成绩直接相关。在本文中,笔者重点分享关于内在奖励的一些思考和建议。

二、基于波特—劳勒综合激励理论的四象限“按需激励”模型

   根据波特—劳勒综合激励模型所描述的内在奖励,跟物质没有直接关系,而更多地是和员工对工作价值和自我认知价值关系紧密,跟工作绩效密切相关,可以说员工对内在奖励越满足,他的内在工作动力就更足,工作绩效就会越好,对公司的贡献就更大。基于这个出发点,在保证员工外在激励的前提下,管理者加大对员工的内在激励,就能更好地激发员工积极性,增强其对工作的价值满足感,进而提升满意度达到个人产出最大化。而每个员工在组织中的工作状态是不一致的,有些员工能力强,但工作意愿稍显不足,有些员工能力不足,但工作意愿很强,有些员工能力强,工作意愿也非常足,而也有员工能力不足,工作意愿也不强……管理者如何做到对不同的员工进行个性化的有效的激励?对此,笔者提出了一个四象限“按需激励”模型(如图2)。
TIM图片20170714111307.png

   根据四象限“按需激励”模型可以看到,该模型强调的是“按需”激励,即根据不同工作状态的员工的激励需求,管理者给予不同的工作激励模式,一方面帮助员工能力成长,更重要的一方面是激发员工的工作价值感,提升工作绩效。

1、推销式激励。这是针对“双低”即低意愿低能力员工的一种激励模式,很多企业内部都不乏这类员工,尤其一些出现职业倦怠、能力一般的老员工,他们需要一种新的能量注入,提升意愿和能力,针对这部分员工管理者可以导入推销式激励,在能力上给予员工工作指导,在工作意愿上给予精神支持,这要求管理者前期对员工倾注更多的精力,包括工作方法上的指导,跟进员工的改善情况,同时对于员工取得的进步及时给予表扬等精神激励。对于“双低”员工,常见的观点是直接放弃,而从对员工负责的角度来讲,管理者还是要先尝试给予员工辅导和提升的机会,通过大量的努力无法让员工提升胜任岗位能力要求,再考虑是否放弃。

2、教练式激励。这是针对高意愿低能力员工的一种激励方式。这部分员工的特征为稳定性好、工作积极、忠诚度高,但工作能力较弱,这部分员工最需要的就是给予方法指导,针对这部分员工管理可以导入教练式激励,采用引导或教练的方式充分激发员工的潜能和能力,帮助员工树立工作目标,密切监督并评估其工作绩效的提升。

3、授权式激励。这是针对“双高”即高意愿高能力员工的一种激励方式。这部分员工通常在企业中是非常受欢迎的员工,表现积极、自律,自我要求高、非常优秀,对企业贡献较大,针对这部分员工,管理者可以采用授权式激励,充分对其进行授权,鼓励他超越自己,并培养为后备管理人才。

4、参与式激励。这是针对低意愿高能力员工的一种激励方式。这部分员工工作能力强,但是意愿不太高,他们对自己工作能力自信,同时希望得到更多的尊重和认同,针对这部分员工,管理可以导入参与式激励,和员工建立充分的信任关系,多给予支持和鼓励,让员工参与一些决策等,激发员工的工作意愿。

   以上是针对四象限“按需激励”模型的具体应用建议,期望通过针对不同员工的激励需求提供相应的激励方式,提升员工的工作价值感,最终通过提升员工满意度来推动组织绩效的提升。从波特—劳勒综合激励模型我们还可以看到,除了外在激励和内在激励是影响员工满意度的因素之外,还有一个调节因素就是“公平感”,即一个人要把自己所得到的报酬与自己认为应该得到的报酬相比较,如果他认为相符,他就会感到满足,并得于激励,以后会更加努力。反之,如果他认为不相符,即使事实上他得到的报酬并不少,但还是会感到不满,甚至沮丧,从而影响他以后的努力。所以企业还要加强对员工感知的关注,营造制度的合理性,双管齐下,员工激励不仅仅是一门科学,更是一门艺术,只有综合运用,多管齐下,才能取得最有效果。

本文刊载于《客户世界》2017年4月刊;本文作者黄清华,作者单位为广东太阳神健康产业有限公司客户联络中心。
继续阅读 »
 
   员工作为企业的重要主体,其工作状态决定了他的工作绩效,员工的工作绩效则决定了企业的产出和绩效,因此员工管理也就成为企业管理者最为关注的问题之一。如何管理好员工并满足其需求、如何有效地激励员工提升其满意度、如何通过激励让员工产出最大化进而提升组织绩效,一直是企业管理者不断探索、力求攻克的难题。

   为此,各大企业都积极推出各种激励手段,包括工资奖金、各种评优评先等员工关怀激励措施,目的是让员工始终保持高效能的工作状态。有些措施取得了很好的成效,有的也会遇到一些瓶颈,比如激励资源虽然投放出去但出现激励措施失衡、激励效果未达到预期等问题,究其原因,可能是缺乏一些系统的激励理论思想的指导所致,以至于在激励的时候出现方法不对或是激励对象不对等情况。激励看似是一种非常有效的手段,但并不是可以泛用或滥用,如何通过激励手段让与员工达到更好的工作绩效,笔者通过对基于波特—劳勒综合激励模型中的一些理论的分享,浅谈个人的一些思考和见解。

一、波特—劳勒综合激励模型的理论指导模式

   波特—劳勒综合激励模型是管理学和组织行为学研究的重要内容之一, 在二十世纪六七十年代,劳勒—波特激励模式的提出确实产生了非常大的影响,直至今天仍有相当的现实意义。它是对激励过程的一个比较恰当的描述,让我们清楚地认识到,激励并不是一个简单的因果关系,不要以为设置了激励目标就一定能获得组织所需要的行动和努力,通过奖励,员工就一定会得到满意,激励是一个复杂的受外界许多因素干扰的循环过程(如图1)。
TIM图片20170714111207.png

   波特和劳勒将得到的奖励分为外在奖励和内在奖励。外在奖励指的是工资、提升、地位、安全感等, 按照马斯洛的需求层次论,它主要是满足一些低层次的需要。内在奖励是指一个人由于工作成绩良好而自己给予的报酬和奖励,如感到完成了一件有意义的工作,对社会做出了贡献等。它对应的是一些高层次需要的满足,与工作成绩直接相关。在本文中,笔者重点分享关于内在奖励的一些思考和建议。

二、基于波特—劳勒综合激励理论的四象限“按需激励”模型

   根据波特—劳勒综合激励模型所描述的内在奖励,跟物质没有直接关系,而更多地是和员工对工作价值和自我认知价值关系紧密,跟工作绩效密切相关,可以说员工对内在奖励越满足,他的内在工作动力就更足,工作绩效就会越好,对公司的贡献就更大。基于这个出发点,在保证员工外在激励的前提下,管理者加大对员工的内在激励,就能更好地激发员工积极性,增强其对工作的价值满足感,进而提升满意度达到个人产出最大化。而每个员工在组织中的工作状态是不一致的,有些员工能力强,但工作意愿稍显不足,有些员工能力不足,但工作意愿很强,有些员工能力强,工作意愿也非常足,而也有员工能力不足,工作意愿也不强……管理者如何做到对不同的员工进行个性化的有效的激励?对此,笔者提出了一个四象限“按需激励”模型(如图2)。
TIM图片20170714111307.png

   根据四象限“按需激励”模型可以看到,该模型强调的是“按需”激励,即根据不同工作状态的员工的激励需求,管理者给予不同的工作激励模式,一方面帮助员工能力成长,更重要的一方面是激发员工的工作价值感,提升工作绩效。

1、推销式激励。这是针对“双低”即低意愿低能力员工的一种激励模式,很多企业内部都不乏这类员工,尤其一些出现职业倦怠、能力一般的老员工,他们需要一种新的能量注入,提升意愿和能力,针对这部分员工管理者可以导入推销式激励,在能力上给予员工工作指导,在工作意愿上给予精神支持,这要求管理者前期对员工倾注更多的精力,包括工作方法上的指导,跟进员工的改善情况,同时对于员工取得的进步及时给予表扬等精神激励。对于“双低”员工,常见的观点是直接放弃,而从对员工负责的角度来讲,管理者还是要先尝试给予员工辅导和提升的机会,通过大量的努力无法让员工提升胜任岗位能力要求,再考虑是否放弃。

2、教练式激励。这是针对高意愿低能力员工的一种激励方式。这部分员工的特征为稳定性好、工作积极、忠诚度高,但工作能力较弱,这部分员工最需要的就是给予方法指导,针对这部分员工管理可以导入教练式激励,采用引导或教练的方式充分激发员工的潜能和能力,帮助员工树立工作目标,密切监督并评估其工作绩效的提升。

3、授权式激励。这是针对“双高”即高意愿高能力员工的一种激励方式。这部分员工通常在企业中是非常受欢迎的员工,表现积极、自律,自我要求高、非常优秀,对企业贡献较大,针对这部分员工,管理者可以采用授权式激励,充分对其进行授权,鼓励他超越自己,并培养为后备管理人才。

4、参与式激励。这是针对低意愿高能力员工的一种激励方式。这部分员工工作能力强,但是意愿不太高,他们对自己工作能力自信,同时希望得到更多的尊重和认同,针对这部分员工,管理可以导入参与式激励,和员工建立充分的信任关系,多给予支持和鼓励,让员工参与一些决策等,激发员工的工作意愿。

   以上是针对四象限“按需激励”模型的具体应用建议,期望通过针对不同员工的激励需求提供相应的激励方式,提升员工的工作价值感,最终通过提升员工满意度来推动组织绩效的提升。从波特—劳勒综合激励模型我们还可以看到,除了外在激励和内在激励是影响员工满意度的因素之外,还有一个调节因素就是“公平感”,即一个人要把自己所得到的报酬与自己认为应该得到的报酬相比较,如果他认为相符,他就会感到满足,并得于激励,以后会更加努力。反之,如果他认为不相符,即使事实上他得到的报酬并不少,但还是会感到不满,甚至沮丧,从而影响他以后的努力。所以企业还要加强对员工感知的关注,营造制度的合理性,双管齐下,员工激励不仅仅是一门科学,更是一门艺术,只有综合运用,多管齐下,才能取得最有效果。

本文刊载于《客户世界》2017年4月刊;本文作者黄清华,作者单位为广东太阳神健康产业有限公司客户联络中心。 收起阅读 »

12张图看懂Gartner《智能客服机器人行业最佳实践》报告

   引言:2016,开启了人工智能(AI)元年,在世界范围内掀起了一轮新的技术和应用革命。由于云计算、大数据、机器学习、深度学习等技术的不断发展进步,伴随着人工红利消失、消费升级、个性化用户体验的刚性需求催化了各种AI应用的快速落地,包括无人驾驶、计算机视觉、智能聊天机器人等人工智能技术慢慢从实验室走进了我们的日常生活。随着2016年Alpha GO打败李世石震惊了世界,人工智能也迎来了一波投资热潮。2016年前三季度全球人工智能行业融资额36.84亿美元,融资交易高达457次。据统计,2015年全球AI市场规模约为484亿元人民币,到2020年,全球AI市场将达到1190亿元人民币规模。

   有科学家大胆预测,在未来几十年人类将创造出具有灵长类动物智能的人工智能系统。但现阶段AI发挥最大生产力更可能是在垂直行业,如无人驾驶、安防、医疗、工业机器人、企业服务等。以企业级服务为例,人工智能已经被企业级软件服务行业视为顶层设计和终极竞争层面,特别是在客户服务行业,智能客服聊天机器人已经展示给世人强大的生产力。

   作为人工智能应用方面的企业级服务先行者,环信CEO刘俊彦认为:“在中国目前的环境,锦上添花的AI功能叫好不叫座,客户缺乏付费意愿。AI只有做到真正替代人工或者完全自动化一个企业的流程,甚至创造出一个全新的更具效率的业务流程,才会有客户大规模买单。”而在客户服务行业,当用户请求接入后,先由智能客服机器人解答80%的常见问题,剩下20%复杂问题再由真人专家客服来回答解决。智能客服机器人创造的整套流程已经完全改变了整个客服行业的劳动力结构和工作方式,正如自动驾驶未来终将彻底改变整个交通出行和汽车制造行业。

   科技和创新进入拐点式爆发,从“互联网+”到后移动互联网时代,再到人工智能的浪潮席卷全球,人工智能与各行业的紧密结合将催生出更多、更大、更接地气的应用场景。互联网作为一个连接器,实现了人与人,人与信息的普世连接,而环信也将借助环信智能客服机器人在新的人工智能时代实现对“人与商业”的重构和深度连接。
智能客服机器人的自我修养【环信版】V1.2---副本---副本_01_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_02_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_03_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_04_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_05_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_06_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_07_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_08_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_09_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_10_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_11_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_12_.png

进入Gartner官网阅读中文版全文
继续阅读 »
   引言:2016,开启了人工智能(AI)元年,在世界范围内掀起了一轮新的技术和应用革命。由于云计算、大数据、机器学习、深度学习等技术的不断发展进步,伴随着人工红利消失、消费升级、个性化用户体验的刚性需求催化了各种AI应用的快速落地,包括无人驾驶、计算机视觉、智能聊天机器人等人工智能技术慢慢从实验室走进了我们的日常生活。随着2016年Alpha GO打败李世石震惊了世界,人工智能也迎来了一波投资热潮。2016年前三季度全球人工智能行业融资额36.84亿美元,融资交易高达457次。据统计,2015年全球AI市场规模约为484亿元人民币,到2020年,全球AI市场将达到1190亿元人民币规模。

   有科学家大胆预测,在未来几十年人类将创造出具有灵长类动物智能的人工智能系统。但现阶段AI发挥最大生产力更可能是在垂直行业,如无人驾驶、安防、医疗、工业机器人、企业服务等。以企业级服务为例,人工智能已经被企业级软件服务行业视为顶层设计和终极竞争层面,特别是在客户服务行业,智能客服聊天机器人已经展示给世人强大的生产力。

   作为人工智能应用方面的企业级服务先行者,环信CEO刘俊彦认为:“在中国目前的环境,锦上添花的AI功能叫好不叫座,客户缺乏付费意愿。AI只有做到真正替代人工或者完全自动化一个企业的流程,甚至创造出一个全新的更具效率的业务流程,才会有客户大规模买单。”而在客户服务行业,当用户请求接入后,先由智能客服机器人解答80%的常见问题,剩下20%复杂问题再由真人专家客服来回答解决。智能客服机器人创造的整套流程已经完全改变了整个客服行业的劳动力结构和工作方式,正如自动驾驶未来终将彻底改变整个交通出行和汽车制造行业。

   科技和创新进入拐点式爆发,从“互联网+”到后移动互联网时代,再到人工智能的浪潮席卷全球,人工智能与各行业的紧密结合将催生出更多、更大、更接地气的应用场景。互联网作为一个连接器,实现了人与人,人与信息的普世连接,而环信也将借助环信智能客服机器人在新的人工智能时代实现对“人与商业”的重构和深度连接。
智能客服机器人的自我修养【环信版】V1.2---副本---副本_01_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_02_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_03_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_04_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_05_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_06_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_07_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_08_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_09_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_10_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_11_.png


智能客服机器人的自我修养【环信版】V1.2---副本---副本_12_.png

进入Gartner官网阅读中文版全文 收起阅读 »

环信移动客服v5.22已发布,自动消息功能助力客户营销

客服如何从成本中心变为营销中心和盈利中心?环信CEC(客户互动云)要把精准营销融入云客服。环信“自动消息”功能通过创建线上的自动消息,可以向APP、网页渠道的目标客户主动推送产品和活动消息,帮助您更好地对您的客户进行营销,将他们留住使用您的产品或服务。

客服模式

支持打印消息记录


支持打印历史会话的消息记录。可将任意一条会话的消息记录打印为PDF或使用打印机打印,消息记录以对话方式呈现,格式清晰,便于文件传递。

在历史会话页面,点击会话进入会话详情页,点击右上方的打印按钮,打印该会话的当前消息记录。如需打印所有消息记录,需要点击“更多历史消息”,将历史消息加载出来后打印。

该功能在客服模式和管理员模式都支持。

支持查看质检评分

支持查看质检员对会话的服务质量给出的质检评分。

在历史会话页面,点击会话进入会话详情页,点击“质检”tab,可以查看质检员对该会话的质检评分。

管理员模式

自动消息

环信移动客服系统推出“自动消息”功能。通过创建线上的自动消息,可以向APP、网页渠道的目标客户主动推送产品和活动消息,帮助您更好地对您的客户进行营销,将他们留住使用您的产品或服务。

“自动消息”有以下特点:
  • 精准筛选目标客户:根据客户的创建时间、标签、客户名称等客户属性进行精准筛选。
  • 预制发送内容和接待者:在设置自动消息时,提前设定好消息内容,并指定接待客户的坐席或技能组。
  • 计划定时发送:支持设置自动消息的持续周期和触发时间点,如中午12:00或凌晨2:00。
  • 发送效果审视:发送后可以随时查看消息发送情况,包括消息发送量、到达终端量、客户打开的数量、客户回复的数量等。


“自动消息”功能为增值服务,如需开通,请提供租户ID并联系环信商务经理。
001.png

“自动消息”使用介绍:1. 创建自动消息。进入“管理员模式 > 自动消息”页面,点击“新建自动消息”按钮,设置自动消息名称、目标客户、消息内容、作用时间,点击“发布按钮”,设置发布时间并发布。
  • 自动消息名称:设置自动消息的名称。
  • 目标客户:根据客户属性筛选自动消息的目标客户。
  • 消息内容:设置自动消息的营销号、接待者、消息内容。营销号将展示在app、网页访客端。
  • 作用时间:设置自动消息的触发时间点。系统在设置的作用时间将自动消息发送给目标客户。
  • 发布时间:设置自定消息的持续周期,系统在该时间范围内按照作用时间将自动消息发送给目标客户。


002.png

2. app、网页访客端展示。自动消息送达访客端后,将展示在聊天窗口中。若客户正在使用网页聊天窗口,会收到如下提醒。  
003.png

注:使用旧版移动客服android/iOS SDK可以收到消息,但统计不到自动消息的打开数、回复数,建议集成最新版移动客服android/iOS SDK。
 
3. 自动消息的发送效果。在自动消息页面,可以查看自动消息的发送效果。
  • 发送数:已发送给客户的自动消息的数量。
  • 到达数:抵达客户使用的访客端的自动消息的数量。
  • 到达率:已到达的自动消息的数量占比。
  • 打开:客户打开的自动消息的数量。
  • 打开率:已打开的自动消息的数量占比。
  • 回复人数:回复自动消息的客户的数量。
  • 回复率:客户回复的自动消息的数量相对于客户打开的自动消息的数量的占比。
    004.png
  •  

 满意度评价邀请设置

新增满意度评价邀请设置页面。原系统开关页面的“会话结束自动发送满意度评价邀请”开关转移至该页面,新增“满意度评价菜单项序号显示为倒序”开关和“评分选项设置”。

满意度评价菜单项序号显示为倒序

在微信、微博等渠道,满意度评价内容是数字型菜单,序号顺序默认为正序。打开开关时,菜单的序号顺序为倒序。

评分选项设置

满意度评分选项,允许自定义星级对应的文字提示,支持为星级添加标签。
005.png

访客端:
若设置评分选项的文字提示和标签,访客端收到评价邀请后,选择满意度评分,需要再次选择标签。

注:微信、微博端支持显示设置的文字提示和标签;app、网页访客端暂时不支持。

客服可以手动发起会话邀请开关

优化“客服主动发起会话”功能。新增“网页端访客访问页面时,客服可以手动发送会话邀请”开关,并支持设置默认消息内容。

“客服主动发起会话”功能为增值服务。开通该增值服务,并打开此开关后,客服可以在“待接入”页面的“正在访问”页签主动向网页渠道的访客发送邀请。邀请送达后,网页端弹窗提醒访客。
006.png

访客端示例:
007.png

支持设置工单帮助主题、优先级、事件推送

支持自定义工单帮助主题、工单优先级,配置工单事件推送。
  • 帮助主题为工单的类别。进入“管理员模式 > 工单 > 工单帮助主题自定义”页面,可以自定义帮助主题选项。
  • 优先级用于标记工单的紧急或重要程度。进入“管理员模式 > 工单 > 工单优先级自定义”页面,可以自定义优先级选项。
  • 事件推送用于将工单相关的数据推送至第三方服务器。进入“管理员模式 > 工单 > 工单事件推送配置”页面,填写第三方服务器的URL地址和token,并启用工单事件推送功能。


注:工单功能为增值服务。使用前,请先在“管理员模式 > 工单 > 申请工单”页面申请开通该功能。

【优化】历史会话页面记录会话过程

历史会话的详情页记录会话过程,包括会话接起、会话转接、会话结束的操作人和发生时间。这些信息显示在“记录”tab页签。

【优化】质量检查的筛选项支持多选

质量检查页面的筛选项(渠道、关联、参与客服)支持多选,方便质检员从不同纬度筛选需要进行质检的会话。

【优化】工作量、工作质量导出报表包含客服账号

工作量、工作质量页面的导出报表增加客服账号,客服账号为客服的登录邮箱地址。

多租户管理后台

多租户管理后台增加以下新功能、优化。

管理员的权限

多租户管理员权限分为普通管理员和超级管理员。
  • 普通管理员:可以查看管理员、租户、统计、设置等页面的相关信息,并导出历史会话、统计数据。仅能够对租户进行管理,包括添加、删除租户等。
  • 超级管理员:拥有普通管理员的所有权限,并且可以创建、删除其他管理员,设置多租户的基本信息、坐席分配、租户模版、单点登录等。


租户成员信息

租户详情页新增成员信息,显示该租户的所有管理员、坐席,以及账号名称、创建时间、在线状态、在线时长等。

坐席分配

新增坐席分配功能,允许超级管理员根据各个租户的实际坐席数,对租户的最大坐席数进行重新分配,优化资源配置。

进入“设置 > 基本信息”页面,点击“坐席分配”按钮,可以重新分配租户的最大坐席数。

单点登录

新增单点登录功能,允许为多租户管理平台的租户设置指向第三方系统的登录URL,坐席使用该第三方系统的账号登录后,可以直接进入客服系统。

移动客服Android SDK

当前版本:V1.0.8

新功能:
  • 支持自动消息的统计上报
  • 支持Google GCM推送
  • 支持显示待接入正在排队人数(增值服务)
  • 支持显示客服的输入状态(增值服务)


移动客服iOS SDK

当前版本:V1.1.2

新功能:
  • 支持自动消息的统计上报


网页插件

当前版本:V47.13.1

新功能:
  • 支持自动消息的统计上报


改进:
  • 客服头像显示在聊天窗口左侧
  • 线上标准版本全面支持移动端

 
环信移动客服更新日志http://docs.easemob.com/cs/releasenote/5.22

环信移动客服登陆地址http://kefu.easemob.com/  
继续阅读 »
客服如何从成本中心变为营销中心和盈利中心?环信CEC(客户互动云)要把精准营销融入云客服。环信“自动消息”功能通过创建线上的自动消息,可以向APP、网页渠道的目标客户主动推送产品和活动消息,帮助您更好地对您的客户进行营销,将他们留住使用您的产品或服务。

客服模式

支持打印消息记录


支持打印历史会话的消息记录。可将任意一条会话的消息记录打印为PDF或使用打印机打印,消息记录以对话方式呈现,格式清晰,便于文件传递。

在历史会话页面,点击会话进入会话详情页,点击右上方的打印按钮,打印该会话的当前消息记录。如需打印所有消息记录,需要点击“更多历史消息”,将历史消息加载出来后打印。

该功能在客服模式和管理员模式都支持。

支持查看质检评分

支持查看质检员对会话的服务质量给出的质检评分。

在历史会话页面,点击会话进入会话详情页,点击“质检”tab,可以查看质检员对该会话的质检评分。

管理员模式

自动消息

环信移动客服系统推出“自动消息”功能。通过创建线上的自动消息,可以向APP、网页渠道的目标客户主动推送产品和活动消息,帮助您更好地对您的客户进行营销,将他们留住使用您的产品或服务。

“自动消息”有以下特点:
  • 精准筛选目标客户:根据客户的创建时间、标签、客户名称等客户属性进行精准筛选。
  • 预制发送内容和接待者:在设置自动消息时,提前设定好消息内容,并指定接待客户的坐席或技能组。
  • 计划定时发送:支持设置自动消息的持续周期和触发时间点,如中午12:00或凌晨2:00。
  • 发送效果审视:发送后可以随时查看消息发送情况,包括消息发送量、到达终端量、客户打开的数量、客户回复的数量等。


“自动消息”功能为增值服务,如需开通,请提供租户ID并联系环信商务经理。
001.png

“自动消息”使用介绍:1. 创建自动消息。进入“管理员模式 > 自动消息”页面,点击“新建自动消息”按钮,设置自动消息名称、目标客户、消息内容、作用时间,点击“发布按钮”,设置发布时间并发布。
  • 自动消息名称:设置自动消息的名称。
  • 目标客户:根据客户属性筛选自动消息的目标客户。
  • 消息内容:设置自动消息的营销号、接待者、消息内容。营销号将展示在app、网页访客端。
  • 作用时间:设置自动消息的触发时间点。系统在设置的作用时间将自动消息发送给目标客户。
  • 发布时间:设置自定消息的持续周期,系统在该时间范围内按照作用时间将自动消息发送给目标客户。


002.png

2. app、网页访客端展示。自动消息送达访客端后,将展示在聊天窗口中。若客户正在使用网页聊天窗口,会收到如下提醒。  
003.png

注:使用旧版移动客服android/iOS SDK可以收到消息,但统计不到自动消息的打开数、回复数,建议集成最新版移动客服android/iOS SDK。
 
3. 自动消息的发送效果。在自动消息页面,可以查看自动消息的发送效果。
  • 发送数:已发送给客户的自动消息的数量。
  • 到达数:抵达客户使用的访客端的自动消息的数量。
  • 到达率:已到达的自动消息的数量占比。
  • 打开:客户打开的自动消息的数量。
  • 打开率:已打开的自动消息的数量占比。
  • 回复人数:回复自动消息的客户的数量。
  • 回复率:客户回复的自动消息的数量相对于客户打开的自动消息的数量的占比。
    004.png
  •  

 满意度评价邀请设置

新增满意度评价邀请设置页面。原系统开关页面的“会话结束自动发送满意度评价邀请”开关转移至该页面,新增“满意度评价菜单项序号显示为倒序”开关和“评分选项设置”。

满意度评价菜单项序号显示为倒序

在微信、微博等渠道,满意度评价内容是数字型菜单,序号顺序默认为正序。打开开关时,菜单的序号顺序为倒序。

评分选项设置

满意度评分选项,允许自定义星级对应的文字提示,支持为星级添加标签。
005.png

访客端:
若设置评分选项的文字提示和标签,访客端收到评价邀请后,选择满意度评分,需要再次选择标签。

注:微信、微博端支持显示设置的文字提示和标签;app、网页访客端暂时不支持。

客服可以手动发起会话邀请开关

优化“客服主动发起会话”功能。新增“网页端访客访问页面时,客服可以手动发送会话邀请”开关,并支持设置默认消息内容。

“客服主动发起会话”功能为增值服务。开通该增值服务,并打开此开关后,客服可以在“待接入”页面的“正在访问”页签主动向网页渠道的访客发送邀请。邀请送达后,网页端弹窗提醒访客。
006.png

访客端示例:
007.png

支持设置工单帮助主题、优先级、事件推送

支持自定义工单帮助主题、工单优先级,配置工单事件推送。
  • 帮助主题为工单的类别。进入“管理员模式 > 工单 > 工单帮助主题自定义”页面,可以自定义帮助主题选项。
  • 优先级用于标记工单的紧急或重要程度。进入“管理员模式 > 工单 > 工单优先级自定义”页面,可以自定义优先级选项。
  • 事件推送用于将工单相关的数据推送至第三方服务器。进入“管理员模式 > 工单 > 工单事件推送配置”页面,填写第三方服务器的URL地址和token,并启用工单事件推送功能。


注:工单功能为增值服务。使用前,请先在“管理员模式 > 工单 > 申请工单”页面申请开通该功能。

【优化】历史会话页面记录会话过程

历史会话的详情页记录会话过程,包括会话接起、会话转接、会话结束的操作人和发生时间。这些信息显示在“记录”tab页签。

【优化】质量检查的筛选项支持多选

质量检查页面的筛选项(渠道、关联、参与客服)支持多选,方便质检员从不同纬度筛选需要进行质检的会话。

【优化】工作量、工作质量导出报表包含客服账号

工作量、工作质量页面的导出报表增加客服账号,客服账号为客服的登录邮箱地址。

多租户管理后台

多租户管理后台增加以下新功能、优化。

管理员的权限

多租户管理员权限分为普通管理员和超级管理员。
  • 普通管理员:可以查看管理员、租户、统计、设置等页面的相关信息,并导出历史会话、统计数据。仅能够对租户进行管理,包括添加、删除租户等。
  • 超级管理员:拥有普通管理员的所有权限,并且可以创建、删除其他管理员,设置多租户的基本信息、坐席分配、租户模版、单点登录等。


租户成员信息

租户详情页新增成员信息,显示该租户的所有管理员、坐席,以及账号名称、创建时间、在线状态、在线时长等。

坐席分配

新增坐席分配功能,允许超级管理员根据各个租户的实际坐席数,对租户的最大坐席数进行重新分配,优化资源配置。

进入“设置 > 基本信息”页面,点击“坐席分配”按钮,可以重新分配租户的最大坐席数。

单点登录

新增单点登录功能,允许为多租户管理平台的租户设置指向第三方系统的登录URL,坐席使用该第三方系统的账号登录后,可以直接进入客服系统。

移动客服Android SDK

当前版本:V1.0.8

新功能:
  • 支持自动消息的统计上报
  • 支持Google GCM推送
  • 支持显示待接入正在排队人数(增值服务)
  • 支持显示客服的输入状态(增值服务)


移动客服iOS SDK

当前版本:V1.1.2

新功能:
  • 支持自动消息的统计上报


网页插件

当前版本:V47.13.1

新功能:
  • 支持自动消息的统计上报


改进:
  • 客服头像显示在聊天窗口左侧
  • 线上标准版本全面支持移动端

 
环信移动客服更新日志http://docs.easemob.com/cs/releasenote/5.22

环信移动客服登陆地址http://kefu.easemob.com/   收起阅读 »

TIOBE 7月编程语言排行榜:Go语言飙升至前十 Java暴跌


微信图片_20170712153712.jpg

来源丨TIOBE
 
翻译丨苗稳
 
   从前几月的排行榜来看,Go语言在今年一路飙升,终于在这个月进入前十名。此外,新兴语言Kotlin、Elixir和Hack在本月并没有太大的进步,Kotlin和Elixir同时下跌了5名,Hack下跌了6名,Elixir再次失去进入50名的机会。

   之前,七牛云许式伟曾说过Go语言会取代Java,从目前来看,Go语言正在朝这一目标迈进,那么它是否会一直保持上升势头,紧跟在JavaScript和Python等明星语言之后吗?让我们拭目以待。

TOP 20编程语言排行榜

微信图片_20170712153754.jpg

TOP 10编程语言指数走势
微信图片_20170712153813.jpg

21-50名编程语言排名
微信图片_20170712153829.jpg

第51到100名编程语言排行如下,由于它们之间的数值差异较小,不做先后排名:

 (Visual) FoxPro, ABC, ActionScript, APL, AutoLISP, bc, Bourne shell, C shell, CFML, CL (OS/400), Clipper, Clojure, Common Lisp, Crystal, Elixir, Elm, Emacs Lisp, Factor, Forth, Icon, IDL, Inform, Io, J, Korn shell, Magic, Maple, ML, MUMPS, NATURAL, NXT-G, OpenCL, OpenEdge ABL, Oz, PL/I, PowerShell, Q, REXX, Ring, S, Smalltalk, SPARK, SPSS, Standard ML, Stata, Tcl, VBScript, Verilog, VHDL, Wolfram


历史排名(1987-2017)

以下排名取自于12个月的平均值。
微信图片_20170712153900.jpg

年度编程语言

年度编程语言是授予一年中评分最高的编程语言:
微信图片_20170712153916.jpg

【说明】TIOBE 编程语言社区排行榜是编程语言流行趋势的一个指标,每月更新,这份排行榜排名基于互联网上有经验的程序员、课程和第三方厂商的数量。排名使用著名的搜索引擎(诸如 Google、MSN、Yahoo!、Wikipedia、YouTube 以及 Baidu 等)进行计算。




请注意这个排行榜只是反映某个编程语言的热门程度,并不能说明一门编程语言好不好,或者一门语言所编写的代码数量多少。

这个排行榜可以用来考查你的编程技能是否与时俱进,也可以在开发新系统时作为一个语言选择依据。

排行榜的详细定义可以参考这里:https://www.tiobe.com/tiobe-index/
 
继续阅读 »

微信图片_20170712153712.jpg

来源丨TIOBE
 
翻译丨苗稳
 
   从前几月的排行榜来看,Go语言在今年一路飙升,终于在这个月进入前十名。此外,新兴语言Kotlin、Elixir和Hack在本月并没有太大的进步,Kotlin和Elixir同时下跌了5名,Hack下跌了6名,Elixir再次失去进入50名的机会。

   之前,七牛云许式伟曾说过Go语言会取代Java,从目前来看,Go语言正在朝这一目标迈进,那么它是否会一直保持上升势头,紧跟在JavaScript和Python等明星语言之后吗?让我们拭目以待。

TOP 20编程语言排行榜

微信图片_20170712153754.jpg

TOP 10编程语言指数走势
微信图片_20170712153813.jpg

21-50名编程语言排名
微信图片_20170712153829.jpg

第51到100名编程语言排行如下,由于它们之间的数值差异较小,不做先后排名:

 (Visual) FoxPro, ABC, ActionScript, APL, AutoLISP, bc, Bourne shell, C shell, CFML, CL (OS/400), Clipper, Clojure, Common Lisp, Crystal, Elixir, Elm, Emacs Lisp, Factor, Forth, Icon, IDL, Inform, Io, J, Korn shell, Magic, Maple, ML, MUMPS, NATURAL, NXT-G, OpenCL, OpenEdge ABL, Oz, PL/I, PowerShell, Q, REXX, Ring, S, Smalltalk, SPARK, SPSS, Standard ML, Stata, Tcl, VBScript, Verilog, VHDL, Wolfram


历史排名(1987-2017)

以下排名取自于12个月的平均值。
微信图片_20170712153900.jpg

年度编程语言

年度编程语言是授予一年中评分最高的编程语言:
微信图片_20170712153916.jpg

【说明】TIOBE 编程语言社区排行榜是编程语言流行趋势的一个指标,每月更新,这份排行榜排名基于互联网上有经验的程序员、课程和第三方厂商的数量。排名使用著名的搜索引擎(诸如 Google、MSN、Yahoo!、Wikipedia、YouTube 以及 Baidu 等)进行计算。




请注意这个排行榜只是反映某个编程语言的热门程度,并不能说明一门编程语言好不好,或者一门语言所编写的代码数量多少。

这个排行榜可以用来考查你的编程技能是否与时俱进,也可以在开发新系统时作为一个语言选择依据。

排行榜的详细定义可以参考这里:https://www.tiobe.com/tiobe-index/
  收起阅读 »

七大有效的编程习惯助你成为更好的程序员


TIM图片20170712152139.png

作者 | Bartlomiej Karalus

翻译 | 雨言

编程能力和水平固然重要,但如果具备良好的编程习惯,往往也能帮助你事半功倍。本文作者通过切身经验,分享了七个有效的编程习惯,希望对大家有所帮助。


    最近在读一些不错的关于习惯养成的书籍,读完之后,备受启迪,于是,我开始反省自己目前的各种习惯,其中有一些就是平时日常生活中的习惯,也有一些仅仅与工作有关,说到工作,就不得不说一下编程习惯了,我很乐意与大家分享我的编程习惯。

随时随地“Ctrl+S”

   这是我多年来一直坚持的一个习惯,尽管现在很多新的IDE甚至不需要手动保存,可以自动保存,但我还是会在代码结束的最后一行不由自主地按下组合键“Ctrl+S”,如果我没记错的话,每次只要我敲键盘一停下来我就会“Ctrl+S”,但奇怪的是,这个“Ctrl+S”实际上比我同事脸上的笑容更能节省我一天的时间。

定期释放大脑内存

   有的程序猿说长时间敲代码让他们感觉像是到了天堂一样飘飘欲仙,感觉棒极了,这在我看来是一种“狂暴模式”,短期内可能确实让人感觉良好,但随后你将需要花费大量的时间进行自我修复。所以说,短时间内的头脑风暴是可以的,但是要适时地停下来歇会儿,头脑风暴太久实际上会让你思维迟钝,容易钻死胡同。

确保排除一切干扰

   当我专注于一件非常重要的事情时,我会把手机关机,避免社交媒体或任何不必要的媒体的干扰,当然,听点音乐还是可以的。不过话又说回来,还是需要采用健康一点的方式。如果你有小孩,你又需要非常专注于工作,为了不被打扰,把他们关在地下室听起来好像还不错,但是从长远来看,这并不是一个好的解决办法。

以终为始

   有人说,可视化的力量无与伦比,它可以帮助我们确定今天的目标,最后在一天结束时减少或消除沮丧和失望等负面情绪。所以,不论什么时候,一定要清楚自己到底想要做什么。这听起来似乎很显而易见,也很容易做到,但实际操作过程中,这个步骤往往经常被忽略。

定期培训

   我有一个很好的习惯就是定期培训,当然去健身房也是一个好习惯,这种情况下,我更关心的是一个人的实际编程能力。我热衷于通过即兴编程训练来让我的思维保持敏锐,这样的训练也许在短期内不会有什么显著的成效,但总有一天会厚积薄发。

从写测试用例开始

   近期最常用的一种模式就是不管写什么代码都先从写测试用例开始,这来源于我早期的一个观点,它帮助我在开始之前就看到了目的地,显然,这让最终呈现出来的结果更加安全可靠,同时还能够设计和记录代码,我意外的是竟然很少有程序猿认同这一观点。
 
切忌“前程规划”

   另一个是我新养成的习惯――避免“前程规划”。以前我也不懂这个道理,总是想一步到位,想一开始就把方方面面都考虑周全,想要覆盖到一切可能的边界的测试用例,甚至想要把我的后代使用时有可能出现的情况也考虑进去。渐渐地,我意识到这样会导致代码基过于复杂,并且耗费大量时间,最常见的结果就是,我的代码完美无瑕同时也一无是处。

   最后,如果你觉得我说的这些有符合你口味的就试试呗!这些对我编程来说确实非常有帮助,但是罗马也不是一天建成的,养成一个习惯最好的办法就是去使用,总有一天你会突然发现,习惯不知不觉已经养成。哈,如果你有一些好的习惯也记得和我分享哦! 
 
本文转自CSDN公众号
继续阅读 »

TIM图片20170712152139.png

作者 | Bartlomiej Karalus

翻译 | 雨言

编程能力和水平固然重要,但如果具备良好的编程习惯,往往也能帮助你事半功倍。本文作者通过切身经验,分享了七个有效的编程习惯,希望对大家有所帮助。


    最近在读一些不错的关于习惯养成的书籍,读完之后,备受启迪,于是,我开始反省自己目前的各种习惯,其中有一些就是平时日常生活中的习惯,也有一些仅仅与工作有关,说到工作,就不得不说一下编程习惯了,我很乐意与大家分享我的编程习惯。

随时随地“Ctrl+S”

   这是我多年来一直坚持的一个习惯,尽管现在很多新的IDE甚至不需要手动保存,可以自动保存,但我还是会在代码结束的最后一行不由自主地按下组合键“Ctrl+S”,如果我没记错的话,每次只要我敲键盘一停下来我就会“Ctrl+S”,但奇怪的是,这个“Ctrl+S”实际上比我同事脸上的笑容更能节省我一天的时间。

定期释放大脑内存

   有的程序猿说长时间敲代码让他们感觉像是到了天堂一样飘飘欲仙,感觉棒极了,这在我看来是一种“狂暴模式”,短期内可能确实让人感觉良好,但随后你将需要花费大量的时间进行自我修复。所以说,短时间内的头脑风暴是可以的,但是要适时地停下来歇会儿,头脑风暴太久实际上会让你思维迟钝,容易钻死胡同。

确保排除一切干扰

   当我专注于一件非常重要的事情时,我会把手机关机,避免社交媒体或任何不必要的媒体的干扰,当然,听点音乐还是可以的。不过话又说回来,还是需要采用健康一点的方式。如果你有小孩,你又需要非常专注于工作,为了不被打扰,把他们关在地下室听起来好像还不错,但是从长远来看,这并不是一个好的解决办法。

以终为始

   有人说,可视化的力量无与伦比,它可以帮助我们确定今天的目标,最后在一天结束时减少或消除沮丧和失望等负面情绪。所以,不论什么时候,一定要清楚自己到底想要做什么。这听起来似乎很显而易见,也很容易做到,但实际操作过程中,这个步骤往往经常被忽略。

定期培训

   我有一个很好的习惯就是定期培训,当然去健身房也是一个好习惯,这种情况下,我更关心的是一个人的实际编程能力。我热衷于通过即兴编程训练来让我的思维保持敏锐,这样的训练也许在短期内不会有什么显著的成效,但总有一天会厚积薄发。

从写测试用例开始

   近期最常用的一种模式就是不管写什么代码都先从写测试用例开始,这来源于我早期的一个观点,它帮助我在开始之前就看到了目的地,显然,这让最终呈现出来的结果更加安全可靠,同时还能够设计和记录代码,我意外的是竟然很少有程序猿认同这一观点。
 
切忌“前程规划”

   另一个是我新养成的习惯――避免“前程规划”。以前我也不懂这个道理,总是想一步到位,想一开始就把方方面面都考虑周全,想要覆盖到一切可能的边界的测试用例,甚至想要把我的后代使用时有可能出现的情况也考虑进去。渐渐地,我意识到这样会导致代码基过于复杂,并且耗费大量时间,最常见的结果就是,我的代码完美无瑕同时也一无是处。

   最后,如果你觉得我说的这些有符合你口味的就试试呗!这些对我编程来说确实非常有帮助,但是罗马也不是一天建成的,养成一个习惯最好的办法就是去使用,总有一天你会突然发现,习惯不知不觉已经养成。哈,如果你有一些好的习惯也记得和我分享哦! 
 
本文转自CSDN公众号 收起阅读 »

超越Twitter,老哥,稳!环信助力新浪微博深度连接“人与商业”

(本文共1766个字,不信你数一数,阅读完需三分钟,不信你试试)
 
   微信渐老,微博逢春。就在大家认为微博没落的时候,新浪微博用月活用户数、收入、股票暴涨,一波“还有这种操作”的方式引领进入社交媒体下半场。据公开数据显示,截至3月31日,微博月活跃用户达3.4亿(其中91%为移动端用户),已超过Twitter成为全球用户规模最大的独立社交媒体公司。得益于用户规模的持续扩大和内容生态的不断完善,微博的商业化继续保持快速增长。财报显示,一季度微博总营收达到13.7亿元,同比增长76%,其中广告营收达到11.7亿元,同比增长80%。
 
 与此相关,微博商业化开放2年多来,为企业带来了品牌曝光、变现转化等机会,然而随着大量咨询需求的涌入,客户沟通成本同时不断变高。如何帮助微博平台用户与粉丝/客户更好地沟通,做更好的商业连接,成为了微博亟需解决的问题,也成为了环信与新浪微博合作的契机。
TIM图片20170712111933.png

    无论对于企业蓝V用户还是个人橙V用户来说,当运营到增长或成熟阶段并且粉丝消息量达到一定规模后,普遍会出现以下这些问题:

   1,消息量增长蹭蹭的,客服小助手忙不过来。很多时候这事儿不是增加几个客服小妹就能解决的,哪怕是一个账号的大量消息,就算多人伺候解决了一部分接待数量问题,但没有好的分配机制,也有可能出现回复互相撞车的情况。

   2,手上有多个账号要管理,来回切换效率低下。尤其对于微博平台的企业用户来说,很可能一家企业会运营多个微博蓝V账号,但回复私信、评论、@时需要来回换账号,甚是麻烦,更不用提可能还需要维护微博以外的其他渠道如微信、官网的互动。

   3,撩了半天好不容易有意向转化成交,跟进却不及时流失了。不少企业运营微博是有转化商机的目的,通过微博沟通后,客服小妹发现潜在商机线索时,需要销售同事进一步跟进沟通,但转接消息不方便,只能要么一个人都负起责任服务同时引导购买,要么得共用账号你聊完毕我来聊;

   针对这些问题,为了帮助微博用户更好地做连接做服务,新浪微博采用了更高级的粉服开发者模式,但需要企业自身具备较高的开发能力,很多企业尤其是中小企业无法HOLD住这种方式,当新浪微博寻找更便捷优质的解决方案时,环信基于在全媒体智能云客服领域的积累和沉淀恰好满足了这样的需求,双方一拍即合拉开了深度合作的序幕。

   环信为新浪推出的多客服系统在微博平台正式上线以来,截止2017年2月,已经有2200家企业注册试用多客服系统,开通坐席累积4000+,共关联938个微博账号,平均一周的会话量达26000条、独立访客数达20000+,帮助注册用户接待历史会话35W条,接待27.2W访客。第一期使用效果较好的企业分布在电商、3C数码、快递、婚纱摄影等行业。

   微博与环信联合推出这套多客服系统,是为了更好地连接人与商业,帮助基于微博的用户更快地成长和成功,为企业和微博大V节能增效附加了更强的客户服务沟通能力:

   1、 降低开发门槛,无缝接入大量信息。开通账号即用,信息进入多客服系统后可以实现智能分配,通过路由设置的熟客优先、空闲率等原则,分配给最合适的客服接待。同时可以根据问题类型、咨询兴趣、商机程度的不同直接对应不同的技能组直接服务,避免等待和流失。

TIM图片20170712112117.png

   2、 统一平台管理账号矩阵。涉及到一家企业或一个运营方需要维护多个账号的情况,可以统一绑定到一套系统中,免去来回切换之苦,统一管理所有消息。

   3、 多渠道接入,不止于微博。对于微博客服渠道,除了天然能获取到的评论、私信、@等消息,更将消息范围扩展到订阅评论、评论中@等。除了微博渠道,企业的其他客服入口如微信、官网、H5等消息也可以一并接入环信多客服系统。
1.png

 4、支持用户画像,帮你更了解TA。不仅能够帮助你获取到非粉丝用户信息及基于昵称的用户UID,还可以结合用户轨迹、行为、互动记录等手动打标签,丰富用户画像,应用到自身业务场景中,更有针对性地记录客户偏好并与客户进行沟通。
2.png

3.png

 多客服系统入口:管理中心—粉丝服务—多客服系统
 
   新浪微博首席执行官王高飞表示:“微博专注于提供中国最好的社交媒体服务,促成了微博强劲的第一季度业绩。展望未来,我们预计将继续保持强劲增长势头,将和合作伙伴进一步优化微博分享、发现和消费信息的竞争力,特别是在移动、社交和视频的场景中。”

   融入了环信移动智能多客服能力的新浪微博平台,秉承的是更加开放、更加精细的商业平台生态构建原则,不仅仅是对商业成功的追求,更是希望致力于提升用户体验,以客户为先,帮助客户成功。
 
点击查看微博多客服系统攻略
 
继续阅读 »
(本文共1766个字,不信你数一数,阅读完需三分钟,不信你试试)
 
   微信渐老,微博逢春。就在大家认为微博没落的时候,新浪微博用月活用户数、收入、股票暴涨,一波“还有这种操作”的方式引领进入社交媒体下半场。据公开数据显示,截至3月31日,微博月活跃用户达3.4亿(其中91%为移动端用户),已超过Twitter成为全球用户规模最大的独立社交媒体公司。得益于用户规模的持续扩大和内容生态的不断完善,微博的商业化继续保持快速增长。财报显示,一季度微博总营收达到13.7亿元,同比增长76%,其中广告营收达到11.7亿元,同比增长80%。
 
 与此相关,微博商业化开放2年多来,为企业带来了品牌曝光、变现转化等机会,然而随着大量咨询需求的涌入,客户沟通成本同时不断变高。如何帮助微博平台用户与粉丝/客户更好地沟通,做更好的商业连接,成为了微博亟需解决的问题,也成为了环信与新浪微博合作的契机。
TIM图片20170712111933.png

    无论对于企业蓝V用户还是个人橙V用户来说,当运营到增长或成熟阶段并且粉丝消息量达到一定规模后,普遍会出现以下这些问题:

   1,消息量增长蹭蹭的,客服小助手忙不过来。很多时候这事儿不是增加几个客服小妹就能解决的,哪怕是一个账号的大量消息,就算多人伺候解决了一部分接待数量问题,但没有好的分配机制,也有可能出现回复互相撞车的情况。

   2,手上有多个账号要管理,来回切换效率低下。尤其对于微博平台的企业用户来说,很可能一家企业会运营多个微博蓝V账号,但回复私信、评论、@时需要来回换账号,甚是麻烦,更不用提可能还需要维护微博以外的其他渠道如微信、官网的互动。

   3,撩了半天好不容易有意向转化成交,跟进却不及时流失了。不少企业运营微博是有转化商机的目的,通过微博沟通后,客服小妹发现潜在商机线索时,需要销售同事进一步跟进沟通,但转接消息不方便,只能要么一个人都负起责任服务同时引导购买,要么得共用账号你聊完毕我来聊;

   针对这些问题,为了帮助微博用户更好地做连接做服务,新浪微博采用了更高级的粉服开发者模式,但需要企业自身具备较高的开发能力,很多企业尤其是中小企业无法HOLD住这种方式,当新浪微博寻找更便捷优质的解决方案时,环信基于在全媒体智能云客服领域的积累和沉淀恰好满足了这样的需求,双方一拍即合拉开了深度合作的序幕。

   环信为新浪推出的多客服系统在微博平台正式上线以来,截止2017年2月,已经有2200家企业注册试用多客服系统,开通坐席累积4000+,共关联938个微博账号,平均一周的会话量达26000条、独立访客数达20000+,帮助注册用户接待历史会话35W条,接待27.2W访客。第一期使用效果较好的企业分布在电商、3C数码、快递、婚纱摄影等行业。

   微博与环信联合推出这套多客服系统,是为了更好地连接人与商业,帮助基于微博的用户更快地成长和成功,为企业和微博大V节能增效附加了更强的客户服务沟通能力:

   1、 降低开发门槛,无缝接入大量信息。开通账号即用,信息进入多客服系统后可以实现智能分配,通过路由设置的熟客优先、空闲率等原则,分配给最合适的客服接待。同时可以根据问题类型、咨询兴趣、商机程度的不同直接对应不同的技能组直接服务,避免等待和流失。

TIM图片20170712112117.png

   2、 统一平台管理账号矩阵。涉及到一家企业或一个运营方需要维护多个账号的情况,可以统一绑定到一套系统中,免去来回切换之苦,统一管理所有消息。

   3、 多渠道接入,不止于微博。对于微博客服渠道,除了天然能获取到的评论、私信、@等消息,更将消息范围扩展到订阅评论、评论中@等。除了微博渠道,企业的其他客服入口如微信、官网、H5等消息也可以一并接入环信多客服系统。
1.png

 4、支持用户画像,帮你更了解TA。不仅能够帮助你获取到非粉丝用户信息及基于昵称的用户UID,还可以结合用户轨迹、行为、互动记录等手动打标签,丰富用户画像,应用到自身业务场景中,更有针对性地记录客户偏好并与客户进行沟通。
2.png

3.png

 多客服系统入口:管理中心—粉丝服务—多客服系统
 
   新浪微博首席执行官王高飞表示:“微博专注于提供中国最好的社交媒体服务,促成了微博强劲的第一季度业绩。展望未来,我们预计将继续保持强劲增长势头,将和合作伙伴进一步优化微博分享、发现和消费信息的竞争力,特别是在移动、社交和视频的场景中。”

   融入了环信移动智能多客服能力的新浪微博平台,秉承的是更加开放、更加精细的商业平台生态构建原则,不仅仅是对商业成功的追求,更是希望致力于提升用户体验,以客户为先,帮助客户成功。
 
点击查看微博多客服系统攻略
  收起阅读 »

【环信征文】Android 开发之应届狗从掉洞到填坑之路

在开发了几个项目之后我决定写篇文章分享一下一路走来的经验教训。
一、在开发中的话慢慢你会理解(如果觉得专业知识警示不想看可看本人写的二部分一点感悟,颇为精彩!希望给予你收获,嘿嘿!)
1.好代码像好的段子,不需要多余的解释。如果你的代码是不解自明的,那么大多数情况下,它并不需要注释和文档。
在使用任何第三方库之前都要三思,这件事非常严肃,别人不维护了怎么办,突然改别的需求了又咋办,自己没进步不知道原理咋办,是不是觉得自己要亲力亲为呢,如果学习了别人的原理去使用,对自己是一大突破,那天自己也能封装个呢,嘿嘿。
212e000206a62a09af6b.jpg


2.除非必须,不要使用数据库。2017再多不过发生的几大事情中,很多都是从删除到跑路,当让前提要自己跑的安全。脱得干净,会丢锅。但是你可以尝试使用realm(第三方数据库),这个真的不错。项目很快就会达到65k方法,真的很快,此时可以求助Multidex。

E84ACF8A154B2E51DE9543662FF3F608.gif


3.RxJava是AsyncTask的最佳替代,而且它远不止于此,此前一个月一直在学习,用上了保证你爱不释手,嘿嘿!
Retrofit是最好用的网络库,不要自己写Http客户端,可以用Volley或OkHttp。
附上一个我喜欢的链接,讲的还是比较透彻的:http://blog.chengdazhi.com/index.php/140 
4.使用RetroLambda缩减代码,我能想到人生最cool的事,就是把RxJava、Retrofit和RetroLambda绑在一起。

2016-12-05-cc4709b76a6aa9763528ada82f7406c2.gif


5.EventBus挺好用,但我不会用太多,因为代码会变得很纠结,不过难者不会,难免有大佬喜欢用。

6.通过功能分包,而不是通过层。这样子功能模块会越发的清晰,但是如果有习惯,那请自便。

7.不要在UI线程中执行逻辑代码,不然可能会ANR。作为新手的我遇到过几次,但是后来我学会注意了,希望后人谨慎!

8.使用Lint检查Layout层级可以帮你发现没用的View,兴许可以去掉。

9.使用Gradle以及默认项目结构。

10.把密码与敏感数据放在gradle.properties里。(译者注:或许更好的方式是把这些数据放在local.properties里,然后把这个文件加进.gitignore)

11.使用styles来避免在Layout文件中写重复代码。

12.不要让ViewGroup层级太多。(会过度绘制)

13.监控电量,充电时可以进行更多的数据更新,低电量时停止数据的自动更新。
14.当系统缺少内存(而不是应用缺少内存)时,系统会调用onLowMemory()方法,所以OOM原则上无法避免。这个嘛我遇到的少,但是还是要记住。
15.使用Account Manager来提示登录所需的信息(用户名、邮箱、密码等)。
16.给方法一个明确的命名,要能顾名思义,作为一名新入门选手这个真的很重要,搞不好就不记得这个代码是不是自己写的了,哈哈!
2016-05-21-37ed343e41a53af66bb76242c66d8b5a.jpg


17.启动界面是应用带给用户的第一体验,如果不需要启动界面,那不要无故添加。要不然后果可想而知(有的启动界面太炫酷,导致用户进不去的真是在我身边发生过)。

2016-05-21-3301241d475b43d63fda2b2fb4c29c02.jpg


18.保持colors.xml文件短而简单,只写基本颜色就行。;保持dimens.xml文件简单,之定义基本常量。

19.当要时常修改一个字符串时,使用StringBuffer或StringBuilder(后者不保证线程安全)。

20.为了避免内存泄露,不要在AsyncCallBack中保留View引用!不要让静态对象持有View引用!

21.最好不要在集合框架中存储View,但你也可以使用WeakHashMap。

22.FlatBuffers是一个高效的跨平台的序列化类库,建议使用,尽管本人没用,但是觉得很好用,学习了一点。

23.Serializable实现起来很方便,但性能是真的差。

在开发过程的注意先说这么多,希望对大家有所帮助。希望给你带来一丝丝感悟,嘿嘿!

二.生活,关于一个应届狗,对实习半年的总结

 转眼间大学生活走到了尽头。人们需要仪式感,所以无论情不情愿,总要和过去的自己诀别一番。尽管你我都知道,毕业后不会是一个更新的自己,只会是一个更老的自己。

2016-01-31-6309d659d99d4f5049577f322e4c8907.gif

只是当你在午夜检点行藏,追忆过去日夜里,回想年初制定的那些计划,有太多的事情值得仔细思量。
csdn是一个让人着迷的地方,人们用各式各样的方式展示他们的博学、美丽和健康(无意给csdn打广告)。环信论坛也是一个讲道理的地方,在这里一切都可以找到方法和经验。所以你看到这里程序员谈笑风生年入百万,健身狂六块腹肌也只一般,营销有秘籍,美容有秘方,屌丝逆袭太简单。好像美腿美颜都不是天生,世上无难事,只要肯登攀。

2016-05-21-3301241d475b43d63fda2b2fb4c29c02.jpg

 
这一切都让人产生错觉。于是我们立下许多flag,仿佛自己也能跟他们一样。
你说自己要瘦成一道闪电,要从130减到120。你办了健身卡,加入夜跑团,心心念念就是自己的计步排行。你每天拍一张照片想见证一个奇迹的诞生。有没有瘦有没有瘦,你特意等了两周才站上体重秤,上面写着61kg。哗,你的三观就此崩塌。你不到一个月就坚持不下去了。该吃吃该喝喝,人生贵在适意过,微胖一点又如何?半年后你忽然想起健身卡上还有几千块钱,心想别浪费了,然后发现健身房烟消云散老板已不知去向,原来的门脸换了主人。老板娘一脸粉饼一脸热情,帅哥美容吗,办个卡吧?
你说未来是互联网的天下,要转行当程序员,上追马化腾下追温赵轮。你买了算法导论和21天精通C++,从谭浩强看到 Bjarne Stroustrup。一入编程深似海,你终于在第20天的时候撑不住了。在此期间你的学习目标从C++、java换成了python,在下载盗版Visual Studio的时候中毒丢失了所有的种子。你备受打击,原来教程里都是骗人的。你打开一个新世界说了句“hello world”,世界回了一句“get out SB”。你灰溜溜地卸载VS,重新装上了最爱用的360软件管家。

2016-05-21-dd4b54f2eb4cc08b5782ec5d02c939c6.jpg



你说要恶补英语提升职场价值,李阳疯后舍你其谁。你下载了沪江英语和哈利波特原版小说,每天在有道上秀出自己羞涩的发音,得到85分的评分。你在地铁上枕头上马桶上背单词。你追随奶爸的脚步刷着书单,最后变成了奶带逛。终于你的哈利波特永远停在了第一章,词汇永远在5000打转,听力就像罗永浩说的听了3000张英文唱片除了fuck什么也没听到。你搞不定任何一个多音节单词的pronunciation,只有第一页的abandon没齿难忘。

17_-_1.webp_.jpg


有人曾经说为什么地铁上都是学英语的而不是其他,因为学英语是失败了也不心疼的。我们已习惯一次次的跳票和失败,有些事你我早已心知肚明。我们都是平凡人,在牛人出没的地方有了自己也优秀的错觉。如果一个人是因为看了环信博客上的知识、经验和见解才开始计划,那么十有八九是坚持不下去的。坚持是种稀缺品。我们能坚持的常常只有平庸。那些能够成功的人,往往早就养成了成功的习惯,不会等到知乎和环信论坛的出现。

哈哈,是了。 这不是生活的真谛,却是一个残酷的真相。我们都是平凡人,平凡到一年的生活真的可以用一句话来总结。因为除了年龄,一切都没有改变。

于是平庸的日子一年一年。我们总会在年初的时候立很多的flag,又在年末的时候亲手拔掉,开始一个新的轮回。

然而,这平凡的一年中有多少刻骨铭心的快乐、痛苦、感动和辛酸,只有我们自己知道。人的命运又怎么能跑过历史的进程,除了他又有谁能永恒?也许我们最终也会甘于平凡,但至少我们努力过挣扎过振奋过。哪怕它唯一的意义只是在夜深人静的时候,被自己感动得热泪盈眶。

2016-11-12-3b4a954ea34d51b3110268ef1cb8a745.gif


一首旧作,聊寄衷肠。

白马秋风塞上,杏花春雨江南。九十还续旧因缘,世事浮云过眼。
理想绝逼是病,节操果断换钱。不当大V好多年,听取呵呵一片。
 
 
 
继续阅读 »
在开发了几个项目之后我决定写篇文章分享一下一路走来的经验教训。
一、在开发中的话慢慢你会理解(如果觉得专业知识警示不想看可看本人写的二部分一点感悟,颇为精彩!希望给予你收获,嘿嘿!)
1.好代码像好的段子,不需要多余的解释。如果你的代码是不解自明的,那么大多数情况下,它并不需要注释和文档。
在使用任何第三方库之前都要三思,这件事非常严肃,别人不维护了怎么办,突然改别的需求了又咋办,自己没进步不知道原理咋办,是不是觉得自己要亲力亲为呢,如果学习了别人的原理去使用,对自己是一大突破,那天自己也能封装个呢,嘿嘿。
212e000206a62a09af6b.jpg


2.除非必须,不要使用数据库。2017再多不过发生的几大事情中,很多都是从删除到跑路,当让前提要自己跑的安全。脱得干净,会丢锅。但是你可以尝试使用realm(第三方数据库),这个真的不错。项目很快就会达到65k方法,真的很快,此时可以求助Multidex。

E84ACF8A154B2E51DE9543662FF3F608.gif


3.RxJava是AsyncTask的最佳替代,而且它远不止于此,此前一个月一直在学习,用上了保证你爱不释手,嘿嘿!
Retrofit是最好用的网络库,不要自己写Http客户端,可以用Volley或OkHttp。
附上一个我喜欢的链接,讲的还是比较透彻的:http://blog.chengdazhi.com/index.php/140 
4.使用RetroLambda缩减代码,我能想到人生最cool的事,就是把RxJava、Retrofit和RetroLambda绑在一起。

2016-12-05-cc4709b76a6aa9763528ada82f7406c2.gif


5.EventBus挺好用,但我不会用太多,因为代码会变得很纠结,不过难者不会,难免有大佬喜欢用。

6.通过功能分包,而不是通过层。这样子功能模块会越发的清晰,但是如果有习惯,那请自便。

7.不要在UI线程中执行逻辑代码,不然可能会ANR。作为新手的我遇到过几次,但是后来我学会注意了,希望后人谨慎!

8.使用Lint检查Layout层级可以帮你发现没用的View,兴许可以去掉。

9.使用Gradle以及默认项目结构。

10.把密码与敏感数据放在gradle.properties里。(译者注:或许更好的方式是把这些数据放在local.properties里,然后把这个文件加进.gitignore)

11.使用styles来避免在Layout文件中写重复代码。

12.不要让ViewGroup层级太多。(会过度绘制)

13.监控电量,充电时可以进行更多的数据更新,低电量时停止数据的自动更新。
14.当系统缺少内存(而不是应用缺少内存)时,系统会调用onLowMemory()方法,所以OOM原则上无法避免。这个嘛我遇到的少,但是还是要记住。
15.使用Account Manager来提示登录所需的信息(用户名、邮箱、密码等)。
16.给方法一个明确的命名,要能顾名思义,作为一名新入门选手这个真的很重要,搞不好就不记得这个代码是不是自己写的了,哈哈!
2016-05-21-37ed343e41a53af66bb76242c66d8b5a.jpg


17.启动界面是应用带给用户的第一体验,如果不需要启动界面,那不要无故添加。要不然后果可想而知(有的启动界面太炫酷,导致用户进不去的真是在我身边发生过)。

2016-05-21-3301241d475b43d63fda2b2fb4c29c02.jpg


18.保持colors.xml文件短而简单,只写基本颜色就行。;保持dimens.xml文件简单,之定义基本常量。

19.当要时常修改一个字符串时,使用StringBuffer或StringBuilder(后者不保证线程安全)。

20.为了避免内存泄露,不要在AsyncCallBack中保留View引用!不要让静态对象持有View引用!

21.最好不要在集合框架中存储View,但你也可以使用WeakHashMap。

22.FlatBuffers是一个高效的跨平台的序列化类库,建议使用,尽管本人没用,但是觉得很好用,学习了一点。

23.Serializable实现起来很方便,但性能是真的差。

在开发过程的注意先说这么多,希望对大家有所帮助。希望给你带来一丝丝感悟,嘿嘿!

二.生活,关于一个应届狗,对实习半年的总结

 转眼间大学生活走到了尽头。人们需要仪式感,所以无论情不情愿,总要和过去的自己诀别一番。尽管你我都知道,毕业后不会是一个更新的自己,只会是一个更老的自己。

2016-01-31-6309d659d99d4f5049577f322e4c8907.gif

只是当你在午夜检点行藏,追忆过去日夜里,回想年初制定的那些计划,有太多的事情值得仔细思量。
csdn是一个让人着迷的地方,人们用各式各样的方式展示他们的博学、美丽和健康(无意给csdn打广告)。环信论坛也是一个讲道理的地方,在这里一切都可以找到方法和经验。所以你看到这里程序员谈笑风生年入百万,健身狂六块腹肌也只一般,营销有秘籍,美容有秘方,屌丝逆袭太简单。好像美腿美颜都不是天生,世上无难事,只要肯登攀。

2016-05-21-3301241d475b43d63fda2b2fb4c29c02.jpg

 
这一切都让人产生错觉。于是我们立下许多flag,仿佛自己也能跟他们一样。
你说自己要瘦成一道闪电,要从130减到120。你办了健身卡,加入夜跑团,心心念念就是自己的计步排行。你每天拍一张照片想见证一个奇迹的诞生。有没有瘦有没有瘦,你特意等了两周才站上体重秤,上面写着61kg。哗,你的三观就此崩塌。你不到一个月就坚持不下去了。该吃吃该喝喝,人生贵在适意过,微胖一点又如何?半年后你忽然想起健身卡上还有几千块钱,心想别浪费了,然后发现健身房烟消云散老板已不知去向,原来的门脸换了主人。老板娘一脸粉饼一脸热情,帅哥美容吗,办个卡吧?
你说未来是互联网的天下,要转行当程序员,上追马化腾下追温赵轮。你买了算法导论和21天精通C++,从谭浩强看到 Bjarne Stroustrup。一入编程深似海,你终于在第20天的时候撑不住了。在此期间你的学习目标从C++、java换成了python,在下载盗版Visual Studio的时候中毒丢失了所有的种子。你备受打击,原来教程里都是骗人的。你打开一个新世界说了句“hello world”,世界回了一句“get out SB”。你灰溜溜地卸载VS,重新装上了最爱用的360软件管家。

2016-05-21-dd4b54f2eb4cc08b5782ec5d02c939c6.jpg



你说要恶补英语提升职场价值,李阳疯后舍你其谁。你下载了沪江英语和哈利波特原版小说,每天在有道上秀出自己羞涩的发音,得到85分的评分。你在地铁上枕头上马桶上背单词。你追随奶爸的脚步刷着书单,最后变成了奶带逛。终于你的哈利波特永远停在了第一章,词汇永远在5000打转,听力就像罗永浩说的听了3000张英文唱片除了fuck什么也没听到。你搞不定任何一个多音节单词的pronunciation,只有第一页的abandon没齿难忘。

17_-_1.webp_.jpg


有人曾经说为什么地铁上都是学英语的而不是其他,因为学英语是失败了也不心疼的。我们已习惯一次次的跳票和失败,有些事你我早已心知肚明。我们都是平凡人,在牛人出没的地方有了自己也优秀的错觉。如果一个人是因为看了环信博客上的知识、经验和见解才开始计划,那么十有八九是坚持不下去的。坚持是种稀缺品。我们能坚持的常常只有平庸。那些能够成功的人,往往早就养成了成功的习惯,不会等到知乎和环信论坛的出现。

哈哈,是了。 这不是生活的真谛,却是一个残酷的真相。我们都是平凡人,平凡到一年的生活真的可以用一句话来总结。因为除了年龄,一切都没有改变。

于是平庸的日子一年一年。我们总会在年初的时候立很多的flag,又在年末的时候亲手拔掉,开始一个新的轮回。

然而,这平凡的一年中有多少刻骨铭心的快乐、痛苦、感动和辛酸,只有我们自己知道。人的命运又怎么能跑过历史的进程,除了他又有谁能永恒?也许我们最终也会甘于平凡,但至少我们努力过挣扎过振奋过。哪怕它唯一的意义只是在夜深人静的时候,被自己感动得热泪盈眶。

2016-11-12-3b4a954ea34d51b3110268ef1cb8a745.gif


一首旧作,聊寄衷肠。

白马秋风塞上,杏花春雨江南。九十还续旧因缘,世事浮云过眼。
理想绝逼是病,节操果断换钱。不当大V好多年,听取呵呵一片。
 
 
  收起阅读 »

环信CEC给保险行业提供全流程客户互动解决方案

   
   2017年7月6-7日以“保险科技,创新保险生态”为主题的中国保险IT应用高峰论坛在北京召开。环信CEC(Customer Engagement Cloud)——全媒体智能客户交互云,基于全球领先的即时通讯云技术,通过人工智能和大数据赋能,在保险行业积累了大量关于移动化承保保全、视频客服车损定险、机器人自助理赔、精准用户画像主动营销等落地经验,提供了从客户互动渠道、到客户服务、再到精准营销的全流程客户互动解决方案,典型用户包括中信证券、泰康在线、中意人寿等。截止2016年底,环信CEC共服务了58541家企业客户,现已覆盖包括保险、证券、银行、电商、教育、O2O等领域的众多标杆企业。
ea790d9dly1fha0pwdxwkj20zk0qomzy.jpg


ea790d9dly1fha0n74k4tj21kw1h7k0a.jpg


ea790d9dly1fha0muqy60j20zg1bqqa2.jpg

 
继续阅读 »
   
   2017年7月6-7日以“保险科技,创新保险生态”为主题的中国保险IT应用高峰论坛在北京召开。环信CEC(Customer Engagement Cloud)——全媒体智能客户交互云,基于全球领先的即时通讯云技术,通过人工智能和大数据赋能,在保险行业积累了大量关于移动化承保保全、视频客服车损定险、机器人自助理赔、精准用户画像主动营销等落地经验,提供了从客户互动渠道、到客户服务、再到精准营销的全流程客户互动解决方案,典型用户包括中信证券、泰康在线、中意人寿等。截止2016年底,环信CEC共服务了58541家企业客户,现已覆盖包括保险、证券、银行、电商、教育、O2O等领域的众多标杆企业。
ea790d9dly1fha0pwdxwkj20zk0qomzy.jpg


ea790d9dly1fha0n74k4tj21kw1h7k0a.jpg


ea790d9dly1fha0muqy60j20zg1bqqa2.jpg

  收起阅读 »

简商沙龙:B2B电商如何玩转在线供应链金融

    B2B电商“春光乍现”,引入金融服务已有基本共识,且条件初步成熟。在线金融的增值服务对平台盈利及生态构建至关重要。

但,尚需解决以下两个问题:

1、B2B电商需要具备哪些能力才能更好地对接在线供应链金融服务?

2、适合B2B电商的在线供应链金融服务应该具有哪些特点和能力?


B2B电商如何玩转在线供应链金融?

本期简商沙龙特地请来前IBM高管、现任国付宝CTO邓明和B2B电商资深从业者、对产业互联网及B2B电商有独到见解的现任1号签联合创始人胥明为您解读,机会难得,仅限30人,快来报名吧! 
微信640x360.jpg

嘉宾介绍

胥明.png

1号签 联合创始人 胥明


胥明,业内资深的产业互联网观察者,对互联网商业模式和B2B垂直电商具有近20年的研究和实践经验,B2B 1.0时代就曾经主持研发过数个大型B2B交易平台,对B2B有独到见解,现任第三方电子签约平台——1号签的联合创始人。

邓明.png

国付宝 CTO 邓明


IT老兵。1999年入职IBM,在GBS部门供职15年。先后涉足电商、银行、电信、石油石化等多个行业。现任国付宝CTO。
活动概况
受众:
B2B电商创始人、联合创始人、VP及高管
B2B垂直媒体负责人、记者、编辑

规模:30人(审核制,凭名片入场,谢绝空降)

价格:80元/位
注:分享到朋友圈后,截图给主办方可免费参与

活动流程:
13:30-14:00 签到+茶歇
14:00-15:00 主题演讲:《彻底的全线上交易闭环,重构B2B未来》
15:00-16:00 主题演讲:《B2B电商的在线供应链金融》
16:00-17:00 互动交流

时间:
2017年7月12日(周三)13:30 - 17:00

地点:
北京泰智会创业空间(丹棱街一号互联网金融中心一层103):地铁10号线海淀黄庄站A2口出,步行5min即到

路线图.PNG

主办方简介
1号签
1号签是国内领先的第三方电子签约平台,可实现合同文件在线签署,以拥有专利技术的线上签约取代现行签约方式,在金融、旅游、B2B、互联网、教育、房地产、物流、人资等行业及政府机构广泛应用,同时提供举证与司法鉴定等法律服务。




国付宝
国付宝信息科技有限公司是由商务部中国国际电子商务中心发起,与海航集团联手组建的,精心打造国有背景独立第三方支付平台。依托国有背景、先进支付技术推出“国付宝”系列电子支付产品,于2011.12.22日正式获得中国人民银行颁发的互联网支付和移动支付业务许可证。经过多年发展,现已成长为具有互联网支付、移动支付、基金支付、跨境支付、和预付卡支付业务的综合金融支付服务平台。
场地简介
泰智会
泰智会是总部设立在北京海淀区的全国创新载体运营商和科技服务商,通过服务企业、产业组织和产业园区,满足企业发展规模提升中的融资、产业落地等各类需求,给产业园区注入生命力,形成完整的产业生态系统,是创新的“产业”孵化体系。泰智会正在北京、深圳、上海、成都、西安、武汉等8个城市和美国纽约落地建设。

微信图片_20170706144123.jpg


场地内部路线.jpg

组织机构​
logo汇总图.jpg

 
PS:活动咨询及市场合作请联系王女士,13501399269(电话及微信)wanghan@enjoysign.com
活动报名:点击报名
继续阅读 »
    B2B电商“春光乍现”,引入金融服务已有基本共识,且条件初步成熟。在线金融的增值服务对平台盈利及生态构建至关重要。

但,尚需解决以下两个问题:

1、B2B电商需要具备哪些能力才能更好地对接在线供应链金融服务?

2、适合B2B电商的在线供应链金融服务应该具有哪些特点和能力?


B2B电商如何玩转在线供应链金融?

本期简商沙龙特地请来前IBM高管、现任国付宝CTO邓明和B2B电商资深从业者、对产业互联网及B2B电商有独到见解的现任1号签联合创始人胥明为您解读,机会难得,仅限30人,快来报名吧! 
微信640x360.jpg

嘉宾介绍

胥明.png

1号签 联合创始人 胥明


胥明,业内资深的产业互联网观察者,对互联网商业模式和B2B垂直电商具有近20年的研究和实践经验,B2B 1.0时代就曾经主持研发过数个大型B2B交易平台,对B2B有独到见解,现任第三方电子签约平台——1号签的联合创始人。

邓明.png

国付宝 CTO 邓明


IT老兵。1999年入职IBM,在GBS部门供职15年。先后涉足电商、银行、电信、石油石化等多个行业。现任国付宝CTO。
活动概况
受众:
B2B电商创始人、联合创始人、VP及高管
B2B垂直媒体负责人、记者、编辑

规模:30人(审核制,凭名片入场,谢绝空降)

价格:80元/位
注:分享到朋友圈后,截图给主办方可免费参与

活动流程:
13:30-14:00 签到+茶歇
14:00-15:00 主题演讲:《彻底的全线上交易闭环,重构B2B未来》
15:00-16:00 主题演讲:《B2B电商的在线供应链金融》
16:00-17:00 互动交流

时间:
2017年7月12日(周三)13:30 - 17:00

地点:
北京泰智会创业空间(丹棱街一号互联网金融中心一层103):地铁10号线海淀黄庄站A2口出,步行5min即到

路线图.PNG

主办方简介
1号签
1号签是国内领先的第三方电子签约平台,可实现合同文件在线签署,以拥有专利技术的线上签约取代现行签约方式,在金融、旅游、B2B、互联网、教育、房地产、物流、人资等行业及政府机构广泛应用,同时提供举证与司法鉴定等法律服务。




国付宝
国付宝信息科技有限公司是由商务部中国国际电子商务中心发起,与海航集团联手组建的,精心打造国有背景独立第三方支付平台。依托国有背景、先进支付技术推出“国付宝”系列电子支付产品,于2011.12.22日正式获得中国人民银行颁发的互联网支付和移动支付业务许可证。经过多年发展,现已成长为具有互联网支付、移动支付、基金支付、跨境支付、和预付卡支付业务的综合金融支付服务平台。
场地简介
泰智会
泰智会是总部设立在北京海淀区的全国创新载体运营商和科技服务商,通过服务企业、产业组织和产业园区,满足企业发展规模提升中的融资、产业落地等各类需求,给产业园区注入生命力,形成完整的产业生态系统,是创新的“产业”孵化体系。泰智会正在北京、深圳、上海、成都、西安、武汉等8个城市和美国纽约落地建设。

微信图片_20170706144123.jpg


场地内部路线.jpg

组织机构​
logo汇总图.jpg

 
PS:活动咨询及市场合作请联系王女士,13501399269(电话及微信)wanghan@enjoysign.com
活动报名:点击报名 收起阅读 »

从传统客服到电商客服管理,需要过几道坎?

    不可否认,电话客服已慢慢没落。究其原因有很多,但主要是成本过高,加上新生代的沟通方式发生了很大的变化。

   逢电商的蓬勃发展,促使在线客服大行其道。传统客服的机会越来越少,新兴行业的发展却越来越迅猛。于是,很多人尝试从传统行业跳到电商行业。

   问题来了,一直从事传统电话客服管理的人,有没可能容易华丽丽转身到电商客服管理?要做怎样的积累?
 
从我经验看,从传统客服转变为电商客服管理,还是比较容易的。只要在传统客服管理体系中增加三个知识点,就能顺利转变为电商客服管理了。这三个知识点是:
 
  • ☑入门级电商指标。
  • ☑人货场理论
  • ☑电商客服管理

 
先定义本文的2个概念:
 
  1. ☊ 传统客服:指通过电话接入提供服务。
  2. ✎ 电商客服:指通过在线接入提供服务,这里特指天猫,京东、独立商城的实物商品零售客服。

一、入门级电商指标

   这不是本文重点,所以我只概述性描述,起到抛砖引玉的作用。sorry,这里并不会告诉你电商是什么,是怎样发展的诸如此类的知识点。在我看来,把电商的各个指标搞深搞透了,就算是入门了。我只列举,详细大家可度娘。 
  • 流量指标:PV、UV、跳失率、平均停留时长、平均访问深度。
  • 商品指标:售罄率、动销率
  • 客户指标:销售额、客单价、件单价、客件数、动销率。
  • 库存指标:库存天数、库存周转率、售罄率。
  • 物流指标:订单满足率、订单响应时长、平均送货时间。
  • 退货指标:金额退货率、数量退货率、订单退货率。
  • 会员指标:会员留存率、会员复购率、会员回购率。

 
二、人货场分析

电商的本质是零售。所以很多零售理念可以用来分析电商行业。其中人货场思维模式最为普遍。

这个也不是本文重点,借用@黄成明《数据化管理》一书中的思维导图进行说明:
微信图片_20170705114344.jpg

三、电商客服管理

电商的在线客服与传统电话客服相比,差异不大,管理方式甚至是一样的。主要有以下四方面的区别:

岗位设置不一致

传统客服简单的组织架构分现场管理、培训管路、质量管理。我在《3招搞定自建客服中心》一文有提,这里不再重复。电商客服也是一样,区别主要在于电商客服的售后岗位和评价岗位。以下举一个电商组织架构的栗子:
微信图片_20170705114459.jpg

在线指标不一致

   几乎全部电商都是在线客服或者混合型。显而易见,由于在线客服是文字聊天,所以与传统语音客服在指标监控上会有不一致,以下列举在线客服特有的重点指标:
 
销售数据
 
  • call in转化率=询问客户数/总IP。
  • 询单转化率=经询问后成交的客户/询问的客户数。
  • 静默转化率=未经询问直接拍下付款的客户/总IP。
  • 全店转化率=所有成交客户/总IP。


效率指标
 
  • 最大同时接待数:在所选时间内,客服同时接待的最大值。(同时接待的定义:一个客服在某一时刻前后两分钟内有聊天的客户数。
  • 回复率=回复过的客户总人次/总接待人次。
  • 慢响应人数:同一聊天中,超过3次,每次回复间隔超过120秒的人数。可自定义次数与间隔时间。
  • 长接待人数:一般定义为超过20分钟才回复相应的客户数。可自定义时间。


人工智能应用更为广泛

目前客服行业的人工智能,主要是回复一些通用程度较高的问题,这只是一些日常的简单问题,用人力回答会耗费太多资源,用人工智能系统去回答的话,只需要告诉对方简单的流程步骤即可。具体如下:
 
  • 24小时客服在线,全天候相应客户咨询与需求。
  • 建立客服机器人的知识库,用深度学习方式自动回复重复问题。
  • 接入人工时机器人给予部分回复建议,加快反馈速度。


当然,有部分厂商产品可以做到智能监控、智能质检等,但未十分成熟。

客户信息“大”数据化

电商客服,客户在店铺中的所有行为都被记录在案并能进行查询。这与传统电话客服系统只简单记录客户通话记录与客户订单信息有很大差别。

客户信息的“大”数据化,最大的一个应用是:用户画像。简单点讲,就是给客户贴标签。具体现在不展开了,用户画像可以从以下几个方面收集信息:基本属性、购买能力、行为特征、心理特征、兴趣爱好等。

传统客服与电商客服,在本质上是一致的。所以,想要从传统转变为电商客服,需要花的时间不会很长。

本文作者:陈秋良

本文首发公众号:陈秋良
继续阅读 »
    不可否认,电话客服已慢慢没落。究其原因有很多,但主要是成本过高,加上新生代的沟通方式发生了很大的变化。

   逢电商的蓬勃发展,促使在线客服大行其道。传统客服的机会越来越少,新兴行业的发展却越来越迅猛。于是,很多人尝试从传统行业跳到电商行业。

   问题来了,一直从事传统电话客服管理的人,有没可能容易华丽丽转身到电商客服管理?要做怎样的积累?
 
从我经验看,从传统客服转变为电商客服管理,还是比较容易的。只要在传统客服管理体系中增加三个知识点,就能顺利转变为电商客服管理了。这三个知识点是:
 
  • ☑入门级电商指标。
  • ☑人货场理论
  • ☑电商客服管理

 
先定义本文的2个概念:
 
  1. ☊ 传统客服:指通过电话接入提供服务。
  2. ✎ 电商客服:指通过在线接入提供服务,这里特指天猫,京东、独立商城的实物商品零售客服。

一、入门级电商指标

   这不是本文重点,所以我只概述性描述,起到抛砖引玉的作用。sorry,这里并不会告诉你电商是什么,是怎样发展的诸如此类的知识点。在我看来,把电商的各个指标搞深搞透了,就算是入门了。我只列举,详细大家可度娘。 
  • 流量指标:PV、UV、跳失率、平均停留时长、平均访问深度。
  • 商品指标:售罄率、动销率
  • 客户指标:销售额、客单价、件单价、客件数、动销率。
  • 库存指标:库存天数、库存周转率、售罄率。
  • 物流指标:订单满足率、订单响应时长、平均送货时间。
  • 退货指标:金额退货率、数量退货率、订单退货率。
  • 会员指标:会员留存率、会员复购率、会员回购率。

 
二、人货场分析

电商的本质是零售。所以很多零售理念可以用来分析电商行业。其中人货场思维模式最为普遍。

这个也不是本文重点,借用@黄成明《数据化管理》一书中的思维导图进行说明:
微信图片_20170705114344.jpg

三、电商客服管理

电商的在线客服与传统电话客服相比,差异不大,管理方式甚至是一样的。主要有以下四方面的区别:

岗位设置不一致

传统客服简单的组织架构分现场管理、培训管路、质量管理。我在《3招搞定自建客服中心》一文有提,这里不再重复。电商客服也是一样,区别主要在于电商客服的售后岗位和评价岗位。以下举一个电商组织架构的栗子:
微信图片_20170705114459.jpg

在线指标不一致

   几乎全部电商都是在线客服或者混合型。显而易见,由于在线客服是文字聊天,所以与传统语音客服在指标监控上会有不一致,以下列举在线客服特有的重点指标:
 
销售数据
 
  • call in转化率=询问客户数/总IP。
  • 询单转化率=经询问后成交的客户/询问的客户数。
  • 静默转化率=未经询问直接拍下付款的客户/总IP。
  • 全店转化率=所有成交客户/总IP。


效率指标
 
  • 最大同时接待数:在所选时间内,客服同时接待的最大值。(同时接待的定义:一个客服在某一时刻前后两分钟内有聊天的客户数。
  • 回复率=回复过的客户总人次/总接待人次。
  • 慢响应人数:同一聊天中,超过3次,每次回复间隔超过120秒的人数。可自定义次数与间隔时间。
  • 长接待人数:一般定义为超过20分钟才回复相应的客户数。可自定义时间。


人工智能应用更为广泛

目前客服行业的人工智能,主要是回复一些通用程度较高的问题,这只是一些日常的简单问题,用人力回答会耗费太多资源,用人工智能系统去回答的话,只需要告诉对方简单的流程步骤即可。具体如下:
 
  • 24小时客服在线,全天候相应客户咨询与需求。
  • 建立客服机器人的知识库,用深度学习方式自动回复重复问题。
  • 接入人工时机器人给予部分回复建议,加快反馈速度。


当然,有部分厂商产品可以做到智能监控、智能质检等,但未十分成熟。

客户信息“大”数据化

电商客服,客户在店铺中的所有行为都被记录在案并能进行查询。这与传统电话客服系统只简单记录客户通话记录与客户订单信息有很大差别。

客户信息的“大”数据化,最大的一个应用是:用户画像。简单点讲,就是给客户贴标签。具体现在不展开了,用户画像可以从以下几个方面收集信息:基本属性、购买能力、行为特征、心理特征、兴趣爱好等。

传统客服与电商客服,在本质上是一致的。所以,想要从传统转变为电商客服,需要花的时间不会很长。

本文作者:陈秋良

本文首发公众号:陈秋良 收起阅读 »

经纬熊飞:企业服务行业如何先赢而后战

   
201707039141499064337064.jpg

   企业服务并非科技新兴领域,早在上世纪70年代,美国已出现SAP、微软、Oracle这样的ToB公司,成长为巨头。在国内,由于经济快速增长及人力成本低廉,一直以来,企业服务市场属于少为人知的领域。2012年起,国内GDP增速放缓,人力成本增长问题凸显,同时2013年棱镜门事件后,国内加大去IOE力度,也为企业级服务创业提供了较好的发展土壤。

   经纬创投是最早布局企业服务领域的机构。从2012年开始,经过5 年的探索与沉淀,目前在经纬系布局的近50家企业服务创业项目中,有北森、销售易、七牛、永洪BI、OneAPM、环信、GrowingIO、亿方云、上上签、佳格数据、盖雅工场、Pingcap等已初露锋芒。

   今天的文章来自我们与经纬董事总经理熊飞的一次交流,希望对你有所启发。以下,Enjoy:“企业服务项目到底怎么投?两个核心关键点。

Q:在我看来,做VC有个能力:当有经验积累后,挑项目的时候,是能够预判出项目发展路径的。但问题在于,当一个项目到了一定的标准,投与不投,是多维度进行判断的。比如Saas,中国Saas目前看来还比较难做,如果满足了基本条件KPI达标,那么超越KPI的标准是什么?在此之上经纬看重什么?

熊飞:第一点,是个大市场。比如CRM,再比如人力资源,也有很多细分项目,比如做核心人力、做招聘,但肯定不只是做一个报表工具。企业服务公司所处的市场足够大,这是核心。企业服务本身是让企业为该职能相关痛点去付费。而销售、HR、客服、财务等职能,是企业最核心职能,痛点的商业价值最大。所以大市场的基础,是该产品关注的是企业核心职能,以及解决的是核心职能中的核心痛点。

第二点,要考虑这个项目是不是处在浪尖位置。我们经常说投浪尖。三五年前投Saas,那个时候对于早期项目来说是一个浪尖。过去一两年投infrastructure(IT底层架构),也是个浪尖,比如说marketing automation(营销自动化)、iot等等。所以如果你现在做客服Saas创业就不是浪尖了,因为已有环信这些头部项目。浪尖的优势在于你是最早做的,所有资源都给你。

总结一下:它应该是这个领域最早的探路者,且速度一直高速增长。如果市场够大,并处于浪尖的位置,是先人半步与先人一步的机会,这个我们是非常看重的。“企业服务,产品技术导向的创始人更有优势。

Q:在这两点满足的前提下,关于团队层面,有什么体会?你们看重创始人的哪些特质?

熊飞:我觉得没有完美决策,我们常说VC是一个判断+运气的连续体,但投ToB靠判断会更多一些。做的每一个判断都希望结果是大概率事件,但所谓大概率也只能证明这个项目七八成应该投,但没有百分之百。

我个人倾向产品技术导向的创始人。在我看来,投产品技术导向的团队没什么下行风险,但上行收益巨大;因为产品技术好,最差情况就是没销售,但优势在于产品壁垒高,一旦市场找到感觉,找到销售合伙人,业务可能就会以5 倍、10倍增速发展。但纯销售导向创始人,早期业务起来比较快,但如果竞争对手是产品技术导向,对手一旦找到市场感觉和销售合伙人,下行风险就很大。

宏观来看,企业服务公司产品技术的护城河宽不宽,有没有留下足够多的安全边际,是我们很关注的点。这也是经纬系企业服务公司,为什么普遍发展很扎实、高速健康增长的原因。我们在投的时候,是希望跟产品技术导向、着重于打磨自己产品的创始人去沟通。

Q:说到产品和技术,其实相对难判断,ToC可能是看KPI;ToB的话,特别是一些早期公司除了看创始人过去的背景,怎么去判断呢?

熊飞:我觉得有几点,第一,做reference track,团队的能力,是可以通过reference相当程度判断。

第二,团队投每个领域都会投入很多的时间,要了解趋势,知道有哪些领先的公司。形成初步投资假设。再去和公司聊发展、聊产品,就能够比较快的判断出这个团队的视野、产品意识。

第三,就是一些标杆客户的反馈,这个是实打实的。做到这三点就很快能做出不赖的判断。“先赢而后战。

Q:经纬五年前就开始布局ToB,坚持到现在。在我看来,五年前的时候应该非常寂寞。直到2015年大家才普遍觉得 ToB是风口,这期间你是怎么去判断的?

熊飞:投ToB其实投的创始人的特质,往往都是比较踏实、稳重、重逻辑、重积累,团队专注某一个方向;ToC则不然,可能需要创始人是愿意快速变化的人——这两类人是完全不一样的。

另外,我个人觉得在中国投ToB的长期回报会比美国投ToB好很多。原因在于:

在美国,因为Salesforce、Workday等已有领先者产品的市场占有度很高,导致创业公司长不动、长不大,很多都是10亿美金、12亿美金被并购。在中国,ToB领域竞争并不激烈,因为没有产品供给,很多公司创业两年,就可以做中国500强的生意,这在美国不可想象。所以从长期来看,国内 ToB创业公司的天花板显著的高。

另外,从运营效率来看国内Saas创业公司也有不小优势。美国很多Saas公司大概做到1 个亿美金收入还在不停亏损,还要不停地往前赶,很难实现现金流打平。但在国内,至少我们投的很多Saas公司做到亿元人民币量级的时候,或者之后一年,就有机会做到单月盈亏平衡。

最后,从经纬角度来说,最核心是投产品高壁垒和护城河足够宽的项目,比如像HR领域的北森现在发展很好,五年后还会发展很好、再比如销售易、环信、GrowingIO……这些公司现在很好,我们也能看到它们五年后都会很好。

大核心、大前提还是投到最优秀的公司。我很喜欢《孙子兵法》里面的一句话——先胜而后战,你要先确保你大概率能赢的再去打。张颖有一句话,叫自强则万强,只要把产品、技术做到行业内非常领先,我觉得融资的问题都是业务问题。“企业服务这么火,创业到底是该切入大客户还是小客户?

熊飞:经纬投企业服务五年时间,这个行业的发展是超出预期的。几点原因:

中国人力成本的提高到了一个转折点。我经常举例子,六年前一个人工资大概3000元 / 月,一台电脑5000元。现在反过来了,一个人工资5000元,笔记本电脑的价格只有2000元。企业主是很理性的,以前2:1,现在变1:2了,他希望更大投入提高效率。而且,最近中国经济增长放缓,三年前企业主都在谈拉贷款、扩产能,但是现在想的是如何高效地去提高利润,也落在软件上。

我有个观察,ToB市场爆发,不是留给海外巨头,而是给国内创业企业的巨大机会。很像七八年前智能手机的市场,当时移动手机市场刚起来,大家知道苹果、三星非常好,可是一台手机要六七千块。所以需求起来的时候,性价比更高的国产手机,小米、OPPO、华为、中兴爆发式增长。ToB领域也类似,软件从最初大型和超大型企业的刚需,过渡到中型以上企业的刚需,而这个爆发的市场更关注性价比和产品体验,使得国内创业公司成为最大受益方。

Q:那么现在如果再做企业服务创业的话,是否理想的客户反而不是中海油、中石油,而应该是中型企业?

熊飞:我们投的大部分成功企业服务公司,不是一上来就瞄准中海油等超大型企业,无法一击即中,因为超大型企业的功能需求太多了。它们往往是先瞄准100人到300人的中型企业,或者是中型偏小型企业,要先快速上手,再逐年向上走,今年可能是服务100人到300人的企业,明年可能是300人到800人,后年可能是1000人到2000人。随着功能不断地添加,这是一个“逆流而上”的策略。

Q:有个现象非常有趣——很多企业服务创业者会在两头摇摆,以前做大客户出身的会非常痛恨做大企业,过去诸如催款、服务等等小事,CEO、工程师动不动就被叫过去处理问题。 经历过做大客户的,现在就愿意做小企业或者中小企业,他觉得我是产品说话,不会像以前那样被牵着鼻子走;但又会发现一个新问题:收费有点困难。小企业消失得快,或者是需求率不高。他们就像一个钟摆在不断摇摆。你怎么看?

熊飞:我觉得一定要做中大企业。一点一点往上。全球IT投入90% 来自于财富两千强,再90% 来自于两万强,你做不到两万强的生意,你就只有1% 的市场,自然这个公司能够成为一个很大的、很牛的公司的概率也变得很小。“投资的魅力所在:不断地去证伪。

Q:经纬企业服务团队做的最快的一次决策多长时间?为什么?

熊飞:最快决策是当天见完觉得可以投,就签下TS。能这么快的原因是,团队在该领域已做了足够多思考,见了足够多公司,当遇到这家公司时,其实是捅破了这层“窗户纸”。

另外,我认为投资的魅力所在,是一个不断证伪的过程。VC这个行业是一个idea business,所有的回报取决于你的idea质量,本质在于两点:

第一,generate idea的能力,就是说你的视野够广,经常在一线跑,有很多的思考。

第二,证伪idea的能力。如果你没有证伪idea的能力,那就变成了自己做空中楼阁的假设。

经纬企业服务团队每天都在不断地拼命去证伪——比如17年初定了三四个ToB的主方向,现在看有两个觉得不错;但是已有一个觉得机会不大,还有一个待判断。所以每个季度都在推翻自己投资的思路和假设。

Q:Peter Thiel的书《Zero to One》里说过创投要有一个非常规的想法。如果说你提一个跟ToB相关的观点,比如“我觉得我这么认为,但是其他的投资人未必是这么认为的”。如果有,是什么?

熊飞:我觉得是中国企业服务创业公司机会规模,10倍于目前美国企业服务创业机会。原因在于,美国在enterprise是三波的创业浪潮,第一波是上世纪70年代到80年代,像SAP、微软、Oracle,他们现在都是1000亿到3000亿美金的公司。第二波是云计算,从上世纪90年代末到2000下半叶,这时崛起了Salesforce、workday、NetSuite、ServiceNow这一系列公司,从几十亿美金到六百亿美金。第三波就是现在,现在有一些AI企业服务创业公司开始起来。

在中国,这三波发展是融合在一起爆发的,三、四年前没有人谈企业服务,现在所有人都在谈企业服务,所有人都在谈企业服务直接上云计算,所有人都在谈企业服务和AI的结合。所以三波浪潮的合并,使得目前中国企业服务创业公司的天花板显著的高。

Q:会不会有这样一个趋势,SAP这些公司等于是压在中国公司头上的石头,首先会有一批企业服务本土企业。未来中国公司出海,反过来最后会不会变成中国公司把SAP干掉?

熊飞:第一,我不知道会不会干掉,但我相信未来的5 到10年中国的企业服务公司会在全球企业服务市场将占据重要地位,原因有两点:一是随着中国企业的出海而出海;二是价格优势,SAP、Oracle现在是一个85分到90分的产品,但我们中国的企业服务产品现在很努力地在赶上,虽然可能还是一个75分的产品,但是价格是其1 /3。三是,未来中国企业的最佳实践,会成为第三世界国家(企业服务下一波机会所在地)的最佳实践。
继续阅读 »
   
201707039141499064337064.jpg

   企业服务并非科技新兴领域,早在上世纪70年代,美国已出现SAP、微软、Oracle这样的ToB公司,成长为巨头。在国内,由于经济快速增长及人力成本低廉,一直以来,企业服务市场属于少为人知的领域。2012年起,国内GDP增速放缓,人力成本增长问题凸显,同时2013年棱镜门事件后,国内加大去IOE力度,也为企业级服务创业提供了较好的发展土壤。

   经纬创投是最早布局企业服务领域的机构。从2012年开始,经过5 年的探索与沉淀,目前在经纬系布局的近50家企业服务创业项目中,有北森、销售易、七牛、永洪BI、OneAPM、环信、GrowingIO、亿方云、上上签、佳格数据、盖雅工场、Pingcap等已初露锋芒。

   今天的文章来自我们与经纬董事总经理熊飞的一次交流,希望对你有所启发。以下,Enjoy:“企业服务项目到底怎么投?两个核心关键点。

Q:在我看来,做VC有个能力:当有经验积累后,挑项目的时候,是能够预判出项目发展路径的。但问题在于,当一个项目到了一定的标准,投与不投,是多维度进行判断的。比如Saas,中国Saas目前看来还比较难做,如果满足了基本条件KPI达标,那么超越KPI的标准是什么?在此之上经纬看重什么?

熊飞:第一点,是个大市场。比如CRM,再比如人力资源,也有很多细分项目,比如做核心人力、做招聘,但肯定不只是做一个报表工具。企业服务公司所处的市场足够大,这是核心。企业服务本身是让企业为该职能相关痛点去付费。而销售、HR、客服、财务等职能,是企业最核心职能,痛点的商业价值最大。所以大市场的基础,是该产品关注的是企业核心职能,以及解决的是核心职能中的核心痛点。

第二点,要考虑这个项目是不是处在浪尖位置。我们经常说投浪尖。三五年前投Saas,那个时候对于早期项目来说是一个浪尖。过去一两年投infrastructure(IT底层架构),也是个浪尖,比如说marketing automation(营销自动化)、iot等等。所以如果你现在做客服Saas创业就不是浪尖了,因为已有环信这些头部项目。浪尖的优势在于你是最早做的,所有资源都给你。

总结一下:它应该是这个领域最早的探路者,且速度一直高速增长。如果市场够大,并处于浪尖的位置,是先人半步与先人一步的机会,这个我们是非常看重的。“企业服务,产品技术导向的创始人更有优势。

Q:在这两点满足的前提下,关于团队层面,有什么体会?你们看重创始人的哪些特质?

熊飞:我觉得没有完美决策,我们常说VC是一个判断+运气的连续体,但投ToB靠判断会更多一些。做的每一个判断都希望结果是大概率事件,但所谓大概率也只能证明这个项目七八成应该投,但没有百分之百。

我个人倾向产品技术导向的创始人。在我看来,投产品技术导向的团队没什么下行风险,但上行收益巨大;因为产品技术好,最差情况就是没销售,但优势在于产品壁垒高,一旦市场找到感觉,找到销售合伙人,业务可能就会以5 倍、10倍增速发展。但纯销售导向创始人,早期业务起来比较快,但如果竞争对手是产品技术导向,对手一旦找到市场感觉和销售合伙人,下行风险就很大。

宏观来看,企业服务公司产品技术的护城河宽不宽,有没有留下足够多的安全边际,是我们很关注的点。这也是经纬系企业服务公司,为什么普遍发展很扎实、高速健康增长的原因。我们在投的时候,是希望跟产品技术导向、着重于打磨自己产品的创始人去沟通。

Q:说到产品和技术,其实相对难判断,ToC可能是看KPI;ToB的话,特别是一些早期公司除了看创始人过去的背景,怎么去判断呢?

熊飞:我觉得有几点,第一,做reference track,团队的能力,是可以通过reference相当程度判断。

第二,团队投每个领域都会投入很多的时间,要了解趋势,知道有哪些领先的公司。形成初步投资假设。再去和公司聊发展、聊产品,就能够比较快的判断出这个团队的视野、产品意识。

第三,就是一些标杆客户的反馈,这个是实打实的。做到这三点就很快能做出不赖的判断。“先赢而后战。

Q:经纬五年前就开始布局ToB,坚持到现在。在我看来,五年前的时候应该非常寂寞。直到2015年大家才普遍觉得 ToB是风口,这期间你是怎么去判断的?

熊飞:投ToB其实投的创始人的特质,往往都是比较踏实、稳重、重逻辑、重积累,团队专注某一个方向;ToC则不然,可能需要创始人是愿意快速变化的人——这两类人是完全不一样的。

另外,我个人觉得在中国投ToB的长期回报会比美国投ToB好很多。原因在于:

在美国,因为Salesforce、Workday等已有领先者产品的市场占有度很高,导致创业公司长不动、长不大,很多都是10亿美金、12亿美金被并购。在中国,ToB领域竞争并不激烈,因为没有产品供给,很多公司创业两年,就可以做中国500强的生意,这在美国不可想象。所以从长期来看,国内 ToB创业公司的天花板显著的高。

另外,从运营效率来看国内Saas创业公司也有不小优势。美国很多Saas公司大概做到1 个亿美金收入还在不停亏损,还要不停地往前赶,很难实现现金流打平。但在国内,至少我们投的很多Saas公司做到亿元人民币量级的时候,或者之后一年,就有机会做到单月盈亏平衡。

最后,从经纬角度来说,最核心是投产品高壁垒和护城河足够宽的项目,比如像HR领域的北森现在发展很好,五年后还会发展很好、再比如销售易、环信、GrowingIO……这些公司现在很好,我们也能看到它们五年后都会很好。

大核心、大前提还是投到最优秀的公司。我很喜欢《孙子兵法》里面的一句话——先胜而后战,你要先确保你大概率能赢的再去打。张颖有一句话,叫自强则万强,只要把产品、技术做到行业内非常领先,我觉得融资的问题都是业务问题。“企业服务这么火,创业到底是该切入大客户还是小客户?

熊飞:经纬投企业服务五年时间,这个行业的发展是超出预期的。几点原因:

中国人力成本的提高到了一个转折点。我经常举例子,六年前一个人工资大概3000元 / 月,一台电脑5000元。现在反过来了,一个人工资5000元,笔记本电脑的价格只有2000元。企业主是很理性的,以前2:1,现在变1:2了,他希望更大投入提高效率。而且,最近中国经济增长放缓,三年前企业主都在谈拉贷款、扩产能,但是现在想的是如何高效地去提高利润,也落在软件上。

我有个观察,ToB市场爆发,不是留给海外巨头,而是给国内创业企业的巨大机会。很像七八年前智能手机的市场,当时移动手机市场刚起来,大家知道苹果、三星非常好,可是一台手机要六七千块。所以需求起来的时候,性价比更高的国产手机,小米、OPPO、华为、中兴爆发式增长。ToB领域也类似,软件从最初大型和超大型企业的刚需,过渡到中型以上企业的刚需,而这个爆发的市场更关注性价比和产品体验,使得国内创业公司成为最大受益方。

Q:那么现在如果再做企业服务创业的话,是否理想的客户反而不是中海油、中石油,而应该是中型企业?

熊飞:我们投的大部分成功企业服务公司,不是一上来就瞄准中海油等超大型企业,无法一击即中,因为超大型企业的功能需求太多了。它们往往是先瞄准100人到300人的中型企业,或者是中型偏小型企业,要先快速上手,再逐年向上走,今年可能是服务100人到300人的企业,明年可能是300人到800人,后年可能是1000人到2000人。随着功能不断地添加,这是一个“逆流而上”的策略。

Q:有个现象非常有趣——很多企业服务创业者会在两头摇摆,以前做大客户出身的会非常痛恨做大企业,过去诸如催款、服务等等小事,CEO、工程师动不动就被叫过去处理问题。 经历过做大客户的,现在就愿意做小企业或者中小企业,他觉得我是产品说话,不会像以前那样被牵着鼻子走;但又会发现一个新问题:收费有点困难。小企业消失得快,或者是需求率不高。他们就像一个钟摆在不断摇摆。你怎么看?

熊飞:我觉得一定要做中大企业。一点一点往上。全球IT投入90% 来自于财富两千强,再90% 来自于两万强,你做不到两万强的生意,你就只有1% 的市场,自然这个公司能够成为一个很大的、很牛的公司的概率也变得很小。“投资的魅力所在:不断地去证伪。

Q:经纬企业服务团队做的最快的一次决策多长时间?为什么?

熊飞:最快决策是当天见完觉得可以投,就签下TS。能这么快的原因是,团队在该领域已做了足够多思考,见了足够多公司,当遇到这家公司时,其实是捅破了这层“窗户纸”。

另外,我认为投资的魅力所在,是一个不断证伪的过程。VC这个行业是一个idea business,所有的回报取决于你的idea质量,本质在于两点:

第一,generate idea的能力,就是说你的视野够广,经常在一线跑,有很多的思考。

第二,证伪idea的能力。如果你没有证伪idea的能力,那就变成了自己做空中楼阁的假设。

经纬企业服务团队每天都在不断地拼命去证伪——比如17年初定了三四个ToB的主方向,现在看有两个觉得不错;但是已有一个觉得机会不大,还有一个待判断。所以每个季度都在推翻自己投资的思路和假设。

Q:Peter Thiel的书《Zero to One》里说过创投要有一个非常规的想法。如果说你提一个跟ToB相关的观点,比如“我觉得我这么认为,但是其他的投资人未必是这么认为的”。如果有,是什么?

熊飞:我觉得是中国企业服务创业公司机会规模,10倍于目前美国企业服务创业机会。原因在于,美国在enterprise是三波的创业浪潮,第一波是上世纪70年代到80年代,像SAP、微软、Oracle,他们现在都是1000亿到3000亿美金的公司。第二波是云计算,从上世纪90年代末到2000下半叶,这时崛起了Salesforce、workday、NetSuite、ServiceNow这一系列公司,从几十亿美金到六百亿美金。第三波就是现在,现在有一些AI企业服务创业公司开始起来。

在中国,这三波发展是融合在一起爆发的,三、四年前没有人谈企业服务,现在所有人都在谈企业服务,所有人都在谈企业服务直接上云计算,所有人都在谈企业服务和AI的结合。所以三波浪潮的合并,使得目前中国企业服务创业公司的天花板显著的高。

Q:会不会有这样一个趋势,SAP这些公司等于是压在中国公司头上的石头,首先会有一批企业服务本土企业。未来中国公司出海,反过来最后会不会变成中国公司把SAP干掉?

熊飞:第一,我不知道会不会干掉,但我相信未来的5 到10年中国的企业服务公司会在全球企业服务市场将占据重要地位,原因有两点:一是随着中国企业的出海而出海;二是价格优势,SAP、Oracle现在是一个85分到90分的产品,但我们中国的企业服务产品现在很努力地在赶上,虽然可能还是一个75分的产品,但是价格是其1 /3。三是,未来中国企业的最佳实践,会成为第三世界国家(企业服务下一波机会所在地)的最佳实践。 收起阅读 »

【环信征文】Android程序员北漂记-从逃离北上广到逃回北上广

司马雼是我的学长,先后在国内两家top 10大厂担任资深Android工程师,对Android技术有如痴如醉的热情,并且乐于帮助同行,最难得的是他还有一个漂亮的女朋友,不愧是Android程序员中的人生赢家。我将他的经历稍作加工后用明清小说的笔法写出来,希望每个读到这篇文章的Android工程师都能走他的路。

第一回:小庙无地容巨擘 大厂有礼迎硕士
诗曰:

老板抠门巧计乖,却将忠义苦挤排。

基础扎实绩点高,苍天岂能误人才。


司马雼2008年考入合肥工业大学,2012年保研本校,2014年进入合肥某小公司实习。

司马雼一开始选择的是JavaEE方向,他在实习期间就以专家的标准严格要求自己,不但让服务端的内核稳定度提升了好几个档次,还让内存消耗下降了好多个数量级。完成本职工作后还帮助运维那边修复了几次硬件的故障。不料老板嫉贤妒能成性,只爱奴才,不要人才。这个老板不但不给司马雼升职加薪,还侮辱司马雼:““雼”是“宕”的繁体字,你越俎代庖搞运维不怕把服务器搞宕机?”信而见疑、怀才不遇的司马雼愤而辞职。司马雼辞职刚好赶上某大厂(国内top 10)招Android实习生,他突击学习了几天Android就去面试了。

一面的时候主要考察Android和Java的基础知识,比如Java的数据类型、运算符优先级和Android的布局以及生命周期,基础扎实的司马雼都能准确无误地回答。

二面的时候面试官问了许多数据结构和算法、设计模式、架构的方面的问题,司马雼不但能画出好几种设计模式的UML图,还对MVC、MVP、MVVM的区别和优缺点发表了自己的看法。

最后HR面的时候收了司马雼的成绩单复印件,对他4.0的GPA和专业top 5%感到很满意。

司马雼通过了面试,顺利成为该厂的Android实习生。不久,司马雼以专业top 5%的优异成绩硕士毕业,转正成为Android工程师。而那家小公司呢,不知道什么时候就因为bug太多导致用户严重流失而倒闭了。

异史氏曰:Java玩得6的学生选择Android作为发展方向是一个明智的抉择,这个世界正处于、并将长期处于移动互联网时代。校招面试除了考察Android和Java基础知识,还考察你学习的基础理论课程的知识,最后通常还要收成绩单的复印件。大厂的校招面试一般有固定的问题和模式,比如阿里校招笔试题来自《技术之瞳》,微软校招笔试题来自《编程之美》等,尽管临阵磨枪也有一定的成功几率,但别忘了玩3年LOL的枪不可能比刷6年LeetCode的枪更快。(时间没错,沉迷LOL的大学生都考不上硕士)

第二回:荣升高级愁田舍 游子低头思莼鲈
诗曰:

当年许汜初炒房,羞无才气见刘郎。

如今司马有远志,却愁无房迎新娘。


炒房团自古有之,祖师爷是东汉末年的许汜。当年许汜空有国士之名,却全无救世之意,整天就知道求田问舍,因此被胸襟海阔,志向山高,忧国忘家的刘备鄙视。此事有辛弃疾《水龙吟》为证:“求田问舍,怕应羞见,刘郎才气。”

司马雼和许汜的志向有天壤之别,他的梦想就是把有限的生命投入无限的Android技术中,他不甘心每天只做UI的微调,他发现App存在很大的改进空间,并付诸行动。

司马雼对App的代码进行了大规模重构,在MVP与MVVM中选择了MVP架构,并自主研发了一套的网络请求框架(结合了OKHttp和Gson,可以理解为国产的Retrofit)(该框架不开源,类似框架的源码:https://github.com/qiujuer/OkHttpPacker)代替OKHttp。这样一来不但减少了大量冗余代码,层次结构也变得更加清晰。


订单状态这种需要和服务器实时同步的数据,以前一直用每秒一次的轮询,司马雼发现这是App又费电又费流量的祸根,采取了用推送代替轮询的解决方案。


APK瘦身也是Android性能优化的重要组成部分,司马雼去掉了很多不必要依赖和重复的工具类,让APK打包后的体量轻了一半。

两年后,这个App完成了从3.3到6.3共13个版本的迭代,App的启动速度提升了120%,Crash 率也由8‰降低到1‰。立下汗马功劳的司马雼被任命为项目组长、技术指导、高级工程师。

尽管司马雼工作兢兢业业,也为我国的开源事业添砖加瓦,还写技术博客帮助了很多人。北京高昂的房价却让他有点羡慕那个被他鄙视了多年的许汜。

异史氏曰:Android工程师(在没有“高级”等前缀时)每天最多的工作都是UI的改来改去,想在平凡的工作中取得不平庸的业绩就要付出努力,提升App的性能是有效途径之一。贡献开源代码和分享技术文章的时间也是可以挤出来的。如果在工作中有出色的成绩,升职加薪只是时间问题。

第三回:桑梓惜别因缘浅 楷模入职即资深
诗曰:

北京买房要筑台,还有堵车与雾霾。

回到省会想定居,一问工资又回来。


北京的房价、堵车、雾霾逼得司马雼决定裸辞,逃离北上广,他的目的地是上了七年学的合肥。他刚辞职,老东家的最大竞争对手(全国top 20)和另一家全国top 10的大厂都邀请他去面试。他两个月来参加了这两家大厂和合肥当地两家大厂的面试。

面试官首先询问的总是Java和Android的高级特性,Java的高级特性主要有JVM模型、类加载机制和GC原理等,Android的高级特性主要有几大FLAG和LauchMode的区别和使用场景、Binder的引用和实体以及权限系统的交互等。司马雼对技术钻研很有深度,总是对答如流。


面试的第二阶段就是让司马雼自己去讲他做过的项目,然后面试官会冷不丁的让他去解释其中某一部分,有时候让他解释当时为什么要这么做,有时候问他现在觉得有没有更好的办法。司马雼处理问题的思路和解决问题的能力给面试官留下了深刻印象。


面试官有时候会问一些该企业所在行业需要关注的Android技术,比如研究输入法的公司会询问他Android手势和多点触摸,研究物联网的公司会问他Bluetooth相关知识等。因为司马雼广泛涉猎Android知识,他的技术广度也让面试官啧啧赞叹。

每次面试官问司马雼:“你还有什么想和我说的吗?”的时候,司马雼就把他的技术博客和开源项目一股脑砸向面试官,面试官是司马雼的粉丝或者面试官正在用司马雼的开源项目的情况发生了好几次。

司马雼在合肥拿到了两个资深Android工程师的offer,尽管合肥房价不到北京的1/3,可是最多30W的年薪让司马雼在合肥买房遥遥无期。这时司马雼接到了一个电话,逃离北京前面试的全国top 10的大厂给了他60W年薪和项目经理、技术经理、资深工程师的title。他决定逃回北上广,逃离北上广的计划刚开始就结束了。

异史氏曰:有多年工作经验的求职者几乎不需要在求职网站上投简历,想让你做他的同时的同行朋友会内推你。社招面试和校招面试是不同的,社招面试没有固定的问题和模式,临时抱佛脚是行不通的。社招面试基本都会考察这几个问题:第一个阶段是Android和Java的高级特性,考察技术深度;第二个阶段是讲述自己的项目,并在中间穿插着问题,考察解决问题的经验;第三个阶段(未必有)是问该公司所在行业需要掌握的Android知识,考察技术广度和快速上手情况。技术博客和开源项目是很重要的加分项,如果平时不积累、不分享,求职者会失去很多机会。二三线城市的房价更亲民,但工资非常不人性,逃离北上广需谨慎。

第四回:专家立功施小计 淑女出闺成大礼
诗曰:

经验丰富技术精,消除隐患立大功。

全球大会登讲台,抱得淑女入后宫。


话说司马雼所在的团队负责公司的Android客户端的安全工作,工作内容包含保活、防拦截、防篡改和防反编译等工作。他发现自家App存在不少可能被恶意利用的隐患:

首先,坏人可以通过NotificationListenerService拦截自家App的推送,给用户造成自家App没有推送的假象。


其次,在上一条基础上。坏人可以在虚拟机里运行一个窃取推送App,收到自家App推送后,用AccessibilityService打开Notification对应的Activity,找到里面的WebView,然后取得链接及网页中的内容,稍加修改(换logo、改名字)推送给坏人自己的App。


此外公司的微信公众号打开自己App需要用浏览器打开链接,这也给坏人以可乘之机。


更有甚者,坏人最丧心病狂的手段就是卸载了自家App后,在肉鸡中安装一个与自家App的packgaeName一致,但Signature不一样而且没有launcher的假App,这样肉鸡的用户永远也安装不了自家App,而且还不能用长按拖拽桌面icon进垃圾桶的方式删除假App。

司马雼花了两年时间为公司消除了以上隐患,荣升架构师、技术专家(时间没错,这是小说,出现未来时间很正常)。各大IT论坛、IT活动的聘书和邀请函也如雪片般飞来,不是邀请他做特约作者,就是邀请他当讲座嘉宾。

某IT大会在北京举行,司马雼作为特约嘉宾在台上妙语连珠、口若悬河。大会期间,司马雼结识了某IT社区的技术编辑椎名,这位淑女负责大会的后勤和报道工作。椎名不但知书达理、兰心蕙质,相貌也倾国倾城,有诗为证:
乐天浔阳歌《长恨》,陈王洛水赋《感甄》。

摩诘青溪《西施咏》,潇湘红楼《明妃吟》。


没错,这诗集合了白居易《长恨歌》、曹植《感甄赋》、王维《西施咏》、林黛玉《明妃吟》,椎名的美貌用古往今来的美女诗都搁一块也写不完。淑女椎名倾慕司马雼的才华,从此司马雼正式脱单。

不久,年薪100W的司马雼在北京买房定居。又过了几个月,这对为我国IT事业做出了巨大贡献的情侣在北京举办了盛大的婚礼。

异史氏曰:公司大到一定程度,别有用心的竞争对手就会搞小动作,因此想成为大厂的技术专家,懂点安全方面的知识是很有帮助的。程序员是经常被嘲笑为“注定孤独一生”的群体,但出人头地的程序员抱得美人归的可能性非常大,毕竟女人的颜值通常和她的男朋友的收入成正比。
 
本文首发于51CTO的IT故事汇:http://mdsa.51cto.com/art/201707/543909.htm
继续阅读 »
司马雼是我的学长,先后在国内两家top 10大厂担任资深Android工程师,对Android技术有如痴如醉的热情,并且乐于帮助同行,最难得的是他还有一个漂亮的女朋友,不愧是Android程序员中的人生赢家。我将他的经历稍作加工后用明清小说的笔法写出来,希望每个读到这篇文章的Android工程师都能走他的路。

第一回:小庙无地容巨擘 大厂有礼迎硕士
诗曰:

老板抠门巧计乖,却将忠义苦挤排。

基础扎实绩点高,苍天岂能误人才。


司马雼2008年考入合肥工业大学,2012年保研本校,2014年进入合肥某小公司实习。

司马雼一开始选择的是JavaEE方向,他在实习期间就以专家的标准严格要求自己,不但让服务端的内核稳定度提升了好几个档次,还让内存消耗下降了好多个数量级。完成本职工作后还帮助运维那边修复了几次硬件的故障。不料老板嫉贤妒能成性,只爱奴才,不要人才。这个老板不但不给司马雼升职加薪,还侮辱司马雼:““雼”是“宕”的繁体字,你越俎代庖搞运维不怕把服务器搞宕机?”信而见疑、怀才不遇的司马雼愤而辞职。司马雼辞职刚好赶上某大厂(国内top 10)招Android实习生,他突击学习了几天Android就去面试了。

一面的时候主要考察Android和Java的基础知识,比如Java的数据类型、运算符优先级和Android的布局以及生命周期,基础扎实的司马雼都能准确无误地回答。

二面的时候面试官问了许多数据结构和算法、设计模式、架构的方面的问题,司马雼不但能画出好几种设计模式的UML图,还对MVC、MVP、MVVM的区别和优缺点发表了自己的看法。

最后HR面的时候收了司马雼的成绩单复印件,对他4.0的GPA和专业top 5%感到很满意。

司马雼通过了面试,顺利成为该厂的Android实习生。不久,司马雼以专业top 5%的优异成绩硕士毕业,转正成为Android工程师。而那家小公司呢,不知道什么时候就因为bug太多导致用户严重流失而倒闭了。

异史氏曰:Java玩得6的学生选择Android作为发展方向是一个明智的抉择,这个世界正处于、并将长期处于移动互联网时代。校招面试除了考察Android和Java基础知识,还考察你学习的基础理论课程的知识,最后通常还要收成绩单的复印件。大厂的校招面试一般有固定的问题和模式,比如阿里校招笔试题来自《技术之瞳》,微软校招笔试题来自《编程之美》等,尽管临阵磨枪也有一定的成功几率,但别忘了玩3年LOL的枪不可能比刷6年LeetCode的枪更快。(时间没错,沉迷LOL的大学生都考不上硕士)

第二回:荣升高级愁田舍 游子低头思莼鲈
诗曰:

当年许汜初炒房,羞无才气见刘郎。

如今司马有远志,却愁无房迎新娘。


炒房团自古有之,祖师爷是东汉末年的许汜。当年许汜空有国士之名,却全无救世之意,整天就知道求田问舍,因此被胸襟海阔,志向山高,忧国忘家的刘备鄙视。此事有辛弃疾《水龙吟》为证:“求田问舍,怕应羞见,刘郎才气。”

司马雼和许汜的志向有天壤之别,他的梦想就是把有限的生命投入无限的Android技术中,他不甘心每天只做UI的微调,他发现App存在很大的改进空间,并付诸行动。

司马雼对App的代码进行了大规模重构,在MVP与MVVM中选择了MVP架构,并自主研发了一套的网络请求框架(结合了OKHttp和Gson,可以理解为国产的Retrofit)(该框架不开源,类似框架的源码:https://github.com/qiujuer/OkHttpPacker)代替OKHttp。这样一来不但减少了大量冗余代码,层次结构也变得更加清晰。


订单状态这种需要和服务器实时同步的数据,以前一直用每秒一次的轮询,司马雼发现这是App又费电又费流量的祸根,采取了用推送代替轮询的解决方案。


APK瘦身也是Android性能优化的重要组成部分,司马雼去掉了很多不必要依赖和重复的工具类,让APK打包后的体量轻了一半。

两年后,这个App完成了从3.3到6.3共13个版本的迭代,App的启动速度提升了120%,Crash 率也由8‰降低到1‰。立下汗马功劳的司马雼被任命为项目组长、技术指导、高级工程师。

尽管司马雼工作兢兢业业,也为我国的开源事业添砖加瓦,还写技术博客帮助了很多人。北京高昂的房价却让他有点羡慕那个被他鄙视了多年的许汜。

异史氏曰:Android工程师(在没有“高级”等前缀时)每天最多的工作都是UI的改来改去,想在平凡的工作中取得不平庸的业绩就要付出努力,提升App的性能是有效途径之一。贡献开源代码和分享技术文章的时间也是可以挤出来的。如果在工作中有出色的成绩,升职加薪只是时间问题。

第三回:桑梓惜别因缘浅 楷模入职即资深
诗曰:

北京买房要筑台,还有堵车与雾霾。

回到省会想定居,一问工资又回来。


北京的房价、堵车、雾霾逼得司马雼决定裸辞,逃离北上广,他的目的地是上了七年学的合肥。他刚辞职,老东家的最大竞争对手(全国top 20)和另一家全国top 10的大厂都邀请他去面试。他两个月来参加了这两家大厂和合肥当地两家大厂的面试。

面试官首先询问的总是Java和Android的高级特性,Java的高级特性主要有JVM模型、类加载机制和GC原理等,Android的高级特性主要有几大FLAG和LauchMode的区别和使用场景、Binder的引用和实体以及权限系统的交互等。司马雼对技术钻研很有深度,总是对答如流。


面试的第二阶段就是让司马雼自己去讲他做过的项目,然后面试官会冷不丁的让他去解释其中某一部分,有时候让他解释当时为什么要这么做,有时候问他现在觉得有没有更好的办法。司马雼处理问题的思路和解决问题的能力给面试官留下了深刻印象。


面试官有时候会问一些该企业所在行业需要关注的Android技术,比如研究输入法的公司会询问他Android手势和多点触摸,研究物联网的公司会问他Bluetooth相关知识等。因为司马雼广泛涉猎Android知识,他的技术广度也让面试官啧啧赞叹。

每次面试官问司马雼:“你还有什么想和我说的吗?”的时候,司马雼就把他的技术博客和开源项目一股脑砸向面试官,面试官是司马雼的粉丝或者面试官正在用司马雼的开源项目的情况发生了好几次。

司马雼在合肥拿到了两个资深Android工程师的offer,尽管合肥房价不到北京的1/3,可是最多30W的年薪让司马雼在合肥买房遥遥无期。这时司马雼接到了一个电话,逃离北京前面试的全国top 10的大厂给了他60W年薪和项目经理、技术经理、资深工程师的title。他决定逃回北上广,逃离北上广的计划刚开始就结束了。

异史氏曰:有多年工作经验的求职者几乎不需要在求职网站上投简历,想让你做他的同时的同行朋友会内推你。社招面试和校招面试是不同的,社招面试没有固定的问题和模式,临时抱佛脚是行不通的。社招面试基本都会考察这几个问题:第一个阶段是Android和Java的高级特性,考察技术深度;第二个阶段是讲述自己的项目,并在中间穿插着问题,考察解决问题的经验;第三个阶段(未必有)是问该公司所在行业需要掌握的Android知识,考察技术广度和快速上手情况。技术博客和开源项目是很重要的加分项,如果平时不积累、不分享,求职者会失去很多机会。二三线城市的房价更亲民,但工资非常不人性,逃离北上广需谨慎。

第四回:专家立功施小计 淑女出闺成大礼
诗曰:

经验丰富技术精,消除隐患立大功。

全球大会登讲台,抱得淑女入后宫。


话说司马雼所在的团队负责公司的Android客户端的安全工作,工作内容包含保活、防拦截、防篡改和防反编译等工作。他发现自家App存在不少可能被恶意利用的隐患:

首先,坏人可以通过NotificationListenerService拦截自家App的推送,给用户造成自家App没有推送的假象。


其次,在上一条基础上。坏人可以在虚拟机里运行一个窃取推送App,收到自家App推送后,用AccessibilityService打开Notification对应的Activity,找到里面的WebView,然后取得链接及网页中的内容,稍加修改(换logo、改名字)推送给坏人自己的App。


此外公司的微信公众号打开自己App需要用浏览器打开链接,这也给坏人以可乘之机。


更有甚者,坏人最丧心病狂的手段就是卸载了自家App后,在肉鸡中安装一个与自家App的packgaeName一致,但Signature不一样而且没有launcher的假App,这样肉鸡的用户永远也安装不了自家App,而且还不能用长按拖拽桌面icon进垃圾桶的方式删除假App。

司马雼花了两年时间为公司消除了以上隐患,荣升架构师、技术专家(时间没错,这是小说,出现未来时间很正常)。各大IT论坛、IT活动的聘书和邀请函也如雪片般飞来,不是邀请他做特约作者,就是邀请他当讲座嘉宾。

某IT大会在北京举行,司马雼作为特约嘉宾在台上妙语连珠、口若悬河。大会期间,司马雼结识了某IT社区的技术编辑椎名,这位淑女负责大会的后勤和报道工作。椎名不但知书达理、兰心蕙质,相貌也倾国倾城,有诗为证:
乐天浔阳歌《长恨》,陈王洛水赋《感甄》。

摩诘青溪《西施咏》,潇湘红楼《明妃吟》。


没错,这诗集合了白居易《长恨歌》、曹植《感甄赋》、王维《西施咏》、林黛玉《明妃吟》,椎名的美貌用古往今来的美女诗都搁一块也写不完。淑女椎名倾慕司马雼的才华,从此司马雼正式脱单。

不久,年薪100W的司马雼在北京买房定居。又过了几个月,这对为我国IT事业做出了巨大贡献的情侣在北京举办了盛大的婚礼。

异史氏曰:公司大到一定程度,别有用心的竞争对手就会搞小动作,因此想成为大厂的技术专家,懂点安全方面的知识是很有帮助的。程序员是经常被嘲笑为“注定孤独一生”的群体,但出人头地的程序员抱得美人归的可能性非常大,毕竟女人的颜值通常和她的男朋友的收入成正比。
 
本文首发于51CTO的IT故事汇:http://mdsa.51cto.com/art/201707/543909.htm 收起阅读 »

微信后台基于时间序的海量数据冷热分级架构设计实践

   微信的后台数据存储随着微信产品特性的演进,经历了数次的架构改造,才形成如今成熟的大规模分布式存储系统,有条不紊的管理着由数千台异构机型组成的机器集群,得以支撑每天千万亿级的访问、键值以及 PB 级的数据。

   作为以手机为平台的移动社交应用,微信内大部分业务生成的数据是有共性可言的:数据键值带有时间戳信息,并且单用户数据随着时间在不断的生成。我们将这类数据称为基于时间序的数据。比如朋友圈中的发表,或者移动支付的账单流水等业务生成的数据都满足这样的特征。基于时间序的数据都天然带有冷热分明属性――这是由手机的物理特性决定的,它的尺寸有限的屏幕所展示的数据只能分屏,通过手指的滑动,平滑而又连续的沿时间轴依次访问――通常是由最新生成的数据,慢慢回溯到较早前的数据。同时朋友圈等业务都是信息读扩散的应用场景,这就意味着它们生成的后台数据具有读多写少的鲜明特征。
  1. 在微信的实际应用场景中,这类数据的主要特点包括:数据量大、访问量大、重要程度高等。这些特点在现网的实际运营过程中,给我们带来了非常大的挑战,主要包括:
  2. 数据量大,需求的存储容量高――基于时间序的数据通常不会删除,而是随着时间不断积累,数据量达到 PB 级别,相应需要的存储空间也与日俱增;
  3. 访问量大,节日效应明显――基于时间序的数据往往是热点业务生成的数据,它们的访问量居高不下,基本维持在每分钟数十亿次的级别。尤其是在节日期间,瞬发访问量更可达平日的三至五倍;
  4. 重要性高,用户感知明显,数据一旦丢失,导致用户不能正常使用产品,并因此而转化成的投诉率高。


   通过堆机器来横向扩展存储自然可以应对如上的各种挑战,然而在成本预算紧张的前提下,机器数目是有限的。在这种情况下,基于时间序的海量数据的冷热分级架构便应运而生。该架构正是为了应对后台日益膨胀的这类数据,本着充分利用机器资源,发挥各种硬件介质特长的原则,结合数据的冷热分明、读多写少的访问特征而开发和设计出来的。它基于数据分层的理念,根据不同时间段的数据在访问热度和数据量上的差异,定制不同的服务策略,在纵向上扩展存储的边界。横向扩展存储是易于理解的,通过向原集群中增加相同类型的机器――其中必然涉及到一轮历史数据的迁移――最终新旧机器负载均衡,彼此之间并无差异的对外提供服务。在这种方案下,数据横向流动,系统一视同仁的对待,显然并无因地制宜思想的容身之所。而纵向扩展存储的架构便提供了这样一种思路:

   对热点数据,数据量少,但承担的访问流量大,我们当然是希望它们能常驻内存,因此系统提供了有强一致保证的内存层,在应对突发流量时,也可在不涉及历史数据迁移的前提下,单独、动态的快速扩展内存层。

   对历史数据,数据存量大,但承担的访问量非常有限,我们当然是不希望用昂贵的固态硬盘来存储它们,因此,系统提供了廉价的机械盘层,并且有一套透明的冷数据剥离和批量下沉的流程,将存储层中历史数据源源不断的抽离到机械盘层。

   通过这样的一种纵向分层、单独扩展的思路,即为我们系统提供了极大的灵活性,解决了节日期间存储层面临的内存瓶颈,以从长远的角度为我们缓解了成本压力,解决了存储层面临的磁盘容量瓶颈。

   当然一套成功的大型分布式系统仅有这些是不够的,还必须包括数据多副本复制策略以及分区算法等,也要有能应对复杂的现网运营环境的能力。我们结合各层的服务特点,制订了相对应的数据强一致算法,如内存层通过版本号控制来保证与存储层的完全一致,存储层通过 Paxos Group 实现多副本容灾,而机械盘层则通过串行写来保证。我们同时也实现了自己的去中心化的数据路由算法,确保了数据和流量的均匀分布,并且保证这种特性在横向扩展后依然成立。

   通过如上工作的努力,环环相扣,我们的基于时间序的海量数据的冷热分层架构成功的应对了 PB 级数据、千亿级访问以及万亿级键值带来的挑战。

系统设计
数据模型
本文提及的海量数据的冷热分级架构是专门服务于基于时间序的数据,它们主要特征为:

a). 数据键值带有时间戳信息 ;

b). 单用户数据随着时间在不断的生成。

   我们设计的架构强依赖于特性 a),各个环节基本上是依赖于键值中的时间戳来分发数据或者进行数据排序的。至于键值中的时间戳如何生成、全局是否维持统一时间、如何维持等则不在本文的讨论范围,通常这由前端的业务特性以及后台的时间服务器策略决定的。

   而特性 b) 则保证了本架构的必要性、实用性。如果数据规模有限,以用户的账户信息举例,它就像我们日常生活中的户口本,它只有一份,对单用户而言不会新增。则我们通常用固定的机器集群存储就可以,并且鲜有变更。而我们要处理的是用户的日记本、或者记账簿,它们每天都在不断生成新数据。

我们以现网某个集群的实例情况举例,说明下此类业务数据有如下的特点:

1.、数据量大,PB 级数据,万亿级键值,并且在源源不断的生成中,然而新生成的数据相较于历史存量数据占比小。下图展示了该集群数据在各时间段的一个占比情况。
001.jpg

2、访问量大,峰值可达每分钟数十亿次访问,尤其是在节日期间,用户高涨的热情更可以转化成平日三至五倍的访问量。同时具有冷热分明、读多写少 (读写比例甚至可达 100:1) 的访问特征,比如节日期间倍增的访问通常是对节日期间生成的新增数据的访问。下图展示了该集群访问在各时间段的一个占比情况。
002.jpg

3、数据安全性要求高,这类数据通常是用户感知敏感数据,一旦丢失,转化成的用户投诉率高。
003.jpg

存储层

004.jpg

数据强一致性保证
 
业务要求系统必须保证在数据的多份副本之间保持强一致性。――这是一个历久弥新的挑战。我们将分内存层、存储层、机械硬盘层分别来考虑数据的强一致性维持。
 
强一致缓存
 
正如前文描述,内存层作为一种强一致性分布式缓存,它完全是向存储层对齐的,自身无法判别数据有效性,本身多副本之间也没有交互的必要。它对前端而言是只读的,所有的写请求并不通过它,它只能算是存储层中数据的一个视图。所以它对前端数据有效性的承诺完全是依赖于存储层的正确性的。
 
Paxos Group
 
我们基于 Paxos Group 实现了存储层的数据一致性,通过采用无租约的方式,使得系统在保证强一致性的前提下达到了最大的可用性。Paxos 算法是由 Lesile Lamport 在论文中首提的,它唯一的作用是在多个参与者之间唯一的确定一个常量值。――这点同分布式存储没有直接关联的。我们在 Paxos 算法的基础上,设计出基于消息驱动的 Paxos Log 组件――每一条操作日志都要 Paxos 算法来确定,再进一步实现了基于 Paxos Log 的强一致性读写。

Paxos Group 因为采用了无主模型,组内所有机器在任一时刻都处于相同的地位。Paxos 算法本质是个多副本同步写算法,当且仅当系统中的多数派都接受相同值后,才会返回写成功。因此任意单一节点的失效,都不会出现系统的不可用。

强一致性写协议的主要问题来源于 Paxos 算法本身,因为要确保数据被系统内的多数派接受,需要进行多阶段的交互。我们采用如下的方法,解决了 paxos 算法写过程中出现的问题:基于 fast accept 协议优化了写算法,降低了写盘量以及协议消息发送、接收次数,最终实现了写耗时和失败的降低;基于随机避让、限制单次 Paxos 写触发 Prepare 的次数等方法,解决了 Paxos 中的活锁问题。

强一致性读协议本身和 Paxos 算法并没有太大的关系,只要确认多副本之间的多数派,即可获取到最新的数据。我们通过广播的方式获取到集群中多数机器(包含自身)的 paxos log 的状态,然后判断本机数据的有效性。

当系统中的单机节点失效,数据完全丢失的时候――这种情况是可以算是 Paxos 算法的盲区,因为该算法基于所有的参与者都不会违背自己曾经的承诺,即拜占庭失败而导致的数据不一致。――而这种情况在现网运营中可谓是常态,因此,我们引入了 Learner Only 模式。在该模式下故障机只接收已提交的数据,而不参与 Paxos 协议的写过程,意即不会因数据丢失而违背任何承诺。然后通过异步 catch up 和全量数据校验快速从其它副本中恢复数据。

为了防止多节点同时失效,我们将数据的多副本分布在不同园区的机器上。园区是同一个城市不同数据中心的概念。如此,我们的结构足以应对单数据中心完全隔离级别的灾难。
 
串行写入
 
因为对客户端透明,冷数据下沉流程作为机械硬盘层的唯一写者,则该层的数据一致性是易于实现的。我们通过三副本串行写入、全部提交才算成功的方式来实现了多副本之间的数据一致性。

作为补充,冷数据集群为数据块增加了 CRC 校验和一致性恢复队列,当单机数据不可用 (丢失或者损坏) 时,首先客户端会跳转到其它备份中读 (三机同时对外提供读服务),一致性恢复队列会异步的从其它备份数据块中恢复本机数据。

因为采用了 No Raid 方式组织的盘组,并且同组机器间盘级别数据文件一致,在单盘故障引发数据丢失时,只要从其它机器相同序盘中传输数据文件即可。

数据分区
 
静态映射表
 
数据分区的主要目的是为了确保同层机器间的负载均衡,并且当机器规模发生变化后,在最终仍然可以达到负载均衡的一种状态。

经典的一致性哈希算法的初衷是为了健壮分布式缓存,基于运行时动态的计算哈希值和虚拟节点来进行寻址。数据存储与分布式缓存的不同在于,存储必须保证数据映射的单调性,而缓存则无此要求,所以经典的一致性哈希通常会使用机器 IP 等作为参数来进行哈希,这样造成的结果一方面是数据的落点时而发生改变,一方面是负载通常不均衡。因此我们改造了此算法。

我们通过预计算虚拟节点随机数的方法,生成了割环点同实体机器之间的映射表。该映射表最多可支持一千组的集群规模,满足在任意组数情况下,实体机器间割段长度维持差异在 2% 以内;并且增加任意组数 (总组数上限不超过一千组),变动后的实体机器间的割段长度依然维持差异在 2% 以内。我们将此映射表硬编码,在运行时避免了计算的过程,数据根据键值哈希值寻址时,只要经过一次二分查找即可获取到对应的实体机器的编号。我们在内存层、存储层以及机械硬盘层都采用了这个映射表,保证了数据在各层路由算法的一致。在工程实现方面,我们可以合理使用这个特性来批量合并请求,以降低资源消耗,这在稍后的章节会有详细描述。
 
组内均衡
 
组是数据分区的独立单元,是虚拟节点对应的实体单位。组之间是互相独立的。每组由多台物理机器组成,这是 Paxos Group 生效的基本单位。一份数据包括的多份副本分别散落在组内的各台机器上。为了在组内机器上保证负载均衡,我们同样设计了一套算法,规定了数据副本之间的访问优先级,前端会依优先级逐一的请求数据,只要成功获取,即中断这个过程。然后我们再将副本按优先级均匀的散落在组内机器上,如此即可实现组内负载的均衡。
 
数据迁移
 
静态映射表是非常灵活的,在不达到组数上限的情况下,可以任意的增加一组或者多组机器。当然这个过程中一些数据的路由映射发生了改变,则就涉及到了历史数据的挪腾。为了在挪腾的过程中不影响服务,保证数据依然可读可写,我们开发出了对前端透明的,基于迁移标志位,通过数据双写和异步挪数据的方式实现的安全的、可回退的数据迁移流程。
 
最小不变块
 
存储层和机械硬盘层通过冷数据链接耦合在了一起。因为两层使用了相同的映射表,那么当存储层因扩容而发生迁移时,那么冷数据链接无疑也要重新寻址,进行一轮重新定位。如果我们以单键值为粒度记录冷数据链接和进行冷数据下沉,那么在万亿键值的语境下,效率无疑是低下。因此我们设计了最小不变块的算法,通过两阶段哈希,使用中间的哈希桶聚集数据,将数据键值和冷数据存储层的机器路由隔离开来。通过该算法,我们可以实现:批量的转存冷数据、热数据存储层批量的以块 (block) 为单位记录冷数据链接、当热数据存储层发生扩容时,块 (block) 内的数据不因扩容被打散掉,而可以整体的迁移到新目标机上。
 
工程实现
 
糟糕的工程实现可以毁掉一个完美的系统设计,因此,如何在工程实现的过程中,通过技术的手段,提升系统的表现,同样值得重视。
 
高效缓存
 
内存层的设计严重依赖存储层数据版本号的高效获取,那自然是版本号请求全落在内存中就可以了。因此,针对这种情况我们为定长的版本号设计了一套极简的、轻量的、行之有效的缓存――内存容量不足以支撑版本号全缓存。
005.jpg

它的数据结构只是一个二维数组,一维用来构建 hash 链,一维用来实现 LRU 链。每次读或者写都需要通过数组内数据的挪动,来进行更新。如此一来,我们就通过千万级数目的 LRU 链群,实现了缓存整体的 LRU 淘汰。它具有定长,可共享内存搭载,进程重启不丢失、内存使用率高等优点。
 
批量操作
 
对系统服务器而言,前端访问过来的某个请求,其对应的逻辑操作都是串行的,我们自然可以梳理这个串行流程中的 CPU 消耗点进行优化。然而当主要的瓶颈被逐渐的消灭掉后,CPU 消耗点变得分散,优化效果就变得微乎其微了。因此,我们只能寻找其它突破点。

我们发现在存储引擎、一致性协议算法的实现流程中,逻辑操作步骤多,涉及到网络交互,硬盘读写等过程。因此,我们决定合并不同请求中的相同步骤,实现批量化操作,极大的优化了 CPU 消耗。

合并的代价即是耗时略有增加,我们通过快慢分离,只针对热点数据请求中的逻辑操作进行合并,去掉了耗时中的不稳定因子,减少了耗时抖动。
 
请求合并
 
既然单机的逻辑操作性能已经得到了极大的提升,那么前后端的网络交互阶段,包括接入层的打包解包、协议处理等环节,成为了资源的主要消耗点。参考批量操作的经验,我们同样使用批量化的技术来优化性能――即将后台访问过来的单条请求 (Get) 在内存层聚合成一次批量请求 (Batch Get)。
 
路由收敛
 
因为每个数据都是根据键值单独进行路由的,如果要进行请求合并,我们就必须确保同一个批量请求内的数据,都会寻址到相同的 Paxos Group 上。因此,我们必须在内存层将落到同一台存储机器上的 Get 请求聚合起来。我们首先在内存层和存储层采用了相同的路由算法,然后将内存层的组数同存储层的组数进行对齐,来完成了这一目标。

006.jpg


相关工作
 
在设计的阶段,我们充分的调研了业界的各类方案,大到系统的整体架构,小到具体的技术点。各种方案自有应用场景、各有千秋,不能单纯以好坏区别,我们同样基于自己的业务场景,谨慎的选择合适的方案,或者弃而不用。在此尽量叙述。

处理 SNS 类业务生成的数据,业界有多种的冷热分离架构可以参考。我们以 Facebook 的 Cold Storage 系统举例而言,它也是基于冷热分层的想法,设计出了服务它们照片业务数据的存储方案。不同的是它采用了软硬件结合的方法,一方面定制专门的服务器(包括硬盘、电源等)和数据中心,一方面降低冷数据的备份数、增加纠删码等手段。

然而它们的经验我们是无法彻底套用的,主要两种原因:我们可使用的机器机型是固定的,不存在自己定制硬件的条件。同时它处理的是照片这种大 value 的数据。而我们基本上是文本这种类型的小 value 数据。从前文提及的 TB 访问量角度来看,它们处理的数据是容量瓶颈的,而我们处理的是 IO 瓶颈的,可以算是不太冷的冷数据带来的挑战。所以,我们只能实现自己的冷数据管理策略。

同样,业界有诸多关于如何实现数据一致性的方案。包括我们微信自研的 Quorum 协议,它是一种 NWR 协议,采用异步同步的方式实现数据多副本。即然是异步同步,那在多副本达到最终一致,必然存在一个时间差,那么在单机出现离线的情况下,就会有一定概率导致数据的不可用。而我们追求的是在单点故障下,所有的数据都保证强可用性。

因此,我们采用了无主的去中心化的 Paxos Group 实现了这一目标,其中非租约是 PaxosStore 架构的一个创新亮点。在故障时通常系统是抖动的,会有时断时续的状况,常见的租约做法在这种场景下容易出现反复切换主机而导致长期不可用,而 PaxosStore 的非租约结构能够轻松应对,始终提供良好的服务。PaxosStore 核心代码正在整理开源当中,预计四季度会正式发布,同时该项目的底层框架也基于我们已开源的协程库 github.com/libco。
 
转自“计算机与网络安全”,作者杨平安
继续阅读 »
   微信的后台数据存储随着微信产品特性的演进,经历了数次的架构改造,才形成如今成熟的大规模分布式存储系统,有条不紊的管理着由数千台异构机型组成的机器集群,得以支撑每天千万亿级的访问、键值以及 PB 级的数据。

   作为以手机为平台的移动社交应用,微信内大部分业务生成的数据是有共性可言的:数据键值带有时间戳信息,并且单用户数据随着时间在不断的生成。我们将这类数据称为基于时间序的数据。比如朋友圈中的发表,或者移动支付的账单流水等业务生成的数据都满足这样的特征。基于时间序的数据都天然带有冷热分明属性――这是由手机的物理特性决定的,它的尺寸有限的屏幕所展示的数据只能分屏,通过手指的滑动,平滑而又连续的沿时间轴依次访问――通常是由最新生成的数据,慢慢回溯到较早前的数据。同时朋友圈等业务都是信息读扩散的应用场景,这就意味着它们生成的后台数据具有读多写少的鲜明特征。
  1. 在微信的实际应用场景中,这类数据的主要特点包括:数据量大、访问量大、重要程度高等。这些特点在现网的实际运营过程中,给我们带来了非常大的挑战,主要包括:
  2. 数据量大,需求的存储容量高――基于时间序的数据通常不会删除,而是随着时间不断积累,数据量达到 PB 级别,相应需要的存储空间也与日俱增;
  3. 访问量大,节日效应明显――基于时间序的数据往往是热点业务生成的数据,它们的访问量居高不下,基本维持在每分钟数十亿次的级别。尤其是在节日期间,瞬发访问量更可达平日的三至五倍;
  4. 重要性高,用户感知明显,数据一旦丢失,导致用户不能正常使用产品,并因此而转化成的投诉率高。


   通过堆机器来横向扩展存储自然可以应对如上的各种挑战,然而在成本预算紧张的前提下,机器数目是有限的。在这种情况下,基于时间序的海量数据的冷热分级架构便应运而生。该架构正是为了应对后台日益膨胀的这类数据,本着充分利用机器资源,发挥各种硬件介质特长的原则,结合数据的冷热分明、读多写少的访问特征而开发和设计出来的。它基于数据分层的理念,根据不同时间段的数据在访问热度和数据量上的差异,定制不同的服务策略,在纵向上扩展存储的边界。横向扩展存储是易于理解的,通过向原集群中增加相同类型的机器――其中必然涉及到一轮历史数据的迁移――最终新旧机器负载均衡,彼此之间并无差异的对外提供服务。在这种方案下,数据横向流动,系统一视同仁的对待,显然并无因地制宜思想的容身之所。而纵向扩展存储的架构便提供了这样一种思路:

   对热点数据,数据量少,但承担的访问流量大,我们当然是希望它们能常驻内存,因此系统提供了有强一致保证的内存层,在应对突发流量时,也可在不涉及历史数据迁移的前提下,单独、动态的快速扩展内存层。

   对历史数据,数据存量大,但承担的访问量非常有限,我们当然是不希望用昂贵的固态硬盘来存储它们,因此,系统提供了廉价的机械盘层,并且有一套透明的冷数据剥离和批量下沉的流程,将存储层中历史数据源源不断的抽离到机械盘层。

   通过这样的一种纵向分层、单独扩展的思路,即为我们系统提供了极大的灵活性,解决了节日期间存储层面临的内存瓶颈,以从长远的角度为我们缓解了成本压力,解决了存储层面临的磁盘容量瓶颈。

   当然一套成功的大型分布式系统仅有这些是不够的,还必须包括数据多副本复制策略以及分区算法等,也要有能应对复杂的现网运营环境的能力。我们结合各层的服务特点,制订了相对应的数据强一致算法,如内存层通过版本号控制来保证与存储层的完全一致,存储层通过 Paxos Group 实现多副本容灾,而机械盘层则通过串行写来保证。我们同时也实现了自己的去中心化的数据路由算法,确保了数据和流量的均匀分布,并且保证这种特性在横向扩展后依然成立。

   通过如上工作的努力,环环相扣,我们的基于时间序的海量数据的冷热分层架构成功的应对了 PB 级数据、千亿级访问以及万亿级键值带来的挑战。

系统设计
数据模型
本文提及的海量数据的冷热分级架构是专门服务于基于时间序的数据,它们主要特征为:

a). 数据键值带有时间戳信息 ;

b). 单用户数据随着时间在不断的生成。

   我们设计的架构强依赖于特性 a),各个环节基本上是依赖于键值中的时间戳来分发数据或者进行数据排序的。至于键值中的时间戳如何生成、全局是否维持统一时间、如何维持等则不在本文的讨论范围,通常这由前端的业务特性以及后台的时间服务器策略决定的。

   而特性 b) 则保证了本架构的必要性、实用性。如果数据规模有限,以用户的账户信息举例,它就像我们日常生活中的户口本,它只有一份,对单用户而言不会新增。则我们通常用固定的机器集群存储就可以,并且鲜有变更。而我们要处理的是用户的日记本、或者记账簿,它们每天都在不断生成新数据。

我们以现网某个集群的实例情况举例,说明下此类业务数据有如下的特点:

1.、数据量大,PB 级数据,万亿级键值,并且在源源不断的生成中,然而新生成的数据相较于历史存量数据占比小。下图展示了该集群数据在各时间段的一个占比情况。
001.jpg

2、访问量大,峰值可达每分钟数十亿次访问,尤其是在节日期间,用户高涨的热情更可以转化成平日三至五倍的访问量。同时具有冷热分明、读多写少 (读写比例甚至可达 100:1) 的访问特征,比如节日期间倍增的访问通常是对节日期间生成的新增数据的访问。下图展示了该集群访问在各时间段的一个占比情况。
002.jpg

3、数据安全性要求高,这类数据通常是用户感知敏感数据,一旦丢失,转化成的用户投诉率高。
003.jpg

存储层

004.jpg

数据强一致性保证
 
业务要求系统必须保证在数据的多份副本之间保持强一致性。――这是一个历久弥新的挑战。我们将分内存层、存储层、机械硬盘层分别来考虑数据的强一致性维持。
 
强一致缓存
 
正如前文描述,内存层作为一种强一致性分布式缓存,它完全是向存储层对齐的,自身无法判别数据有效性,本身多副本之间也没有交互的必要。它对前端而言是只读的,所有的写请求并不通过它,它只能算是存储层中数据的一个视图。所以它对前端数据有效性的承诺完全是依赖于存储层的正确性的。
 
Paxos Group
 
我们基于 Paxos Group 实现了存储层的数据一致性,通过采用无租约的方式,使得系统在保证强一致性的前提下达到了最大的可用性。Paxos 算法是由 Lesile Lamport 在论文中首提的,它唯一的作用是在多个参与者之间唯一的确定一个常量值。――这点同分布式存储没有直接关联的。我们在 Paxos 算法的基础上,设计出基于消息驱动的 Paxos Log 组件――每一条操作日志都要 Paxos 算法来确定,再进一步实现了基于 Paxos Log 的强一致性读写。

Paxos Group 因为采用了无主模型,组内所有机器在任一时刻都处于相同的地位。Paxos 算法本质是个多副本同步写算法,当且仅当系统中的多数派都接受相同值后,才会返回写成功。因此任意单一节点的失效,都不会出现系统的不可用。

强一致性写协议的主要问题来源于 Paxos 算法本身,因为要确保数据被系统内的多数派接受,需要进行多阶段的交互。我们采用如下的方法,解决了 paxos 算法写过程中出现的问题:基于 fast accept 协议优化了写算法,降低了写盘量以及协议消息发送、接收次数,最终实现了写耗时和失败的降低;基于随机避让、限制单次 Paxos 写触发 Prepare 的次数等方法,解决了 Paxos 中的活锁问题。

强一致性读协议本身和 Paxos 算法并没有太大的关系,只要确认多副本之间的多数派,即可获取到最新的数据。我们通过广播的方式获取到集群中多数机器(包含自身)的 paxos log 的状态,然后判断本机数据的有效性。

当系统中的单机节点失效,数据完全丢失的时候――这种情况是可以算是 Paxos 算法的盲区,因为该算法基于所有的参与者都不会违背自己曾经的承诺,即拜占庭失败而导致的数据不一致。――而这种情况在现网运营中可谓是常态,因此,我们引入了 Learner Only 模式。在该模式下故障机只接收已提交的数据,而不参与 Paxos 协议的写过程,意即不会因数据丢失而违背任何承诺。然后通过异步 catch up 和全量数据校验快速从其它副本中恢复数据。

为了防止多节点同时失效,我们将数据的多副本分布在不同园区的机器上。园区是同一个城市不同数据中心的概念。如此,我们的结构足以应对单数据中心完全隔离级别的灾难。
 
串行写入
 
因为对客户端透明,冷数据下沉流程作为机械硬盘层的唯一写者,则该层的数据一致性是易于实现的。我们通过三副本串行写入、全部提交才算成功的方式来实现了多副本之间的数据一致性。

作为补充,冷数据集群为数据块增加了 CRC 校验和一致性恢复队列,当单机数据不可用 (丢失或者损坏) 时,首先客户端会跳转到其它备份中读 (三机同时对外提供读服务),一致性恢复队列会异步的从其它备份数据块中恢复本机数据。

因为采用了 No Raid 方式组织的盘组,并且同组机器间盘级别数据文件一致,在单盘故障引发数据丢失时,只要从其它机器相同序盘中传输数据文件即可。

数据分区
 
静态映射表
 
数据分区的主要目的是为了确保同层机器间的负载均衡,并且当机器规模发生变化后,在最终仍然可以达到负载均衡的一种状态。

经典的一致性哈希算法的初衷是为了健壮分布式缓存,基于运行时动态的计算哈希值和虚拟节点来进行寻址。数据存储与分布式缓存的不同在于,存储必须保证数据映射的单调性,而缓存则无此要求,所以经典的一致性哈希通常会使用机器 IP 等作为参数来进行哈希,这样造成的结果一方面是数据的落点时而发生改变,一方面是负载通常不均衡。因此我们改造了此算法。

我们通过预计算虚拟节点随机数的方法,生成了割环点同实体机器之间的映射表。该映射表最多可支持一千组的集群规模,满足在任意组数情况下,实体机器间割段长度维持差异在 2% 以内;并且增加任意组数 (总组数上限不超过一千组),变动后的实体机器间的割段长度依然维持差异在 2% 以内。我们将此映射表硬编码,在运行时避免了计算的过程,数据根据键值哈希值寻址时,只要经过一次二分查找即可获取到对应的实体机器的编号。我们在内存层、存储层以及机械硬盘层都采用了这个映射表,保证了数据在各层路由算法的一致。在工程实现方面,我们可以合理使用这个特性来批量合并请求,以降低资源消耗,这在稍后的章节会有详细描述。
 
组内均衡
 
组是数据分区的独立单元,是虚拟节点对应的实体单位。组之间是互相独立的。每组由多台物理机器组成,这是 Paxos Group 生效的基本单位。一份数据包括的多份副本分别散落在组内的各台机器上。为了在组内机器上保证负载均衡,我们同样设计了一套算法,规定了数据副本之间的访问优先级,前端会依优先级逐一的请求数据,只要成功获取,即中断这个过程。然后我们再将副本按优先级均匀的散落在组内机器上,如此即可实现组内负载的均衡。
 
数据迁移
 
静态映射表是非常灵活的,在不达到组数上限的情况下,可以任意的增加一组或者多组机器。当然这个过程中一些数据的路由映射发生了改变,则就涉及到了历史数据的挪腾。为了在挪腾的过程中不影响服务,保证数据依然可读可写,我们开发出了对前端透明的,基于迁移标志位,通过数据双写和异步挪数据的方式实现的安全的、可回退的数据迁移流程。
 
最小不变块
 
存储层和机械硬盘层通过冷数据链接耦合在了一起。因为两层使用了相同的映射表,那么当存储层因扩容而发生迁移时,那么冷数据链接无疑也要重新寻址,进行一轮重新定位。如果我们以单键值为粒度记录冷数据链接和进行冷数据下沉,那么在万亿键值的语境下,效率无疑是低下。因此我们设计了最小不变块的算法,通过两阶段哈希,使用中间的哈希桶聚集数据,将数据键值和冷数据存储层的机器路由隔离开来。通过该算法,我们可以实现:批量的转存冷数据、热数据存储层批量的以块 (block) 为单位记录冷数据链接、当热数据存储层发生扩容时,块 (block) 内的数据不因扩容被打散掉,而可以整体的迁移到新目标机上。
 
工程实现
 
糟糕的工程实现可以毁掉一个完美的系统设计,因此,如何在工程实现的过程中,通过技术的手段,提升系统的表现,同样值得重视。
 
高效缓存
 
内存层的设计严重依赖存储层数据版本号的高效获取,那自然是版本号请求全落在内存中就可以了。因此,针对这种情况我们为定长的版本号设计了一套极简的、轻量的、行之有效的缓存――内存容量不足以支撑版本号全缓存。
005.jpg

它的数据结构只是一个二维数组,一维用来构建 hash 链,一维用来实现 LRU 链。每次读或者写都需要通过数组内数据的挪动,来进行更新。如此一来,我们就通过千万级数目的 LRU 链群,实现了缓存整体的 LRU 淘汰。它具有定长,可共享内存搭载,进程重启不丢失、内存使用率高等优点。
 
批量操作
 
对系统服务器而言,前端访问过来的某个请求,其对应的逻辑操作都是串行的,我们自然可以梳理这个串行流程中的 CPU 消耗点进行优化。然而当主要的瓶颈被逐渐的消灭掉后,CPU 消耗点变得分散,优化效果就变得微乎其微了。因此,我们只能寻找其它突破点。

我们发现在存储引擎、一致性协议算法的实现流程中,逻辑操作步骤多,涉及到网络交互,硬盘读写等过程。因此,我们决定合并不同请求中的相同步骤,实现批量化操作,极大的优化了 CPU 消耗。

合并的代价即是耗时略有增加,我们通过快慢分离,只针对热点数据请求中的逻辑操作进行合并,去掉了耗时中的不稳定因子,减少了耗时抖动。
 
请求合并
 
既然单机的逻辑操作性能已经得到了极大的提升,那么前后端的网络交互阶段,包括接入层的打包解包、协议处理等环节,成为了资源的主要消耗点。参考批量操作的经验,我们同样使用批量化的技术来优化性能――即将后台访问过来的单条请求 (Get) 在内存层聚合成一次批量请求 (Batch Get)。
 
路由收敛
 
因为每个数据都是根据键值单独进行路由的,如果要进行请求合并,我们就必须确保同一个批量请求内的数据,都会寻址到相同的 Paxos Group 上。因此,我们必须在内存层将落到同一台存储机器上的 Get 请求聚合起来。我们首先在内存层和存储层采用了相同的路由算法,然后将内存层的组数同存储层的组数进行对齐,来完成了这一目标。

006.jpg


相关工作
 
在设计的阶段,我们充分的调研了业界的各类方案,大到系统的整体架构,小到具体的技术点。各种方案自有应用场景、各有千秋,不能单纯以好坏区别,我们同样基于自己的业务场景,谨慎的选择合适的方案,或者弃而不用。在此尽量叙述。

处理 SNS 类业务生成的数据,业界有多种的冷热分离架构可以参考。我们以 Facebook 的 Cold Storage 系统举例而言,它也是基于冷热分层的想法,设计出了服务它们照片业务数据的存储方案。不同的是它采用了软硬件结合的方法,一方面定制专门的服务器(包括硬盘、电源等)和数据中心,一方面降低冷数据的备份数、增加纠删码等手段。

然而它们的经验我们是无法彻底套用的,主要两种原因:我们可使用的机器机型是固定的,不存在自己定制硬件的条件。同时它处理的是照片这种大 value 的数据。而我们基本上是文本这种类型的小 value 数据。从前文提及的 TB 访问量角度来看,它们处理的数据是容量瓶颈的,而我们处理的是 IO 瓶颈的,可以算是不太冷的冷数据带来的挑战。所以,我们只能实现自己的冷数据管理策略。

同样,业界有诸多关于如何实现数据一致性的方案。包括我们微信自研的 Quorum 协议,它是一种 NWR 协议,采用异步同步的方式实现数据多副本。即然是异步同步,那在多副本达到最终一致,必然存在一个时间差,那么在单机出现离线的情况下,就会有一定概率导致数据的不可用。而我们追求的是在单点故障下,所有的数据都保证强可用性。

因此,我们采用了无主的去中心化的 Paxos Group 实现了这一目标,其中非租约是 PaxosStore 架构的一个创新亮点。在故障时通常系统是抖动的,会有时断时续的状况,常见的租约做法在这种场景下容易出现反复切换主机而导致长期不可用,而 PaxosStore 的非租约结构能够轻松应对,始终提供良好的服务。PaxosStore 核心代码正在整理开源当中,预计四季度会正式发布,同时该项目的底层框架也基于我们已开源的协程库 github.com/libco。
 
转自“计算机与网络安全”,作者杨平安 收起阅读 »

环信移动客服v5.21已发布,支持客服发送语音消息、语音转文字及支付功能

客服模式

支持客服发送语音消息

Web版客服工作台支持发送语音消息。与app渠道的客户聊天时,客服可以向客户发送语音消息。

点击输入框上方的麦克风按钮,开始录音并发送。每条语音消息最多为60秒,达到60秒后自动发送。

注:发送语音消息功能仅Chrome浏览器在https模式下支持。 
001.png

管理员模式

语音转文字beta版

Web版客服工作台支持将app、微信、微博渠道的客户的语音消息自动转为文字,并显示在语音消息下方。方便客服快速识别客户的消息内容,并作出回应。

客服模式的会话、待接入、历史会话、客户中心页面,管理员模式的搜索、历史会话、客户中心、当前会话、质量检查页面,均支持显示语音消息对应的文字。 
002.png

语音转文字功能正在beta测试阶段,如果您希望先行体验,请提供租户ID,并联系环信商务经理。

开通语音转文字功能后,需要进入“管理员模式 > 设置 > 系统开关”页面,打开“启用语音转文字服务”开关。 
003.png

在线支付

在线支付功能全新上线。支持在web版移动客服工作台购买标准版坐席、对租户进行续费、增购坐席,并查看订单信息。

进入“管理员模式 > 设置 > 企业信息”页面,点击“购买”按钮。 
004.png

选择“缴费类型”、购买期限,填写坐席数量,确定并支付订单。

目前,只提供标准版坐席的在线支付功能。缴费类型包括:
  • 新购:第一次购买坐席时,请选择“新购”;
  • 续费:需要延长租户的到期日,请选择“续费”;
  • 增购:在已有坐席的基础上,增加坐席数量,请选择“增购”。


注:增购坐席时,坐席的到期日与租户的到期日一致,我们按比例收取坐席费用。 
005.png

【优化】客服超时未回复提醒客服

原“客服超时未回复访客端提示”开关更名为“客服超时未回复提示”,并支持设置“提醒客服”和“提醒访客”。

进入“管理员模式 > 设置 >系统开关”页面,对“客服超时未回复提示”的开关进行设置。

“提醒客服”开关打开,客服超时未回复时,会话主动排在进行中会话列表的顶部并标注颜色。
“提醒访客”开关打开,客服超时未回复时,系统自动发送一条提示语给客户。

006.png

进行中会话列表提醒示例: 
007.png

【优化】工作量、工作质量支持导出客服的真实姓名

对客服的工作量、工作质量详情进行导出时,导出文件包含客服的真实姓名,便于识别对应客服,使数据更直观。
 
环信移动客服更新日志http://docs.easemob.com/cs/releasenote/5.21

环信移动客服登陆地址http://kefu.easemob.com/ 
继续阅读 »
客服模式

支持客服发送语音消息

Web版客服工作台支持发送语音消息。与app渠道的客户聊天时,客服可以向客户发送语音消息。

点击输入框上方的麦克风按钮,开始录音并发送。每条语音消息最多为60秒,达到60秒后自动发送。

注:发送语音消息功能仅Chrome浏览器在https模式下支持。 
001.png

管理员模式

语音转文字beta版

Web版客服工作台支持将app、微信、微博渠道的客户的语音消息自动转为文字,并显示在语音消息下方。方便客服快速识别客户的消息内容,并作出回应。

客服模式的会话、待接入、历史会话、客户中心页面,管理员模式的搜索、历史会话、客户中心、当前会话、质量检查页面,均支持显示语音消息对应的文字。 
002.png

语音转文字功能正在beta测试阶段,如果您希望先行体验,请提供租户ID,并联系环信商务经理。

开通语音转文字功能后,需要进入“管理员模式 > 设置 > 系统开关”页面,打开“启用语音转文字服务”开关。 
003.png

在线支付

在线支付功能全新上线。支持在web版移动客服工作台购买标准版坐席、对租户进行续费、增购坐席,并查看订单信息。

进入“管理员模式 > 设置 > 企业信息”页面,点击“购买”按钮。 
004.png

选择“缴费类型”、购买期限,填写坐席数量,确定并支付订单。

目前,只提供标准版坐席的在线支付功能。缴费类型包括:
  • 新购:第一次购买坐席时,请选择“新购”;
  • 续费:需要延长租户的到期日,请选择“续费”;
  • 增购:在已有坐席的基础上,增加坐席数量,请选择“增购”。


注:增购坐席时,坐席的到期日与租户的到期日一致,我们按比例收取坐席费用。 
005.png

【优化】客服超时未回复提醒客服

原“客服超时未回复访客端提示”开关更名为“客服超时未回复提示”,并支持设置“提醒客服”和“提醒访客”。

进入“管理员模式 > 设置 >系统开关”页面,对“客服超时未回复提示”的开关进行设置。

“提醒客服”开关打开,客服超时未回复时,会话主动排在进行中会话列表的顶部并标注颜色。
“提醒访客”开关打开,客服超时未回复时,系统自动发送一条提示语给客户。

006.png

进行中会话列表提醒示例: 
007.png

【优化】工作量、工作质量支持导出客服的真实姓名

对客服的工作量、工作质量详情进行导出时,导出文件包含客服的真实姓名,便于识别对应客服,使数据更直观。
 
环信移动客服更新日志http://docs.easemob.com/cs/releasenote/5.21

环信移动客服登陆地址http://kefu.easemob.com/  收起阅读 »

【环信公开课第14期视频回放】情感计算:如何用人工智能解读人类“情感”

        朱泙漫学屠龙于支离益 , 殚千金之家,三年技成而无所用其巧。

——《庄子·列御寇》

      6月25日,EmoKit创始人兼CEO魏清晨在环信公开课上以“情感计算”为主题做了人工智能解读人类“情感”的分享。魏清晨称,机器人未必像人的形态一样,有胳膊、有腿、有眼睛、有嘴,但如果要让机器实现真正智能,并且跟我们产生自然而然的交互,需要具备情绪识别和表达的能力。
 
  魏清晨讲到, EmoKit主要专注于机器人情感的研发,让机器人从一个多模态的形式了解人的情感,从渠道数据来源的角度去做综合判断,可以预见的未来,曾经独属于人类的情感将“赋能”人工智能!
 
公开课课程大纲 
  • 情感计算概述与发展

  1. 情绪是人类社会奖惩机制最底层的编码
  2. 情感计算包含的模块和价值
  3. 情感计算,是人工智能的下一个未来
  4. 情感计算的技术实现

  • 情感信号的获取与量化

  1. 分析、建模与识别
  2. 情感理解和反馈
  3. 情感合成与表达
  4. 人机交互的实现

  • AI+情感计算的应用

  1. 情感计算在环信IM的最佳实践
  2. 环信客服通过情感计算实现智能质检
  3. 更多落地场景
  4. 商业变现

  • AI火爆背景下的冷思考

 
视频回放

 






 
已有8625名开发者加入环信公开课,妹子比例10%!还有最强王者等你开黑!赶紧加入我们一起玩耍吧!
扫码.gif

 
 
继续阅读 »
        朱泙漫学屠龙于支离益 , 殚千金之家,三年技成而无所用其巧。

——《庄子·列御寇》

      6月25日,EmoKit创始人兼CEO魏清晨在环信公开课上以“情感计算”为主题做了人工智能解读人类“情感”的分享。魏清晨称,机器人未必像人的形态一样,有胳膊、有腿、有眼睛、有嘴,但如果要让机器实现真正智能,并且跟我们产生自然而然的交互,需要具备情绪识别和表达的能力。
 
  魏清晨讲到, EmoKit主要专注于机器人情感的研发,让机器人从一个多模态的形式了解人的情感,从渠道数据来源的角度去做综合判断,可以预见的未来,曾经独属于人类的情感将“赋能”人工智能!
 
公开课课程大纲 
  • 情感计算概述与发展

  1. 情绪是人类社会奖惩机制最底层的编码
  2. 情感计算包含的模块和价值
  3. 情感计算,是人工智能的下一个未来
  4. 情感计算的技术实现

  • 情感信号的获取与量化

  1. 分析、建模与识别
  2. 情感理解和反馈
  3. 情感合成与表达
  4. 人机交互的实现

  • AI+情感计算的应用

  1. 情感计算在环信IM的最佳实践
  2. 环信客服通过情感计算实现智能质检
  3. 更多落地场景
  4. 商业变现

  • AI火爆背景下的冷思考

 
视频回放

 






 
已有8625名开发者加入环信公开课,妹子比例10%!还有最强王者等你开黑!赶紧加入我们一起玩耍吧!
扫码.gif

 
  收起阅读 »

《IT经理世界》特写:环信的Alpha刘,布局未来的商业智能!


微信图片_20170627113413.gif
6月20号刊

新疆界

微信图片_20170627111638.jpg

刘俊彦说不想做一家小老头公司——规模不大,每年挣个几千万元,日子过得滋润,但每年只有10%左右的增长。

技术男刘俊彦的思维很跳跃,2014年做即时通讯云,一年后开始做客服云,不到一年,又开辟了智能机器人业务。看起来好像在分片作战,但突然有一天他已经在一个更大的战略布局里了。

这些年,云的概念被炒到火热,企业不惜花血本布局云计算,可一轮下来之后,不同的业务还是要各养一套人马,各养一套软件系统,说好的大数据,量是上去了,但是实际利用率却如挤牙膏,效用微乎其微。很多企业现在正处在一个升级也不是,不升级也不是的难受期。

见到刘俊彦的时候,他刚送走一家航空公司的几位管理人员,他们现在的烦恼是,守着一大批高净值的用户,只能卖个机票,最多再卖个保险,利润已经碰到天花板,有种守着宝藏却挖不出金子的感觉。刘俊彦在他的小会议室的黑板上,画了一个完整的从用户服务到用户营销的闭环图,这张图里包含了航空公司乃至一些大企业当下的几大痛点及应对招数,如同在下一盘围棋,细节处棋势做得够厚,大局又跳出常人思维之外,细看与AlphaGo的风格颇为相似。

这是刘俊彦第一次将自己成熟的大局想法展示给外界。
 
高效融资与快速换挡
 
刘俊彦毕业于英国伦敦大学国王学院计算机专业,后一直在IT外企从事技术研发工作,2013年,离职创业前已经成为红帽开源软件领域领先的专家。这一年,他已经年过40。

最初的一年多时间,是在海淀图书城的车库咖啡里度过的,当时刘俊彦和另外三位合伙人都刚从外企里出来,各自都已经是行业里优秀的技术人才,都实现了财务自由,清楚自己要的是什么,且志趣相投,所以走到了一起。

刚开始,大家专注于做产品,也没有急着去找投资。一年后,一个偶然的机会,投资自己找上了门。

2014年5月,刘俊彦他们进驻到氪空间的当天下午,经纬的投资人找到了他们,大概聊了两个多小时,双方就达成了合作意向。紧接着不到半年,SIG和红杉资本相继成为投资方。几家投资方看中的是刘俊彦等人创立的环信公司在即时通讯领域的开发能力和社交大数据分析能力,以及环信自主研发的高并发可扩展架构。

此前,刘俊彦拥有17年的开发经验,其擅长的领域在于实时消息系统和高并发消息中间件等。2013年,社交软件开始大行其道,当时很多人找他为APP开发即时通讯聊天功能,一般如果企业自己开发的话,怎么都需要好几个月时间,而使用刘俊彦的团队的产品只需一天功夫就出来了。因此,最初的产品并非他们刻意做出来的,而是需求在先,而且令他们也没想到的是,做着做着就成“风口”了。

很快,使用了环信即时通讯功能的APP上的用户从几万飞速上升到几千万,乃至后来的几个亿,每天下发的消息达20亿条。曾经在短信高峰时代,中国移动每天的消息量是7亿,目前国内能支撑并发连接几千万的团队不超过5个,包括腾讯、阿里、新浪微博、陌陌等,另外还有一个就是环信。

用户上去之后,新的需求又来了。开始,很多人只是把APP内的聊天功能用作连接人与人的社交管道,但很快就不断有人找上门来,希望把APP内的聊天功能做成淘宝旺旺那样连接人和商业的客服工具。

从本质上来讲,环信早期推出的即时通讯云是基于PaaS平台的服务,而要做客服云则需建立在SaaS平台上,如此跨平台的转变,对于一家创业公司,无论是人才、资本、研发或渠道等各方面都会带来严峻的挑战。

2015年4月,A轮的三家投资方在前几个轮次共900万美元的基础上,再次追加了共1250万美元的B轮投资,在资本方的财力和战略加持下,一个月后,环信客服产品线上市,一年后环信客服产品的客户量、销售额等硬指标均达到几十倍上百倍的增长。

据刘俊彦介绍,早期客服云的客户几乎一半多来自即时通讯云,相当于后者是前者的流量导入渠道,后者反过来巩固了前者的价值所在。

目前,环信客服产品的企业用户已经超过5万多家,用户也从国美在线、58到家、新东方等扩展到了十几个行业当中。

然而,IT业一年相当于传统行业十年,这是一个变换以秒速推进的行业,刘俊彦很快又迎上了新的挑战。

痛点与前瞻

随着产品的积累和行业的扩展,刘俊彦开始接触到一些保险、证券、航空等行业大客户。曾经有一家保险公司的客户跟他提到亲身经历的一件事情,以往保险公司客户经理做客户维护的通常做法就是每年会定期提前一两个月给老客户打电话,提醒他们保险快到期,可以续费了。其中有一个老客户,关系维护得挺好,但是这个老客户最近新买了辆哈雷摩托车,而他的客户经理没能及时了解并提供摩托车的保险报价,结果错失了老用户。

这种个案在保险公司普遍存在。如果有更懂用户的数据,进行再分析和精准营销,就能很快帮老用户接上新的业务,还可以把以前让利给渠道的部分,直接反馈给用户,大幅提高销售成功率。

刘俊彦说,做即时通讯,做客服,真正的差距在于,怎么通过商业智能帮助企业去挖掘以前看不到的客户信息,提高销售转换率,发掘新销售机会,以及人工智能技术怎么代替人工,怎么帮企业营销,这都是未来技术。

2016年年初,环信基于企业一体化智能商业的需求,开始推全媒体智能客户服务。所谓全媒体就是不管客服请求来自微信、微博或APP,还是网页或电话,都可以同时呈现在一个界面上,由专人统一处理。

以前企业不同的渠道由不同的人马在支持,各自软件系统也不一样,信息也是各自孤立的,片段化的,环信做到了让一个支持人员同时监控所有渠道,客户身份也可以从孤立的信息中关联起来,形成一个统一身份。也就是说,同一个用户打完电话,再用微信接入,通过各种技术方法可以跨屏身份合并被识别为是同一个人。

此外,一家企业如果每天进来10万条消息,环信的技术可以识别出来自不同渠道不同数据格式的信息,然后对其进行数据清理,再做主题分析和情感分析,从而知道用户今天都反馈了什么问题,情感是愤怒还是高兴,可能的消费趋势是什么?进一步还可以給出用户画像,画像信息详尽,一直可追溯到用户城市、职业、性别、喜好、消费能力、行为轨迹,等等。

这些数据对于企业至关重要。不仅是保险公司,证券公司、航空公司等等行业都存在类似的强烈需求。

环信还在自己研发客服机器人。刘俊彦认为,环信既有SaaS客服软件高市场占有率的通道优势,又有了大量的数据积累,加上对垂直行业的深度理解,在开发具有高度行业特征的客服机器人上,又领先了其他对手。

2017年 ,环信整合旗下即时通信云、移动客服、智能客服机器人和主动营销产品线,推出环信CEC (Customer Engagement Cloud),向企业提供从客户互动渠道,到客户服务,再到精准客户营销的全流程客户互动解决方案。

技术出身的刘俊彦,既可以不断挖掘出用户的痛点,在技术细节上下足功夫,又可以跳出来,把握住前瞻性技术,果断出击。当一个个看似不大相关的痛点技术在量的积累上突破一个爆发性临界点时,全新的需求与应用又把之前所有的技术关联在了一起。

这一切使得刘俊彦像一个“做局”的高手。

转变与坚持

创业仅仅4年,刘俊彦已经看惯了互联网领域的迎来送往,2014年,他还经常在微信里看见做社交应用的CEO们发朋友圈,到2015年左右,这些人大多看不到了,换了一批做O2O的CEO,一年以后,这些人又看不见踪影了。大浪淘沙,互联网的残酷淘汰是铁律。

当年那些做即时通讯服务的环信的老对手们,现在大多还在做老业务,日子过得还不错。刘俊彦却早已不在当初的格局里了。

做即时通讯云有一个特点,从几十万用户到几百万用户是一个技术节点,从几百万到几千万又是一个节点,用户过亿之后则是一个更大的节点。每一个节点处,基本上架构要推倒重写一遍。这要求技术团队快速的迭代和积累,一旦有一个环节出问题,就有可能导致服务不可用。

这期间,环信团队也经历了重大考验,也被客户骂过,好在最后都坚持过来了。现在环信即时通讯技术架构早已稳定下来,即使再扩容4~5倍也不成问题。

然而,就在这么一个节点上,刘俊彦毅然决定再另外做一个SaaS平台,这对于整个团队是一种怎样的震撼。虽然对于技术能力强悍的环信团队来讲,技术难题最终都是可以克服的,而对市场的敏锐嗅觉以及果断决策,却非易事。事实上刘俊彦的判断是精准的。

环信最初的客户群主要集中在互联网领域,这些客户的生命周期比较短,付费能力比较低,好处是决策周期短,商业谈判简单,能迅速达成交易,迅速验证需求,这适合早期创业。

有了这段经历也让刘俊彦开始明白,为什么美国的SaaS软件同行们天天讲生命周期价值,讲内容营销,因为他们也跟环信一样做的是小客户,可见对于小客户这一招中外通吃。而大客户不是这么玩的。

在美国做企业服务,底层有一批创业公司,天花板是做到几亿美元到几十亿美元市值,基本很难再往上突破了。这是因为大客户都被微软、甲骨文、Salesforce这样的公司牢牢掌握着,小企业根本没机会进入那个圈子。

某种程度上,中国也差不多,但也有很大不同。中国大型企业还没有强大的科技公司可以很好地服务于他们,这些年主要依赖于一些大型系统集成商,系统集成商的做法跟甲骨文等这些科技巨头又不一样,他们以项目运行的方式推进,在创新和积累上相对较弱。

以前中国的大型国企或私企也认可这种做法,但随着整体经济环境进入L型经济,增长放缓,企业追求利润的结果就是更加注重创新,尤其是服务创新,这两年刘俊彦明显地感觉到国内大型企业有一种创新急迫感,他意识到谁能服务中国500强企业,谁就会成为中国的甲骨文。

由于求稳,当年环信的竞争对手就没赶上这波新的机会。“如果我们到现在还只是在做最初的一个业务,我们也就成为了一家小老头公司。”刘俊彦平静地说。

2017年3月,环信完成1.03亿元的C轮融资,由经纬领投,银泰嘉禾跟投。

当然,考验仍然存在。SaaS是一种功能密集型的技术,最考验大规模研发团队的研发效率和管理能力。2016年新组建的智能机器人团队则是资本密集型,这个团队虽然人不多,但是一年投入却上千万元。

不同的技术、人才、资本结构,对于管理是一大考验。不过刘俊彦认为,既然创业就要全力以赴去做,“挖人要看眼光,选择很重要,路线很重要,信任也很重要,既然选择上了火箭飞船,就不要考虑是几等舱。”
 
作者 | 刘晓芳

微信编辑 | 李昊原

原文发表于《IT经理世界》,转载请注明
继续阅读 »

微信图片_20170627113413.gif
6月20号刊

新疆界

微信图片_20170627111638.jpg

刘俊彦说不想做一家小老头公司——规模不大,每年挣个几千万元,日子过得滋润,但每年只有10%左右的增长。

技术男刘俊彦的思维很跳跃,2014年做即时通讯云,一年后开始做客服云,不到一年,又开辟了智能机器人业务。看起来好像在分片作战,但突然有一天他已经在一个更大的战略布局里了。

这些年,云的概念被炒到火热,企业不惜花血本布局云计算,可一轮下来之后,不同的业务还是要各养一套人马,各养一套软件系统,说好的大数据,量是上去了,但是实际利用率却如挤牙膏,效用微乎其微。很多企业现在正处在一个升级也不是,不升级也不是的难受期。

见到刘俊彦的时候,他刚送走一家航空公司的几位管理人员,他们现在的烦恼是,守着一大批高净值的用户,只能卖个机票,最多再卖个保险,利润已经碰到天花板,有种守着宝藏却挖不出金子的感觉。刘俊彦在他的小会议室的黑板上,画了一个完整的从用户服务到用户营销的闭环图,这张图里包含了航空公司乃至一些大企业当下的几大痛点及应对招数,如同在下一盘围棋,细节处棋势做得够厚,大局又跳出常人思维之外,细看与AlphaGo的风格颇为相似。

这是刘俊彦第一次将自己成熟的大局想法展示给外界。
 
高效融资与快速换挡
 
刘俊彦毕业于英国伦敦大学国王学院计算机专业,后一直在IT外企从事技术研发工作,2013年,离职创业前已经成为红帽开源软件领域领先的专家。这一年,他已经年过40。

最初的一年多时间,是在海淀图书城的车库咖啡里度过的,当时刘俊彦和另外三位合伙人都刚从外企里出来,各自都已经是行业里优秀的技术人才,都实现了财务自由,清楚自己要的是什么,且志趣相投,所以走到了一起。

刚开始,大家专注于做产品,也没有急着去找投资。一年后,一个偶然的机会,投资自己找上了门。

2014年5月,刘俊彦他们进驻到氪空间的当天下午,经纬的投资人找到了他们,大概聊了两个多小时,双方就达成了合作意向。紧接着不到半年,SIG和红杉资本相继成为投资方。几家投资方看中的是刘俊彦等人创立的环信公司在即时通讯领域的开发能力和社交大数据分析能力,以及环信自主研发的高并发可扩展架构。

此前,刘俊彦拥有17年的开发经验,其擅长的领域在于实时消息系统和高并发消息中间件等。2013年,社交软件开始大行其道,当时很多人找他为APP开发即时通讯聊天功能,一般如果企业自己开发的话,怎么都需要好几个月时间,而使用刘俊彦的团队的产品只需一天功夫就出来了。因此,最初的产品并非他们刻意做出来的,而是需求在先,而且令他们也没想到的是,做着做着就成“风口”了。

很快,使用了环信即时通讯功能的APP上的用户从几万飞速上升到几千万,乃至后来的几个亿,每天下发的消息达20亿条。曾经在短信高峰时代,中国移动每天的消息量是7亿,目前国内能支撑并发连接几千万的团队不超过5个,包括腾讯、阿里、新浪微博、陌陌等,另外还有一个就是环信。

用户上去之后,新的需求又来了。开始,很多人只是把APP内的聊天功能用作连接人与人的社交管道,但很快就不断有人找上门来,希望把APP内的聊天功能做成淘宝旺旺那样连接人和商业的客服工具。

从本质上来讲,环信早期推出的即时通讯云是基于PaaS平台的服务,而要做客服云则需建立在SaaS平台上,如此跨平台的转变,对于一家创业公司,无论是人才、资本、研发或渠道等各方面都会带来严峻的挑战。

2015年4月,A轮的三家投资方在前几个轮次共900万美元的基础上,再次追加了共1250万美元的B轮投资,在资本方的财力和战略加持下,一个月后,环信客服产品线上市,一年后环信客服产品的客户量、销售额等硬指标均达到几十倍上百倍的增长。

据刘俊彦介绍,早期客服云的客户几乎一半多来自即时通讯云,相当于后者是前者的流量导入渠道,后者反过来巩固了前者的价值所在。

目前,环信客服产品的企业用户已经超过5万多家,用户也从国美在线、58到家、新东方等扩展到了十几个行业当中。

然而,IT业一年相当于传统行业十年,这是一个变换以秒速推进的行业,刘俊彦很快又迎上了新的挑战。

痛点与前瞻

随着产品的积累和行业的扩展,刘俊彦开始接触到一些保险、证券、航空等行业大客户。曾经有一家保险公司的客户跟他提到亲身经历的一件事情,以往保险公司客户经理做客户维护的通常做法就是每年会定期提前一两个月给老客户打电话,提醒他们保险快到期,可以续费了。其中有一个老客户,关系维护得挺好,但是这个老客户最近新买了辆哈雷摩托车,而他的客户经理没能及时了解并提供摩托车的保险报价,结果错失了老用户。

这种个案在保险公司普遍存在。如果有更懂用户的数据,进行再分析和精准营销,就能很快帮老用户接上新的业务,还可以把以前让利给渠道的部分,直接反馈给用户,大幅提高销售成功率。

刘俊彦说,做即时通讯,做客服,真正的差距在于,怎么通过商业智能帮助企业去挖掘以前看不到的客户信息,提高销售转换率,发掘新销售机会,以及人工智能技术怎么代替人工,怎么帮企业营销,这都是未来技术。

2016年年初,环信基于企业一体化智能商业的需求,开始推全媒体智能客户服务。所谓全媒体就是不管客服请求来自微信、微博或APP,还是网页或电话,都可以同时呈现在一个界面上,由专人统一处理。

以前企业不同的渠道由不同的人马在支持,各自软件系统也不一样,信息也是各自孤立的,片段化的,环信做到了让一个支持人员同时监控所有渠道,客户身份也可以从孤立的信息中关联起来,形成一个统一身份。也就是说,同一个用户打完电话,再用微信接入,通过各种技术方法可以跨屏身份合并被识别为是同一个人。

此外,一家企业如果每天进来10万条消息,环信的技术可以识别出来自不同渠道不同数据格式的信息,然后对其进行数据清理,再做主题分析和情感分析,从而知道用户今天都反馈了什么问题,情感是愤怒还是高兴,可能的消费趋势是什么?进一步还可以給出用户画像,画像信息详尽,一直可追溯到用户城市、职业、性别、喜好、消费能力、行为轨迹,等等。

这些数据对于企业至关重要。不仅是保险公司,证券公司、航空公司等等行业都存在类似的强烈需求。

环信还在自己研发客服机器人。刘俊彦认为,环信既有SaaS客服软件高市场占有率的通道优势,又有了大量的数据积累,加上对垂直行业的深度理解,在开发具有高度行业特征的客服机器人上,又领先了其他对手。

2017年 ,环信整合旗下即时通信云、移动客服、智能客服机器人和主动营销产品线,推出环信CEC (Customer Engagement Cloud),向企业提供从客户互动渠道,到客户服务,再到精准客户营销的全流程客户互动解决方案。

技术出身的刘俊彦,既可以不断挖掘出用户的痛点,在技术细节上下足功夫,又可以跳出来,把握住前瞻性技术,果断出击。当一个个看似不大相关的痛点技术在量的积累上突破一个爆发性临界点时,全新的需求与应用又把之前所有的技术关联在了一起。

这一切使得刘俊彦像一个“做局”的高手。

转变与坚持

创业仅仅4年,刘俊彦已经看惯了互联网领域的迎来送往,2014年,他还经常在微信里看见做社交应用的CEO们发朋友圈,到2015年左右,这些人大多看不到了,换了一批做O2O的CEO,一年以后,这些人又看不见踪影了。大浪淘沙,互联网的残酷淘汰是铁律。

当年那些做即时通讯服务的环信的老对手们,现在大多还在做老业务,日子过得还不错。刘俊彦却早已不在当初的格局里了。

做即时通讯云有一个特点,从几十万用户到几百万用户是一个技术节点,从几百万到几千万又是一个节点,用户过亿之后则是一个更大的节点。每一个节点处,基本上架构要推倒重写一遍。这要求技术团队快速的迭代和积累,一旦有一个环节出问题,就有可能导致服务不可用。

这期间,环信团队也经历了重大考验,也被客户骂过,好在最后都坚持过来了。现在环信即时通讯技术架构早已稳定下来,即使再扩容4~5倍也不成问题。

然而,就在这么一个节点上,刘俊彦毅然决定再另外做一个SaaS平台,这对于整个团队是一种怎样的震撼。虽然对于技术能力强悍的环信团队来讲,技术难题最终都是可以克服的,而对市场的敏锐嗅觉以及果断决策,却非易事。事实上刘俊彦的判断是精准的。

环信最初的客户群主要集中在互联网领域,这些客户的生命周期比较短,付费能力比较低,好处是决策周期短,商业谈判简单,能迅速达成交易,迅速验证需求,这适合早期创业。

有了这段经历也让刘俊彦开始明白,为什么美国的SaaS软件同行们天天讲生命周期价值,讲内容营销,因为他们也跟环信一样做的是小客户,可见对于小客户这一招中外通吃。而大客户不是这么玩的。

在美国做企业服务,底层有一批创业公司,天花板是做到几亿美元到几十亿美元市值,基本很难再往上突破了。这是因为大客户都被微软、甲骨文、Salesforce这样的公司牢牢掌握着,小企业根本没机会进入那个圈子。

某种程度上,中国也差不多,但也有很大不同。中国大型企业还没有强大的科技公司可以很好地服务于他们,这些年主要依赖于一些大型系统集成商,系统集成商的做法跟甲骨文等这些科技巨头又不一样,他们以项目运行的方式推进,在创新和积累上相对较弱。

以前中国的大型国企或私企也认可这种做法,但随着整体经济环境进入L型经济,增长放缓,企业追求利润的结果就是更加注重创新,尤其是服务创新,这两年刘俊彦明显地感觉到国内大型企业有一种创新急迫感,他意识到谁能服务中国500强企业,谁就会成为中国的甲骨文。

由于求稳,当年环信的竞争对手就没赶上这波新的机会。“如果我们到现在还只是在做最初的一个业务,我们也就成为了一家小老头公司。”刘俊彦平静地说。

2017年3月,环信完成1.03亿元的C轮融资,由经纬领投,银泰嘉禾跟投。

当然,考验仍然存在。SaaS是一种功能密集型的技术,最考验大规模研发团队的研发效率和管理能力。2016年新组建的智能机器人团队则是资本密集型,这个团队虽然人不多,但是一年投入却上千万元。

不同的技术、人才、资本结构,对于管理是一大考验。不过刘俊彦认为,既然创业就要全力以赴去做,“挖人要看眼光,选择很重要,路线很重要,信任也很重要,既然选择上了火箭飞船,就不要考虑是几等舱。”
 
作者 | 刘晓芳

微信编辑 | 李昊原

原文发表于《IT经理世界》,转载请注明
收起阅读 »

【开源OA项目】基于环信IM开发完整的企业通讯解决方案-Dolores

  

  前阵子钉钉在微信楼下刷了一波#创业很苦,坚持很酷#的广告,浓浓的“丧”文化风格文案受到了各界褒贬不一的评价,也引起了大家对OA办公系统的关注。
   对企业而言,初选OA办公系统是为了满足需求,解决当下问题,由于OA办公系统的在公司运作流程中扮演的重要性,安全与隐私等问题急需未雨绸缪,“可定制”、“可私有化部署”的OA办公系统成为了更多企业的首选。
公司想自己开发一套IM系统应该从哪里开始呢? 企业通讯录怎么保持同步呢? 企业通讯录的权限管理应该怎么做?

   三个关于OA办公系统的究极问题,从开源的OA办公项目-Dolores(朵拉)诞生迎刃而解了。Dolores项目遵循Apache Licence 2.0 开源协议,可以直接拿来用,也可以修改代码来满足需要并作为开源或商业产品发布/销售。
OA广告图.jpg

关于Dolores?

Dolores是一套完整的企业通信解决方案,一个完整的企业沟通工具(以下简称企业IM),支持以下几个功能:IM消息服务、组织架构管理、工作流集成。


Dolores项目源码地址:https://github.com/DoloresTeam​ 
技术讨论群:641256202(QQ群)

整个解决方案都包括了什么?
  • 企业通讯录的管理:部门/员工的增删改查
  • 通讯录全量更新:全量/增量更新 
  • 企业通讯录权限管理:基于RBAC权限管理模型
  • 企业即时通讯IM:企业通信对IM这块的可靠性要求高,选择了目前比较成熟的IM云服务厂商-环信

 
 
组织架构

企业通讯录可以说是企业沟通中最重的业务之一,能够提供员工各种服务的认证,获取员工的联系方式等。
 
组织架构-Server

服务端主要包括以下功能:
  1. 支持管理人员(例如HR)对部门和员工进行增删改查
  2. 支持部门和员工自定义排序,自定义元信息存储
  3. 权限管理
  4. 员工通讯录视图 (员工根据自己的权限生成通讯录)
  5. 通讯录增量更新 (鉴于移动端特殊的网络环境和设备,通讯录应该支持差量更新)
  6. 集成 IM 用户系统


在这里我们主要讨论以下两个问题:
 
权限管理

  随着企业逐渐的发展,团队壮大为了更有效的沟通,以及保护公司内部的一些商业信息不被泄漏,我们应该为通讯录添加权限管理。

基于Role-based access control(RBAC)的权限管理模型

为了介绍此权限管理模型,我们先解释一下基本概念
  • 角色:通常是指企业中某一个工作岗位,这个岗位具有特定的权利和职责。被赋予此角色的员工,将获得这种权利与职责
  • 权限:被赋予访问实体的权利。在本项目中是指访问部门和访问某一个或者某一类员工的权利
  • 用户-角色分配(User-Role Assignment URA):为某个用户指定一个或者多个角色,此员工将获得这些角色所具有权利的集合
  • 角色-权限分配(Role-Permission Assignment RPA):将权限分配给角色,一个角色可以包含多个权利。在本项目中是指多个访问部门和访问员工的权限


在用户和权限之间引入角色中介,将用户与权限的直接关系弱化为间接关系。
|ˉˉˉ|           |ˉˉ ˉ|          |ˉˉˉˉ ˉˉ|  
| User |---URA---> | Role |<---RPA---| Permission |
|______| |_______| |_____________|

    以角色为中介,首先创建访问每个部门和员工的访问权限,然后创建不同的角色,根据这些角色的职责不同分配不同的权限,建立角色-权限的关系以后,不同的角色将会有不同的权限。根据员工不同的岗位,将对应的角色分配给他们,建立用户-角色关系,这就是RBAC的主要思想。

一个员工可以用户多个角色,一个角色可以用于多个访问权限。RBAC 极大的简化了员工的授权管理。

   由于企业的部门和员工数量很多,在创建权限时管理员不可能去设置每一个权限可以访问的每一个部门和每一个员工。所以本项目将功能和指责类似的部门和员工看作是同一类型,在创建部门和员工的时候为每一个部门和员工分配固有属性type,管理员在设置权限规则的时候只需要指定可访问的部门类型和员工即可。

增量更新

   鉴于移动终端计算资源有限,如网络,存储,电量等,所以通讯录的更新技术应该保证尽量少的资源。另外由于通讯录的特殊性,通讯录的变化需要能实时通知到受影响的在线员工。

基于版本号与变更日志的增量更新模型

   客户端第一次登陆系统以后,我们根据当前登录角色生成对应的通讯录视图,并以当前时间戳作为版本号,返回给客户端。客户端后续通过此版本号增量更新通讯录。

版本号

   版本号有两种:一是客户端当前通讯录版本 c-version, 二是服务端通讯录每一次变化时的版本号s-version

变更日志

   在管理员修改权限规则,或者修改某个岗位的访问规则时会影响大面积员工的通讯录视图,此时如果用增量更新会导致服务器流量异常,因此在这2中情况会清空原来的变更日志并且要求客户端进行一次全量更新。

   如果管理员新增了员工,服务端会根据被修改的员工或者部门type, 反推出所有受影响的员工,然后生成一条变更日志, 例如:
{
"content" : [
{
"cn" : "Lucy.Liu",
"id" : "b4vlfg91scgi1dcju8v0",
"title" : "市场运营负责人",
"email" : [
"lucy.liu@dolores.store"
],
"priority" : "101111",
"name" : "刘小飞",
"telephoneNumber" : "18888888888"
}
],
"createTimestamp" : "20170614063303Z",
"category" : "member",
"action" : "add"
}

客户端在请求增量更新的时候,通过当前登陆ID与版本号,可查找出所有与自己相关的变更日志,然后在客户端数据库中应用这些变更,即可完成同步。

组织架构-Client

   由于现在员工办公设备的多样性,客户端要根据自己公司的情况,覆盖的足够完整,常见的平台有 iOS Android windowsmac linux , 对于后三个平台可以用 Web APP 来覆盖,iOS&Android 用原生的app来提升用户体验。

客户端App主要包括以下功能:
  1. 会话列表
  2. 优秀的聊天界面,历史记录
  3. 组织机构全量/增量更新
  4. 员工个人资料展示


客户端数据库设计

IM数据库设计
 
当前版本使用环信SDK
 
组织架构数据库设计

表设计

客户端组织架构较服务端简单,不关联用户Role,客户端本地存储Staff(员工)和Department(部门)信息:
  • 一个部门可以包含相关子部门和部门员工。该部门员工和部门在视图上处于同级关系。
  • 员工隶属于部门,同一员工可以存在于多个部门。
  • 员工角色用title来表示。


用户在登录客户端成功后,会根据该用户信息创建用户对应的数据库文件,用户表(User)保存用户相关信息,关联该用户staff信息。

客户端组织架构同服务端逻辑。

工作流集成

(TODO)
 
如何使用Dolores

本项目现在已经完成了第一个测试版本,本小节将指导您如何安装使用。

后端数据库

鉴于通讯录对数据库操作的特点多度少写,以及部门之间的树状关系,我们选择LDAP协议来存取数据。

我们有独立的repo来帮助您完成数据库的安装与初始化。请移步这里

组织架构管理

Dolores 初始版本使用Golang实现,大家既可以下载各个平台的可执行包,也可以安装Go语言的开发环境自己编译。

我们有独立的repo来帮助您,运行后端服务。请移步这里

客户端

我们现在有提供一个iOS版的Demo。请移步这里

Done

如果您顺利的完成以上三步,访问 http://localhost:3280 (端口号根据自己的配置,可能会有差异),使用 username: admin, password: dolores 登陆后端管理页面,添加权限规则,添加角色,添加员工、部门,然后使用iOS客户端登陆,就可以愉快的开始聊天啦~
 
负载均衡

(TODO)

多机容灾

(TODO)

LICENSE
 Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/

更多信息请前往github项目主页

 
这里我对每个repo做一个简单的介绍


Dolores: 项目简介, 整个项目的架构, 数据库设计等等 你想了解的一切都可以在这里看到
dolores-ios: iOS版demo,可以聊天查看组织架构
dolores-android: 哈哈 还没有,当然我们欢迎各路安卓大牛贡献安卓版demo
organization: 组织架构的创建管理、更新、审计等等核心的东西都在这里啦
dolores-server: 为客户端提供restfull api 与环信服务器集成
dolores-admin: 后台管理网站,用于管理部门员工。一个基于React的webapp还很基础,欢迎各位大牛pr.
dolores-ldap-init: 后台数据库的初始化工具,详情可以查看readme
easemob-resty:对环信rest api的封装,让调用环信api更简单
dolores-avatar:生成类似钉钉那样的默认头像


最后再说一点整个服务端是用go来写的,作者也是golang的初学者,如果代码哪里写的有问题或者架构有问题欢迎大家指正
THE CALM BEFORE THE STORM.
暴风雨前的宁静

ONE MORE THING 最后附上Dolores项目LOGO
当时作者正在二刷 《西部世界》这部剧,所以选择了女主的名字dolores作为整个项目的名字,而这个logo则寓意剧中的host。
687474703a2f2f6f7131696e636b76692e626b742e636c6f7564646e2e636f6d2f646f6c6f726573313032342e706e67.png
继续阅读 »
  

  前阵子钉钉在微信楼下刷了一波#创业很苦,坚持很酷#的广告,浓浓的“丧”文化风格文案受到了各界褒贬不一的评价,也引起了大家对OA办公系统的关注。
   对企业而言,初选OA办公系统是为了满足需求,解决当下问题,由于OA办公系统的在公司运作流程中扮演的重要性,安全与隐私等问题急需未雨绸缪,“可定制”、“可私有化部署”的OA办公系统成为了更多企业的首选。
公司想自己开发一套IM系统应该从哪里开始呢? 企业通讯录怎么保持同步呢? 企业通讯录的权限管理应该怎么做?

   三个关于OA办公系统的究极问题,从开源的OA办公项目-Dolores(朵拉)诞生迎刃而解了。Dolores项目遵循Apache Licence 2.0 开源协议,可以直接拿来用,也可以修改代码来满足需要并作为开源或商业产品发布/销售。
OA广告图.jpg

关于Dolores?

Dolores是一套完整的企业通信解决方案,一个完整的企业沟通工具(以下简称企业IM),支持以下几个功能:IM消息服务、组织架构管理、工作流集成。


Dolores项目源码地址:https://github.com/DoloresTeam​ 
技术讨论群:641256202(QQ群)

整个解决方案都包括了什么?
  • 企业通讯录的管理:部门/员工的增删改查
  • 通讯录全量更新:全量/增量更新 
  • 企业通讯录权限管理:基于RBAC权限管理模型
  • 企业即时通讯IM:企业通信对IM这块的可靠性要求高,选择了目前比较成熟的IM云服务厂商-环信

 
 
组织架构

企业通讯录可以说是企业沟通中最重的业务之一,能够提供员工各种服务的认证,获取员工的联系方式等。
 
组织架构-Server

服务端主要包括以下功能:
  1. 支持管理人员(例如HR)对部门和员工进行增删改查
  2. 支持部门和员工自定义排序,自定义元信息存储
  3. 权限管理
  4. 员工通讯录视图 (员工根据自己的权限生成通讯录)
  5. 通讯录增量更新 (鉴于移动端特殊的网络环境和设备,通讯录应该支持差量更新)
  6. 集成 IM 用户系统


在这里我们主要讨论以下两个问题:
 
权限管理

  随着企业逐渐的发展,团队壮大为了更有效的沟通,以及保护公司内部的一些商业信息不被泄漏,我们应该为通讯录添加权限管理。

基于Role-based access control(RBAC)的权限管理模型

为了介绍此权限管理模型,我们先解释一下基本概念
  • 角色:通常是指企业中某一个工作岗位,这个岗位具有特定的权利和职责。被赋予此角色的员工,将获得这种权利与职责
  • 权限:被赋予访问实体的权利。在本项目中是指访问部门和访问某一个或者某一类员工的权利
  • 用户-角色分配(User-Role Assignment URA):为某个用户指定一个或者多个角色,此员工将获得这些角色所具有权利的集合
  • 角色-权限分配(Role-Permission Assignment RPA):将权限分配给角色,一个角色可以包含多个权利。在本项目中是指多个访问部门和访问员工的权限


在用户和权限之间引入角色中介,将用户与权限的直接关系弱化为间接关系。
|ˉˉˉ|           |ˉˉ ˉ|          |ˉˉˉˉ ˉˉ|  
| User |---URA---> | Role |<---RPA---| Permission |
|______| |_______| |_____________|

    以角色为中介,首先创建访问每个部门和员工的访问权限,然后创建不同的角色,根据这些角色的职责不同分配不同的权限,建立角色-权限的关系以后,不同的角色将会有不同的权限。根据员工不同的岗位,将对应的角色分配给他们,建立用户-角色关系,这就是RBAC的主要思想。

一个员工可以用户多个角色,一个角色可以用于多个访问权限。RBAC 极大的简化了员工的授权管理。

   由于企业的部门和员工数量很多,在创建权限时管理员不可能去设置每一个权限可以访问的每一个部门和每一个员工。所以本项目将功能和指责类似的部门和员工看作是同一类型,在创建部门和员工的时候为每一个部门和员工分配固有属性type,管理员在设置权限规则的时候只需要指定可访问的部门类型和员工即可。

增量更新

   鉴于移动终端计算资源有限,如网络,存储,电量等,所以通讯录的更新技术应该保证尽量少的资源。另外由于通讯录的特殊性,通讯录的变化需要能实时通知到受影响的在线员工。

基于版本号与变更日志的增量更新模型

   客户端第一次登陆系统以后,我们根据当前登录角色生成对应的通讯录视图,并以当前时间戳作为版本号,返回给客户端。客户端后续通过此版本号增量更新通讯录。

版本号

   版本号有两种:一是客户端当前通讯录版本 c-version, 二是服务端通讯录每一次变化时的版本号s-version

变更日志

   在管理员修改权限规则,或者修改某个岗位的访问规则时会影响大面积员工的通讯录视图,此时如果用增量更新会导致服务器流量异常,因此在这2中情况会清空原来的变更日志并且要求客户端进行一次全量更新。

   如果管理员新增了员工,服务端会根据被修改的员工或者部门type, 反推出所有受影响的员工,然后生成一条变更日志, 例如:
{
"content" : [
{
"cn" : "Lucy.Liu",
"id" : "b4vlfg91scgi1dcju8v0",
"title" : "市场运营负责人",
"email" : [
"lucy.liu@dolores.store"
],
"priority" : "101111",
"name" : "刘小飞",
"telephoneNumber" : "18888888888"
}
],
"createTimestamp" : "20170614063303Z",
"category" : "member",
"action" : "add"
}

客户端在请求增量更新的时候,通过当前登陆ID与版本号,可查找出所有与自己相关的变更日志,然后在客户端数据库中应用这些变更,即可完成同步。

组织架构-Client

   由于现在员工办公设备的多样性,客户端要根据自己公司的情况,覆盖的足够完整,常见的平台有 iOS Android windowsmac linux , 对于后三个平台可以用 Web APP 来覆盖,iOS&Android 用原生的app来提升用户体验。

客户端App主要包括以下功能:
  1. 会话列表
  2. 优秀的聊天界面,历史记录
  3. 组织机构全量/增量更新
  4. 员工个人资料展示


客户端数据库设计

IM数据库设计
 
当前版本使用环信SDK
 
组织架构数据库设计

表设计

客户端组织架构较服务端简单,不关联用户Role,客户端本地存储Staff(员工)和Department(部门)信息:
  • 一个部门可以包含相关子部门和部门员工。该部门员工和部门在视图上处于同级关系。
  • 员工隶属于部门,同一员工可以存在于多个部门。
  • 员工角色用title来表示。


用户在登录客户端成功后,会根据该用户信息创建用户对应的数据库文件,用户表(User)保存用户相关信息,关联该用户staff信息。

客户端组织架构同服务端逻辑。

工作流集成

(TODO)
 
如何使用Dolores

本项目现在已经完成了第一个测试版本,本小节将指导您如何安装使用。

后端数据库

鉴于通讯录对数据库操作的特点多度少写,以及部门之间的树状关系,我们选择LDAP协议来存取数据。

我们有独立的repo来帮助您完成数据库的安装与初始化。请移步这里

组织架构管理

Dolores 初始版本使用Golang实现,大家既可以下载各个平台的可执行包,也可以安装Go语言的开发环境自己编译。

我们有独立的repo来帮助您,运行后端服务。请移步这里

客户端

我们现在有提供一个iOS版的Demo。请移步这里

Done

如果您顺利的完成以上三步,访问 http://localhost:3280 (端口号根据自己的配置,可能会有差异),使用 username: admin, password: dolores 登陆后端管理页面,添加权限规则,添加角色,添加员工、部门,然后使用iOS客户端登陆,就可以愉快的开始聊天啦~
 
负载均衡

(TODO)

多机容灾

(TODO)

LICENSE
 Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/

更多信息请前往github项目主页

 
这里我对每个repo做一个简单的介绍


Dolores: 项目简介, 整个项目的架构, 数据库设计等等 你想了解的一切都可以在这里看到
dolores-ios: iOS版demo,可以聊天查看组织架构
dolores-android: 哈哈 还没有,当然我们欢迎各路安卓大牛贡献安卓版demo
organization: 组织架构的创建管理、更新、审计等等核心的东西都在这里啦
dolores-server: 为客户端提供restfull api 与环信服务器集成
dolores-admin: 后台管理网站,用于管理部门员工。一个基于React的webapp还很基础,欢迎各位大牛pr.
dolores-ldap-init: 后台数据库的初始化工具,详情可以查看readme
easemob-resty:对环信rest api的封装,让调用环信api更简单
dolores-avatar:生成类似钉钉那样的默认头像


最后再说一点整个服务端是用go来写的,作者也是golang的初学者,如果代码哪里写的有问题或者架构有问题欢迎大家指正
THE CALM BEFORE THE STORM.
暴风雨前的宁静

ONE MORE THING 最后附上Dolores项目LOGO
当时作者正在二刷 《西部世界》这部剧,所以选择了女主的名字dolores作为整个项目的名字,而这个logo则寓意剧中的host。
687474703a2f2f6f7131696e636b76692e626b742e636c6f7564646e2e636f6d2f646f6c6f726573313032342e706e67.png
收起阅读 »

视频超过三十秒后再接受 无数据

iOS 根安卓的  视频聊天 超过三十秒之后在接受就没有画面了 都是黑的 小窗口是有画面的是因为 超时了吗 ? 还是什么原因该怎么解决呢  谢谢
iOS 根安卓的  视频聊天 超过三十秒之后在接受就没有画面了 都是黑的 小窗口是有画面的是因为 超时了吗 ? 还是什么原因该怎么解决呢  谢谢