客户关系管理2.0-从深航的会员注册流程谈起

    近一年老往广东方向出差,因此老坐深圳航空的飞机。对于我这样的怕麻烦的人来说,一直嫌各大航空公司繁琐的申请流程,也懒得每一次坐飞机还要记住带什么会员卡,也没有企图从各大航空公司所谓的会员里程积分计划中得到什么好处,因此一直尚未办理任何航空公司的会员卡。同样的道理,用了移动的全球通8、9年,从未使用过移动所谓的“积分兑换计划”,尽管移动每过几天就会发一堆垃圾短信,告诉提供乱七八糟的奖品。

最近,深圳航空给我寄了一封信,告诉我已经成为深航尊鹏俱乐部的会员,并且附带了会员卡及会员手册等东西。记不得自己填写过什么会员注册表格,这不是像互联网公司常用的垃圾邮件伎俩吗,忽悠人民群众的眼球和点击率,因此一抛了之。没想到又过了几天,深航又发了一个短信给我:

尊敬的深航会员,登录深航网站修改注册证件类型、号码与您实际乘机证件一致,您的飞行里程便可自动累计,详询:4008-808-666[深圳航空]

    这倒是有趣,这么简单,随手登录了深航网站网站,试验了一下,的确能够正常登录。看来航空公司也改变自己的营销策略和客户服务流程了,不管深航的出发点是什么,至少从注册为会员的流程而言,去除无用的繁琐环节,简化了注册流程,有点web 2.0的强调“用户体验为中心”的味道,值得称赞一下。按照当下流行的术语,逢新事物必称“xx 2.0”,我们姑且叫:航空公司客户关系管理 2.0。

谈谈自己对CRM 2.0的一些粗略理解,不成体系且杂乱,有空再梳理。

客户关系管理1.0 下,每一个企业的口号都是“以客户为中心”、“客户至上”,但企业的各种客服、市场营销、运营、产品研发等都是以企业自己想当然的“客户”及“客户需求”为出发点,在企业的各种精英员工内心深处其实还是有一种天生的优越感,以为自己就是权威,以为自己所提供的服务是唯一的,客户对此一定会趋之若鹜。于是乎要设立一堆人为的障碍来淘汰一堆不符合条件的客户,美其名曰“客户漏斗”、“客户细分”、“客户分层”。对于企业而言,其进行数据挖掘关心的客户价值更多的是客户所能带来的消费价值和潜在消费价值,企业所谓的“以客户为中心”中的“客户”其实是所谓的带来80%收益的20%的高端客户;企业营销方式或为Push方式或为Pull方式,所谓的“客户互动”只不过逢年过节的各种名义的联谊会及积分兑换。一个典型的场景就是航空公司的会员注册流程、移动的会员积分计划。

客户关系管理2.0下,企业在遵循2-8原则的基础上(毕竟企业资源是有限的,不可能对所有客户都一视同仁),应当关注并把握整个社会“长尾化、个性化、去中心化”的趋势;关注诸如IM、SNS、Blog、Wiki等新兴媒体在企业客户关系管理中所扮演的口碑效应;更加关注每一个鲜活的个体需求而非千篇一律想当然的群体需求,应当更加关注与客户更加真实、有效的互动形式而非形式化的所谓“回报”、“联谊”;更加关注与客户接触过程中的每一次“用户体验”是否为最佳的而非形式化的“客户满意度调查”,不要担心用户不再使用自己的服务,而应当担心自己的服务是否能够让用户以最低的成本使用完后尽快离开,正如google一贯的宗旨:“让用户尽快离开自己的网站”;

所谓的CRM 2.0还是CRM 1.0都只是各位专家们的术语而已,但对于每一个企业而言,“关注用户体验”、“以客户为中心”并不只是书本上的术语而已,我相信:只有从内心深处真正尊重每一个鲜活个体的个性化需求,企业才能够最终真正满足目标客户群体的需求,从而在日新月异的市场竞争中胜出。

Technorati 标签: ,,,,,

我的sns社区思考1-社区关系模型

我的SNS思考

无线互联网建设思考

对于无线互联网的建设上思路,我觉得有几条主线:

1、 围绕通路相关的业务:看看成功的互联网企业,所谓渠道为王、终端为王的口号在互联网时代一样通用,谁能够打通无线互联网、互联网、传统渠道的通路,那就成功了一半。目前重点考虑手机客户端、传统销售渠道、数字内容分销平台

2、围绕电子商务所展开的相关业务:目前重点考虑手机支付平台、手机垂直电子商务(B2B、B2C)

3、 围绕用户社区展开的业务:包括用户社区、商家社区,以及围绕社区所进行的社会化商务。社区的建设重点是信用体系及积分体系的建设。

    在目前的建设阶段,由于人力资源的有效,门户社区及客户端的建设上不可能面面俱到,也不可能靠互联网自己的口碑传播来逐步形成用户社区,提高用户的粘度。所谓要集中优势兵力打歼灭战,因此我觉得关键还是要找到一两个具有病毒式营销或能够引爆流行的可运营的产品或服务,以此产品或服务为切入点吸引用户。要找到这样的产品或服务,我觉得首先需要对用户进行准确的细分,挖掘每一种细分用户的核心的关注点和兴趣所在,按照我自己的一些理解,可以粗浅分为普通大众和商务人群两种。

1、普通大众的需求及特点:

  • 通信需求是最基本需求
  • 渴望成名,展现自我
  • 结交更多的朋友
  • 能够有便捷的工具,帮助其与外界沟通,跟上流行和时尚
  • 一夜暴富
  • 隐私
  • 等等

2、商务人群的需求及特点:

  • 能够及时了解商业机会
  • 结交更多对事业有所帮助的商业伙伴
  • 协同需求
  • 等等

一些想到的方向,供后续思考:

1、 Twitter微博客模式:

定位:

    满足普通大众无聊消磨时光及其展现自我的需求。从目前应用来看,手机客户端基于twitter模式的社区比纯粹的小圈子更为具有吸引力。

   对于社区,可以重点考虑基于位置的社区,同时借鉴Facebook开放平台及社区建设经验。

服务提供商

    http://twitter.com/

    http://www.taotao.com/

    http://fanfou.com/

2、 基于gprs的发短信方式

定位:

    满足所有人免费发短信(只收gprs流量)的需求

    可以利用gprs包月服务来发短信。像目前诸如飞信、做做客、pingco等提供的免费短信功能都通过此种途径。通过此种模式实际上还可以打电话。

    针对商务人士可以提供国内发往国外的短信服务。

    但这种模式与我们目前靠短信赚钱的模式有一定冲突,需要从产品定位及包装上区别开来。

服务提供商

    http://www.zozoc.cn

    http://www.pingco.com/

     http://world.china.com/worldchina/index.htm

    http://www.10166.com.cn/

    http://www.fetion.com.cn/


3、 基于syncml协议的类RSS内容订购服务

定位

    提供经过精心筛选的最新的资讯(重点为普通大众感兴趣的内容,而不是很宽泛的内容,例如图片等),可以与标签或rss结合,这样用户进来后可以迅速找到自己喜欢的精选内容,不用再去一些大而全的wap站点。

服务提供商:

    Mytt中的“频道”中提供了此种初步功能(我猜想是基于syncml协议做的),但没有持续更新和维护。

4、 基于回拨形式的电话

定位:

    提供相对低廉的通信服务,低廉的通信服务是所有用户共同的需求。

    由于国内voip政策风险,可以通过回拨方式来提供voip服务,或者与国外有一堆低廉的voip服务提供商合作来提供此种服务。国内像http://www.vivame.cn/http://www.pingco.com都提供此类服务。

服务提供商:

    http://www.talkonaut.com/

    http://www.rebtel.com

    http://www.jajah.com

    http://www.fring.com/

    http://www.voipdiscount.com

    http://www.voipstunt.com

    http://www.vivame.cn/

    http://www.pingco.com

5、 站点导航(聚合门户)

定位:

    为广大手机用户提供各种诸如互联网上hao123、265这样的导航服务,最终形成手机内容的聚合门户。

服务提供商:

    http://www.datuu.com/

    http://www.haodewap.com/

6、 个人理财

    由于股票的买卖对于我们而言,只能卖客户端,不具有太大的运营价值。

    在个人理财服务上,彩票网上代购合买是一个值得密切关注的方向。只是由于去年年底的五部委发文禁止网上代购合买业务,目前政策形式不是很明朗。但值得我们关注,预计此业务还是会以诸如牌照等形式推出的。此种业务很适合做运营,也适合作为一个服务嵌入客户端,可持续观察。

服务提供商:

    http://www.500wan.com/

    http://www.wozhongle.com

    http://www.zhcw.com/

 

学习电信BOSS系统好榜样-电子商务系统建设思考4:客户、组织机构、人员权限域思考

  公司需要搭建新的融合电子商务及电信增值业务功能的系统,与以前单纯的电子商务系统或电信系统架构设计的需求相比较,此种融合了互联网和电信业务的需求的系统架构过程倒具有较大的挑战性,也比较有趣。尤其在商业模式尚需要进一步细化的情况下,怎样在模型搭建时候能够尽量考虑到未来业务模式的变迁,能够较好支撑未来业务的发展需求,不至于后续大动干戈。

  领域模型上总体上分为如下几个域:

  • 客户、组织机构、人员权限域
  • 产品域
  • 定价域
  • 计费/交易域
  • 帐务/结算域
  • 资源域
  • internet域
  • 统计及经营分析域

先思考一下客户、组织机构、人员权限域及产品域的模型。

人员权限及产品模型

Why most large-scale web sites not written in Java

Gigaspaces公司的大牛Nati Shalom及其同事Geva Perry 的关于在web2.0时代,java在高性能、大容量、高负荷的互联网应用领域所扮演的角色进行了较为理智和深入的思考,在TheServerSideArtima上也引起了激烈的讨论。由于Nati ShalomGeva Perry  ,都算得上Java的大牛,其所在公司Gigaspaces开发的产品GigaSpaces eXtreme Application Platform (XAP)也是基于Java的高性能平台,因此其观点算得上对Java在互联网时代的定位的反思,相比较而言国内的“我该学习Java还是学习.Net之类的讨论”层次明显得不一样。

讨论的一些相关内容:

Why most large-scale web sites not written in Java

Why most large-scale Web sites are not written in Java [Personal View]

Large-Scale Web Sites and Java

y1po13h7kl8WSSz36U09lQcrdOfz0gLB0jbAlnLlGMewxrqDFf58IZEUmqLCtbQ5qQzwL73puADD3c

一些Web2.0应用杰出代表的系统架构

我比较赞同Geva Perry Large-Scale Web Sites and Java的观点:

my intuition is that the trend for Web apps that are coming from start-ups or large pure web players (as opposed to web apps from airlines, banks, etc.) is definitely towards the LAMP stack. However, Java will still remain strong for a while and  especially for Web apps that have to deal with more complex processes in the back-end.

对互联网企业的Web应用而言,强调的是开发、部署、维护的敏捷性,因此我觉得Web层的应用还是采用像RoR、Django、LAMP(CakePHP)的应用架构相对方便,另外在性能调优(例如Cache、页面静态化)方便,像LAMP这样的架构还是较为成熟;在诸如像电子支付这样关注事务完整性、在MVC业务层有复杂的业务逻辑处理(例如交易、结算)的互联网应用领域采用Java架构还是较为恰当的;当然像银行业务、电信系统、电子政务系统这样传统的企业应用领域(Workflow、ESB、Rule Engine、SoA、消息服务等)Java还是会占据较大的优势。

归根结底,采用什么样的语言及架构还是需要根据业务模式的需要来决定。

一些相关的文档,值得一读

http://fishtrain.com/2007/09/26/interview-with-gigaspaces

http://royal.pingdom.com/?p=95

http://royal.pingdom.com/?p=173

http://natishalom.typepad.com/nati_shaloms_blog/2007/10/why-most-scalab.html

http://natishalom.typepad.com/nati_shaloms_blog/2007/10/why-most-large-.html

http://gevaperry.typepad.com/main/2007/10/large-scale-web.html

 

Pownce Lessons Learned-Do a lot with a little…

Pownce的创始人之一兼主力开发人员leah culver(好像是一个女士,牛人)在slideshare上发布了一篇pownce lessons learned的文章,比较全面介绍了关于构建Pownce应用的各种经验,对于构建web2.0应用还是很有借鉴意义的。怎样“Do a lot with a little”是每一个创业者都必须随时考虑的问题。

另外一篇关于Pownce的文章也值得一读Interview with Leah Culver: The Making of Pownce

1、团队规模、产品开发周期

开发团队规模:只有一个web开发工程师(应该还有后台开发人员),呵呵,那就是leah culver

开发周期:开发了4个月,pownce是自筹资金玩的,也面临初创性互联网公司短交付期的要求。只不过付出没有白费,现在应该有一堆投资商排队要投。

2、Lessons Learned

2.1、Think about technology choices

主要信息来自Interview with Leah Culver: The Making of Pownce

Web框架:基于django,我的最爱

文件存储:基于amazon的S3(Simple Storage Service)

Web IM:基于AIR(Adobe Integrated Runtime)

数据库:mysql

Caching:memcached

Load balancing:Perlbal

2.2、Do a lot with a little

Small Team:Multiple roles,Learn quickly,Dedicated

采用开源工具

充分利用自己的资源

2.3、Be kind to your database

使用memcached做caching;Caching at page and object / list level;Cached  static pages since launch

对非实时任务,使用队列(消息队列?)作为任务调度的机制。

限定返回的记录数量及数据分页。

采用恰当的索引

避免复杂查询

2.4、Expect Anything

数据备份、版本控制

系统监控

利用社区的力量-Keep in touch with your community.

  • Let users know what you’re working on
  • Respond to individual bug reporters
  • Inform users of bug fixes and new features
  • Be careful about asserting deadlines

同盟军及合作伙伴

持续优化

3、 参考资料

http://immike.net/blog/2007/07/06/interview-with-leah-culver-the-making-of-pownce/

http://phaedo.cx/archives/2007/07/02/pownce-django-powered/

每間公司都該聘一位駭客的3大理由

 

Technorati 标签: , , ,