重要度

変更の重要度

インフラストラクチャの変更管理の重要度 を参考に、カスタマーサポートオペレーションでは、適切な計画期間を判断するのに役立つ C1 〜 C4 のスケールで変更を定義しています。

重要度は、Issue/MR をどのデプロイに含めるかを決定する際に考慮されます。

変更重要度の定義

変更重要度 1

これらは、サポートエンジニアまたは顧客のエクスペリエンスを大幅に変更する可能性のある、影響度またはリスクが高い変更です。変更が環境にダウンタイムを引き起こす場合は、常に C1 に分類されます。

重要度 1 のリクエストの例:

• 広く使用されている Zendesk ビューの機能を変更する
• 重要なプロセス変更をサポートするために Zendesk を変更する
• 使用中の任意の SLA ポリシーへの変更

変更重要度 2

これらは、サポートエンジニアまたは顧客のエクスペリエンスに大きな影響を与えるとは予想されないものの、何か予期せぬことが起こった場合に影響を受けるリスクが多少残る変更です。

重要度 2 のリクエストの例:

• サポートポータルのテーマを更新する
• 新しいチケットフォームを追加する
• SSAT またはサポート KPI に関連するトリガー/自動化を変更する

変更重要度 3

これらは、否定的な影響のリスクがないか、非常に低いものの、ある程度の本質的な複雑さがあるか、完全に自動化されておらず手動操作を伴う変更です。

重要度 3 のリクエストの例:

• サポートフォームに新しいフォームフィールドを追加する
• 期限切れの Zendesk 組織を一括削除する
• サポートエンジニアにとって便利になる新しい Zendesk アプリを追加する
• アクティブなマクロを削除または非アクティブ化する

変更重要度 4

これらは、リスクが極めて低く、頻繁に実行される変更、または完全に自動化された変更です。多くの場合、これらは実質的な制御手段としてではなく、主に可視性のために記録される変更です。

重要度 4 のリクエストの例:

• ZD 組織からユーザーを追加または削除する
• マクロを作成または更新する

変更重要度の判断

Issue または MR の作業を開始するときは、まず手元のタスクの変更重要度を判断する必要があります。

変更重要度の判断に関するガイダンスについては、変更重要度の定義 を参照してください。

重要度レベルの判断には常に最善の判断を使用してください。迷った場合は、カスタマーサポートオペレーションのリーダーシップに支援を求めてください。

システムの重要度

システム重要度の定義

これに関する定義については、クリティカルシステムティアの指定 を参照してください。

カスタマーサポートオペレーションのシステム重要度

ページのソースコードを見る - ページの編集 - please contribute.