CRM- Salesforce体验报告

Salesforce为公认Saas No.1产品,借用系统上线推广时领导的宣导,“我们的销售人员能使用到salesforce是一种自豪,在跟客户打交道时是加分项”。Salesforce是如此出名,硬气到业务反馈不好用,只能是业务方案或管理上的问题,产品已是业界第一了,还能有更好用的CRM系统吗?

当然信息系统有“三分产品,七分实施”的说法(发现除了2/8法则,IT还有3/7法则。“三分产品,七分销售”,“三分技术,七分管理”,“三分产品,七分运营”。。),在erp实施项目时常听到。因为erp作为企业内部管理中最“重”的系统,极度依赖业务咨询与变革。产品再好,解决不了业务管理上的问题。CRM虽然强调“relationship”,注重与客户、合作伙伴、经销商、代理商的协同,但其本质仍是供公司内部员工使用的职能化管理软件,因此项目成功与否也会很大程度上取决于项目实施的效果。因此项目选择top级咨询公司作为实施方,sponsor全力支持,获得了相关业务领导承诺,作为年度变革项目推进。上线结果低于预期,推广任务艰巨。这也是Salesforce来到中国水土不服的其中一个例子。

产品需求分析阶段的PMF,产品市场契合点,放到B端即分析产品成熟度与业务成熟度的契合度。而Salesforce的问题,在于其“过于先进了”,国外销售方法论有完整的标准作业,语言通用,而放到本土,流程过于复杂了,pipeline每一阶段怎么要填入这么多信息?销售是要在外面抢客户的,不是天天给系统录内容,字段多,业务流过于死板。用惯了牛犁地,提供拖拉机,反而出现极度不适;二是作为老外设计的产品,Saleforce有着不属国内2C产品的用户友好度,但在由外及内的功能,仍有待提升。例如service个案处理,有较大比例属于2C部分,用户如何提交维修个案、匹配设备档案、看个案进度与状态,不是salesforce的强项,对于终端用户体验差;三是部分功能过于死板,对于不同行业兼容性差,如CPQ无法提供复杂灵活的配置引擎;四是数据,涉及客户、销售合同属于企业敏感信息,对于有国际或2G业务公司,无法安心将数据放到云上,特别还是来自美国的公司。无论SF提供多完备的数据安全资质证明,这个不信任是无法消除的。

了解了下Salesforce客户定制化开发模式,开发人员表示,coding完全感觉不到是在云上。IDE安装插件后,可以将相关模块代码pull下来,debug、deploy与本地开发无任何差别。Salesforce对于核心部分与扩展部分区分极其严谨,严格分离共享对象和定制对象。客户定制化与产品标准迭代不会产生冲突。

而这是目前国内Saas常见的难题,项目二开,结果产品升级造成逻辑冲突,稳定性极差,无法定位到问题,因此要靠交付团队现场实施时,尽可能拒绝定制化要求(这本就是Saas的核心要求,标准功能复用降低边际成本,保证高续费率提供统一功能迭代。但放到一个个实际客户项目极其困难,免不了要做项目二开)。站在客户角度,业务提的需求自有其合理性,为什么要求甲方为了你们的产品的不成熟而额外增加业务工作量,上系统的初衷不是为了方便业务吗?产品标准化原则无法满足实际业务需求,对于双方都是伤害,矛盾升级到无法调和,就要考虑,要不迁到本地吧。

Salesforce的定制化开发能力,在不影响产品迭代的前提下,基本可以支撑客户内部开发人员发挥满足业务需求。EBS有弹性域概念,而SF可直接自定义对象,不用关心存在哪张表,即建即用,数据层与服务层实现分离。接口、UI、表单、工作流、数据、报表,就足够内部开发团队使用了。Salesforce另一个强大之处,在于其Paas平台force.com。由Saas出发,做到一定规模后搭建Paas,Pass的成功案例不多。国内本森在做,不知道效果。能做成paas,前提是Saas产品已具备足够认可度,可以围绕该产品打造生态,供给与需求可以搭配,要求插件或附加模块具有足够的普遍性,同时技术上也是个挑战,要对原系统重构。前日读《长尾效应》,作者也以Salesforce为例,在线软件供应模式,连接众多的小开发商或独立开发者,与顾客需求。尾部支持头部,小开发商满足顾客扩展性或各类特殊需求。此外,针对不同行业的特殊规定与要求,也可以开发行业特定版本的CRM。

回到产品本身,Saas最核心的概念即“租户”,据说为Salesforce首创,下图形象描述了多租户(Multitenancy)的理念——“数据与配置的虚拟分区,组织使用单独的虚拟实例,并可以对虚拟实例进行客制化”;提供四套环境,Product Org、FullSandbox、Sandbox、Dev。三套环境一般足够了,加上了预发布环境;首页程序商店,AppExchange,能做到程序/插件市场,就算是top级Saas;企业级在线SNS,Chatter。当然在国内,为什么不直接用微信,或公司IM钉钉、企微呢?Chatter的优势在于与系统的结合性,基于内容、任务发起对话,组件团队群聊。支持发布任务、分享、@提问及调查(相较微信属于鸡肋功能)。

CRM- Salesforce体验报告

 

CRM- Salesforce体验报告

近期看到文章,将CRM划分为三类,企业内部使用的CRM、C2B CRM及C2C2B CRM(https://mp.weixin.qq.com/s/otqYAJuzVdt1t7f9ELtQYw),从是否适合资本快速驱动角度,认为后两类CRM可借助资本快速成长。其实这种划分及结论,也适用于其他Saas产品。企业内部强管理属性的Saas,并未看出与传统管理系统的独特优势,周期较长,需要借助实施项目沉淀方案与产品。此外相较软件大厂,没有行业经验与方案的优势,这是大B看重的。而小B,需求各异,无法快速复制,客单价低,无法给客户带来直观价值;C2B Saas,还有B2C,及涉及内外交互的Saas,连接需求端与供给端,找到最优的推拉结合点。而且这类产品,就不像IT系统降本增效、成本中心的概念了,是在提供增值服务,甚至在改变公司经营模式,带来更大的效益。做内部系统实施,总觉得是为了满足公司那几个业务部门基于落后的使用习惯而提出的需求,或某几个领导完全出于自身考量的要求,极度考验服务耐心;三是C2C2B,构建平台,类似阿里的S2B2C,与企业“合能”,共同服务于客户。文中提到的四个特征,“C端用户高频参与,交易模式简单,做平台或连接器,竞争因素为流量或供应链”,即可作为判断标准,在符合条件的2B产品中,找机会吧。


1. 战略层

1.1 产品目标:业务标准化,借项目实现业务变革;增加透明度,减少系统外的个人操作(特别对于销售人员、合作伙伴),降低风险;流程优化,提高效率;赋能,主要涉及销售、合作伙伴、市场、客服角色

1.2 用户需求:数字化营销服

2. 范围层

2.1 功能模块

CRM- Salesforce体验报告

2.1.1 销售云 sales

  1. 线索管理(线索录入场景,线索培育,线索评分设定,线索分配机制,线索跟踪)

  2. 商机管理

  3. 销售协同

  4. 销售预测

  5. 销售计划

  6. 客户拜访

  7. 活动记录

  8. 销售费用管理

  9. 合同管理

2.1.2 客服云 service

  1. 客户需求与服务管理

  2. 知识库管理

  3. 设备管理

  4. 多渠道客户服务管理

2.1.3 市场营销云 marketing

  1. 市场活动计划

  2. 市场活动执行

  3. 活动受众管理

  4. 市场活动分析

2.1.4 合作伙伴云 community

  1. 伙伴注册

  2. 伙伴信息管理

  3. 伙伴联系人管理

  4. 伙伴赋能

  5. 目标、激励及账款管理

2.1.5 配置报价器CPQ

  1. 产品信息管理

  2. 定价信息管理

  3. 配置信息管理

  4. 报价管理


2.2 业务方案

2.2.1 渠道型销售

  1. 协议管理(协议产品,销售目标,返利规则,销售区域,付款条件)

  2. 基本信息管理

  3. 通路管理(渠道通路关系配置)

  4. 订单与合同管理(报价单,授权申请,下单订单配置,订单审批,订单变更,订单退货)

  5. 目标与激励体系

  6. 考核体系

  7. 财务信息:应收账款,逾期欠款,信用等级,黑名单

  8. 订单信息:订单状态,入库时间,发货时间

2.2.2 项目型销售

  1. 线索转业务机会(客户,联系人,业务机会)

  2. 业务机会信息管理(小组成员,产品需求,联系人角色,困难与需要的帮助,立项申请)

  3. 需求确认

  4. 标前引导与解决方案确认

  5. 投标(解决方案,商务报价)

  6. 商务谈判(合同条款)

  7. 签订合同(合同归档,合同变更)

  8. 输单、暂停、重启、取消

  9. 销售订单及回款(框架合同订单,合同回款)

2.2.3 CPQ

CPQ的核心为BOM与配置规则引擎,即产品基础数据与产品销售规则,数据量极大,规则灵活多变,往往需要全职的数据团队维护。从业务操作上,涉及报价单管理,产品数据配置,报价基础数据配置,销售规则配置,报价单类型,产品销售权限控制,产品选择,报价单审批,授权价位审核,特价审批,备货通知,生成订单。

CPQ对于拉通前后端,实现数字化营销其中决定性的作用。维护统一全局的产品目录,对产品做全生命周期管理,才能给下游系统提供实时准确的产品数据源;BOM涉及销售BOM、制造BOM,以及如何转化;适配不同场景,及复杂产品的配置报价;打通与后端供应链的信息流,不仅是销售的可配置项,也要考虑供给端能否订单及时齐套。

2.2.4 销售目标

  1. 销售活动计划制定与执行(日程活动计划管理,销售周报)
  2. 目标达成分析

2.2.5 服务个案

  1. 服务个案接入

  2. 服务个案处理(团队协作,发布消息、任务,服务方案知识库,个案查询,个案提醒)

  3. 服务个案关闭(满意度调查)

  4. 报表分析

2.2.6 其他

  1. 销售管道pineline
  2. 销售预测
  3. 销售方法论
  4. 营销管理模板

3. 结构层

3.1 业务流程

核心流程:线索,客户,业务机会,解决方案,报价,合同,订单,回款,客服

3.1.1 从市场到商机

  1. 市场洞察

  2. 市场管理

  3. 营销赋能

  4. 产生需求

3.1.2 从商机到付款

  1. 从线索到商机

  2. 从商机到订单

  3. 从订单到回款

  4. 管理变更

  5. 管理项目

  6. 管理合同/协议生命周期

3.1.3 从问题到解决

  1. 问题受理

  2. 问题处理

  3. 问题关闭

3.1.4 客户关系管理

  1. 管理客户政策

  2. 管理客户关系

  3. 管理客户接触与沟通

  4. 管理合作伙伴关系

  5. 管理客户满意度

  6. 管理客户信息

3.2 销售订单/项目按生命周期划分业务流程

  1. 购买需求

  2. 项目申请

  3. 可行性研究

  4. 项目计划书

  5. 立项招标

  6. 技术方案介绍

  7. 技术洽谈

  8. 商务谈判

  9. 合同签订

  10. 合同履行

  11. 售后服务

  12. 后期维护

3.3 数据架构

CRM的关键数据定义,包括客户 account、联系人 contact、潜在客户 lead、业务机会 opportunity、个案 case。

3.3.1 主数据

  1. 产品主数据

  2. 产品文档主数据

  3. 员工主数据

  4. 价格主数据(市场指导价RRP、协议价格、成交价)

  5. 客户主数据

  6. 销售预测数据

  7. 合同主数据

  8. 库存主数据

  9. 销售项目主数据

3.3.2 集成数据

  1. ERP。产品,产品成本,产品价格,订单,应收账款,逾期账款,库存,订单回款,合同回款,付款条件,币种,汇率,国家/区域。

  2. MDM。客户,员工,岗位,公司组织,销售项目,合同,业务机会。


4. 框架层

4.1 界面设计

  1. 顶端导航栏
  2. 状态栏
  3. 标题栏
  4. 头部区域
  5. 内容区域

4.2 导航设计

/

5. 表现层

/