客户转交后仍由旧员工看到：负责人和数据权限联合排查｜云上订货系统
云上订货 · 更新于 2026-10-08
客户改交新员工后，旧员工仍能搜索到该客户，先查档案是否已经更新，再查旧员工为什么仍有查看范围。所属员工用于确认当前客户负责人，客户数据权限决定员工能够查询哪些客户，两项结果需要分别回读。同一企业内的客户交接，按PC客户列表、所属员工确认和员工账号权限分别排查。图中系统画面为历史资料；处理时应在自己的原客户档案中核负责人，再由旧新员工分别读取当前权限和查询结果。
先确定原客户和实际转交入口
先在PC“客户列表”用客户编号搜索，打开同一条客户详情。客户名称、联系人或门店简称可能相似，只比较列表名称容易把另一家门店误认成原客户。保存转交前的客户编号、所属员工、所属区域，以及当时操作的企业和账号。按本次交接的原客户编号定位并核对原档案；不要修改另一客户的所属员工来试探本次交接结果。
确认所谓“转交”究竟做了哪一步：在客户列表勾选客户后“修改所属员工”，在编辑客户中改了所属员工，还是只在备注写了交接说明。备注可以记录首单、价格和收货地址等交接事项，但不会替代所属员工字段；新增跟进记录也不能证明负责人已修改。若只口头交接或写了备注，应先核实际保存结果，不能直接进入旧员工权限异常判断。
图1：历史PC客户列表可按客户编号确认交接对象；转交结果仍须重新打开原客户核所属员工。
判断转交是否完成，先查客户基本信息里的“所属员工”，再查旧员工能否看到。负责人已是新员工而旧员工仍可见，是需要核权限的结果；负责人仍是旧员工，则先核客户选择、目标员工和保存是否成功。不要用“旧员工没有看到”反推转交成功，因为客户状态、区域、标签或其他筛选也可能使原客户暂时不出现在列表。
当前客户列表还存在发起“客户转移申请”的入口，它针对客户归属申请，不能与同企业内“修改所属员工”混用。遇到申请、店铺归属或集团商城转移时，先记录入口名称和申请状态，再回到对应流程核结果。申请发起成功不代表客户所属员工已改变；跨企业或跨店铺交接也不能合并成一次员工变更。
图2：先分别确认原客户、当前负责人、旧员工查看范围和历史对象，避免只凭列表可见或备注判断转交结果。
修改所属员工，先回读原客户结果
从客户列表勾选需要交接的原客户，再选择“修改所属员工”。批量操作前核勾选数量和客户清单，尤其不要把同名客户、其他区域门店或上一轮保留的勾选混进来。该操作有独立的操作权限，账号看得到客户并不意味着能修改所属员工；没有按钮时先核管理员给该账号的操作权限，不用导入、删除重建或改客户类型绕过入口。
选择目标员工时确认姓名、部门及账号状态，避免同名员工误选。PC员工选择范围为启用员工，并且该次选择为一个目标员工；它不是给同一客户增加多个负责人。若目标员工在选择列表中找不到，先核员工账号是否启用、是否属于当前企业及搜索条件。不要用另一个员工暂代后再转回，因为这样会增加交接记录和定位实际结果的难度。
图3：历史PC勾选客户后的“修改所属员工”入口；所属区域与所属员工是两项独立操作。
确认对话框会显示客户名称、客户数量和目标员工。逐项核对后再确定；取消或关闭对话框不会完成修改。一次修改多个客户时，对话框的首个名称和“等”不能代替完整清单检查。遇到客户选择为空、目标员工为空或员工不存在等失败提示，应保留首次提示，重新核选择内容，而不是连续点击确定或把失败当作已经保存。
图4：历史确认框列出一个客户及目标员工；此画面是保存前确认，不是修改成功回读。
保存后刷新客户列表，再重新打开原编号的客户基本信息，确认“所属员工”确实是目标员工。成功提示后仍要做这次回读，旧详情标签页或旧列表不能代替新查询。批量交接逐个核原客户，确认没有漏改；原客户编号、所属区域、客户状态及交接范围同时保留。修改所属员工不会替你重新设置旧员工的客户数据权限，也不能当成所属区域已变化。
旧员工仍可见，核四种客户数据权限
由有管理权限的账号打开“员工账号”中旧员工的权限设置，读取“客户数据权限”的实际选项。不要仅按职位、部门名称或角色名称猜权限，也不要用管理员自己的搜索结果代替旧员工结果。核对当前是“全部客户”“负责的客户”“指定区域的客户（含负责的客户）”还是“仅显示15条数据”，再把该选项与原客户当前所属员工、所属区域对应起来。
选择“全部客户”时，客户改交新员工并不自动使旧员工失去查看范围；仍查到原客户可能符合其原有权限。选择“负责的客户”时，普通客户查询主要依据当前所属员工判断，客户已改交且刷新后仍命中，才进一步核实际账号、企业、页面和查询条件。不过页面还可能叠加其他操作权限及筛选，不能据这一选项承诺所有报表、记录和详情都采用同一范围。
“指定区域的客户（含负责的客户）”同时考虑负责客户和指定区域。即使负责人已换，原客户区域仍在旧员工指定范围内时，继续可见不等于转交失效。核客户档案的所属区域和旧员工指定的客户区域，不要拿联系地址、所在地区文字或员工所在部门代替。若业务交接要求旧员工不再查看，应由管理员明确调整范围并保存，不能随意改客户区域去掩盖权限差异。
“仅显示15条数据”是列表数量限制，不能把它解释为仅看自己负责的十五个客户，也不能据未出现在前十五条就判断已不可见。修改权限时，指定区域选项还需选择负责区域；保存失败应先处理原提示。保存成功后重新打开员工权限核选项，再由旧员工刷新查询，必要时重新进入当前企业。不要固定等待几分钟就宣布生效，也不要把未保存的选项截图当作最终权限。
图5：四种权限分别核查看范围，指定区域含负责客户与十五条限制不能当作负责人转交结果。
历史记录与任务，分别核归属边界
客户基本信息里新的所属员工，是当前档案负责人回验的关键字段。历史系统画面可以帮助找到该位置，旧新员工的可见结果仍需各用自己的账号重新查询。手机管理端客户详情也可回读同一客户编号与所属员工；PC已修改而手机仍显示旧内容时，先重新查询并打开原客户，记录两端刷新时点和账号，不能因端别不同就再做一次转交。
历史客情记录中的创建人、记录员工和录入内容属于该次沟通信息，不能因为客户改交就要求它们全部改成新员工。看到旧员工姓名，先辨认是在客户档案“所属员工”，还是在跟进记录的创建人或回复里。客情列表还区分我负责的记录和全部跟进，并叠加日期及数据范围；原客户当前负责人已更新，不意味着旧草稿或旧沟通内容应被删除。
图6：历史PC基本信息显示客户编号、所属区域和所属员工；交接时需重新打开原客户核当前值。
任务跟进还有自己的跟进员工、关联客户和计划内容。客户档案改交后，原任务仍出现旧跟进员工时，不能只凭该姓名断言客户仍归旧员工，也不能假定未完成任务已经自动交接。沿原任务核实际执行安排和处理状态，再由业务人员确认是否需要后续任务交接。不要作废原任务或把旧反馈删掉来制造“旧员工看不到”的结果，历史工作应有可追溯的依据。
客户关联商机也应独立打开回读所属员工。批量修改客户所属员工与商机员工同步存在不同处理边界，不能把客户保存成功当作商机已同步成功的证明。先保存实际操作入口，分别记录原客户和关联商机结果；发现商机仍是旧员工时交接这一处差异，不通过反复编辑客户、重复转换商机或重建客户试图强制同步。订单、资金和历史单据的范围也不能由一次客户列表结果推断。
图7：客户档案、历史跟进、原任务和关联商机分别回读，旧姓名所在字段决定下一步核验对象。
用旧新员工的同条件查询完成交接
最终查询先固定当前企业和原客户编号，再分别记录旧员工、新员工以及管理员的实际账号身份。两名员工各自刷新客户列表，核相同客户状态、区域、标签、客户类型和所属员工筛选。手机管理端还可能保留来源、账号状态等筛选，清空相关条件后重新查询，再打开原客户详情。新员工查不到时，先核当前所属员工和筛选，不要立即给他全部客户权限。
把结果写成可复查的两项结论：原客户当前所属员工是谁，旧员工在当前权限及查询条件下能否看到。新员工能看到并且档案负责人正确，可以确认这部分交接；旧员工仍可见且属于全部客户或指定区域范围，应说明权限依据。只有预期明确要求旧员工不可见、相应范围已保存且同条件查询仍可见，才保留为权限差异继续处理，不能给所有旧员工统一判失败。
交接异常时保留原客户编号、操作入口、勾选客户数量、目标员工、保存时间及首次提示，再附旧员工权限选项、指定区域和刷新后的实际页面。若没有显示内部编号，用客户编号和原客户名称定位，不补造业务编号。另列历史跟进、任务或关联商机里的差异，说明具体字段与时间；这样的证据可以把保存失败、范围允许和其他对象未交接分别定位。
排查结束后仍保留原客户和历史工作结果。不要为隐藏旧员工可见而删除客户、停用订货账号、清空跟进记录或改掉所有旧姓名，这些动作会影响真实业务并丢失依据。负责人正确、权限符合预期、旧新员工同条件回读一致后再交接；尚未完成实际账号核验时，保留待核项，不能用历史截图、管理员结果或一次成功提示宣布全部权限已经生效。
图8：同一原客户先核当前负责人，再分别核旧新员工查询结果和权限依据，异常留在对应层处理。