サービスリクエスト管理のデータテンプレート
サービスリクエスト管理のデータテンプレート
- 収集を推奨する属性
- 記録すべき主要なアクティビティ
- データ抽出の手順
サービスリクエスト管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
サービス依頼について、特定の時点で発生したイベントまたはタスクの名称です。 | ||
|
説明
アクティビティ名は、サービス依頼のライフサイクルにおける特定のステップやイベントを表します。システム監査ログ、ステータス変更、ユーザーが行った操作などから抽出されます。例として、「依頼を担当者に割り当て」「メモを追加」「サービス依頼を解決」などがあります。 この属性は、サービス依頼の流れを視覚的に表すプロセスマップの作成に欠かせません。アクティビティの順序や発生頻度を分析することで、組織は実際のプロセスを把握し、ステップ間のボトルネックを特定し、アクティビティにかかる時間を測定できます。また、コンプライアンスに適合しないバリアントや非効率なバリアントも検出できます。
重要な理由
この属性でプロセスマップのステップを定義し、サービス依頼のワークフローを可視化して分析できます。
入手先
Freshserviceのチケットに関連付けられた「activities」または「audits」から生成されます。システムイベントを業務で分かりやすいアクティビティ名に対応付ける変換ロジックが必要になることがあります。
例
サービスリクエスト作成リクエストを担当者に割り当てサービスリクエストを解決サービスリクエストをクローズ
|
|||
|
イベント時刻
EventTime
|
アクティビティが発生した正確なタイムスタンプです。 | ||
|
説明
イベント時刻は、サービス依頼の特定のアクティビティが記録された日時を示します。イベントを正しい順序に並べ、イベント間の所要時間を計算するために欠かせません。 プロセスマイニングでは、この属性を使ってケースごとにアクティビティを並べます。時間に関する分析の基礎となり、サイクルタイムやアクティビティ間の待ち時間、サービスレベル合意(SLA)の遵守状況を測定できます。ボトルネックの特定やプロセスのパフォーマンス把握には、正確なタイムスタンプが欠かせません。
重要な理由
イベントを時系列に並べるための情報であり、サイクルタイムの測定やボトルネックの検出など、パフォーマンス分析の基礎となります。
入手先
Freshservice内のアクティビティまたは監査ログエントリの作成タイムスタンプに相当します。
例
2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
|
|||
|
サービス依頼ID
ServiceRequestId
|
各サービス依頼を一意に識別する番号です。 | ||
|
説明
サービス依頼IDは、Freshserviceに登録された各新規サービス依頼に割り当てられる一意の番号またはコードです。作成から終了まで、依頼の全期間を追跡するための主キーとして機能します。 プロセスマイニングでは、このIDがケースIDとして機能し、関連するすべてのイベントを結び付けます。ステータス変更、担当者の割り当て、メモなどのイベントは、このIDを使って関連付けられます。サービス依頼IDごとの経過を分析すると、プロセス全体を可視化し、よくある経路を特定するとともに、個々のケースに影響する逸脱やボトルネックを検出できます。
重要な理由
関連するすべてのイベントを結び付ける重要なケースIDです。これにより、1件のサービス依頼の開始から終了までの経過を追跡できます。
入手先
Freshserviceのチケットオブジェクトにある主要フィールドです。ユーザーインターフェースに表示され、Freshservice APIからも取得できます。
例
SR-12943SR-13501SR-14011
|
|||
|
ソースシステム
SourceSystem
|
データの抽出元となるシステムを示します。 | ||
|
説明
この属性はプロセスデータの取得元を示します。この場合はFreshserviceです。複数のシステムのデータを統合してプロセス全体を把握する環境で、特に役立ちます。 単一システムの分析では不要に見える場合もありますが、将来の拡張やデータガバナンスを考慮し、この属性を含めることが推奨されます。データの出所を明確にし、データ統合の処理を管理しやすくします。
重要な理由
データの出所と追跡可能性を確保します。複数システムのデータを統合する場合や、データガバナンスの観点から重要です。
入手先
通常、データ抽出・変換(ETL)の処理中に追加される固定値です。
例
FreshserviceFreshservice-API-v2
|
|||
|
最終データ更新日時
LastDataUpdate
|
ソースシステムからデータを最後に更新した日時を示すタイムスタンプです。 | ||
|
説明
この属性には、Freshserviceからデータセットを最後に抽出または更新した日時が記録されます。分析対象のデータがどの時点のものかを把握できます。 プロセスを分析する際は、データがいつ更新されたかを知ることが重要です。このタイムスタンプがあれば、最新の情報を見ているかどうかを確認できます。適切なタイミングで業務上の判断を下し、分析から得られたインサイトを信頼するために役立ちます。
重要な理由
データの更新時期を把握できるため、最新の情報に基づいて分析や判断を行えます。
入手先
データ抽出・変換(ETL)の処理中に生成され、データセットに記録されます。
例
2024-05-21T02:00:00Z2024-05-20T02:00:00Z
|
|||
|
サービス種別
ServiceType
|
依頼されたサービスの具体的な種類またはカテゴリです。 | ||
|
説明
サービス種別は、必要なサービスの内容に基づいて依頼を分類します。例として、「新しいハードウェアの依頼」「ソフトウェアへのアクセス」「パスワードのリセット」などがあります。多くの場合、ユーザーが選択したサービスカタログの項目に関連付けられています。 この属性を使うと、サービス種別ごとに依頼を分け、プロセスやパフォーマンスを比較できます。「サービス種別ごとの平均アクティビティ数」などの重要業績評価指標(KPI)の算出にも欠かせません。どのサービスが複雑で、より多くのリソースを必要とするかを特定できます。分析結果は、特定のサービス種別におけるプロセスの簡素化や自動化の検討に役立ちます。
重要な理由
依頼カテゴリごとにプロセスの流れや複雑さを比較し、標準化や自動化を検討すべき領域の特定に役立ちます。
入手先
Freshserviceの設定によって異なりますが、チケットオブジェクトの「category」「item」またはカスタムフィールドに対応することがよくあります。
例
新入社員のオンボーディングソフトウェアライセンスの依頼VPNアクセス
|
|||
|
ステータス
Status
|
ライフサイクルにおけるサービス依頼の現在のステータスです。 | ||
|
説明
ステータスフィールドは、特定の時点におけるサービス依頼の状態を示します。例として、「オープン」「保留」「解決済み」「クローズ」などがあります。ステータスの変更は、プロセスマイニングでアクティビティを特定する主な情報源となることがよくあります。 ステータスを分析すると、プロセスの流れを把握し、依頼が特定の状態にとどまる時間を確認できます。たとえば、ステータスが「保留」のまま長く続く場合、依頼者からの情報や外部ベンダーの回答を待つことがボトルネックになっている可能性があります。また、プロセスの各段階の開始点と終了点を定義するうえでも重要な属性です。
重要な理由
各イベントの状況を把握し、「オープン」や「保留」などの状態にかかる時間を測定することで、遅延の特定に役立ちます。
入手先
Freshserviceのチケットオブジェクトにある「status」フィールドから取得できます。
例
オープン保留解決済みクローズ
|
|||
|
優先度
Priority
|
サービス依頼の優先度です。低、中、高、緊急などがあります。 | ||
|
説明
優先度は、サービス依頼の重要度と緊急度を示します。目標解決時間や割り当てるリソースを決める際に使われます。ルールに基づいて自動設定する場合と、担当者が手動で設定する場合があります。 プロセスマイニングでは、優先度は重要な分析軸です。依頼を優先度別に分け、高優先度と低優先度の項目でプロセスの流れやパフォーマンスを比較できます。SLAの遵守状況を分析し、トリアージの段階で適切かつ迅速に優先度が設定されているかを把握するうえで役立ちます。
重要な理由
SLAの遵守状況を分析し、依頼が業務への影響に応じて適切にトリアージされ、処理されているかを把握するうえで重要です。
入手先
Freshserviceのチケットオブジェクトにある「priority」フィールドから取得できます。
例
低中高緊急
|
|||
|
割り当て済みチーム
AssignedTeam
|
サービス依頼の対応を担当するサポートチームまたはグループです。 | ||
|
説明
この属性は、サービス依頼を担当する機能別のグループやチームを示します。例として、「ITサポートレベル2」や「ハードウェア調達」などがあります。個々の担当者が対応を開始する前に、依頼がチームに割り当てられる場合があります。 割り当て済みチームごとに分析すると、チーム単位のパフォーマンスや業務量を把握し、特定の機能領域におけるボトルネックを特定できます。各チームがどれだけ効率よく依頼を処理しているかを評価し、サポート組織全体でリソース配分を最適化するうえで役立ちます。
重要な理由
チームまたはグループ単位でパフォーマンスと業務量を分析できます。リソース管理や、機能領域ごとのボトルネック特定に役立ちます。
入手先
Freshserviceのチケットオブジェクトにある「group」フィールドから取得できます。
例
サービスデスクネットワーク運用アプリケーションサポート
|
|||
|
割り当て済み担当者
AssignedAgent
|
現在、サービス依頼を担当している担当者の名前です。 | ||
|
説明
この属性は、特定の時点でサービス依頼を担当するサポート担当者を示します。依頼のライフサイクルを通じて、担当者が変更されることがあります。 割り当て済み担当者を分析すると、担当者のパフォーマンスや業務量の分布を把握できます。担当者ごとの平均解決時間、対応中の依頼数、再割り当て率などの重要業績評価指標(KPI)を算出できます。これにより、成果を上げている担当者、追加のトレーニングが必要な担当者、業務量の偏りを特定できます。
重要な理由
担当者の業務量やパフォーマンスを分析し、再割り当てが解決時間に与える影響を把握できます。
入手先
Freshserviceのチケットオブジェクトにある「agent」または「responder」フィールドから取得できます。
例
Alice JohnsonRobert Smith未割り当て
|
|||
|
SLAポリシー名
SlaPolicyName
|
依頼に適用されたサービスレベル合意(SLA)ポリシーの名称です。 | ||
|
説明
この属性は、サービス依頼の目標応答時間と解決時間を定めるSLAポリシーを特定します。ポリシーは通常、優先度、サービス種別、依頼者のグループなどに基づいて設定されます。 適用されたSLAポリシーを把握することは、SLA遵守状況・違反分析ダッシュボードに欠かせません。定められた目標に対するパフォーマンスを正確に測定し、どのポリシーで違反が頻発しているかを分析できます。その結果を受けて、プロセスのパフォーマンスやSLA目標の実現可能性を見直すことができます。
重要な理由
依頼が達成すべきサービス目標を特定します。SLAの遵守状況を正確に報告するうえで欠かせません。
入手先
この情報はチケットに関連付けられたSLAデータに含まれます。SLA関連のAPIエンドポイントまたはフィールドを指定して取得する必要がある場合があります。
例
高優先度インシデント:4時間標準依頼:3日VIPサポート:1時間
|
|||
|
SLA期限日時
SlaDueDate
|
SLAに基づき、サービス依頼の解決が予定されている期限のタイムスタンプです。 | ||
|
説明
この属性は、適用されるSLAポリシーで定められたサービス依頼の解決期限を示します。依頼の作成時刻、優先度、SLAで定められた営業時間に基づいて算出されるタイムスタンプです。 リアルタイムのパフォーマンス監視や、事後のSLA遵守状況の分析に欠かせないデータです。実際の解決時刻とSlaDueDateを比較すると、SLAを「達成」したか「未達」だったかを判定できます。SLA遵守率の重要業績評価指標(KPI)を算出する基礎となります。
重要な理由
解決の目標期限です。サービス依頼がSLAを達成したか、未達だったかを判定する基準となります。
入手先
Freshservice内で算出されるフィールドです。チケットには「Due by」と表示され、APIからも取得できます。
例
2023-10-28T17:00:00Z2023-11-01T09:00:00Z
|
|||
|
SLA未達かどうか
IsSlaBreached
|
サービス依頼が解決期限のSLA目標を超過したかどうかを示す真偽値です。 | ||
|
説明
この計算属性は、サービス依頼がSLA期限を過ぎてからクローズされたかどうかを真偽値で示します。「Service Request Closed」または「Service Request Resolved」のタイムスタンプと「SlaDueDate」を比較して算出します。 この属性を使うと、SLA遵守状況ダッシュボードでの分析や可視化が簡単になります。依頼を簡単に絞り込み、集計して、全体のSLA遵守率に関する重要業績評価指標(KPI)を算出できます。この属性で分けて分析すると、期限を超過した依頼と期限内に解決した依頼のプロセス特性をすばやく比較できます。
重要な理由
目標を達成できなかった依頼を絞り込み、集計するための明確なフラグを提供し、SLA遵守状況の分析を簡単にします。
入手先
データ変換時に、最終解決時刻と「SlaDueDate」フィールドを比較して算出するフィールドです。
例
truefalse
|
|||
|
チャネル
Channel
|
サービス依頼の送信に使われた方法またはチャネルです。 | ||
|
説明
チャネルは、セルフサービスポータル、メール、電話、チャットなど、サービス依頼がどのように作成されたかを示します。この情報から、ユーザーの利用傾向やチャネルの効率を把握できます。 チャネル別にプロセスを分析すると、重要なインサイトが得られることがあります。たとえば、ポータルから送信された依頼は必要な情報がそろっていることが多く、メールで送信された依頼より早く解決する場合があります。メールの場合は、追加のやり取りが必要になることがあります。この分析は、より効率的なチャネルの利用を促す取り組みに役立ちます。
重要な理由
送信チャネルがプロセスの効率、解決時間、必要な手戻りの量に影響するかを分析できます。
入手先
Freshserviceのチケットオブジェクトにある「source」フィールドから取得できます。
例
メールポータル電話チャット
|
|||
|
依頼者
Requestor
|
サービス依頼を送信したユーザーです。 | ||
|
説明
この属性は、サービス依頼を開始した人(通常は従業員)を示します。誰がサービスデスクを利用し、どのようなニーズを持っているかを把握するための情報です。 プロセスの流れを分析する際、依頼者や所属部門が主な分析軸になるとは限りませんが、これらの情報から傾向が見つかることがあります。たとえば、特定の部門から不備のある依頼が頻繁に送られている場合、対象を絞ったトレーニングが必要だと分かることがあります。顧客体験に関する分析にも欠かせません。
重要な理由
依頼を開始したユーザーの情報を把握し、個人、部門、拠点ごとの依頼傾向を分析できます。
入手先
Freshserviceのチケットオブジェクトにある「requester」フィールドから取得できます。
例
John DoeJane Smithサービスアカウント
|
|||
|
依頼者の部門
RequestorDepartment
|
依頼者が所属する部門です。 | ||
|
説明
この属性は、サービス依頼を送信したユーザーの所属部門を示します。例として、「営業」「財務」「人事」などがあります。通常、システム内のユーザープロフィールから取得されます。 部門別のプロセスパフォーマンス分析は、よく行われる分析の1つです。特定の部門で解決時間が長くなっていないか、固有のプロセスニーズがないかを把握できます。分析結果は、リソース配分やトレーニング施策の検討、部門別サービスの提供に役立ちます。
重要な理由
事業部門ごとにプロセスを分けて分析し、部門固有の問題やパフォーマンスの違いを特定できます。
入手先
この情報は依頼者のプロフィールに関連付けられています。Freshserviceの標準「department」フィールド、またはカスタムユーザーフィールドに含まれている場合があります。
例
財務マーケティング情報技術
|
|||
|
再割り当て回数
ReassignmentCount
|
サービス依頼が別の担当者またはチームに再割り当てされた合計回数です。 | ||
|
説明
この計算属性は、サービス依頼ごとに「Request Reassigned」または同様のアクティビティの発生回数を数えます。再割り当てが多い場合、初期トリアージの問題、スキルに基づく振り分けの誤り、業務量の偏りなどが考えられます。 この属性は、「担当者のパフォーマンスと業務量の分布」ダッシュボードと「依頼あたりの担当者平均再割り当て回数」重要業績評価指標(KPI)の分析に役立ちます。この指標を分析すると、チケットが担当者間を転送される原因となるプロセス上の弱点を特定できます。転送が増えると解決時間が長くなり、担当者と依頼者の双方に負担がかかります。
重要な理由
振り分けの非効率さやプロセス上の滞りを測定します。回数が多い場合、初期トリアージや担当者の業務量に問題があり、遅延につながっている可能性があります。
入手先
データ変換時に、各「ServiceRequestId」について特定の割り当て変更アクティビティを数えて算出します。
例
013
|
|||
|
手戻りの有無
IsRework
|
依頼に手戻りのアクティビティが含まれていたかどうかを示す真偽値です。 | ||
|
説明
この計算フラグは、サービス依頼で手戻りを示す特定のアクティビティが発生した場合に真になります。例として、解決後の再開(「Service Request Reopened」)、複数回の再割り当て、ユーザーへの情報の再依頼(「Information Requested from Requestor」)などがあります。 この属性を使うと、プロセスの非効率さを簡単に分析できます。手戻りが発生したケースを絞り込み、そのプロセスマップやサイクルタイムを、手戻りのないケースと比較できます。「サービス依頼の手戻り分析」ダッシュボードを支え、非効率な引き継ぎや初回情報の不足がもたらす影響の定量化に役立ちます。
重要な理由
非効率な繰り返しや同じステップの再実行が発生したケースを簡単に特定・分析し、品質低下によるコストの定量化に役立ちます。
入手先
データ変換時に、各「ServiceRequestId」のアクティビティの順序に業務ロジックを適用して算出します。
例
truefalse
|
|||
|
終了時刻
EndTime
|
アクティビティが完了した正確なタイムスタンプです。 | ||
|
説明
終了時刻は、アクティビティが完了したタイムスタンプを示します。Freshserviceの多くのイベントでは開始時刻と終了時刻が同じで、特定の時点に発生するイベントとして扱われます。一方、ステータスに基づくアクティビティでは、次のステータス変更時刻が終了時刻になります。 この属性は、アクティビティの所要時間やアクティビティ間の待ち時間を算出するために必要です。終了時刻から開始時刻を差し引くと、特定のタスクの処理時間を求められます。時間がかかるアクティビティを特定し、改善候補を見つけるうえで役立ちます。
重要な理由
アクティビティの所要時間を算出できます。ボトルネックの特定や、各ステップの処理時間の測定に欠かせません。
入手先
Freshserviceのログに直接記録されるフィールドではありません。サービス依頼ごとに、イベントの並び順で次に発生するイベントのタイムスタンプから算出する必要があります。
例
2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
|
|||
サービスリクエスト管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
SLA目標を超過
|
サービスリクエストの解決時間が、定められたサービスレベル契約(SLA)の目標時間を超えたときに発生する計算上のイベントです。システムで直接記録されるイベントではなく、解決時間とSLA期限を比較して算出します。 | ||
|
重要な理由
サービスの実績を約束した水準と直接比較できるため、管理上の重要業績評価指標(KPI)となります。どの種類や優先度のリクエストが目標未達となるリスクが高いかを特定できます。
入手先
「解決済み」のタイムスタンプと「SLA期限」のタイムスタンプを比較して算出します。解決時刻が期限より後の場合、このイベントが発生します。
記録
解決時刻とSLA期限のタイムスタンプを比較します。resolved_at > sla_due_byの場合、このイベントを作成します。
イベントタイプ
calculated
|
|||
|
サービスリクエストをクローズ
|
サービスリクエストのライフサイクルの終了を示す最後のアクティビティです。通常、「解決済み」の状態で一定期間が経過し、再オープンされなかった場合に自動で発生します。 | ||
|
重要な理由
このイベントは、プロセスインスタンスの正式な終了を示します。「Resolved」から「Closed」までの時間は、依頼者が対応内容を確認する期間です。
入手先
チケットのステータス変更履歴から推定されます。ステータスが「Closed」に変わった時点のタイムスタンプに相当します。
記録
チケットのステータスが「Closed」に変わった時点のタイムスタンプを記録します。
イベントタイプ
inferred
|
|||
|
サービスリクエストを解決
|
担当者が解決策を提示し、作業が完了したと判断した時点を示す重要な節目です。チケットのステータスが「解決済み」に変更されたことから推定します。 | ||
|
重要な理由
このアクティビティは、実作業の終了を示します。この時点までの所要時間は、担当者とプロセスの効率を測る重要な指標であり、SLAの算出にも使われます。
入手先
チケットのステータス変更履歴から推定します。ステータスが初めて「解決済み」に設定された時点のタイムスタンプに対応します。
記録
チケットのステータスが初めて「解決済み」に変更された時点のタイムスタンプを記録します。
イベントタイプ
inferred
|
|||
|
サービスリクエスト作成
|
Freshserviceに新しいリクエストが正式に登録され、サービスリクエストのライフサイクルが始まるアクティビティです。サービスカタログ、メール、その他のチャネルから新しいチケットレコードが作成された際に明示的に記録され、一意のサービスリクエストIDが付与されます。 | ||
|
重要な理由
このプロセスの主な開始イベントです。このアクティビティから他のアクティビティまでの時間を分析することは、全体のサイクルタイムを測定し、初期処理の遅延を特定するうえで基本となります。
入手先
このイベントはFreshserviceに明示的に記録されます。通常、チケットのアクティビティログまたは監査証跡で確認でき、チケットの作成タイムスタンプに対応します。
記録
Freshserviceのチケットデータから、チケットの作成タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
リクエストを担当者に割り当て
|
サービスリクエストが対応する担当者に割り当てられた時点を示します。重要な節目であり、チケットの「割り当て先担当者」または「所有者」フィールドの変更を追跡して推定します。 | ||
|
重要な理由
このアクティビティは、担当者の業務負荷を分析し、割り当てプロセスのボトルネックを特定するうえで重要です。作成から割り当てまでの時間は、重要なパフォーマンス指標です。
入手先
チケットのアクティビティログまたはフィールドの監査証跡で、「担当者」または「割り当て先」フィールドの変更を追跡して推定します。
記録
「割り当て先担当者」フィールドに値が入力された時点、または値が変更された時点のタイムスタンプを記録します。
イベントタイプ
inferred
|
|||
|
外部ベンダーに対応を依頼
|
チケットの解決を外部ベンダーまたは第三者に引き継いだ時点を示します。「ベンダー待ち」や「第三者待ち」などのステータスへの変更から推定します。 | ||
|
重要な理由
ベンダーとの連携によって大幅な遅延が発生することがあります。このアクティビティを追跡することは、ベンダーのパフォーマンスとサービスリクエスト全体のサイクルタイムへの影響を測定するうえで重要です。
入手先
チケットのステータス変更履歴から推定します。外部ベンダーへの依存を追跡するために設定されたステータスを確認します。
記録
チケットのステータスフィールドが、第三者の対応を待つ状態を示す値に変更されたことを検出します。
イベントタイプ
inferred
|
|||
|
サービスリクエストを再オープン
|
チケットが「解決済み」となった後も問題が続いていると依頼者が伝え、チケットがオープン状態に戻ったときに発生します。ステータスが「解決済み」から「オープン」または「進行中」に変更されたことから推定します。 | ||
|
重要な理由
リクエストの再オープンは、初回対応での解決率の低さや顧客の不満を示す有力な指標です。この手戻りの流れを追跡することは、解決策の品質向上に欠かせません。
入手先
アクティビティログにあるチケットのステータス変更履歴から推定します。「解決済み」から「オープン」への直接的なステータス変更です。
記録
ステータスが解決済みからオープンに変更されたことを検出します。
イベントタイプ
inferred
|
|||
|
メモを追加
|
担当者または依頼者がサービスリクエストに追加した公開または非公開のメモを表します。チケットの会話履歴またはアクティビティログに明示的に記録されるイベントです。 | ||
|
重要な理由
メモの頻度やタイミングを分析すると、連絡のパターン、連携の効率、プロセス内で認識のずれが生じる箇所を把握できます。
入手先
Freshserviceのチケットの会話履歴に明示的に記録されます。各メモにはタイムスタンプと作成者が記録されます。
記録
チケットの会話履歴またはコメントログから各エントリを抽出します。
イベントタイプ
explicit
|
|||
|
リクエストの優先順位付け
|
低、中、高などの優先度がサービスリクエストに割り当てられた時点で発生するアクティビティです。チケットの履歴にある「優先度」フィールドの変更を検出して推定します。 | ||
|
重要な理由
優先順位付けは、リソースの配分とSLA目標の達成に欠かせません。このアクティビティを分析すると、リクエストが適切かつ迅速に評価されているかを確認できます。
入手先
Freshserviceのチケットのフィールド変更履歴から推定します。「優先度」フィールドの更新を確認し、変更時のタイムスタンプを記録します。
記録
「優先度」フィールドがnullまたは以前の値から変更されたことを検出し、そのタイムスタンプを記録します。
イベントタイプ
inferred
|
|||
|
リクエストの再割り当て
|
初回の割り当て後に担当者またはグループが変更されたことを記録するアクティビティです。「割り当て先担当者」または「割り当て先グループ」フィールドのその後の更新を検出して推定します。 | ||
|
重要な理由
再割り当てが頻繁に発生する場合、初期の振り分け、担当者のスキル適合、業務負荷の配分に問題がある可能性があります。このアクティビティは、担当者再割り当て数の重要業績評価指標(KPI)や手戻り分析に欠かせません。
入手先
チケットのフィールド変更履歴から推定します。「割り当て先担当者」または「割り当て先グループ」フィールドの初期値が設定された後、更新されるたびにこのイベントが記録されます。
記録
初回の割り当て後に「割り当て先担当者」または「割り当て先グループ」フィールドが変更されたことを検出します。
イベントタイプ
inferred
|
|||
|
リクエストの振り分け
|
新しく作成されたサービスリクエストの初期評価と分類を表します。通常、最初に優先度が設定された時点、またはリクエストがグループに割り当てられた時点から推定します。これは、リクエストが確認され、キューに入ったことを示します。 | ||
|
重要な理由
振り分けを追跡すると、初期対応チームの効率を測定できます。この段階での遅延は、全体の解決時間とSLA遵守率に大きく影響する可能性があります。
入手先
アクティビティログから推定します。作成後に発生した最初の「優先度設定」または「グループ割り当て」イベントのタイムスタンプで特定できます。
記録
優先度フィールドまたは割り当てグループフィールドが変更された時刻のうち、最も早いものを特定します。
イベントタイプ
inferred
|
|||
|
依頼者から情報を受領
|
依頼者が必要な情報を提供し、担当者が作業を再開できる時点で発生します。通常、チケットのステータスが「保留中」から「オープン」に自動で戻ったことから推定します。 | ||
|
重要な理由
このアクティビティにより、情報依頼から回答までの流れを把握できます。情報を依頼してから受け取るまでの時間は、分析と改善が必要な重要な待ち時間です。
入手先
ステータスが「保留中」から「オープン」または「進行中」に戻ったことから推定します。多くの場合、依頼者からの返信がきっかけとなります。
記録
チケットのステータスが保留中からオープンに変更されたことを検出します。
イベントタイプ
inferred
|
|||
|
依頼者が解決を確認
|
提供された解決策に依頼者が満足したことを明示的に確認するアクティビティです。肯定的なアンケート回答や、チケットがクローズされる前の特定のコメントから推定できます。 | ||
|
重要な理由
確認結果から、解決の品質について直接的なフィードバックを得られます。確認率が低い場合、チケットが再オープンされていなくても、解決策が利用者のニーズを十分に満たしていない可能性があります。
入手先
この情報を直接取得するのは難しく、個別の設定が必要になる場合があります。チケットに紐付いた顧客満足度アンケートの回答や、特定のタグの付与から推定できます。
記録
満足度アンケートや解決後に付与されたタグなど、関連データの分析が必要です。
イベントタイプ
inferred
|
|||
|
依頼者に情報を依頼
|
担当者が依頼者に追加情報を求め、処理を一時停止した時点を表します。チケットのステータスが「保留中」または「顧客待ち」に変更されたことから推定します。 | ||
|
重要な理由
このアクティビティは、遅延や手戻りのよくある原因を示します。発生頻度を分析すると、リクエストのテンプレートや初期のデータ収集を改善する機会を特定できます。
入手先
チケットのステータス変更履歴から推定します。「顧客の回答待ち」や「情報待ち」などのステータスへの変更を確認します。
記録
チケットのステータスフィールドが、利用者からの入力を待つ状態を示す値に変更されたことを検出します。
イベントタイプ
inferred
|
|||
|
社内レビューを実施
|
提案された解決策またはリクエストへの対応を進める前に、社内レビューや承認が必要なことを示します。「承認待ち」や「社内レビュー」などのステータスへの変更から推定します。 | ||
|
重要な理由
社内レビューは、特に複雑なサービスリクエストや影響の大きいリクエストで、ボトルネックの原因になることがあります。所要時間を測定すると、承認ワークフローの効率化に役立ちます。
入手先
チケットのステータス変更履歴から推定します。ワークフローで「社内承認待ち」などの専用ステータスを使用する必要があります。
記録
チケットのステータスフィールドが、社内レビューまたは承認を示す値に変更されたことを検出します。
イベントタイプ
inferred
|
|||
データ抽出ガイド
準備はできましたか?
データを準備して、サービスリクエスト管理プロセスの改善に取り組みましょう。サービス提供の改善を支援します。
Freshserviceでサービスリクエストの効率を高めましょう
対応の遅れとユーザーの不満を解消し、自動化率70%を実現しましょう。
クレジットカードは不要です。数分で設定できます。