一、功能介绍
跟进记录页按当前企微企业和账号可见员工所拥有的客资查询全局跟进记录，并按创建时间倒序分页。当前真实筛选只有“客户姓名/联系电话”、创建日期和跟进类型；员工、组织、跟进方式、留资方式和渠道筛选已从界面隐藏。列表展示客户、跟进时间/方式/动作/内容、跟进人、组织、下次计划和创建时间。详情抽屉当前只复用列表行，不调用已存在的详情接口，因此部分字段始终为空，也不显示语音、图片或扩展字段。
二、功能亮点
- 非纯数字关键词按客户姓名模糊匹配，纯数字关键词按联系电话模糊匹配。
- 按跟进记录 createdAt 的精确起止时间和 20 类跟进类型查询。
- 按 createdAt 倒序分页，支持每页 10、20、50 或 100 条。
- 列表同时展示实际跟进时间与记录创建时间，便于区分业务发生和录入。
- 服务端要求 CUSTOMER_SALES 专区和 `LEAD_FOLLOW_VIEW`，并通过所属客资强制企业与可见员工范围。
- 详情抽屉展示四组信息，但当前不重新请求详情，记录名称、跟进动作和下次跟进方式缺少列表字段。
三、使用场景
适用于销售复盘自己可见客资的沟通记录，主管检查授权团队的服务连续性，以及客服核对某次跟进是否已录入。它不是员工工作量统计、客户总数报表或完整附件档案；同一客资可有多条记录，且可见范围由客资 owner 决定。
四、使用权限
- 进入列表和调用列表/详情端点需要客户销售专区可用，以及路由 `/customer/follow-up-records` 的 `LEAD_FOLLOW_VIEW`。
- 后端从 TenantContext 获取当前 authCorpId；缺少租户上下文或系统绕过状态会直接拒绝。
- 查询通过所属客资限定 authCorpId，并在普通数据范围下将客资 ownerId 限定为当前账号可见员工 ID。
- 详情端点先找到记录，再用记录的 leadId 执行相同企业和可见 owner 校验；直接猜测 followId 不能读取不可见客资记录。
- 页面只有读取和导出占位，没有新增、修改或删除跟进记录操作。
- 跟进内容、客户联系方式和地址属于个人与业务敏感信息，只在最小授权范围内查看。
五、前置条件
- 确认当前企微企业、登录角色和组织权限组正确；可见范围以客资 ownerId 与可见员工列表为准。
- 业务人员已从客户详情、员工端或业务流程产生跟进记录，并且记录关联有效 leadId。
- 明确要查的是记录创建日期还是实际跟进时间；页面日期筛选实际使用 createdAt。
- 准备客户姓名或仅数字联系电话。带 `+`、空格或连字符的电话会被当作姓名关键词。
- 准备准确的跟进类型文案；筛选使用完全相等，不是包含匹配。
- 需要附件、录音、定位或扩展字段时，先确认其他业务详情是否有可靠来源；当前列表和抽屉不展示这些内容。
- 大范围查询前缩小时间与类型；列表转换当前每条记录会额外读取客资和创建人，页量越大查询压力越高。
六、操作步骤
- 进入「客户管理 → 跟进记录」。页面默认不带时间和类型条件，以每页 10 条查询当前权限范围内记录。
- 在关键词框输入客户姓名片段或纯数字联系电话。纯数字会写入 userMobile，其他文本写入 userName；一个关键词不能同时搜索姓名和电话。
- 选择创建日期。日期变化会立即写入 startTime/endTime，但只有点击「搜索」后才发起请求；边界按包含关系查询 createdAt。
- 选择跟进类型。选项包括普通跟进、订单/任务创建、合同款/定金、客户状态流转、云电销、企微消息和第三方同步等，接口按完整文本相等匹配。
- 点击「搜索」，核对总数和当前页。列表按记录 createdAt 倒序，不按 followTime 排序。
- 分别查看“跟进时间”和“创建时间”。补录记录可能两者不同，不能只看列表位置判断业务发生先后。
- 核对跟进方式。PHONE、WECHAT、VISIT、SMS、OTHER 会映射为电话、微信、到店、短信、其他；其他中文或未知编码原样显示。
- 核对跟进人和所在组织。服务优先读取创建人账号的真实姓名/名称/账号和上级部门；缺失时回退到客资导购与客资组织。
- 点击「详情」。当前抽屉直接使用列表行，不调用 `/detail`；基本信息中的记录名称通常为空，跟进动作读取 follow_action 而后端返回 followType，下次跟进方式也没有返回，所以这些项可能显示短横线。
- 详情抽屉可复核跟进时间、创建时间、方式、内容、下次时间/内容、跟进人和组织。它不展示客户手机号、地址、定位、录音、图片或扩展字段。
- 需要核对完整客资历史时，从《查看和筛选客户》进入对应客户详情，对照 leadId、followTime、内容和创建人；当前列表行没有客户详情跳转。
- 切换页码或页大小。后端最大限制为 100 条；页面支持 10、20、50、100。
- 点击「重置」会清空关键词、日期和类型，恢复每页 10 条并重新查询。展开/收起按钮当前只有三个可见筛选项，更多组织与渠道筛选仍被注释。
- 点击「导出Excel」会按当前筛选和当前页记录生成 CSV 文件。需要留证时在授权环境记录查询条件和记录 ID，不复制过量敏感内容。
- 发现记录缺失时依次核对企业、客资 owner、可见员工范围、创建日期、跟进类型和软删除状态，再与客户详情交叉验证。
七、字段与规则说明
- 列表必须有 `LEAD_FOLLOW_VIEW`，并受 CUSTOMER_SALES 专区守卫。
- 记录表没有独立租户键，列表通过 lead 子查询限定客资 authCorpId 和 ownerId 可见范围。
- 纯数字关键词只查手机号；其他关键词只查客户姓名，均为模糊包含。
- 跟进类型为精确相等匹配。
- 创建日期筛选作用于 createdAt，不是 followTime；开始和结束边界均包含。
- 时间解析异常时后端只记录警告并忽略对应时间条件，不会向页面返回校验错误。
- 列表按 createdAt 降序；同一创建时间的稳定次序没有额外 ID 排序。
- 同一客资可有多条记录，列表总数是记录数，不是去重客户数或员工工作量。
- 详情按钮不调用详情接口，只使用当前列表行。
- 记录名称、follow_action/跟进动作、next_follow_method/下次跟进方式不是列表响应字段，详情中通常显示短横线。
- 后端将 images、录音和若干扩展字段固定为空，页面也没有附件展示区域。
- 每条列表记录转换时分别查询关联客资和创建人，最多 100 条时可能形成明显 N+1 查询压力。
- 组织、跟进方式、上级组织、留资方式和获客渠道筛选当前被隐藏，加载组织树和来源树却仍会在页面挂载时发生。
- 导出功能开发中，不会生成文件。
八、风险与限制
跟进记录包含客户姓名、联系方式、地址和员工业务判断。错误理解 createdAt/followTime、把记录数当客户数、详情字段缺失或数据范围差异会造成错误绩效判断。大页量的逐条关联查询还可能拖慢页面；导出未实现不代表可以用截图绕过最小必要原则。
注意
不要在跟进内容中记录密码、完整证件号、支付凭据、健康隐私或无关敏感信息。不要把空列表直接解释为员工未跟进；先核对企业、owner 可见范围、创建日期和类型。当前详情不完整，关键事实必须与客户详情和业务记录交叉确认。
九、常见问题
- 为什么看不到同事的记录？列表只返回当前企业内、owner 属于账号可见员工范围的客资跟进。
- 为什么不能按跟进员工或组织筛选？这些控件当前已隐藏，后端列表也只支持姓名/手机号、跟进类型和创建时间。
- 日期筛选的是哪个时间？筛选 createdAt，不是 followTime。
- 为什么输入带加号或横线的电话搜不到？只有全数字关键词才作为 userMobile，其他格式会按客户姓名查询。
- 为什么详情里的记录名称为空？列表响应没有 name 字段，抽屉又没有请求详情。
- 为什么跟进动作显示短横线？抽屉读取 follow_action/followAction，后端列表返回的是 followType。
- 为什么下次跟进方式为空？后端保留 nextUserFollowMode 数字字段，但列表没有返回 next_follow_method。
- 详情为什么没有图片或录音？后端当前将 images 和录音字段置空，页面也无附件区域。
- 为什么大页量加载较慢？每条记录转换都会额外查询客资和创建人，存在 N+1 压力。
- 记录条数能代表客户数吗？不能，同一客资可有多条跟进记录。
- 如何确认记录真实完整？用记录 ID、leadId、followTime 和内容到客户详情及相关业务流程交叉核对。
十、相关指南
继续阅读《查看和筛选客户》定位客资并进入详情；需要审计操作时间和接口结果时结合《查询系统操作与接口日志》，但操作日志不能替代跟进业务记录。
说明
页面入口：/customer/follow-up-records