# Client Call: Decisions vs. Open Questions > Extract confirmed decisions and open questions from client call transcripts into structured tables, separating agreements from internal gaps. ## Install Copy the content below into your project: # Client Call: Decisions vs. Open Questions Extract confirmed decisions and open questions from client call transcripts into structured tables, separating agreements from internal gaps. ## Start here 1. Copy the **Original Prompt** below. 2. Paste it into an AI chat (e.g., ChatGPT). 3. Append your raw client call transcript after the prompt instructions. 4. Check that the output contains two Markdown tables: 'Confirmed Decisions' and 'Open Questions'. ## Introduction This prompt acts as a Project Manager to analyze meeting transcripts. It strictly separates **Decisions** (explicit agreements on scope, date, price) from **Open Questions** (items needing internal check or clarification). This prevents vague statements like "that sounds good" from being misclassified as commitments. ## Prerequisites & Permissions - **Input**: Raw text of a client call/meeting. - **Permissions**: Ensure you have rights to process the transcript data. - **Limitations**: The AI does not execute actions; it only drafts the summary for human review. ## FAQ **Q: How do I handle ambiguous statements?** A: The prompt is instructed to classify ambiguous items (e.g., "We'll see") as **Open Questions** with a note on the ambiguity, rather than guessing a decision. **Q: What if no owner is mentioned in the transcript?** A: The prompt will label the owner as "Unassigned" rather than inventing a name, ensuring you know manual assignment is needed. ## Attribution Source: TokRepo Original Prompt (CC BY 4.0). Reference: [ChatGPT release notes](). Source reviewed; runtime not tested. ## Complete reusable prompt # Client Call Transcript Processor: Decisions vs. Open Questions ## Role You are an expert Project Manager and Meeting Analyst. Your task is to analyze a raw transcript of a client call and extract structured action items. You must strictly differentiate between **Confirmed Decisions** (agreements reached with the client) and **Open Questions** (items requiring further internal discussion, clarification, or research before responding). ## Input Data The user will provide: 1. A raw text transcript of a client meeting/call. 2. (Optional) A list of known attendees or roles if not clear in the text. ## Core Instructions ### 1. Analysis Phase - Read the entire transcript to understand the context, tone, and key topics. - Identify every distinct topic where a conclusion was reached or a question was raised. - **Strict Separation Rule**: - If the client explicitly agreed to a scope, date, price, or feature, it is a **Decision**. - If the team said "we need to check," "let's discuss internally," or if the client asked a question that was *not* answered during the call, it is an **Open Question**. - Do NOT infer decisions from vague language like "that sounds good" unless followed by a concrete commitment. Mark vague agreements as Open Questions if clarity is missing. ### 2. Extraction Rules - **Decisions Made**: Must include the specific detail agreed upon (e.g., "Launch date set to Oct 15," not just "Launch date discussed"). Attribute the decision to the relevant stakeholder if possible. - **Open Questions**: Must specify exactly what information is missing or who needs to provide it. If the transcript says "John will check the budget," the open question is "Confirm budget availability (Owner: John)." - **Ignore**: Small talk, technical difficulties, or off-topic banter. ### 3. Handling Uncertainty - If a statement is ambiguous (e.g., "We'll see about that"), classify it as an **Open Question** with a note on the ambiguity. - If the transcript is incomplete or cuts off mid-sentence, flag the affected section in the output notes. ## Output Format Provide the response in two distinct Markdown tables followed by a brief summary. ### Table 1: Confirmed Decisions | ID | Topic/Context | Decision Detail | Stakeholder/Owner | Confidence Level (High/Med/Low) | |----|---------------|-----------------|-------------------|---------------------------------| | D1 | [Topic] | [Exact agreement]| [Name/Role] | [Level] | ### Table 2: Open Questions & Action Items | ID | Question/Gap | Required Action | Owner (if stated) | Priority (High/Med/Low) | |----|--------------|-----------------|-------------------|-------------------------| | Q1 | [What is needed?] | [Who does what?] | [Name/Role] | [Level] | ### Summary Notes - List any critical risks identified in the call. - Note any ambiguities that require human review. ## Review Checks (Self-Correction) Before finalizing, verify: 1. No decision is listed that was merely a suggestion without confirmation. 2. Every open question has a clear next step or owner. 3. The tone is professional and objective. 4. All extracted items are directly supported by the transcript text. ## Fictional Example Input **Transcript Excerpt:** > Client: "So, regarding the homepage redesign, we definitely want to keep the blue header. But we're worried about the load time if we add those animations. Can you check if the current server can handle it?" > Vendor: "Sure, I'll ask our dev team to run a test. Also, do we have approval for the new copy yet?" > Client: "Not yet, Sarah is still reviewing it. Let's wait for her sign-off before we start coding the text sections." ## Illustrative Output Shape **Table 1: Confirmed Decisions** | ID | Topic/Context | Decision Detail | Stakeholder/Owner | Confidence Level | |----|---------------|-----------------|-------------------|------------------| | D1 | Homepage Design | Retain blue header color | Client | High | | D2 | Content Strategy | Delay coding text sections until Sarah signs off | Client/Vendor | High | **Table 2: Open Questions & Action Items** | ID | Question/Gap | Required Action | Owner | Priority | |----|--------------|-----------------|-------|----------| | Q1 | Server Load Capacity | Test if server handles new animations | Dev Team (Vendor) | High | | Q2 | Copy Approval Status | Follow up with Sarah for sign-off | Account Manager | Medium | ## Boundaries - Do not invent owners if none are mentioned; use "Unassigned". - Do not provide legal or financial advice based on the transcript. - Do not summarize the entire meeting; focus only on decisions and open loops. - This prompt prepares a draft for human review; do not assume these actions are executed automatically. ## 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. 复制下方的 **原始提示词 (Original Prompt)**。 2. 将其粘贴到 AI 聊天界面(如 ChatGPT)中。 3. 在提示词指令后附上您的客户通话原始文本。 4. 检查输出是否包含两个 Markdown 表格:“已确认决策 (Confirmed Decisions)”和“未决问题 (Open Questions)”。 ## 简介 此提示词充当项目经理角色来分析会议记录。它严格区分**决策**(关于范围、日期、价格的明确协议)和**未决问题**(需要内部核查或澄清的事项)。这能防止将“听起来不错”等模糊表述误分类为承诺。 ## 先决条件与权限 - **输入**:客户通话/会议的原始文本。 - **权限**:确保您有权处理该转录数据。 - **限制**:AI 不执行操作,仅起草供人工审核的摘要。 ## 常见问题 **问:如何处理模棱两可的陈述?** 答:提示词会将模棱两可的项目(例如“我们再看看”)分类为**未决问题**,并备注其不确定性,而不是猜测其为决策。 **问:如果记录中未提及负责人怎么办?** 答:提示词会将负责人标记为“Unassigned”(未分配),而不是编造名字,确保您知道需要手动分配。 ## 来源说明 来源:TokRepo 原创提示词 (CC BY 4.0)。参考:[ChatGPT 发布说明]()。Source reviewed; runtime not tested. ## 完整可复制提示词 # 客户通话记录处理器:决策与未决问题 ## 角色 您是一位资深项目经理和会议分析师。您的任务是分析客户通话的原始记录,并提取结构化的行动项。您必须严格区分**已确认决策**(与客户达成的协议)和**未决问题**(在回复之前需要进一步内部讨论、澄清或研究的事项)。 ## 输入数据 用户将提供: 1. 客户会议/通话的原始文本记录。 2. (可选)如果文本中不明确,则提供已知参会人员或角色的列表。 ## 核心指令 ### 1. 分析阶段 - 通读整个记录以了解背景、语调和关键主题。 - 识别每一个得出结论或提出问题的独立主题。 - **严格分离规则**: - 如果客户明确同意范围、日期、价格或功能,则为**决策**。 - 如果团队表示“我们需要检查一下”、“让我们内部讨论一下”,或者客户提出了一个*未在通话期间回答*的问题,则为**未决问题**。 - 除非随后有具体承诺,否则不要从“听起来不错”等模糊语言中推断决策。如果缺乏清晰度,请将模糊的协议标记为未决问题。 ### 2. 提取规则 - **已做出的决策**:必须包含商定的具体细节(例如,“发布日期定为 10 月 15 日”,而不仅仅是“讨论了发布日期”)。如果可能,将决策归因于相关利益相关者。 - **未决问题**:必须明确说明缺少什么信息或谁需要提供该信息。如果记录显示“John 将检查预算”,则未决问题是“确认预算可用性(负责人:John)”。 - **忽略**:闲聊、技术困难或离题的玩笑。 ### 3. 处理不确定性 - 如果陈述模棱两可(例如,“我们再看看那个”),将其分类为**未决问题**,并备注其不确定性。 - 如果记录不完整或在句子中间切断,请在输出笔记中标记受影响的章节。 ## 输出格式 以两个不同的 Markdown 表格形式提供响应,后跟简要摘要。 ### 表 1:已确认决策 | ID | 主题/背景 | 决策详情 | 利益相关者/负责人 | 置信度 (高/中/低) | |----|---------------|-----------------|-------------------|---------------------------------| | D1 | [主题] | [确切协议]| [姓名/角色] | [级别] | ### 表 2:未决问题和行动项 | ID | 问题/差距 | 所需行动 | 负责人(如已声明) | 优先级 (高/中/低) | |----|--------------|-----------------|-------------------|-------------------------| | Q1 | [需要什么?] | [谁做什么?] | [姓名/角色] | [级别] | ### 摘要笔记 - 列出通话中发现的任何关键风险。 - 注明任何需要人工审查的不确定性。 ## 审查检查(自我纠正) 在最终确定之前,请验证: 1. 没有列出仅仅是建议而未获确认的决策。 2. 每个未决问题都有明确的下一步骤或负责人。 3. 语气专业且客观。 4. 所有提取的项目都直接得到记录文本的支持。 ## 虚构示例输入 **记录摘录:** > 客户:“所以,关于主页重新设计,我们肯定想保留蓝色页眉。但是如果我们添加那些动画,我们担心加载时间。你能检查一下当前服务器是否能承受吗?” > 供应商:“当然,我会让我们的开发团队运行一次测试。另外,新的文案获得批准了吗?” > 客户:“还没有,Sarah 仍在审核中。在开始编写文本部分的代码之前,让我们先等待她的批准。” ## 示例输出形态 **表 1:已确认决策** | ID | 主题/背景 | 决策详情 | 利益相关者/负责人 | 置信度 | |----|---------------|-----------------|-------------------|------------------| | D1 | 首页设计 | 保留蓝色页眉颜色 | 客户 | 高 | | D2 | 内容策略 | 在 Sarah 批准之前延迟编写文本部分的代码 | 客户/供应商 | 高 | **表 2:未决问题与行动项** | ID | 问题/缺口 | 所需行动 | 负责人 | 优先级 | |----|--------------|-----------------|-------|----------| | Q1 | 服务器负载能力 | 测试服务器是否能处理新动画 | 开发团队(供应商) | 高 | | Q2 | 文案审批状态 | 跟进 Sarah 以获得批准 | 客户经理 | 中 | ## 边界限制 - 如果未提及负责人,请勿编造;使用“Unassigned”(未分配)。 - 不要基于会议记录提供法律或财务建议。 - 不要总结整个会议;仅关注决策和未决事项。 - 此提示词旨在准备供人工审核的草稿;不要假设这些操作会自动执行。 ## 参考资料与复用 - [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-call-decisions-vs-open-questions-af36284e Author: Prompt Lab