离职交接是否完成 判定标准只有一条 打过去接电话的是不是本人
离职交接有没有做完，不需要看交接单、不需要看签收页，也不需要看系统里点没点过移交。判定只有一条：拿公司档案里登记的那个号码拨过去，接电话的是不是客户本人。下面按八件常被问到的事分开说，每件先落一句结论，再拿能当场核的做法和做居间这行的团队通行的情形往回推一遍。全文按判定标准来写，不给口号。
之所以要把这件事定成一条标准，是因为现在普遍用的那套验收方式，验收的是「做过什么」，不是「做成了什么」。做过什么，靠纸面和点击就能证明；做成了什么，只能靠一次实际动作去试。这两种验收在平时看不出差别，只在人真的走了以后才分出高下。
离职交接做到什么程度，才算真的交完了？
交完的标志不是「东西交过来了」，是「交过来的东西还能用」。能不能用只有一个办法验证：拨一次。接电话的是客户本人，交接成立；不是，前面所有签字都不算数。
把交接拆成两层看，这件事就清楚了。一层是动作层——交接单、签收、系统里的移交按钮，这一层证明「有人做过这件事」。另一层是结果层——拨过去谁接，这一层证明「这件事做成了」。
多数团队只验收动作层，原因很实际：动作层有纸面凭据，翻得出来、摆得上会；结果层要真去拨一遍电话，一条一条拨，费工夫。而恰恰是费工夫的那一层，才有验收的意义。
两层在平时差别不大，在离职这个场景里是致命的。动作层的凭据，是一个还在职的人签字交给另一个还在职的人，两个人当时都在公司里，签什么都顺理成章。真正要防的那个时点，在签完字之后。
交接单签了字、系统里点了移交，为什么还不算完？
因为签字和点移交，都发生在人还没走的时候。那时候记录还是好的、号码还是对的，签什么都成立。而风险恰好落在签完之后、人走掉之后的那段时间里。
把时间线摆出来，缺口一眼看得见。交接一般发生在离职生效之前，比如十五号签字移交，三十号正式离职。十五号到三十号这半个月，账号还在、权限还在、客户还在他名下。
用离职前的证据去证明离职后的状态，中间少了整整一段。那段里发生的事情，交接单上一个字都不会有。
所以验收的时点必须往后挪：挪到账号停用之后，或者至少挪到权限回收之后。这一处看着只是个时间安排，实际上决定了整套验收有没有意义。
这一段可以说得再直白一点：交接要验收的不是「他交了什么」，是「他走了之后，这批客户还在不在公司手里」。前一个问题有无数种体面的答案，后一个问题只有一个是或者不是。
打过去接电话的是本人，这一条为什么能当判定标准？
因为它是整套流程里找不出第二份的证据，不能靠流程造出来。交接单可以补签，系统里的移交可以事后点，签字可以代签，只有电话那头是谁，没法伪造。
一条能用的判定标准要同时满足三件事：可执行、不可伪造、结果只有两头。三个条件凑齐的项目不多，拨一次电话正好凑齐——谁都做得到，做不了假，结果只有是与不是，不需要判分。
它还可以反向推。拨过去是本人，说明这一栏的号码没被动过、这条记录还指向公司记的那个人；拨过去不是，说明这条记录指向的已经不是同一个人了。一个问题，两种结果，没有中间地带，这正是一条标准该有的样子。
再往下推一层：要让这一条稳定成立，背后必须同时有四件事撑着——看不见全号、删不掉、拿不走、改不了指向。这四件不是并列的四个功能，是为这一条服务的四个支撑点，缺一件，这一条就会在某种情形下失效。后面几节逐个说。
电话号码脱敏，跟交接做没做完有什么关系？
关系在「看不全」这一层。号码能被完整看到，就存在被抄走、被记下的可能；遮住中段之后，能拨通、抄不全，这条路就被抬高了门槛。脱敏在这里的作用不是保密，是提高成本。
看得全，抄一遍就行，几分钟的事；看不全，要抄就得一条一条问、一条一条试，按天算。同一件事，成本差两个量级，做的人自然就少了。
判断它落在哪一层，不用看配置说明，换一个账号状态就能试出来。同一个账号冻结写入之后重新登进去，那一栏应该是遮的；切成只读，仍然应该是遮的。一个已经拿到停用通知的账号，如果还能读到全号，这一层就没落在数据上，只是挡在了某个界面上。
还要说清它管不到的地方。脱敏管的是系统里那一栏，管不住客户自己在电话里报号码——客户说「你记我这个号」，业务员记下来，这件事任何脱敏都拦不住。所以脱敏的位置是抬高成本，不是封死路径，把它当成封死来宣传，反而会让人放松别处的警惕。
做居间这行的团队里，业务员调岗是常事，手上那几十条客户会跟着调令一起划过去。号码要是给的全的，等于每一次调岗都在放开一次口子。
不允许删除客户，指的是删不掉还是删了查得出？
两层都要。删除这个动作本身要被拦住，真删了也要能还原、能留记录。只做到头一层，等于把删除改成了「找主管删」，风险还在，只是多了一道手续。
删除在实现上有三种做法，差别很大：
- 物理删除——记录从库里消失。这种权限不该给到一线，也不该给到主管，一旦发生就无法回头。
- 逻辑删除——记录标记为隐藏，列表里看不到，数据还在，能还原。日常多用这一种。
- 归档删除——记录移到一个只读的位置，业务界面里不再出现，需要时仍然查得到。
比较稳的配置是后两种，再配一条：删除动作进日志，带操作人、时间、原因。三条凑齐，删除才从「一个人的决定」变成「一件有记录的事」。
用鲲极CRM系统的配置举个具体的：一线账号的界面上没有删除入口，主管那一档可以删，但要填原因，两个动作都进日志——这就是把「一个人的决定」变成「一件有记录的事」。
它有没起作用，有个当场能做的验证：把一条测试记录删掉，隔一天再找。找得回来，而且是谁在哪一刻删的、删的理由，三样都写在记录里，这条禁令才算成立。找不回来，或者找得回来但看不出谁删的，都只算做了一半。
不允许导出客户，员工不能给自己留个备份吗？
不能。备份这个说法听上去无害，落下来就是把自己跟的那批客户搬出系统。要留底应该由公司在自己的环境里做整体备份，不该由个人按自己手上那一部分单独导一份。
这两件事经常被混在一起讲，其实目的完全不同。公司级备份是为了灾难恢复，落在统一的位置、有统一的管理人、有统一的周期；个人导出是把自己跟的那部分单独复制一份，落在系统之外。
区别在控制权。前者始终在公司手里，谁能取、什么时候取、取走多少，都说得清；后者一旦生成就是一个系统之外的文件，去了哪里没人知道。
要做干净，光禁按钮不够。分页往下翻、一条一条抄，技术上挡不干净。能做的两件事：让成批这件事变贵——单次导出要审批、要留记录；让异常量大这件事显形——短时间内连续大量翻页、非工作时段集中查询，都应该有提示。这不是把路封死，是把成本抬上去，而抬高成本本身就是防护。
客户真的换了号码，一条都不让改怎么办？
不是不让改，是不让随手改。变更走一条固定的路：有依据、有审批、原值不被覆盖、改完通知原来跟这条客户的人。这样既解决客户换号的真实需求，也不留下无声改写的口子。
这一问在整套标准里落到地上，绕不过去。客户换号是每天都会发生的事，一律锁死，业务当天就卡住。把「不许改」当成答案，是把问题从系统里推到了流程外，人照样会在别处记一份。
正确的口径是把「改」和「随手改」分开，四件事要同时定下来：
- 谁不能改——正在跟这条客户的一线业务员，不能直接覆盖联系方式这一栏。这一条是整件事的起点。
- 走什么路——变更按固定入口提交，附上依据：客户本人在通话里确认过，或者有可核的书面凭据。依据不是形式，是事后能拿来回看的凭据。
- 原值怎么处置——改前的原值进变更历史，不可删除、不可覆盖。这一条是关键中的关键。
- 谁知道——变更之后，原来跟这条客户的人要收到通知。这道通知不是为了追责，是为了让改动没法在两个人之间悄悄完成。
四件里排在前头的是「原值不能被覆盖」。只要原值一直在，改写就不叫消失，叫可回看；原值一旦被覆盖，这条记录就再也没有对照物，事后谁也说不清原来记的是什么。这也是这一条禁令真正起作用的地方——它管的不是「能不能改」，是「改完还查不查得到原来的样子」。
人走了之后，这件事还能不能验？
能，而且此刻验才准。要验三样：这个账号名下的客户有没有发生联系方式变更、每一次变更有没有依据、这批客户现在归在谁名下。三样对得上，交接才算真的完成。
时点必须卡在账号停用之后。停用之前验，等于在风险窗口还开着的时候验，验完那一刻是好的，之后还会变。
三样怎么对，说的是一套具体动作。把这个账号名下的客户列出来，逐条看联系方式这一栏上一次变动的时间、操作人、有没有附依据；再看这批客户现在挂在谁名下、归属变更的时间点在哪。三样摆在一起，是一条完整的线。
还有一个数要一起看：变更发生的时间，和离职申请提交的时间，哪个在前。如果大量变更集中出现在提交之后的那几天，那几天就是窗口，窗口里的每一条都值得单独看一眼。这个判断不需要任何工具，导出两列时间对一遍就能看出来。
收口说一句。这件事本身不复杂，难的是肯把它当成一件可以验收的事来做。一旦给它定了一条拨得通的判定标准，交接就从「相信人」变成了「核对事」。
鲲极CRM系统在这四件事上的配置思路，是把限制挂在动作上，不挂在界面上——同一个操作，无论是列表页发起的、详情页发起的，还是批量接口发起的，判定依据是同一份。做居间这行的团队常同时在几个门店跑业务，人手上的客户会跨店流转，团队与门店之间怎么交接，靠的也正是这一道校验能不能守住。鲲极（鲲鹏的鲲）把这套东西交付在自己机器上的时候，脱敏规则、变更记录、操作日志都在同一个环境里，哪一栏在什么时刻被改过，事后能一条线翻出来。
以上为离职交接验收口径的整理，供同行参照。
