mcpField
R
resolution-notes

resolution-notes

github.com/happy-technologies-llcその他4141 回インストール2 日前に更新
リポジトリ

resolution-notes について

このスキルは、ServiceNow Customer Service Management のケースを終了するサービスエージェント向けに、構造化された解決記録を作成します。調査履歴、根本原因、解決の検証、顧客確認、SLA 状況をまとめ、ナレッジベース文書や監査にも役立ちます。

主な機能

  1. 01顧客が報告した問題の要約
  2. 02調査手順と結果の整理
  3. 03根本原因と検証済み解決策の記録
  4. 04予防策と推奨事項の追加
  5. 05顧客確認と SLA 状況の確認

活用シーン

  1. 01CSM ケース終了時の解決内容の記録
  2. 02類似ケースに再利用できる情報の整理
  3. 03ナレッジベースや監査記録の作成

MCP 対応

SN-Get-Record でケース詳細を取得し、SN-Query-Table で作業メモ、関連タスク、顧客との通信、SLA データ、類似ケース、ナレッジベース記事を検索します。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/happy-technologies-llc/happy-platform-skills --skill resolution-notes

インストール後、Claude Code で/resolution-notesを入力して読み込まれたか確認します。

詳細

解決記録

概要

このスキルは、カスタマーサービス管理(CSM)ケースをクローズする際に、包括的で適切に構成された解決記録を作成します。次のことに役立ちます。

  • 顧客から報告された元の問題を、関連する背景情報とともに要約する
  • 実施したすべての診断手順と調査結果を記録する
  • 問題の根本原因を特定して記録する
  • 適用した解決策とその検証内容を説明する
  • 再発防止のための対策と推奨事項を提示する
  • 顧客とのコミュニケーション、ナレッジベースの記事、監査証跡に適した、明瞭で専門的なドキュメントを作成する

使用するタイミング: CSM エージェントがケースを解決またはクローズする準備ができており、詳細な解決ドキュメントを作成する必要があるときです。また、インシデント後のレビュー、ナレッジベース記事の作成、コンプライアンス監査にも役立ちます。

前提条件

  • ロール: sn_customerservice_agent、sn_customerservice_manager、または csm_admin
  • アクセス権: sn_customerservice_case、sys_journal_field、sn_customerservice_task、interaction、sys_email、kb_knowledge、sn_customerservice_sla、customer_account テーブルへの読み取りアクセス権、およびケースの resolution_notes と close_notes フィールドへの書き込みアクセス権
  • 知識: CSM ケースの解決コード、クローズ要件、および組織のドキュメント作成基準に関する理解

手順

ステップ 1:ケースの詳細をすべて取得する

解決に関連するすべてのフィールドを含む、完全なケースレコードを取得します。

MCP を使用する場合(Claude Code/Desktop):

Tool: SN-Get-Record
Parameters:
  table_name: sn_customerservice_case
  sys_id: [case_sys_id]
  fields: number,short_description,description,state,priority,urgency,impact,category,subcategory,contact,account,consumer,product,asset,assigned_to,assignment_group,opened_at,opened_by,resolved_at,resolved_by,closed_at,closed_by,resolution_code,resolution_notes,close_notes,escalation,severity,sla_due,contact_type,reassignment_count,reopen_count,cause,business_duration,calendar_duration,made_sla

REST API を使用する場合:

GET /api/now/table/sn_customerservice_case/{case_sys_id}?sysparm_fields=number,short_description,description,state,priority,urgency,impact,category,subcategory,contact,account,consumer,product,asset,assigned_to,assignment_group,opened_at,opened_by,resolved_at,resolved_by,closed_at,resolution_code,resolution_notes,close_notes,escalation,severity,reassignment_count,reopen_count,cause,business_duration,calendar_duration,made_sla&sysparm_display_value=true
ステップ 2:すべての作業メモを収集する(調査の経緯)

調査と解決のタイムラインを再構成するため、作業メモの履歴をすべて取得します。

MCP を使用する場合:

Tool: SN-Query-Table
Parameters:
  table_name: sys_journal_field
  query: element_id=<case_sys_id>^element=work_notes^ORDERBYsys_created_on
  fields: sys_id,value,sys_created_on,sys_created_by
  limit: 100

REST API を使用する場合:

GET /api/now/table/sys_journal_field?sysparm_query=element_id=<case_sys_id>^element=work_notes^ORDERBYsys_created_on&sysparm_fields=value,sys_created_on,sys_created_by&sysparm_limit=100
ステップ 3:関連タスクとその結果を確認する

追加の解決情報や完了したアクションがないか、子タスクを確認します。

MCP を使用する場合:

Tool: SN-Query-Table
Parameters:
  table_name: sn_customerservice_task
  query: parent=<case_sys_id>^ORDERBYsys_created_on
  fields: sys_id,number,short_description,state,assigned_to,assignment_group,opened_at,closed_at,close_notes,work_notes
  limit: 20

REST API を使用する場合:

GET /api/now/table/sn_customerservice_task?sysparm_query=parent=<case_sys_id>^ORDERBYsys_created_on&sysparm_fields=number,short_description,state,assigned_to,assignment_group,opened_at,closed_at,close_notes&sysparm_limit=20&sysparm_display_value=true
ステップ 4:顧客とのコミュニケーションを確認する

解決の確認を得るため、顧客向けのコミュニケーションを取得します。

MCP を使用する場合:

Tool: SN-Query-Table
Parameters:
  table_name: sys_journal_field
  query: element_id=<case_sys_id>^element=comments^ORDERBYDESCsys_created_on
  fields: value,sys_created_on,sys_created_by
  limit: 20
Tool: SN-Query-Table
Parameters:
  table_name: sys_email
  query: instance=<case_sys_id>^ORDERBYDESCsys_created_on
  fields: sys_id,subject,type,body_text,sys_created_on,sys_created_by
  limit: 10

REST API を使用する場合:

GET /api/now/table/sys_journal_field?sysparm_query=element_id=<case_sys_id>^element=comments^ORDERBYDESCsys_created_on&sysparm_fields=value,sys_created_on,sys_created_by&sysparm_limit=20

GET /api/now/table/sys_email?sysparm_query=instance=<case_sys_id>^ORDERBYDESCsys_created_on&sysparm_fields=subject,type,body_text,sys_created_on&sysparm_limit=10&sysparm_display_value=true
ステップ 5:SLA の達成状況を確認する

解決がサービスレベル目標を達成したか記録するため、SLA データを取得します。

MCP を使用する場合:

Tool: SN-Query-Table
Parameters:
  table_name: sn_customerservice_sla
  query: task=<case_sys_id>
  fields: sla,stage,has_breached,planned_end_time,end_time,business_duration,percentage,business_percentage
  limit: 10

REST API を使用する場合:

GET /api/now/table/sn_customerservice_sla?sysparm_query=task=<case_sys_id>&sysparm_fields=sla,stage,has_breached,planned_end_time,end_time,business_duration,percentage&sysparm_limit=10&sysparm_display_value=true
ステップ 6:関連する KB 記事を検索する

この問題に関する KB 記事が存在するか、または作成すべきかを確認します。

MCP を使用する場合:

Tool: SN-Query-Table
Parameters:
  query: workflow_state=published^short_descriptionLIKE[key_terms]
  table_name: kb_knowledge
  limit: 5
Tool: SN-Query-Table
Parameters:
  table_name: kb_knowledge
  query: workflow_state=published^short_descriptionLIKE[key_terms]
  fields: number,short_description,text,kb_category,sys_updated_on
  limit: 5

REST API を使用する場合:

GET /api/now/table/kb_knowledge?sysparm_query=workflow_state=published^short_descriptionLIKE<key_terms>&sysparm_fields=number,short_description,kb_category&sysparm_limit=5&sysparm_display_value=true
ステップ 7:類似するオープンケースを確認する

この解決策が役立つ可能性のある、ほかのオープンケースがないか特定します。

MCP を使用する場合:

Tool: SN-Query-Table
Parameters:
  table_name: sn_customerservice_case
  query: category=[category]^subcategory=[subcategory]^stateNOT IN6,7,8^sys_id!=<case_sys_id>^short_descriptionLIKE[key_terms]
  fields: number,short_description,state,assigned_to,account
  limit: 10

REST API を使用する場合:

GET /api/now/table/sn_customerservice_case?sysparm_query=category=<category>^subcategory=<subcategory>^stateNOT IN6,7,8^sys_id!=<case_sys_id>^short_descriptionLIKE<key_terms>&sysparm_fields=number,short_description,state,assigned_to,account&sysparm_limit=10&sysparm_display_value=true
ステップ 8:解決記録を作成する

収集した情報をすべてまとめ、包括的な解決ドキュメントを作成します。

解決記録の構成:

=== RESOLUTION NOTES ===
Case: [number]
Resolved By: [agent_name] | Resolution Date: [resolved_at]
Resolution Code: [resolution_code]

1. ISSUE SUMMARY
   Customer [contact_name] from [account_name] reported [short_description]
   on [opened_at]. The issue affected [product/service] and was categorized
   as [category]/[subcategory] with [priority] priority.

   Detailed Description:
   [description - summarized]

   Impact:
   - Business Impact: [impact description]
   - Users Affected: [scope]
   - Duration of Impact: [from opened_at to resolved_at]

2. INVESTIGATION TIMELINE
   [date_1] - Case created via [contact_type]. Initial triage performed.
   [date_2] - [investigation action and finding]
   [date_3] - [investigation action and finding]
   [date_4] - [escalation if applicable]
   [date_5] - Root cause identified.
   [date_6] - Fix applied and verified.

3. ROOT CAUSE
   [Detailed root cause description]

   Contributing Factors:
   - [factor_1]
   - [factor_2]

4. RESOLUTION
   Resolution Code: [Solved Permanently / Workaround / Not Reproducible /
                      Duplicate / etc.]

   Resolution Details:
   [Step-by-step description of the fix applied]

   Verification:
   - [How the fix was verified]
   - [Customer confirmation of resolution - date and method]

5. STEPS TAKEN
   1. [step_1 with date]
   2. [step_2 with date]
   3. [step_3 with date]
   ...

   Steps Attempted But Unsuccessful:
   1. [failed_step_1 - reason it did not work]
   2. [failed_step_2 - reason it did not work]

6. RELATED TASKS
   - [task_number]: [description] - [outcome]
   - [task_number]: [description] - [outcome]

7. SLA PERFORMANCE
   - Response SLA: [Met/Breached] ([actual] vs [target])
   - Resolution SLA: [Met/Breached] ([actual] vs [target])
   - Business Duration: [duration]
   - Calendar Duration: [duration]
   - Reassignment Count: [count]

8. PREVENTIVE MEASURES
   - [recommendation_1 - e.g., "Apply patch X to all production servers"]
   - [recommendation_2 - e.g., "Update monitoring to detect this condition"]
   - [recommendation_3 - e.g., "Add this scenario to runbook Y"]

9. KNOWLEDGE BASE
   - Existing KB Referenced: [KB number and title, if applicable]
   - KB Article Recommended: [Yes/No]
     If Yes: [suggested article title and key content points]

10. RELATED CASES
    - Similar Open Cases: [list of case numbers that may benefit]
    - Previously Resolved: [case numbers with same root cause]

クローズメモ(close_notes フィールド用の短い要約):

Issue: [one-line description]
Root Cause: [one-line root cause]
Resolution: [one-line resolution description]
Preventive Action: [one-line preventive measure]
KB Reference: [KB number or "N/A"]
Customer Confirmed: [Yes/No - date]

ツールの使用方法

MCP ツールのリファレンス
ツール使用するタイミング
SN-Natural-Language-Search関連する KB 記事や、同様の解決済みケースを検索する
SN-Query-Table作業メモ、タスク、メール、SLA データ、類似ケースを取得する
SN-Get-Record解決に関するすべてのフィールドを含む完全なケースレコードを取得する
REST API リファレンス
エンドポイントメソッド用途
/api/now/table/sn_customerservice_caseGETケースの詳細と類似ケースの検索
/api/now/table/sys_journal_fieldGET作業メモとコメントの履歴
/api/now/table/sn_customerservice_taskGET関連タスクの結果
/api/now/table/sys_emailGETメールでのやり取りと確認
/api/now/table/interactionGETやり取りのレコード
/api/now/table/kb_knowledgeGETKB 記事の参照情報
/api/now/table/sn_customerservice_slaGETSLA の達成状況データ
/api/now/table/customer_accountGETアカウントの背景情報

ベストプラクティス

  • 詳細かつ簡潔にする: 関連する詳細をすべて含めつつ、重複は避けてください。解決メモには、冗長にならずに経緯がすべて伝わるように記載します
  • 根本原因を正確に記録する: 症状、要因、実際の根本原因を区別してください。これは傾向分析において重要です
  • 失敗した試みも含める: うまくいかなかったことの記録も、うまくいったことと同じくらい有益です。後続のエージェントが失敗した手順を繰り返すのを防げます
  • 顧客の確認を得る: 顧客が解決を確認したかどうか、またその方法(メールの返信、電話、チャットメッセージ)を必ず記録してください
  • ナレッジベースの記事を推奨する: この解決方法に関するナレッジベース記事がない場合は、新規作成を推奨してください。記事がある場合は、更新が必要かどうかを記録してください
  • 関連するケースにリンクする: パターンの検出や先回りした連絡に役立つよう、類似ケースを特定して参照してください
  • 標準の解決コードを使用する: 正確なレポート作成のため、組織で定義された解決コードを一貫して使用してください
  • SLA の遵守状況を記録する: SLA の遵守状況は、アカウント健全性の指標や契約上の義務に反映されます
  • 後から読む人に伝わるように書く: 数か月後、数年後にそのケースを初めて読む人にも理解できる解決メモにしてください
  • 社内向けメモと顧客向けメモを分ける: 詳細な技術分析は作業メモに記載し、resolution_notes と close_notes には簡潔な要約を記載してください

トラブルシューティング

「解決コードの選択肢がわかりにくい」

原因: 解決コードは組織や CSM の設定によって異なります
解決策: 選択可能なコードを選択肢リストから照会します:GET /api/now/table/sys_choice?sysparm_query=name=sn_customerservice_case^element=resolution_code&sysparm_fields=label,value。一般的なコードには、解決済み(恒久対応)、解決済み(回避策)、再現不能、重複、既知のエラー、ユーザーエラー、設定変更があります。

「作業メモに根本原因が見つからない」

原因: 調査中に根本原因が明示的に記録されていない可能性があります
解決策: 作業メモのタイムライン全体を確認し、問題の理解に至った転換点を探します。技術的な詳細については、エスカレーションメモとタスクのクローズメモを確認してください。根本原因が本当に不明な場合は、最も可能性の高い仮説を添えて「Root Cause: Undetermined」と記録します。

「顧客が解決を確認しなかった」

原因: 顧客が解決通知に返信しなかった可能性があります
解決策: sys_email を確認し、解決通知メールが不達になっていないか調べます。コメントを確認し、間接的な確認がないか調べます。標準の待機期間を過ぎても確認がない場合は、「Customer confirmation: Not received within [X] day waiting period. Auto-resolved per policy.」と記録します。

「SLA データに誤った違反が表示される」

原因: SLA が誤って一時停止されたか、解決時に計時が停止されなかった可能性があります
解決策: SLA レコードの pause_duration フィールドと pause_time フィールドを確認します。監査ログ(sys_audit テーブル)でケースの状態遷移を確認し、SLA のステージ遷移が正しいことを検証します。

例

例 1:ソフトウェアのバグの解決

シナリオ: 繰り返し発生するアプリケーションエラーに関するケースを解決します。

ステップ 1 - ケースと作業メモを取得する:

Tool: SN-Get-Record
Parameters:
  table_name: sn_customerservice_case
  sys_id: [case_sys_id]
  fields: number,short_description,description,state,priority,category,subcategory,product,contact,account,opened_at,resolved_at,resolution_code,cause,reassignment_count,made_sla,business_duration
Tool: SN-Query-Table
Parameters:
  table_name: sys_journal_field
  query: element_id=<sys_id>^element=work_notes^ORDERBYsys_created_on
  fields: value,sys_created_on,sys_created_by
  limit: 50

生成された解決メモ:

RESOLUTION NOTES - CS0075432

1. ISSUE SUMMARY
   Customer Amy Chen from DataFlow Inc. reported that the reporting
   module throws a "NullPointerException" when generating monthly
   summary reports with more than 10,000 records. Issue began after
   platform upgrade to version 3.4.1. Priority: P2.

2. INVESTIGATION TIMELINE
   Mar 10 - Case created via email. Initial triage by L1 Support.
   Mar 11 - Reproduced in test with 15K record dataset.
   Mar 12 - Identified exception in ReportGenerator.java line 847.
   Mar 13 - Escalated to Engineering (Level 2).
   Mar 14 - Engineering confirmed pagination bug in v3.4.1.
   Mar 17 - Hotfix 3.4.1-HF02 deployed to customer instance.
   Mar 18 - Customer confirmed reports generating successfully.

3. ROOT CAUSE
   A pagination logic error introduced in version 3.4.1 caused a
   null reference when the result set exceeded the default page size
   of 10,000 records. The cursor object was not being re-initialized
   between page iterations.

   Contributing Factors:
   - Insufficient test coverage for large datasets in v3.4.1 release
   - Customer's dataset grew past 10K threshold in February

4. RESOLUTION
   Resolution Code: Solved (Permanently)
   Applied hotfix 3.4.1-HF02 which corrects the pagination cursor
   handling in ReportGenerator.java. Fix verified with 50K record
   dataset in staging before production deployment.

   Verification:
   - Agent verified fix in test environment with 25K records
   - Customer confirmed successful report generation on Mar 18
     via email reply

5. SLA PERFORMANCE
   - Response SLA: Met (2 hours vs 4 hour target)
   - Resolution SLA: Met (6 business days vs 10 day target)
   - Reassignment Count: 1 (L1 to Engineering)

6. PREVENTIVE MEASURES
   - Engineering to add large dataset tests (10K, 50K, 100K) to
     regression suite for reporting module
   - Proactive notification to all customers on v3.4.1 to apply HF02
   - Monitoring alert added for NullPointerException in reporting

7. KNOWLEDGE BASE
   - KB0045678 created: "Reporting Module NullPointerException
     Fix for v3.4.1 - Apply Hotfix HF02"
例 2:設定の問題に関するクローズメモ

シナリオ: 設定が誤っているインテグレーションを迅速に解決します。

ステップ 1 - ケースを取得する:

Tool: SN-Query-Table
Parameters:
  table_name: sn_customerservice_case
  query: number=CS0076100
  fields: sys_id,number,short_description,state,priority,category,product,contact,account,opened_at,resolution_code
  limit: 1

生成されたクローズメモ:

Issue: SSO integration failing with "invalid_redirect_uri" error
Root Cause: OAuth redirect URI in customer's identity provider
  configuration contained a trailing slash that did not match the
  registered callback URL
Resolution: Removed trailing slash from IdP redirect URI
  configuration; SSO authentication now working correctly
Preventive Action: Added redirect URI format validation to
  integration setup checklist (KB0045700)
KB Reference: KB0045700 - SSO Integration Redirect URI Configuration
Customer Confirmed: Yes - Mar 19 via email

関連スキル

  • csm/case-summarization - 解決メモを作成する前にケースを要約する
  • csm/activity-response - ケースのライフサイクル全体を通じて調査活動を記録する
  • csm/sentiment-analysis - 顧客の感情を確認し、解決結果が良好であることを確かめる
  • csm/email-recommendation - 顧客宛ての解決通知メールを作成する
  • knowledge/article-generation - 解決結果からナレッジベースの記事を作成する

コメント