需求不是功能清单，而是待解决的工作问题

CRM项目启动时，业务人员常说“客户资料要更完整”“跟进要自动化”，但这类表达还不足以直接进入设计。不同岗位说的“完整”可能分别指联系方式、服务偏好、当前负责人或历史沟通；“自动化”也可能是提醒、自动分派，或仅仅减少重复录入。若没有先把词义拆开，设计团队容易做出看起来功能齐全、实际却没人按同一方式使用的页面。

需求访谈应从最近发生的一项普通工作开始，而非只问理想状态。请一线人员按时间顺序讲清楚：信息从哪里来，谁先看到，做了什么判断，何时交给下一岗位，完成后留下什么记录。再请主管说明哪些节点需要复核，以及异常由谁决定。把参与岗位分开访谈，避免级别较高的人替日常操作者回答。这里的描述是调研方法，不代表某个企业或系统已经出现相同问题。

访谈记录最好区分四类：现场观察到的事实、员工表达的困难、尚待核实的推测、希望未来实现的目标。比如“重复填写了两次”可通过跟岗确认；“所以客户流失”则需要另外的数据验证。先把两者分开，避免将原因假设直接转成采购或开发要求。

把访谈整理成可以讨论的场景

一条需求场景至少写明触发条件、涉及对象、执行岗位、关键动作、例外情况和结束标志。例如“新线索进入后由谁接手”仍太宽泛；可以继续追问来源渠道是否相同、工作时间外如何处理、负责人未回应时是否需要升级，以及何种记录算已完成。细化并非为了把所有情况都做成复杂流程，而是让业务与实施人员知道边界在哪里。

准备一张需求卡片，记录场景编号、当前操作、问题证据、期望变化、责任岗位、数据来源、待确认事项和验收人。每一项要求都应能回到访谈、制度或现存记录中的依据。若只有一个人的偏好，先标记为待讨论；若制度尚未规定，指定业务负责人定规则，而不是让开发者替公司决定。不同岗位意见冲突时，记录分歧及决策人，不要用一句“按实际需要”掩盖。

场景应覆盖常态和少量高影响异常：信息缺失、重复记录、客户要求更正、负责人休假、任务被取消或需要重新分派。异常选择要来自真实流程和风险，不必穷举所有想象情况。每种情形只问三个问题：谁发现、谁处理、处理后留下什么可追溯结果。这样既能识别权限和交接要求，也不会把需求文档写成没有优先级的愿望清单。

先判断改流程、配系统还是开发

遇到操作困难，不应自动得出“需要定制”。可能是岗位责任没有约定，可能是同一字段被不同团队用来表达不同含义，也可能是已有能力未配置或培训不足。建议先做小范围流程观察：由使用者按现行规则走一遍，记下等待、重复录入、口头交接和返工发生的位置。确认问题后再比较调整流程、利用现有配置、增加人工检查或提出开发需求的成本与风险。

每一项待实现需求，可按业务影响、发生频率、失败后果、人工替代办法和验证难度排序。紧急且影响高的要求应先确认规则与责任；低频、低影响事项可以先记录观察，不一定进入首期。若提出定制，必须说明不定制会造成什么可观察后果、由谁承担临时处理，以及未来规则变化由谁维护。此处讨论的是决策方法，不意味着某个平台支持任意开发或集成。

数据定义也要在设计前厘清。字段的名称、含义、来源、是否必填、谁可查看修改、何时更新以及错误如何更正，都应由业务与数据责任人共同确认。尤其要区分顾客、联系人、服务事项和跟进记录等不同对象，不能只因它们在日常谈话中被统称为“客户资料”，就默认它们应放在同一字段或由同一岗位维护。

让验收标准在设计前就可检查

“界面方便”“提高效率”“实现闭环”无法单独作为验收标准。把它们改写为可观察动作：指定角色能否在规定入口找到记录，能否按授权查看所需信息，完成跟进后是否留下负责人、时间和结果，交接后下一岗位能否继续处理。具体阈值应依据企业真实节奏设定，不应从示例文章直接照搬。

验收用例要和需求卡片一一关联，写出前置条件、测试角色、操作步骤、预期结果、失败处理和证据留存方式。使用虚拟或经过授权处理的数据，避免在演示、截图或培训材料中暴露真实顾客信息。正常路径通过后，再挑选优先级最高的异常路径复测。若某一步依赖外部系统或人工操作，明确写出依赖方和人工责任，不能在验收结论里模糊成“系统已自动完成”。

设计评审时让提出需求的人、日常操作者、流程负责人和技术实施方围绕同一用例逐条确认。界面原型可以用于讨论字段顺序和信息呈现，但原型图不等于已经交付的功能。评审结论应标注已确定、待决策、首期不做三类，并保留决定人和日期，后续变更才能判断是纠错还是范围增加。

控制范围变更并在上线后复核

实施中经常出现“顺便加一个字段”或“再加一条提醒”。单项看似很小，累积后会影响权限、培训、数据迁移、测试和维护。变更申请写明提出原因、关联场景、影响岗位、数据和权限变化、工作量评估、延期或成本影响、审批人及验收方式。没有明确业务收益或负责人时，可先进入待评估队列，不要默认为首期必须交付。

上线前安排少量代表岗位按验收用例演练，观察他们能否理解记录规则，是否仍需维护重复表格，发生错误后能否找到纠正责任人。上线后按约定周期复核需求是否解决原问题，同时关注空字段、重复记录、未完成交接和人工补录等信号。指标只用于找原因，不能脱离业务背景把低使用率直接归咎于员工，也不能仅凭记录量增加就宣称经营结果改善。

复核应形成明确动作：调整培训、澄清规则、修改配置、重新设计场景或暂缓扩展。每次改动继续关联原需求和验收记录，这样系统演进时团队仍能说明为什么改变、影响谁、如何确认。客户信息和员工权限还需依照企业制度及适用要求管理；本文提供项目讨论框架，不替代法律、安全或具体技术审查。

把企雀公开模块信息转成核验问题

企雀会员管理公开资料介绍会员分层，以及顾客领取分配、跟进进度与结果记录。对正在梳理客户经营需求的团队，这些描述可以转成演示核验问题：相关信息在当前方案中如何呈现，使用岗位和权限是什么，跟进结果如何查阅，哪些环节仍由人工完成。公开介绍只证明页面列出的模块方向，不代表特定账号、定制字段、自动化规则或系统集成已包含；实际范围需结合当前方案逐项确认。查看企雀会员管理公开介绍

需求优先级要能解释取舍

评审时可以把需求分成“必须满足”“可由明确人工步骤替代”和“需要观察后再决定”，但每一类都应有理由。必须满足项要指出对应风险、责任岗位和验证方式；人工替代项要写明操作频率、预计负担和复核人；观察项则约定收集什么信号、何时回看。这样的分层让团队能看见暂缓需求的代价，也能避免把所有愿望都包装成不可协商的首期范围。

还应追问需求之间是否互相冲突。例如，一线希望快速录入，管理者又要求更多必填字段；员工想查看完整历史，权限制度却限制部分信息访问。不要只在界面上折中，而应让规则负责人确认业务优先级，并用不同岗位的用例分别验证。若结论改变，更新需求卡片及验收用例，确保后续培训、配置和评估遵循同一版本。