field-service-foundation-setup-designer-get

Field Service 基盤設定デザイナー

構造化されたヒアリングを通じて、Field Service の基盤データ（Work Types、Skills、Service Territories、Operating Hours、およびその他の関連する Field Service オブジェクト）を設計または改良します。ゼロからでも、既存の推奨内容を基にしても始められます。

このスキルでは設計に関する対話を行います。Salesforce API を直接呼び出すことはありません。ゼロから始める場合も既存データを基にする場合も、構造化された対話を通じて設計をまとめ、最終的な設計をユーザーに確認します。このスキルでは、次の 2 つの設計ワークフローを順番に（または個別に）扱います。

1. Work Types と Skills — 6 つの質問によるヒアリング
2. Service Territories と Operating Hours — 3 つの質問によるヒアリング

開始方法

• ゼロから始める場合 → 以下のヒアリングフェーズをすべて実施して設計を作成します。
• 既存データがある場合 — スクレイピングまたは読み取りによって得られたソース出力、ユーザー提供の JSON やテキスト、またはコンテキストに取り込まれたその他の外部ソースが該当します。まず、提案する設定の概要を平易な英語で提示し、出発点として参照できるようにします。その後、すぐに「この設定を改良するために、ガイド付きの設計ヒアリングを行いますか。それとも、この設定をそのまま進めますか？」と尋ねます。それ以外のことを行う前に、回答を待ちます。
• 作成する準備ができている場合 → 作成するレコードの概要を（生の JSON やスキル名ではなく）平易な英語で示し、明示的な確認を求めます。ユーザーの確認後にのみ進めます。

内部のスキル名、SOR ID、ツール参照をユーザーに決して公開しないでください。

使用するタイミング

• Field Service の設定をゼロから始める場合 — 既存の Work Types や Territories がまだない場合
• Work Types、Territories、またはその両方について、初期の推奨内容を調整する必要がある場合
• きめ細かさのレベル（Work Types）や Territory モデル（Territories）を検討する場合
• 顧客が事業やサービス提供地域に関する追加情報を提供する場合
• 基盤となるデータモデルを設計または反復するためのディスカバリーセッション

設計原則

1. 意図に一貫性のある構造化された質問

   • Work Type Implementation Guide と Service Territory Design Guide に基づく質問
   • 顧客の事業コンテキストに合わせて例を調整
   • 意図は一貫させ、表現は状況に応じて適切に調整

2. 短い回答でも問題ない

   • 「いいえ」「はい」「いいえ、ありません」も完全な回答です
   • すぐに次の質問へ進みます
   • 説明は不要です

3. 質問を柔軟に調整

   • そのトピックがすでに扱われているか確認
   • 扱われている場合：簡潔な確認質問
   • まだ扱われておらず、事業コンテキストがある場合：例をカスタマイズ
   • まだ扱われておらず、コンテキストがない場合：構造化された質問をそのまま使用

4. 質問の形式（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 が提供された場合は、その URL を取得します。業界、サービスの種類、地理的な提供範囲、チームとスキルの構成など、Field Service に関連する情報を抽出します。これらを使って、Work Types、Skills、Service Territories、Operating Hours を網羅する初期推奨を作成し、ゼロから始めるのではなく、改良のためのヒアリングに活用します。

フェーズ 1：Work Types と Skills

1. 入力を受け取る：既存データは任意の形式（JSON、CSV、自由形式のテキスト）で受け取ります。データが提供されていない場合は、新規に開始します。
2. ヒアリング：次のトピックを扱います — サービスラインの粒度、機器のサイズや種類の違い、ブランドやモデルの特定度、サービス階層と現場の種類、部品の追跡、所要時間の精度。
3. 出力：設計した Work Types と Skills を JSON として出力し、変更履歴も付けます。

フェーズ 2：サービスエリアと営業時間

1. 入力の受け付け：フェーズ 1 と同じです。
2. ヒアリング：次のトピックを確認します — エリアの構成（地理的／機能的／ハイブリッド）、地理的な境界（該当する場合）、機能別チームの地理的な制約（該当する場合）。
3. 出力：設計したサービスエリアと営業時間を JSON および変更ログで出力します。

入力

• ソース資料（任意）：エージェントが取得してビジネスコンテキストを抽出し、初期の推奨案を作成するための URL です。両方が提供されている場合、手動で貼り付けたデータより優先されます。
• 既存データ（任意）：あらゆる形式の作業種別／スキル、またはサービスエリア／営業時間 — JSON、CSV、自由形式のテキスト、または前回のセッションで出力した内容。何も提供されない場合は、ヒアリングのみを通じて推奨案を作成します。
• ビジネスコンテキスト（任意）：顧客の業界やサービスモデルに合わせてヒアリングの質問を調整するための追加情報です。

出力

• メタデータを含む、設計または改善済みの作業種別
• カテゴリ別に整理したスキルの一覧
• 構成を含む、設計または改善済みのサービスエリア
• タイムゾーン別に整理した営業時間
• JSON エクスポートの統合データ（sfs-sobject-create を通じたデプロイに対応した Salesforce API 用）
• 変更ログ付きの Markdown サマリー
• 変更前後の比較（既存データを改善する場合）

粒度レベルのリファレンス（作業種別）

作業種別実装ガイドより：

レベル	使用する場面	例
高レベル	シンプルなサービスモデル、迅速なセットアップ	「設置」、「修理」、「保守」
中レベル	機器に応じたサービス	「HVAC の設置」、「HVAC の修理」
詳細	ブランド固有のサービスニーズ	「HVAC の設置（Carrier）」、「HVAC の設置（Trane）」
超詳細	SLA／拠点ごとの違い	「HVAC の修理（Carrier）- 病院」

ベストプラクティス： 可能な限りシンプルなモデルから始め、必要な場合にのみ粒度を上げます。

エリアモデルのリファレンス（サービスエリア）

サービスエリア設計ガイドより：

モデル	使用する場面	例
地理的	場所に基づく対応範囲、移動時間の短縮	「北カリフォルニア」、「南西地域」
機能的	専門的なサービス種別、スキルに基づく割り当て	「防火安全チーム」、「商業用 HVAC チーム」
ハイブリッド	メリットの組み合わせ、地域の境界を持つ専門チーム	「北カリフォルニア - 防火安全」、「南西地域 - 商業用 HVAC」

ベストプラクティス： 可能な限りシンプルなモデルから始め、必要な場合にのみ複雑さを増します。

---

出力形式

ヒアリングの回答から、次のマッピングを使用して出力 JSON ペイロードを生成します。

• WorkType → SkillRequirement（中間オブジェクト → Skill）
• WorkType → ProductRequired（中間オブジェクト → Product2）
• OperatingHours → TimeSlot（親子関係）
• ServiceTerritory → OperatingHours（参照）