留学机构内部CRM系统建设总结（二）

上篇文章《留学机构内部CRM系统建设总结（一）》介绍了国际课程的基本知识与业务模式，让各位读者心中先有个大概。

从本篇文章开始，将详细介绍CRM中各个模块的设计，接下来直接进入正题。

一、CRM功能框架

根据上篇文章的介绍，笔者将CRM划分了10个模块：

1. 首页：此处笔者并没有直接进行功能设计。因为虽然都是一些常见的dashboard，但是需要根据业务实际需求，以报表的形式展示相关业务走势。在系统还未正式运行之前很难定义此处的报表内容，并且这些报表在系统初期并不影响业务正常展开。所以笔者决定此版块内容作为二期建设内容。
2. 工单：笔者最初定义的工单与传统意义的“客服工单”要简单一些。因为业务暂时没有专门的客服岗位，所以此工单功能仅作为“待办事项”给销售人员使用。后期再视业务发展情况，不断完善此模块。
3. 客户管理：此模块即售前销售(CC)的核心工作区了。包含了“我的客户”、“试听列表”、“公海池”三个模块。按照一般的CRM来说，此处应该有“线索管理”的模块，笔者一开始也是按照“线索——有效客户——付费客户”这样的流程进行设计的。但是业务方没有MKT团队做线索清洗相关工作，另一方面业务初期的线索来源质量比较高（公司其他渠道），线索清洗的意义不大，所以第一版就省略了“线索管理”模块。此处后期将根据业务发展情况，再添加前置的“线索管理”模块。
4. 付费学生：即“付费客户”，此模块主要供售后销售（CR）使用。“客户管理”中的学生付费后进入此模块。此处支持CR对学生进行“续费、扩科、转课、退费”等关键业务操作。
5. 教务中心：顾名思义，这里是教务的工作区，主要功能为“学员管理（即1V1和班课学生的排课）、试听排课、课程表、教材库”。因为正课（1V1和班课）与试听课的排课机制、业务原理都有较大区别，所以此处笔者将其拆分开来独立运行。
6. 教师中心：此处主要用于管理教师，只有此处被添加的教师才可以进行排课等操作。
7. 课程管理：分为三块“科目管理、班课管理、合同管理”。科目管理即体系科目的类目管理；班课管理即“班课产品”的管理；合同管理即售卖1V1或班课时，客户需要签署的相关合同管理。
8. 订单管理：包含课程订单管理，以及对账管理；可对订单信息进行修改以及作废等操作。
9. 公司管理：包含“组织架构”、“员工管理”、“职位管理”，是此系统能够运行的基础。
10. 其他管理：包含审批和标签管理等功能。

以上即整个CRM的整体功能框架，笔者后续会分几篇文章分别对以上模块做单独介绍。

本次就先介绍整个系统的基础——「公司管理」模块。这一模块也是比较通用的产品设计，适用于各种需要进行权限管理的B端产品。

二、公司管理

因为公司现有OA系统的组织架构模块没有共享的能力，另一方面此“国际课程培训事业部”是作为一个子公司独立品牌运营的，所以需要在此CRM中再单独开发组织架构模块。但是无需特别复杂，仅需达到数据权限与功能权限的控制和业务审批流程控制即可。

1. 组织架构

组织架构即经典的树形结构，笔者在进行方案设计时，参考了现有OA系统以及钉钉的组织架构设计。

组织架构要有最顶级的父级节点，这个节点一般是不能编辑改动的。其他的组织节点全部都挂载在此节点下，因此如果顶级节点一旦被调整位置或被删除，整个系统将会全部乱套甚至瘫痪。

除了顶级节点外，笔者根据业务部门的现在的情况，以及未来的发展趋势，限制了下级节点最多有3级，即【顶级节点】——【一级节点】——【二级节点】——【三级节点】；

除顶级节点外，其他节点都可以调整位置挂在到其他节点下。调整时需要注意如果该节点下还有子节点，那么需要确定子节点是否跟随转移还是默认转移到最近的上级节点。

另外如果该节点内有员工，也是同样的道理需要确定员工是否要跟随转移。这里笔者采用的方案是子节点以及员工全部跟随转移。

还有一点值得注意的是，如果要删除一个节点，必须考虑到该节点内是否有员工存在。这里笔者建议，如果节点内有员工则必须先将员工转移，再进行删除操作。

2. 员工管理

员工管理也可以理解为账号管理，只有被添加了的员工（且状态正常），才可以登录CRM系统。

在员工的信息中，需要定义一个字段作为登录的账号，一般常见的有手机号和邮箱，比较好记而且也方便密码遗失后的找回。不过笔者并没有做密码找回的功能，仅仅是做了管理员重置密码和个人密码修改的功能。因为对于企业内部来说（特别是中小企业）系统管理员就可以承担“找回密码”的功能。

员工的状态也是非常重要的点，一般来说有“在职、离职”两种状态，在职即代表该员工可以正常登陆并访问系统；而一旦被“离职”后，必须要禁止该员工访问系统。

另外因为此CRM是需要接入一个第三方的外呼系统的，届时需要给销售人员添加一个“坐席号”才能正常拨打电话，所以笔者在此版块添加了此字段。

其他的员工档案字段需要根据自己公司的实际情况来定义了，这里笔者就不展开说了。

3. 职位管理

职位管理即角色管理，是为了控制员工可访问的系统资源。

笔者设计的职位属性包含：职位名称、数据权限、功能权限、状态；

职位名称一般是不能重复的，虽然ID是唯一的，但是名称一旦重复，后期在给员工选择职位的时候就很容易混淆；

数据权限主要通过上面所讲的组织架构来进行控制。

不过在职位这里还是进行了权限范围分类：

• 【本人】：即只能看到自己产生的或与自己有关系的数据；
• 【本部门】：可以查看该员工所在部门所有人的数据；
• 【本部门及下级部门】：既可以查看该员工自己所在部门的数据，也可以查看该部门下的所有子部门员工的数据。但同级的邻居部门的数据无法查看；
• 【全部】：可以看到所有人的数据；

功能权限这块就完全需要按照需求来了，没有通用的划分方法。理论上来说，任何一个页面上的任意一个按钮、搜索框、字段等等，都可以做功能权限控制。

在进行功能权限划分的时候，一般只要在文档中写清楚所划分的功能的界限，开发就能够明白了。如果初次功能划分的有问题，也没有关系，毕竟划分功能不是设计功能，这块都是可以反复定义的（但是要善待开发兄弟呀）。

功能划分完成之后，还要以一定的规律呈现，方便在组合的时候快速找到。所以笔者建议可以以导航栏为基础，这样想要开通某个页面下的功能时，自然就能快速锁定该功能的位置；

职位的状态，一般分为“正常、禁用”两种，职位被禁用后，只要员工没有被“离职”，还是可以正常登陆的，但是就无法访问任何系统内容了；

以上就是此CRM的“公司管理”模块的所有功能设计了，因为公司的业务以及组织架构目前较为简单，所以以上的功能就能满足不同业务人员的数据访问控制和可使用功能的控制了。

以上就是本篇文章的全部内容，感谢各位的阅读，下一篇会介绍【客户管理】以及【工单】模块的设计。

作者：Jaycess；教育行业B端产品经理；

本文作者 @Jaycess 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！