第八期 你把客户资源当作资产了吗？

客户数据采集的思路理清之后，Kevin马上组织IT部门人员，对现有的售楼系统按照初步的客户数据采集要去进行整改。在与业务部门和售楼现场座谈后，Kevin发现，不仅仅是一个售楼现场的信息资源，而是一个区域的多个楼盘，乃至于不同地域之间的信息共享都存在很大问题。比如说：在北京已经置业多套万城房产的老业主，在武汉万城地产买房还要排队。这说明，客户信息并没有通过一个有效的资源管理机制来进行共享，从而万城地产的老客户可能就享受不到应由的对待。

James还告诉Kevin，在以往的销售过程中，经常发生业主的信息被泄露给装饰装修商，造成很多业主投诉，还没有入住就不断的被装饰装修商的电话骚扰。这种现象通过加强管理手段虽然遏制了一部分，但是至今仍然存在。还有，当员工离职的时候，也经常造成客户数据丢失。

Kevin组织了内部小组和独立顾问Kay参加的座谈会，着重围绕客户资源管理进行了深入讨论，会上大家基本上统一了对客户资源的认识：无论是营销活动所影响的线索客户，还是销售过程中的潜在客户、意向客户，以及业主或者客户会会员，招商的储备商源、投资者、租赁商户以及专业卖场的消费者等，都是企业宝贵的客户资源，如何有效统一的管理客户资源是企业增强核心竞争力的关键。

那么，这些客户资源如何管理？谁可以看？谁不能看？怎么实现呢？

客户资源作为企业最宝贵的资产，我们就要强调资产的管理和保值，而不是仅仅废弃或者闲置在那里，资产利用率是客户资源最关键的考核指标之一。

对于客户资源管理，首先要确保资源的集中管理。无论从逻辑上还是物理存放上，都要实现集中存储和集中管理。而这个集中，不是单一的总部集中制，根据不同情况是可以分级集中的，比如总部集中整个集团的客户资源，各个地域公司集中各自地域的，而各个销售现场集中管理各自项目现场的，通过分级分层次来实现集中。

集中之后就是共享，集中是分级的，共享也是分级的。共享可以分为：销售团队共享、楼盘共享、地域共享、部门共享、代理共享等等不同级别和情况。根据住宅地产和商业地产的销售模式不同、销售团队模式不同，共享机制也不完全一样。

在对客户资源的资产管理下，最终形成基于统一的客户数据模型的客户全信息视图，同时该全信息视图能够确保在一定规则下的集中和共享，比如跨地区、部门和业务线的在数据权限过滤和限制下的共享。在形成统一的客户全信息视图后，才有可能对客户进行全方位的分析。

该栏目及其相关内容由AMT独家拥有发布权，相关版权归内容提供者。如若转载，请务必注明“来源：AMT公共知识库”及“作者：叶开”，否则将付诸法律。

楚剑，汉拓咨询的资深顾问，致力于CRM的培训、推广服务和客户流程、客户智能分析等咨询服务。技术流程、系统评估客户智能分析等咨询服务。

金华，汉拓咨询的咨询顾问，致力于CRM技术流程、系统评估客户智能分析等咨询服务。

汉拓咨询(www.huntor.cn )是国内第一家专注于客户关系管理领域的咨询机构，秉持中立、全面和深入的宗旨，从事客户战略、客户流程、客户营销和客户商业智能分析的培训、咨询和推广服务！

集中与共享的实现都存在一个权限的问题，权限不仅仅是系统实现，最重要的是在业务规则上明确具体的集中与共享的权限明细，再来通过系统实现。

安全权限管理通过在CRM系统中建立组织架构的方式来达到对登录用户建立不同的数据记录浏览权限的安全控制，有助于CRM系统中的各个管理模块和各功能组的有效运作；同时根据不同用户的工作职责和范围，赋予用户对各类视图和数据、功能操作等不同的访问权限。安全权限管理应具有的两大特点：在系统中创建一个或多个组织机构，实现在不同的组织架构下浏览不同数据记录的权限控制；赋予登录用户不同视图和数据的访问权限和基本功能操作属性。

安全权限管理通过定义组织架构，明确了使用CRM系统的公司的内部从组织、部门、职位到用户的不同的隶属和汇报关系及赋予登录用户相应的访问权限，在功能设置上包括了组织的定义、部门的定义、职位的定义、权限的定义、用户和雇员的定义等；通过定义不同业务性质或业务角色的CRM系统的数据记录浏览权限控制和功能属性操作。

用户（user）

用户指登陆系统进行操作者，从严格意义上讲，用户不等同于企业员工。因为在CRM部署实施中，经常存在以职位或者业务角色而不是具体的个人作为用户的，这样的设置对于企业业务管理更加有利。同时，一个企业员工可能拥有多重用户名，一个是自己姓名的，一个是自己所属的业务角色。

用户的权限实现是根据不同用户的工作职责和范围，将一个或多个权限名赋予一个或多个登录用户，由此决定限制哪些视图登录用户可以访问，同时赋予登录用户基本的功能操作属性（增加、修改、删除）。

用户组（Team）

用户组是指一组用户的集合，其集合是基于业务数据范围的。从安全权限的角度讲，属于同一个用户组的，其数据是可以共享的，而数据的编辑权限有用户组组长进行设置。

在具体应用中，用户组可能是企业的部门（department）、业务单元（Business Unit）、组织结构部分（orgnization structure）、销售/服务区域（divion）等，也可能是一个为了在一定时期内管理部分特定客户而临时组成的客户小组，如VIP客户组。

安全权限管理中定义该用户组的数据访问权限，，包括对主要业务实体的数据的访问、编辑权限，该用户组的权限设置将适应于该组内的所有用户。

管理隶属（manager）

在数据权限范围中有一个特别的关系设定，就是上下级的关系，用户是否是管理权限（is manager）？用户需要汇报给哪一个用户（report to）？管理隶属一般回出现在用户组、组织以及一些特殊的管理应用中。

在安全权限有一个默认的上级规则，就是上级可以查看下级的数据，无论是否属于一个用户组，但是一般而言只有只读权限，有时候也提供设置只读修改权限。上级规则支持无限级，即上级可以查看下级的下级的下级的数据。系统管理员是所有用户的顶端上级。

在日历管理中，需要特殊处理，一般默认的规则是上级可以在日历模块中看到自己的所有下级的日历活动安排，同上级规则。但是，有时候也有一些其它设置，所以又开放查看不属于自己管理的其它用户的日历活动的权限设置。

通过以上所提到的在一般权限实现中的用户、用户组、功能和管理隶属等基本可以实现一般企业的安全权限管理，同时基于用户组与功能组的交叉，并结合用户的个性设置，上下级的隶属，也是可以实现比较复杂的集团化矩阵权限管理。

组织

组织是CRM系统中整个组织架构的第一步（组织本身是没有层次关系的），一个组织可以理解为一个具有独立核算的公司，也可以被理解为若干角色、区域或部门的集合。

设置组织架构，同用户组一样，用户仅能看到属于自己组织下的数据记录。同时，用户基于某个组织下被指定的职位，系统能够提供属于这个职位的用户能浏览和存取相应的数据记录的权限。

企业还可以定义一个外部客户访问的组织，便于更好地管理和控制外部用户浏览和访问CRM系统中的数据记录，这个在合作伙伴管理和渠道管理特别有用。

组织架构的组成是千变万化的，没有唯一或者正确与否，下图只是一个体现，并不一定正确，仅供参考。

图8－1 组织结构

部门

通过设置相应的上级部门、本级部门以及所属组织等关键信息，构成一个在某个组织之下的各个部门之间的不同层次和隶属关系。例如，某组织（集团公司）下辖几个区域分公司，某区域分公司由销售部、市场部、客户服务部构成；从此例来看，区域分公司和销售部、市场部、客户服务部之间被定义为有上下隶属关系的不同部门，区域分公司之间为属于同一层次关系的不同部门。组织本身也必须被定义成一个部门，并且作为一个部门在部门浏览器视图中被显示，构成整个一个组织架构层次关系。

职位

职位是指用户（雇员）所拥有的一个具体岗位。

一位用户可以拥有一个或一个以上的职位，一个职位也可以由一个或一个以上用户所拥有。职位是相对固定的，而拥有职位的用户可以随时改变一个职位。

定义职位的作用主要是通过职位的设置来相应体现在组织内的同一部门内或不同部门之间职位的层次和隶属关系，由此而实现不同职位可以浏览不同数据记录的权限。