管理端 · 客户回访

分配总数＝这一批新分配出去的客户数；已添加微信 / 已拒收 / 待查收＝员工在员工端对每条分配做的动作， 三者相加恒等于分配总数（全部由服务端统计，本页只展示、不重算）。 已经收口的营期不会再出现在上面 —— 收口＝彻底归档：只写一个时间戳，分配记录与查收动作一条都不删， 归档批次可在下面的只读折叠区与回收站里查看；不再提供「重新打开」， 需要回溯时在操作日志里查「营期完成全部添加」。 谁拒的、为什么：每行「已拒收 R 位」下面可展开明细，逐条列出客户名 —— 拒收原因（拒收人） （最多 20 条，多出来的写「…还有 N 条」）—— 这是管理员判断要不要重新分配给谁的依据，不藏着。 员工拒收后，该批分配人必须在右上角「待核实拒收」里逐条选属实 / 不属实（操作留痕：谁、何时、结果）； 不属实会自动把客户恢复给原员工并重新进入待查收；有未核实的拒收时不能收口。 员工写的添加备注也在这里看：每行「已添加微信 K 位」下面同样可展开，逐条列出客户名 —— 添加备注（操作人） （员工点「已添加微信」时必须写至少 5 个字，所以每条都该有内容）——「已添加微信 N 位」只是个数字、看不出真假，备注看得出。 本卡可管理员代操作（待查收可代标已添加微信/拒收，已处理可撤回，均记审计），也可改批次备注与客户交接人。 本卡在有未收口营期、或有已收口营期时都显示；没有 alloc.manage 权限的账号看不到它（服务端返回 403，本页直接隐藏、不占位）。 可展开每行看每个员工的分配数 / 已添加微信 / 已拒收 / 待查收。

已签收＝员工端在「待确认签收」里点过确认签收的客户数（写的是 signedAt）； 应签收 / 共＝该批次全部客户（分母口径 A，含还没加微信与已拒收的）。 未签收＝全部 − 已签收；已添加未签收＝已添加微信里还没签的（＝已添加微信 − 已签收）， 这一项最值得追 —— 微信加上了却迟迟不签。 点营期名按员工展开：员工名 · 已签收 / 应签收，监督到人。 本卡只读：签收只能由员工本人做，管理端不代签；没有未收口营期时显示「—」，不会假装成 0。 已归档批次不再统计（归档＝收口，与左卡同一口径）。