一个客户两个部门跟：共享与数量限制的补丁打法
一个客户两个部门跟：共享与数量限制的补丁做法
一、默认规则管常态，例外要有补丁
分级可见解决的是大多数情况：各人看各人的，各层看各层的。可真实业务里总有例外：某个重点客户，销售部和项目部都要跟进；某位主管带着跨部门小组；某个新人一上来就领一大串客户，根本顾不过来。默认规则管不了这些例外，需要几个专门的补丁机制。把例外情况也收进规矩里。
补丁的意义在于小而准。不动大框架，只在一处开口、只对指定的人生效，用完即收。比起为了迁就例外而把整体边界改宽，补丁的代价小得多，也不会留下长期的后门。默认规则定骨架，补丁机制管关节，两者配合业务才跑得顺。
- ● 例外不是规则的漏洞，是业务的常态
- ● 补丁要打在点上，而不是推翻整个规则
- ● 小口子随时能关，大口子收不回来
图1：数据看板汇总全局，共享边界不失控
把例外情形先盘一遍，配置就有的放矢。常见的例外无非几类：临时协作型的，客户要几个人搭手，走指定共享；带队型的，主管管的人跨了部门，用管理范围圈名册；容量型的，个人手里的客户多得跟不过来，用数量限制约束。
每类例外对应一个补丁，盘点清楚之后逐类配置，比想到哪配到哪有条理，上线后也好向团队解释每条规则的用途。
- ● 先盘点例外类型，再逐类配置
- ● 每个补丁对应一类情形，解释起来清楚
- ● 盘在前、配在后，返工最少
二、指定共享：给协作开一扇小门
指定共享的用法很直接：把某个客户或一批客户单独共享给指定员工，对方可以查看，必要时还能参与协作跟进。关键是这个动作不改变他的默认可见范围，共享一取消。界面恢复原样。说穿了，跨部门要合力拿下一个订单时，这扇小门比把两个人的可见范围都改宽要稳妥得多。事后也不会留下说不清的尾巴。
用指定共享也有讲究：共享要有事由，谁发起、给谁看、为什么，最好在内部说一声；事毕及时取消，不留挂在账上的长期共享。口子开得清楚、收得及时，协作和边界就能兼得。
图2：查重防冲突提示，重复跟进早拦下
- ● 共享的是客户，不是权限
- ● 门小但有锁，随时能关
- ● 共享有事由，取消有时点
共享机制还有个容易被忽略的价值：它让协作有始有终。口头约定的协作，事完就散，客户信息在谁脑子里、答应过谁什么。全凭记忆。
系统里的共享有明确的开始和结束，参与过的人留下的跟进记录都在客户档案里，下一任接手的人翻一翻就知道来龙去脉。协作的痕迹沉淀在系统里，而不是散在聊天记录里，这才是把协作做扎实的样子。
- ● 口头协作凭记忆，系统共享有痕迹
- ● 跟进记录留在档案里，接手不断档
- ● 事了共享即收，档案始终干净
三、管理范围：跨部门小组怎么带
有些主管的团队本身就是跨部门拼起来的，按部门划范围就失灵了。管理范围机制允许单独指定他管哪些人，而不是简单按部门一刀切。小组里的成员来自哪个部门不重要，重要的是他名下这些人的数据都在这位主管的视线里，带跨部门项目就不会两眼一抹黑。调度起来也有依据。
项目解散或成员变动时，调整名册就行。范围跟着带队关系走。往实里说，组织越灵活，这类需求越多，管理范围机制正好补上了部门制框架的短板，让临时性的带队也有清晰的视线边界。
- ● 管人按名册，不按部门框
- ● 范围跟着项目走，项目变范围跟着变
- ● 临时带队也有清晰视线，调度有据
用管理范围还有个附加好处：项目组的成绩单好算。小组名册圈定之后，这段时间项目相关的客户跟进、订单情况都在这位主管的视线和报表里，项目复盘时有现成的口径，不用东拼西凑地对数据。
项目制的团队尤其能体会到这一点，组织是临时的，数据归集是清楚的，项目结束各回各岗。留下的是完整的过程记录。
- ● 名册圈定，项目成绩单自带口径
- ● 组织临时，数据归集不临时
四、客户数量限制：别让名单压在箱底
还有一种隐性浪费：业务员手里囤着很多客户，长期不动也不释放，新同事想跟没得跟。给单个业务员设一个可持有的客户上限，倒逼他定期梳理手里的名单：还在跟的认真跟，不跟的放回池子里流转。客户资源是活的，压在个人箱底就是浪费，上限就是让名单重新流动起来的推手。
上限的数值不必追求精确，比实际能跟得住的量略紧一点即可。太松了形同虚设，太紧了逼人乱放客户。配合未跟进自动释放的规则一起用，囤积的现象自然就少了。设上限之前最好把现状摸一遍：名下客户超过正常跟单能力的人有多少、公海的存量有多大，心里有数再定尺子，推起来阻力也小。
- ● 上限逼着梳理，名单保持流动
- ● 囤而不跟，是对客户资源的浪费
- ● 上限略紧于实际能力，配合释放规则
- ● 定尺子前先摸现状，推起来阻力小
五、补丁打完，闭环才算合上
指定共享解决协作，管理范围解决带队，数量限制解决囤积，再配上长期未跟进自动进公海的规则，整个客户流转就形成了闭环：客户不会被无限压在某个人手里，也不会因为共享而失控。海软CRM 把这几个机制做成独立可配的选项，管理员按团队情况逐项打开，先解决最突出的那类问题，再逐步补齐其他项。
默认规则加补丁，比一开始就把规则定得巨细无遗要务实得多。一句话，规则太密没人记得住，执行起来处处走样；抓大放小，把常见的例外用补丁接住，团队反而更容易把规矩真正用起来。
- ● 闭环的关键是流动，不是控制
- ● 机制各管一段，合起来才成体系
- ● 规则抓大放小，执行才不走样
- ● 默认管常态，补丁管例外，各就各位
上线之后别急着收工。头一段时间留意几类信号：共享是不是越开越多、上限有没有人天天顶格、公海里是不是堆着没人认领的客户。这些信号各自指向不同的调整方向，及时微调。闭环才会越转越顺。机制是死的，业务是活的，让机制贴着业务的实际节奏走，才算真正用出了价值。
- ● 上线后盯紧共享与公海的信号
- ● 机制贴着业务调，价值才出得来
推这些机制时，话要说在前面。给业务员设持有上限，先讲清楚为什么：不是嫌他跟得多，而是让好客户不被压箱底；给主管配管理范围，先说明视线边界在哪，避免有越界的误会。规则连同理由一起公布，执行起来才顺。
多数团队的经验是，把道理讲透之后，大家反而欢迎这些机制，因为认真跟进的人不再吃亏。新同事也有客户可领。
- ● 规则连同理由一起讲，阻力小得多
- ● 机制护的是认真做事的人
六、这些问题是问得最多的
1、问：跨部门要一起跟进某个客户，怎么办？
答：用指定共享。管理员把这位客户单独共享给需要协作的同事，对方可以查看并参与跟进，而他自己的默认可见范围没有任何变化。协作结束后取消共享，界面立刻恢复原样。比起临时改两个人的可见范围，这样既精准又可控，事后也不会留下说不清的权限尾巴。
2、问：共享会不会把边界越开越大？
答：不会，前提是共享按客户逐个指定，而不是按人批量开放。每次共享都对应具体的客户和具体的人，事毕即收。建议团队约定：共享要有事由，主管知情，完成后及时取消。口子小而有记录，就不会演变成变相的全员可见，协作的灵活性和边界的严肃性都在。
3、问：带跨部门项目组的主管，范围怎么设？
答：用管理范围机制。不按他的所属部门划，而是单独指定他管哪些人，项目组成员名下的客户数据都会进入他的视线。项目解散或成员变动时，调整名册即可。这样范围始终跟着带队关系走，而不是被部门架构绑死，临时小组的视线边界同样清清楚楚。
4、问：客户数量限制有什么实际作用？
答：防止囤积。有的业务员把很多客户握在手里，长期不跟进也不放手，新同事没客户可领，客户资源整体在贬值。设了持有上限，他必须定期梳理：在跟的认真跟，不跟的释放回池子流转。名单流动起来，整体成交机会才会变多，新人的成长空间也被腾了出来。
5、问：这些机制要同时都开吗？
答：按需开。先看团队里哪种情况最突出：协作多就先开指定共享，跨部门小组常见就配好管理范围，囤积明显就上数量限制。机制之间互不冲突，也可以逐个启用，每开一项观察一段时间效果，比一次性全开更从容，出问题也容易判断是哪一项在起作用。
