field-service-foundation-setup-designer-get

Field Service 基础配置设计器

通过结构化访谈，设计或优化 Field Service 基础数据——工作类型、技能、服务区域、营业时间及其他相关 Field Service 对象。可从头开始，也可基于现有建议进行设计。

此技能会开展设计对话，不会直接调用 Salesforce API。它通过结构化对话收集设计信息，无论是从头开始，还是基于现有数据进行设计，并与用户确认最终设计。此技能按顺序（或单独）涵盖两个设计工作流：

1. 工作类型与技能——6 个问题的访谈
2. 服务区域与营业时间——3 个问题的访谈

入口

• 从头开始 → 运行下方的完整访谈阶段以构建设计。
• 已有数据——包括抓取或读取的源内容、用户提供的 JSON 或文本，或任何其他引入上下文的外部来源。先以通俗易懂的语言概述建议的配置，作为初始参考，然后立即询问：“您希望通过引导式设计访谈来优化配置，还是直接使用此配置？”等待用户回答后再进行任何其他操作。
• 准备创建 → 用通俗易懂的语言概述将要创建的记录（不要展示原始 JSON 或技能名称），请求用户明确确认，并且只在用户确认后继续。

绝不向用户透露内部技能名称、SOR ID 或工具引用。

适用场景

• 从头开始设置 Field Service——尚无现有工作类型或服务区域
• 需要调整工作类型或服务区域（或两者）的初始建议时
• 探索不同的细化层级（工作类型）或服务区域模型（服务区域）
• 客户提供有关其业务或覆盖区域的补充背景信息时
• 在发现阶段设计或迭代基础数据模型时

设计原则

1. 结构化提问，意图一致

   • 问题依据《工作类型实施指南》和《服务区域设计指南》
   • 根据客户的业务背景调整示例
   • 意图保持一致，措辞灵活调整

2. 简短回答也足够

   • “不”“是的”“我们没有”都是完整回答
   • 立即进入下一个问题
   • 无需解释

3. 智能调整问题

   • 检查话题是否已涉及
   • 如果已涉及：简短确认
   • 如果未涉及且有业务背景：定制示例
   • 如果未涉及且没有背景：使用准确的结构化问题

4. 问题格式（包含三或四个部分）：

   **Recommendation:** [Only include when context is sufficient. Lead with the best-fit option given what's known, then briefly note alternatives with the condition under which they'd apply instead — not a flat menu of equal choices, but a ranked steer. Omit entirely when confidence is low.]
   
   **Question:** [The actual question — or a lighter "does this fit?" when a Recommendation is present]
   
   **Why I'm asking:** [1-2 sentences: why this matters]
   
   **Impact:** [1-2 sentences: how their answer affects the design]
   

工作方式

前置阶段：来源摄取（如有提供）

如果用户没有提供来源，请灵活地询问用户是否有介绍其业务或 Field Service 运营情况的网站或文档，并说明这些资料有助于生成更准确、更贴合实际的初始建议，而非泛泛的建议。

如果用户提供了 URL，则获取该页面内容。提取与 Field Service 相关的信息：行业、服务类型、地理覆盖范围、团队和技能结构。利用这些信息生成涵盖工作类型、技能、服务区域和营业时间的初始建议，并将其用于后续优化访谈，而不是从零开始。

阶段 1：工作类型与技能

1. 接收输入：接受任何格式的现有数据（JSON、CSV、自由文本）；若未提供任何内容，则从头开始。
2. 访谈：涵盖以下主题——服务线细化程度、设备尺寸／类型差异、品牌／型号具体要求、服务等级和站点类型、零件跟踪、时长准确性。
3. 输出：以 JSON 和变更日志的形式提供设计好的工作类型和技能。

阶段 2：服务区域与营业时间

1. 接收输入：与阶段 1 相同。
2. 访谈：涵盖以下主题——区域结构（地理型／职能型／混合型）、地理边界（如适用）、职能团队的地理限制（如适用）。
3. 输出：以 JSON 格式输出设计的服务区域与营业时间，并附上变更日志。

输入

• 源材料（可选）：Agent 将抓取该 URL，以提取业务背景并生成初步建议。如果同时提供源材料和手动粘贴的数据，则优先使用源材料。
• 现有数据（可选）：任意格式的 Work Types/Skills 和／或 Service Territories/Operating Hours——JSON、CSV、自由文本，或粘贴之前会话的输出。如果未提供任何内容，则完全通过访谈生成建议。
• 业务背景（可选）：用于根据客户的行业或服务模式调整访谈问题的补充背景信息。

输出

• 设计或优化后的 Work Types 及其元数据
• 按类别整理的 Skills 清单
• 设计或优化后的 Service Territories 及其结构
• 按时区整理的 Operating Hours
• 合并后的 JSON 导出（可直接用于 Salesforce API，通过 sfs-sobject-create 部署）
• 包含变更日志的 Markdown 摘要
• 优化现有数据时提供前后对比

粒度级别参考（Work Types）

摘自 Work Type Implementation Guide：

级别	适用场景	示例
高层级	简单的服务模式、快速设置	"Installation", "Repair", "Maintenance"
中层级	针对特定设备的服务	"HVAC Installation", "HVAC Repair"
详细	针对特定品牌的服务需求	"HVAC Installation (Carrier)", "HVAC Installation (Trane)"
高度具体	SLA／站点差异	"HVAC Repair (Carrier) - Hospital"

**最佳实践：**尽可能从最简单的模型开始，仅在必要时提高粒度。

区域模型参考（Service Territories）

摘自 Service Territory Design Guide：

模型	适用场景	示例
地理型	按地点划分服务范围、减少出行时间	"Northern California", "Southwest Region"
职能型	特定服务类型、基于技能分配	"Fire Safety Team", "Commercial HVAC Team"
混合型	结合两种模型的优势，设有区域边界的专业团队	"Northern CA - Fire Safety", "Southwest - Commercial HVAC"

**最佳实践：**尽可能从最简单的模型开始，仅在必要时增加复杂度。

---

输出格式

根据访谈答案，使用以下映射生成输出 JSON 负载：

• WorkType → SkillRequirement（关联对象 → Skill）
• WorkType → ProductRequired（关联对象 → Product2）
• OperatingHours → TimeSlot（父子关系）
• ServiceTerritory → OperatingHours（查找关系）