跳到主要内容

CRM 基础 - 线索、商机、账户、联系人

· 阅读需 6 分钟

CRM 基础 - 线索、商机、账户、联系人

  • 线索 - leads
    • 是 营销/marketing 与 销售/sales 的交界点
    • 营销负责创造、发现线索,销售人员需要从线索挖掘商机进行销售转化
    • 挖掘过程就是判断线索是否合格(qualify)或不合格(disqualify)的过程,如果合格则能被转化为商机
    • 线索表示的 潜在销售目标
    • 包含基础的指向信息 - 例如 名片、电话号码+名字
  • 商机 - opportunities
    • 商机可由线索转化,也可直接录入
    • 商机同时也是联系人(contact),在创建商机时自动创建关联的联系人和账户
    • 商机=潜在销售目标(lead+contact)+潜在可销售服务
  • 账户 - accounts
    • B2B 关系往来目标 - 通常对方为公司
    • 关系往来类型不只是销售客户关系,还可能是 合作伙伴(partner)、供应商(vendor) 等
    • 有层级关系,支持复杂的组织结构
  • 联系人 - contacts
    • B2B 关系中对方公司实际操作的人 - 例如 下单、审核、处理发票收据 的

从 Issues 看 CRM 基础概念

作为一个开发者,对 Issues/工单/议题 更加熟悉。管理的好的工单会使得整个开发流程更加顺畅,管理的不好则会导致工单暴增导致无法收尾最终只有大批量关闭。

工单经历发现、创建、确认、修复、关闭。这个过程与 CRM 的 线索、商机、成交过程十分相似。

工单看似是线性的,但实际处理的时候又是流程化的,这个流程并不固定,而是取决于当前问题的状态、类型、指派人。

以 kubernetes 的 issues 为例,大量的 issues 都会打上各种标签

LabelCRM
needs-triage待跟进
triage/unresolved无效的
triage/accepted已确认
kind/*划分类型
area/*划分服务范围

CRM 的核心是 协作,工单的标签系统也是为了方便协作,不同的项目使用的体系不尽相同,因为场景和处理流程不同,但核心目的都是为了协作解决问题。

通过工单的标签定义可观测出处理流程,这样的处理流程是一套 项目管理框架,CRM 中销售也需要一套行之有效的框架,只有当销售人员遵循一套框架体系时流程才可能得以优化。

大小项目的标签分发流程体系不同,就好比大小公司对 CRM 要求不同,初期的需求只要记录信息,中阶的要求需要能按人员按指责去流转跟进,高阶的则需要集成大量的外部系统使得流程自动化。

工单系统这样的自动化比传统 CRM 一条一条记录更加智能,例如 Github 能集成各种第三方的 CI/CD 体现状态,集成各种机器人对 issue 进行自动打标,还有最常见的机器人标记 issue 过期并自动关闭。

不管是工单还是 CRM 的跟进体系最重要的是达到最终完成状态,这个过程需要推进则需要系统进行辅助,最常见的就是确定下一件事的时间节点,将不同的工单/跟进分流给不同的人去处理。

工单/跟进都是非常原始/原子(primitive)的对象,在这样的体系之上可以构建

  • 看板
  • 里程碑
  • 待办列表/Todo List
  • Epic
  • 外部集成
  • 自动化

作为驱动 CRM 销售日常事务来说是非常有用的。

但,工单系统与跟进也有很多不同点:

-工单销售跟进
可见性公开、小组个人、小组
内容文本、评论、活动表单、活动、附件
内容目标人+事
协作人员开发+测试+设计+PM销售个人+销售小组+客服+经理
KPI小组相关个人相关、小组相关
频度
工作内容PR, 提交电话、沟通、日常事务

线索、商机、账户、联系人

回到本来的关注点,先参照现有的系统设计。

Dynamic 365

其中的 Activity 活动概念其实就对应了工单中的活动记录,所有的跟进过程都以活动呈现。似乎接下来该了解一下工单系统的实现了

参考