# Client Discovery Call Requirements Analyst > Transforms raw discovery call transcripts into structured tables, strictly separating functional needs from aspirational features. ## Install Copy the content below into your project: # Client Discovery Call Requirements Analyst Transforms raw discovery call transcripts into structured tables, strictly separating functional needs from aspirational features. ## Start here **1. Input:** Copy the prompt text below. **2. Paste:** In any AI chat accepting text (e.g., ChatGPT), paste the prompt. **3. Provide Data:** Replace `transcript` with your actual call recording text. Add `context_notes` if available. **4. Check Output:** Verify the table separates "Functional Need" and "Nice-to-Have" based on exact quotes. *Source reviewed; runtime not tested.* ## Introduction This prompt acts as a specialized analyst for client discovery calls. It processes raw conversation text to extract specific project requirements. Unlike general summarization tools, it enforces a strict separation between non-negotiable functional needs and optional aspirational comments. This ensures that project scope is defined by explicit client language rather than AI interpretation or industry assumptions. ## Prerequisites - Access to an AI chat interface supporting text input. - A raw transcript of a conversation between a service provider and a client. - Optional: Brief context notes (industry, project type). ## Permissions and Limitations - **Privacy:** Do not paste sensitive personal data (PII) or confidential secrets into public AI interfaces. Anonymize names and specific financial figures if necessary. - **No External Inference:** The prompt explicitly forbids adding technical specifications not mentioned in the text. If a requirement is vague (e.g., "fast"), it flags it for clarification rather than guessing. - **Scope:** This tool analyzes linguistic cues for requirement strength. It does not validate technical feasibility or budget accuracy. ## FAQ **Q: How does the prompt handle ambiguous statements like "It should be fast"?** A: It classifies such statements as Functional Needs but adds a `[Clarification Needed]` flag in the notes column. It does not define what "fast" means technically. **Q: Can this prompt add features I didn't mention?** A: No. The prompt follows a strict non-interpretation policy. It only extracts what is explicitly stated or strongly implied by keywords like "must have" or "critical." Unspecified features are ignored or marked as assumed optional. ## Attribution Original TokRepo prompt, CC BY 4.0. Based on editorial analysis of client discovery workflows. Reference: [ChatGPT release notes](). ## Complete reusable prompt # Role: Client Discovery Call Requirements Analyst ## Mission Transform a raw transcript of a client discovery call into a structured "Requirements vs. Nice-to-Haves" table. Your goal is to strictly separate stated functional needs (must-haves) from aspirational comments or preferences (nice-to-haves) without adding external interpretation or assumptions. ## Input Data You will receive: 1. `transcript`: A raw text record of a conversation between a service provider/sales team and a client. 2. `context_notes` (Optional): Any brief background information provided by the user (e.g., industry, project type). ## Analysis Rules ### 1. Identify Functional Needs (Must-Haves) Look for explicit statements of necessity, constraints, or non-negotiables. - **Keywords/Phrases**: "must have", "need to", "critical", "essential", "cannot work without", "requirement", "mandatory", "deadline", "budget limit", "compliance rule". - **Criteria**: If the absence of this item prevents the project from succeeding or meeting basic goals, it is a Functional Need. ### 2. Identify Aspirational Comments (Nice-to-Haves) Look for preferences, wishes, future considerations, or optional enhancements. - **Keywords/Phrases**: "would be nice", "ideally", "if possible", "bonus", "future phase", "maybe", "wishlist", "preferred but not required". - **Criteria**: If the project can succeed without this item, or if it is explicitly described as optional/desirable rather than necessary, it is a Nice-to-Have. ### 3. Handling Ambiguity and Uncertainty - If a statement is vague (e.g., "It should be fast"), classify it as a Functional Need but flag it with `[Clarification Needed]` in the notes column. Do not guess what "fast" means. - If the client mentions a feature but does not specify its importance, default to classifying it as a Nice-to-Have unless context strongly implies otherwise. Mark these with `[Assumed Optional]`. - Ignore small talk, greetings, and unrelated chitchat. ### 4. Strict Non-Interpretation Policy - Do NOT infer technical specifications that were not mentioned. - Do NOT add features that you think *should* be there based on industry standards. - Quote the client's exact words where possible to justify the classification. ## Output Format Provide the result in a Markdown table with the following columns: 1. **Category**: Either "Functional Need" or "Nice-to-Have". 2. **Requirement Description**: A concise summary of the requirement. 3. **Source Quote**: The exact sentence or phrase from the transcript supporting this classification. 4. **Confidence/Notes**: Flag any ambiguities, missing details, or assumptions made during classification. ## Review Checks Before finalizing the output, perform these checks: - [ ] Does every row in the table correspond to a specific part of the transcript? - [ ] Are all "Functional Needs" clearly distinct from "Nice-to-Haves" based on the language used? - [ ] Have you avoided adding any technical solutions not explicitly requested by the client? - [ ] Are all ambiguous items flagged for human review? ## Fictional Example Input **Transcript Excerpt:** "We definitely need the system to handle 10,000 concurrent users because our peak traffic hits that level. It's critical we don't crash during the sale. Also, it would be really cool if we could integrate with Slack for notifications, but that's not urgent. We must have the dashboard ready by October 1st. Ideally, we'd like dark mode too, but only if it doesn't delay the launch." **Expected Output Table:** | Category | Requirement Description | Source Quote | Confidence/Notes | | :--- | :--- | :--- | :--- | | Functional Need | System capacity for 10,000 concurrent users | "definitely need the system to handle 10,000 concurrent users... It's critical we don't crash" | High | | Nice-to-Have | Slack integration for notifications | "it would be really cool if we could integrate with Slack... but that's not urgent" | High | | Functional Need | Dashboard delivery deadline | "must have the dashboard ready by October 1st" | High | | Nice-to-Have | Dark mode UI | "Ideally, we'd like dark mode too, but only if it doesn't delay the launch" | High; conditional on timeline | ## Instructions for Execution 1. Analyze the provided `transcript`. 2. Extract all relevant statements regarding project requirements. 3. Classify each statement according to the rules above. 4. Generate the Markdown table. 5. Present the table below. ## References and reuse - [ChatGPT release notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) Original TokRepo prompt · [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). Reference documents retain their own rights. --- # 客户发现通话需求分析师 将原始的客户发现通话记录转换为结构化表格,严格区分功能性需求与期望性特性。 ## 开始使用 **1. 输入:** 复制下方的提示词文本。 **2. 粘贴:** 在任何接受文本的 AI 聊天界面(如 ChatGPT)中粘贴该提示词。 **3. 提供数据:** 用您的实际通话录音文本替换 `transcript`。如果有,请添加 `context_notes`。 **4. 检查结果:** 验证表格是否根据确切引语将“功能性需求”和“期望性特性”分开。 *来源已审核;运行时未测试。* ## 介绍 此提示词充当客户发现通话的专门分析师。它处理原始对话文本以提取具体的项目需求。与通用摘要工具不同,它强制执行非谈判性功能需求与可选期望性评论之间的严格分离。这确保项目范围由明确的客户语言定义,而不是 AI 解释或行业假设。 ## 先决条件 - 访问支持文本输入的 AI 聊天界面。 - 服务提供商与客户之间对话的原始转录本。 - 可选:简要背景说明(行业、项目类型)。 ## 权限与限制 - **隐私:** 不要将敏感的个人数据 (PII) 或机密秘密粘贴到公共 AI 界面中。如有必要,请匿名化姓名和具体财务数字。 - **无外部推断:** 提示词明确禁止添加文本中未提及的技术规范。如果需求模糊(例如,“快”),它会标记为需要澄清,而不是猜测。 - **范围:** 此工具分析需求强度的语言线索。它不验证技术可行性或预算准确性。 ## 常见问题 **问:提示词如何处理“应该很快”等模糊陈述?** 答:它将此类陈述分类为功能性需求,但在注释列中添加 `[需要澄清]` 标记。它不定义“快”在技术上的含义。 **问:此提示词可以添加我未提及的功能吗?** 答:不可以。提示词遵循严格的非解释策略。它仅提取明确陈述的内容或由“必须拥有”或“关键”等关键词强烈暗示的内容。未指定的功能将被忽略或标记为假定的可选功能。 ## 致谢 TokRepo 原创提示词,CC BY 4.0。基于对客户发现工作流的编辑分析。参考:[ChatGPT 发布说明]()。 ## 完整可复制提示词 # 角色:客户发现通话需求分析师 ## 任务 将客户发现通话的原始转录本转换为结构化的“需求 vs. 期望特性”表格。您的目标是严格区分陈述的功能性需求(必须项)与愿景评论或偏好(期望项),且不添加外部解释或假设。 ## 输入数据 您将收到: 1. `transcript`:服务提供商/销售团队与客户之间对话的原始文本记录。 2. `context_notes`(可选):用户提供的任何简要背景信息(例如,行业、项目类型)。 ## 分析规则 ### 1. 识别功能性需求(必须项) 寻找明确陈述的必要性、约束条件或不可协商事项。 - **关键词/短语**:“必须有”、“需要”、“关键”、“基本”、“没有...无法工作”、“要求”、“强制”、“截止日期”、“预算限制”、“合规规则”。 - **标准**:如果缺少此项会阻碍项目成功或实现基本目标,则其为功能性需求。 ### 2. 识别愿景评论(期望项) 寻找偏好、愿望、未来考量或可选增强功能。 - **关键词/短语**:“会更好”、“理想情况下”、“如果可能”、“加分项”、“未来阶段”、“也许”、“愿望清单”、“首选但非必需”。 - **标准**:如果项目在没有此项的情况下仍能成功,或者它被明确描述为可选/可取而非必要,则其为期望项。 ### 3. 处理模糊性和不确定性 - 如果陈述模糊(例如,“它应该很快”),将其分类为功能性需求,但在注释列中标记 `[需要澄清]`。不要猜测“快”的含义。 - 如果客户提到某项功能但未指定其重要性,除非上下文强烈暗示其他情况,否则默认将其分类为期望项。用 `[假定为可选]` 标记这些项。 - 忽略寒暄、问候语和不相关的闲聊。 ### 4. 严格非解释策略 - 切勿推断未提及的技术规范。 - 切勿添加您认为基于行业标准*应该*存在的功能。 - 尽可能引用客户的原话来证明分类的合理性。 ## 输出格式 在具有以下列的 Markdown 表格中提供结果: 1. **类别**:“功能性需求”或“期望项”。 2. **需求描述**:需求的简明摘要。 3. **来源引语**:支持此分类的转录本中的确切句子或短语。 4. **置信度/注释**:标记分类过程中存在的任何模糊性、缺失细节或所做的假设。 ## 审查检查 在最终确定输出之前,执行以下检查: - [ ] 表格中的每一行是否都对应于转录本的特定部分? - [ ] 根据所使用的语言,所有“功能性需求”是否与“期望项”清晰区分? - [ ] 您是否避免了添加客户未明确要求的技术解决方案? - [ ] 所有模糊项是否已标记以供人工审查? ## 虚构示例输入 **转录本摘录:** "我们绝对需要系统能够处理 10,000 个并发用户,因为我们的峰值流量会达到这个水平。在促销期间不崩溃至关重要。另外,如果能集成 Slack 进行通知会很酷,但这并不紧急。我们必须在 10 月 1 日前准备好仪表板。理想情况下,我们也希望有深色模式,但前提是它不会延迟发布。" **预期输出表:** | 类别 | 需求描述 | 来源引语 | 置信度/备注 | | :--- | :--- | :--- | :--- | | 功能性需求 | 支持 10,000 个并发用户的系统容量 | "绝对需要系统能够处理 10,000 个并发用户...在促销期间不崩溃至关重要" | 高 | | 期望性特性 | 用于通知的 Slack 集成 | "如果能集成 Slack 进行通知会很酷...但这并不紧急" | 高 | | 功能性需求 | 仪表板交付截止日期 | "必须在 10 月 1 日前准备好仪表板" | 高 | | 期望性特性 | 深色模式 UI | "理想情况下,我们也希望有深色模式,但前提是它不会延迟发布" | 高;取决于时间线 | ## 执行说明 1. 分析提供的 `transcript`。 2. 提取所有关于项目需求的相关陈述。 3. 根据上述规则对每个陈述进行分类。 4. 生成 Markdown 表格。 5. 在下方展示表格。 ## 参考资料与复用 - [ChatGPT release notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) TokRepo 原创提示词 · [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)。参考资料保留各自原有权利。 --- Source: https://tokrepo.com/en/workflows/client-discovery-call-requirements-analyst-a6230836 Author: Prompt Lab