問題管理を改善

この6ステップのガイドに従って、ワークフローを最適化します。
問題管理を改善
問題管理
Zendesk Support
システム
プロセスを選択してください。

Zendesk Supportの問題管理を最適化し、IT環境を安定化

プロセスマイニングにより、手作業のレビューでは見過ごされがちな、隠れたボトルネックや構造的な遅延を明らかにできます。プラットフォームが、チケットが滞留する箇所やチーム間を何度も行き来する箇所を特定するため、解決までの各段階を効率化できます。これにより、管理業務に追われるのではなく、影響の大きい修正に集中できます。

ダウンロードして、事前設定済みのデータテンプレートをご利用ください。よくある課題に取り組み、業務効率化の目標を達成しましょう。6段階の改善計画に沿って進め、データテンプレートガイドもご確認ください。業務の進め方を変えていけます。

詳細な説明を表示

ITの安定性に問題管理の最適化が欠かせない理由

問題管理は、安定したITインフラを支える基盤です。インシデント管理がサービスをできるだけ早く復旧させることを目的とするのに対し、問題管理はインシデントの根本原因を見つけ、取り除くことに重点を置きます。Zendesk Supportの環境では、根本原因が適切に解消されないまま同じ問題が毎週のように再発し、場当たり的な対応を繰り返す状態に陥る組織も少なくありません。その結果、運用コストの増加、サービス可用性の低下、対応に追われ続けるサポートチームの疲弊につながります。

このプロセスの最適化で重視すべきなのは、速さだけではありません。正確さと再発防止も重要です。問題管理のワークフローを見直すと、時間の経過とともに受信するインシデントの総数を減らせます。場当たり的なサポートから先回りしたサポートへ移行することで、技術スキルの高い担当者は繰り返しの修正作業から離れ、事業を前進させる価値の高い取り組みに集中できます。問題がシステム内をどのように進むのかを把握できなければ、調査がどこで止まっているのか、なぜ解決策の実施が遅れているのかを特定するのは困難です。

プロセスマイニングでZendeskのライフサイクルを可視化

プロセスマイニングを使うと、Zendeskのデータからすべての問題レコードが実際にたどった経路を再構成できます。平均解決時間を示す静的なレポートだけを見るのではなく、イベントが実際に発生した順序を確認できます。問題が特定された時点から、実施後レビューが完了するまでの各ステップを可視化できます。この透明性は、文書化されたプロセスと実際の業務の進み方の違いを理解するうえで欠かせません。

技術チームのデジタル上の活動履歴を分析すると、どこで進行が止まっているのかを正確に特定できます。たとえば、回避策が見つかった後、恒久対策を実施する緊急性が薄れ、問題レコードが頻繁に停滞していることが分かる場合があります。プロセスマイニングは、サポートグループ間の過度な引き継ぎや、変更要求の承認待ちが長いといった、見えにくいパターンやボトルネックを明らかにします。データに基づいてプロセスを分析することで、推測に頼らず、改善効果が大きい段階に取り組めます。

調査フローの主要な改善領域に取り組む

Zendesk Supportでよく改善対象となるのが、Tier 2サポートと専門のエンジニアリングチーム間の引き継ぎです。プロセスマイニングを使えば、移行がスムーズに進んでいるのか、それとも担当未設定のキューに問題が埋もれているのかを確認できます。Investigation Commencedの段階にかかった時間を調べることで、効果的な根本原因分析に必要なツールと情報がチームに揃っているかを判断できます。調査段階が一貫して長い場合は、ナレッジベースとの連携強化や、診断手順の標準化が必要な可能性があります。

もう一つの重要な領域は、提案された解決策と恒久対策の実施との間にある隔たりです。多くの組織では、解決策が作成されても、変更管理プロセスとの連携が不十分または過度に複雑なため、バックログに残ってしまいます。プロセスマイニングを使うと、こうした遅れの正確な期間を把握できます。回避策の効果も監視できます。回避策を公開した後もインシデントが同じ割合でエスカレーションしている場合、回避策が見つけにくい、または効果がない可能性があり、直ちに方針を見直す必要があります。

効率的な解決プロセスによる効果

問題管理を適切に最適化すると、組織全体に効果が広がります。最も分かりやすい効果は、根本原因の調査にかかるサイクルタイムの短縮です。調査が早くなれば恒久対策も早く実施でき、繰り返し発生するインシデントの減少に直結します。その結果、サービスレベル合意の遵守率が高まり、事業部門の関係者からの信頼も向上します。

速さだけでなく、技術面での成果の質も高まります。すべての問題について解決の検証と実施後レビューを確実に行うことで、環境に新たな問題を持ち込むリスクを抑えられます。解決した問題から学び、システムの安定性を高める継続的な改善の循環も生まれます。さらに、技術担当者は繰り返し発生する問題への対応に費やす時間が減り、複雑で価値の高い問題解決に集中できるため、疲弊も軽減されます。

データに基づく問題管理を始める

Zendesk Supportの問題管理プロセスを改善するには、経験談だけに頼らず、実際のプロセスデータを使う必要があります。まず現状をマッピングし、待機時間が長い段階や、継続的に負荷が集中しているサポートグループなど、優先的に改善しやすい箇所を特定します。その結果を使って技術チームの現実的な基準値を設定し、より複雑な根本原因調査に必要なリソースを説明します。変更を実施した後もプロセスフローを継続的に監視し、改善が維持され、新たなボトルネックが生じていないことを確認します。サポート組織を先回りして対応できる体制へ変えていくには継続的な取り組みが必要ですが、Zendeskのワークフローを適切に可視化できれば、実現可能です。

問題管理 ITサービス管理 根本原因分析 インシデント削減 サービスデスクマネージャー 変更リクエスト管理 SLAコンプライアンス チケット管理 チケット管理 既知のエラー 再発インシデント 回避策 インシデント防止 ITヘルプデスク

よくある問題と課題

影響している課題を特定

調査段階が長引くと、重要な問題が数週間にわたって未解決のまま残り、技術的負債やインシデントの再発につながります。根本原因分析に時間がかかると、サポートチームは受け身の対応を続けることになり、ITサービスの安定性が低下し、Zendesk Supportの担当者の運用負荷も高まります。こうした遅れは、調査経路が明確でないことや、トラブルシューティング中に過去のデータへアクセスできないことから生じる場合があります。

ProcessMindは、Problem IdentificationからRoot Cause Identifiedまでのタイムラインをマッピングし、調査がどこで停滞しているのかを特定します。異なるサポートグループ間のフローを可視化することで、リソースのボトルネックを見つけ、引き継ぎを効率化して恒久対策を早められます。これにより、技術チームはプロセス上の事務作業の遅れに埋もれず、影響の大きい調査に集中できます。

問題が根本から解消されないと、同じインシデントがサービスデスクに繰り返し流れ込み、貴重な時間とリソースが失われます。この対応の繰り返しにより、チームは戦略的な改善に集中できず、同じ障害を何度も経験するエンドユーザーの不満も高まります。インシデントと根本原因の明確な関連付けがなければ、組織は同じ問題への対応に繰り返しコストを支払うことになります。

Zendesk Supportの問題レコードとインシデント件数の相関を分析し、最も大きな影響を与えている問題を明らかにします。プロセスマイニングにより、回避策が正式な変更要求による根本解決の代わりに、恒久的な対処として使われているかどうかを確認できます。実際のインシデント件数とサービスデスクの負荷の削減効果に基づき、問題解決の優先順位を設定できます。

技術チームが一時的な修正方法を見つけても、ナレッジベースに公開しなければ、一次対応の担当者はユーザーを迅速に支援できません。情報共有が不足すると、インシデントの解決時間が長くなる一方、正式な問題レコードは調査中のまま残ります。貴重な組織知が個人メモや担当者間のメールに埋もれ、Zendesk Support全体で共有されないこともあります。

ProcessMindは、Workaround IdentifiedからWorkaround Publishedへの移行を監視し、ナレッジ共有がワークフローの標準的な工程になっているかを確認します。回避策が見つかっているにもかかわらず文書化されていないケースを特定し、ナレッジ管理の改善を促せます。既知の回避策をインシデント対応者がすぐに利用できるようにすることで、ユーザーが解決策を待つ時間を短縮できます。

優先度の高い問題レコードで解決目標を達成できないと、事業に大きな支障が生じ、生産性が低下する可能性があります。レコードの進捗を明確に把握できなければ、合意したサービスレベル目標を達成するためのリソース配分が難しくなります。問題のライフサイクルのどの段階でSLA違反が頻発しているのかを特定できず、対応に苦慮する組織も少なくありません。

SLA Due Date属性とリアルタイムのプロセス進捗を照合し、違反に至る前にリスクのあるレコードを通知します。Zendesk Supportで、重要な問題への対応速度を維持できていないサポートグループを把握し、必要に応じて負荷を再配分できます。先回りした監視により、サービスレベル合意のコンプライアンスを維持し、影響の大きい問題に必要な注意を向けられます。

問題レコードが異なるサポートグループ間を行き来するだけで、実質的な進展がないことがあります。こうした移行は、担当範囲が不明確であること、チーム間で十分な情報が引き継がれていないこと、調査段階で責任の所在が曖昧であることから生じます。無意味な往復によって問題レコードの経過時間だけが増え、恒久的な解決には近づきません。

プロセスマイニングツールで、Assigned Support Groups間の問題の流れを可視化し、循環する移行や待機時間を検出します。これにより、担当範囲を明確にし、引き継ぎ時に共有される情報の質を高められます。問題が滞留しやすいグループを特定し、Zendesk Supportで対象を絞ったトレーニングやプロセスの見直しを行うことで、チーム間の連携を改善できます。

根本原因の特定は解決の半分にすぎません。多くの組織では、特定した解決策から恒久対策の完了へ移行することに課題があります。変更要求の開始や修正の適用が遅れると、原因が分かっているにもかかわらず、環境はさらなるインシデントのリスクにさらされます。この知識と実行の隔たりは、問題管理チームと変更管理チームの連携不足から生じることがあります。

Proposed Solution DraftedからPermanent Fix Appliedまでのライフサイクルを追跡し、実施段階の障害を特定します。変更管理との連携がどの程度機能しているかを測定し、特定した修正が速やかに展開されるようにできます。変更承認を待っている時間を明らかにすることで、技術的な特定から実際の解決までのワークフローを改善できます。

実施後レビューを省略すると、組織は複雑な問題から学び、再発を防ぐ機会を失います。構造化されたフィードバックの循環がなければ、後続の問題調査でも同じ非効率が繰り返される可能性があります。正式な完了処理がないことで、継続的なサービス改善が進まず、IT成熟度も停滞します。

ProcessMindは、レビューアクティビティを行わずにResolution VerifiedからClosedへ直接移行した問題レコードを特定します。こうした抜けを明らかにすることで、チームがZendesk Supportのライフサイクル全体に従い、継続的な改善に役立つ知見を記録できるようにします。データに基づくこのアプローチにより、重大な問題の一つひとつを組織知の蓄積と、より良い予防策につなげられます。

問題レコードの分類が誤っていたり、根本原因に関する具体的な属性が不足していたりすると、有意義な傾向分析はほぼ不可能になります。このデータ品質の問題により、ITの不安定さを生む本当の要因が見えなくなり、インフラ投資に関する経営判断も難しくなります。Problem Categoryが実際の根本原因と一致していなければ、長期的な戦略計画は不正確な前提に基づくことになります。

Zendesk Supportのプロセスフロー全体で、Problem CategoryやRoot Cause Categoryなどの属性がどのように使われているかを分析します。データが不足している箇所や、ライフサイクルの後半で変更されている箇所を特定することで、データ入力の基準を改善し、問題データからより正確な情報を得られます。どの業務サービスや構成アイテムに投資と対応が最も必要かを、正確に特定できます。

チームが恒久対策の複雑さを避けるため、一時的な回避策に長期間依存することがあります。目の前の症状は解消できても、基盤の不安定さは残り、IT部門の長期的な保守負荷が増えます。こうした一時的な対処が積み重なると、わずかな変更が大きな障害を引き起こす不安定な環境になります。

ProcessMindは、回避策が公開されているにもかかわらず変更要求が開始されていない、長期化した問題レコードを検出します。これにより、一時的な緩和策から恒久的な解決へ移行する問題の優先順位を設定し、技術的負債を減らせます。回避策の公開から経過した時間を監視し、より安定した長期的な解決策へ移行するようチームに促せます。

多くの問題レコードは作成された後、更新されないまま数か月にわたってアクティブ状態に残り、完了に至りません。こうしたレコードはキューを圧迫し、パフォーマンス指標を歪め、業務環境に未解決のリスクを残します。チームがより緊急度の高いインシデントへ移ると、レコードが忘れられ、根本の問題が再び危機を引き起こすこともあります。

Investigation CommencedやProposed Solution Draftedなどのアクティビティ間に長い非アクティブ期間があるレコードを自動的に特定します。これにより、マネージャーはバックログを確認し、停滞した調査を再開させるか、Zendesk Supportで不要になったレコードを正式にクローズできます。非アクティブなレコードを整理することで、問題管理における実際の対応能力と業務量をより正確に把握できます。

一般的な目標

成功の状態を定義

発見までの速さに注目することは重要です。調査が長引くと、システムは脆弱な状態に置かれ続けます。根本原因の特定にかかる時間を短縮すれば、事業への影響を抑え、組織全体のサービス継続性を守れます。調査が早くなれば、ITチームは受け身のトラブルシューティングから、安定性を高める先回りした改善へ移行できます。

ProcessMindは、Zendesk Supportで問題の特定から根本原因の発見までの流れをマッピングします。調査が停滞している段階を特定し、マネージャーは技術専門家の配置を見直して診断手順を効率化できます。こうしたボトルネックを特定することで、組織は調査段階の期間を最大30%短縮できます。

インシデントの再発が多い場合、システム上の問題が根本から解決されていない可能性があります。症状だけでなく根本原因に対処することで、ITチームはサポートの総コストを抑え、ユーザー満足度を高められます。効果的な問題管理は、時間の経過とともにZendesk Supportのキューに入るチケットの減少につながります。

プロセスマイニングを使うと、問題レコードとインシデントの頻発パターンを関連付けられます。ProcessMindは、再発防止に成功した問題解決と、根本原因に対処できなかった解決を明らかにします。この可視性により、インシデントを最も頻繁に引き起こしている問題を優先し、チケットの再発件数を20%削減できます。

効果的な回避策は、恒久的な修正が開発されるまでの間、直ちに影響を軽減します。回避策を文書化し、速やかに公開することで、エンドユーザーの停止時間を短縮し、サービスデスク担当者が関連するインシデントをより迅速に解決できるようになります。回避策への標準化された対応により、技術的な知識が特定のチーム内に閉じ込められることを防げます。

ProcessMindは、回避策が特定されてからZendesk Supportのナレッジベースに公開されるまでの期間を追跡します。一時的な解決策が把握されているにもかかわらず共有されていないケースを検出し、情報がスムーズに行き渡るようにします。この可視性により、回避策の利用可能性が高まり、既知の問題からサービスを復旧するまでの平均時間を短縮できます。

優先度の高い問題についてサービスレベル合意を守ることは、事業に不可欠な安定性を維持するうえで欠かせません。目標を継続して達成することでステークホルダーの信頼が高まり、影響の大きい問題に必要な対応を確実に行えます。目標を達成できない状態が続くと、連鎖的な障害や生産性の低下につながることがあります。

ProcessMindは、対応中のすべての問題レコードについて、SLAの状況をリアルタイムで可視化します。期限超過につながる具体的なプロセス経路を特定し、違反が発生する前に管理者が介入できるようにします。こうした分析結果を利用する組織は、エスカレーション経路の障害を取り除くことで、重大な問題の解決において100%のコンプライアンスを達成できます。

問題の解決には、複数の専門技術チームの協力が必要になることがよくあります。チーム間のスムーズな移行により、情報の欠落を防ぎ、複雑な問題解決で生じがちな待機時間を短縮できます。引き継ぎを最適化すると、ライフサイクル全体が速く進み、コミュニケーション上のミスも大幅に減少します。

このプラットフォームは、Zendesk Support内の異なるサポートグループ間にある引き継ぎポイントを可視化します。各移行時の待機時間を測定することで、ProcessMindはサイロ化を特定し、コミュニケーション経路を効率化します。これにより、管理者は引き継ぎ手順を見直し、グループ間の移管中に問題レコードが保留状態にとどまる時間を短縮できます。

根本原因が判明したら、直ちに実装へ移行する必要があります。調査から変更リクエストの開始までの間隔を短縮することで、システムをできるだけ早く安定した状態に戻せます。この移行時の遅延は、管理上の手続きや部門間の連携不足によって生じることがよくあります。

ProcessMindは、根本原因の特定から変更リクエストの作成または修正の適用までにかかった時間を分析します。診断段階から解決段階への迅速な移行を妨げる管理上の障害を明らかにします。この引き継ぎを効率化することで、組織は複雑なIT問題の解決までの総時間を短縮できます。

実装後レビューは、継続的なプロセス改善と組織の学習に欠かせません。重大な問題をすべて正式なレビューの対象にすることで、過去の失敗から学び、他の領域で同様の問題が発生するのを防げます。レビューを行わなければ、同じプロセス上のミスが繰り返される可能性があります。

プロセスマイニングは、Zendesk Supportで問題レコードがクローズされた後のレビュー完了率を追跡します。この手順を頻繁に省略しているチームやカテゴリーを明らかにし、プロセス標準を対象を絞って徹底できるようにします。レビューのコンプライアンスを高めることで、重大なインシデントのすべてを組織の知識として蓄積できます。

正確な分類は、意味のある傾向分析とリソース計画の基盤です。正確なデータにより、ITサービス品質と業績への影響が大きい領域にリソースを配分できます。カテゴリーが誤っていると、管理レポートの信頼性が低下し、根本原因も見つけにくくなります。

ProcessMindは、問題のライフサイクル全体にわたる再分類のパターンを特定します。初回の分類が誤りやすい箇所を明らかにすることで、管理者はトレーニングやデータ入力手順を改善できます。入力時点でデータ品質を高めることにより、レポートの精度が向上し、ITインフラへの投資に関する戦略的な意思決定も改善されます。

回避策に過度に依存すると、技術的負債が蓄積し、事業の長期的な不安定要因になります。問題管理の最終的な目標は、一時的な修正から、根本的な脆弱性を完全に取り除く恒久的な解決策へ移行することです。問題が回避策の状態に無期限でとどまるケースを減らすことは、重要な成功指標です。

このプラットフォームは、長期間にわたって回避策の状態にある問題の件数を監視します。場当たり的な対応を続けるのではなく、恒久的な修正に必要な技術的作業を実施する根拠となるデータを提供します。この移行により、技術チームの長期的な保守負担が軽減され、システム全体の信頼性が高まります。

アクティビティがないオープンな問題レコードは、環境に対する放置されたリスクを示します。バックログを整理し、常に対応可能な状態に保つことで、ITチームは増え続ける停滞項目の管理ではなく、現在の優先事項に集中できます。停滞したレコードには、将来の大規模な停止につながる未解決の問題が隠れていることがあります。

ProcessMindは、Zendesk Supportで最後のアクティビティまたはステータス変更から経過した時間に基づき、非アクティブな問題レコードを検出します。設定した期間内に進展がないレコードに対して、管理者はアラートの自動化や再割り当てを実行できます。この予防的な監視により、問題レコードの放置を防ぎ、バックログを管理しやすい状態に保てます。

優先度の高い問題は、事業運営と収益に最も大きな影響を及ぼします。こうした問題をより速く、より高い頻度で解決することで、最も重要なサービスと資産を守れます。重大項目の高い解決率は、問題管理プロセスが高い成果を上げていることを示す主要な指標です。

ProcessMindは、優先度の高いレコードと標準レコードのライフサイクルを詳しく比較できます。重大な問題が適切な緊急度で扱われているか、また手順上の障害がどこにあるかを特定します。この分析により、チームは重要度の高い作業を優先でき、目標期間内に解決される重大な問題の割合を高められます。

問題の調査には多くのリソースが必要で、シニアエンジニアが何時間も対応しなければならないことがあります。分析プロセスを効率化することで、専門家は管理作業に費やす時間を減らし、複雑な技術的トラブルシューティングやイノベーションにより多くの時間を使えます。分析コストを削減することで、問題管理機能全体を持続的に運用しやすくなります。

ProcessMindは、調査の種類ごとに必要な作業時間と期間を定量化し、効率的な解決経路を特定します。このデータにより、すべての技術サポートチームでベストプラクティスを標準化できます。組織はこの分析結果を利用して、高い品質基準を維持しながら、問題1件あたりの平均解決コストを削減できます。

Zendeskの問題管理を改善する6つのステップ

1

テンプレートをダウンロード

実施内容

Zendeskの問題管理データ構造向けにあらかじめ設定されたExcelテンプレートをダウンロードします。

重要な理由

標準形式を使うことで、問題レコードとチケットのリンクを分析エンジンに正確に対応させられます。

期待される成果

Zendeskの問題追跡に対応した、すぐに使えるデータテンプレートです。

分析で得られる発見

根本原因を明らかにし、問題管理の遅延を解消

ProcessMindはZendeskのワークフローをマッピングし、調査が滞る箇所や修正が遅れる原因を明らかにします。初回チケットの登録から最終的な恒久対策まで、実際の解決サイクルを明確に把握できます。
  • 解決までのすべてのステップをマッピング
  • 根本原因分析の遅延箇所を特定
  • 修正実装のボトルネックを特定
  • サポートチーム間の一貫性を測定
Discover your actual process flow
Discover your actual process flow
Identify bottlenecks and delays
Identify bottlenecks and delays
Analyze process variants
Analyze process variants
Design your optimized process
Design your optimized process

実証された成果

問題管理ライフサイクルを最適化

プロセスマイニングでZendesk Supportのデータを分析することで、組織は問題解決のボトルネックを特定し、対象を絞った根本原因分析によって繰り返し発生するインシデントをなくせます。

0 %
根本原因分析を迅速化

診断時間を短縮

診断のボトルネックを特定することで、チームは根本原因の発見を早め、根本的な問題をより効率的に解決できます。

0 %
インシデント件数を削減

関連インシデントを削減

恒久的な修正率を高めることで、下流で発生するインシデントが直接減少し、サポート運用の総コストを大幅に削減できます。

+ 0 %
回避策の利用を改善

文書化率を向上

回避策を一貫して公開することで、恒久的な修正の開発中でも、サービスデスク担当者がより迅速にサービスを復旧できます。

0 days
グループ間の引き継ぎを効率化

待機時間を短縮

部門間の移管を可視化することで、レコードが異なる技術サポートグループ間を移動する際の待機時間をなくせます。

0 %
初回解決率を向上

再オープン案件を削減

恒久的な修正の有効性を検証することで、根本原因が確実に解消されたことを確認し、重大なサービス障害の再発を防げます。

0 %
レコードの滞留を削減

未対応の問題案件を整理

オープンレコードを自動監視することで、調査の放置を防ぎ、バックログを対応中で優先度の高い項目に集中させられます。

成果は、プロセスの複雑さやデータ品質によって異なります。以下の数値は、さまざまなZendesk導入環境で確認された一般的な改善例を示しています。

推奨データ

まずは、プロセスマップを明確に作成するために必要な主要な属性とアクティビティから始めます。
イベントログを初めて扱いますか。学ぶ プロセスマイニングのイベントログを作成する方法.

属性

分析に必要な主要データ項目

問題レコードに割り当てられた緊急度です。

重要な理由

SLA遵守状況とリソースの優先順位を分析するため、ケースを区分するうえで欠かせません。

現在、問題レコードを担当しているチームまたは部門です。

重要な理由

組織の分析と、部門間のボトルネックの特定を可能にします。

問題への対応を割り当てられた特定の担当者です。

重要な理由

個人単位でのリソース分析を可能にします。

ライフサイクルにおける問題レコードの現在の状態です。

重要な理由

完了状態に基づいてケースを絞り込めます。

この問題レコードにリンクされたインシデントチケットの数です。

重要な理由

問題の規模とユーザーへの影響を示します。

問題を解決する目標日時です。

重要な理由

コンプライアンスと契約上のパフォーマンスを測定するうえで欠かせません。

問題の分類です(例:Software、Hardware、Network)。

重要な理由

テクノロジーまたは業務サービス別にセグメント化できます。

特定された問題の根本原因です(例:Code Defect、Config Error)。

重要な理由

障害パターンの分析を可能にし、長期的な改善活動の方向性を示します。

アクティビティ

追跡・最適化するプロセスのステップ

Zendesk Support内で問題チケットを最初に作成することです。このイベントは、問題が初めてシステムに記録された時刻を取得し、通常はプロセスインスタンスを開始します。

重要な理由

End To Endの解決サイクルの開始時刻を定め、その後のすべてのリードタイム指標の基準になります。

問題レコードを特定の技術チームまたは部門に振り分けることです。チケットのGroup ID項目が更新された時点で追跡します。

重要な理由

Support Group Handover Analysisダッシュボードで、部門間の待機時間を測定するために欠かせません。

受動的な「New」状態から、対応中のアクティブな状態へ移行したことを示します。担当者が問題を認識し、診断を開始したことを意味します。

重要な理由

Stale Problem Record指標の算出に使用し、Average Root Cause Analysis Duration KPIの起点になります。

問題に対する一時的な修正を文書化し、共有するアクションです。Zendeskでは、回避策が利用可能であることを示す特定のタグやカスタムチェックボックス項目で取得することがよくあります。

重要な理由

Workaround Publication Complianceダッシュボードを支え、長期にわたる調査中もユーザーに一時的な対処を提供できるようにします。

問題の根本的な原因が判明した時点です。通常は、担当者がカスタムの「Root Cause」テキスト項目またはドロップダウンカテゴリーに値を入力した時点で取得します。

重要な理由

Root Cause Investigation Velocityダッシュボードにおける重要なマイルストーンであり、診断効率の測定にも使用します。

技術的な解決策が環境に展開されたことを示します。通常は、チケットが完全に解決される前のカスタムステータス遷移や特定のタグで追跡します。

重要な理由

Fix Implementation Efficiencyダッシュボードで、診断から展開までの時間を測定するために欠かせません。

問題をSolvedとして正式に記録することです。Zendeskでは、標準システムステータスが「Solved」に設定された時点で発生し、修正が検証され、ケースが完了したことを示します。

重要な理由

SLA Performance and Riskの計算およびProblem SLA Adherence Rateにおける主要な終点です。

チケットがロックされ、それ以上変更できなくなるライフサイクル上の最終イベントです。Zendeskでは通常、Solved状態になってから4日後に自動的に発生します。

重要な理由

レコードの存続期間の完全な終了を示し、データ保持と履歴レポートに使用します。

よくある質問

よくある質問

プロセスマイニングは、既存のZendeskイベントログを使い、問題レコードが実際にシステム内を移動する流れを視覚的なマップにします。隠れたボトルネックや標準業務手順からの逸脱を特定し、調査がどこで停滞しているかを正確に確認できます。

開始するには、問題レコードID、各ステータス変更のタイムスタンプ、ステータス更新や割り当て変更などのアクティビティ名が通常必要です。優先度、カテゴリ、担当グループなどの追加項目があると、より詳細なフィルタリングと根本原因分析が可能になります。

インシデントと問題レコードの関係をマッピングすることで、恒久的に解決せず、回避策で繰り返し対処している問題のパターンを特定できます。この可視性により、再発するサポートチケットのまとまりを解消する、影響の大きい対策を優先できます。

Zendeskデータを接続してから、数日で最初のプロセスマップを確認できるチームが多いです。過去のログを使うため、重要なボトルネックやコンプライアンス上の問題を特定するために、新しいデータが蓄積されるまで待つ必要はありません。

はい。問題レコードが異なるサポートグループや技術チーム間を移動する状況を追跡します。引き継ぎが失敗する箇所や、レコードが長時間停止している箇所を正確に特定し、より適切なリソース配分につなげられます。

いいえ。Zendeskがバックグラウンドで生成している監査ログを分析するため、現在のワークフローを変更したり、カスタム項目を追加したり、エージェントの作業方法を変えたりする必要はありません。

システムは、各プロセス段階にかかった時間を、設定したサービスレベル目標と照合して監視します。診断から修復への遷移の遅延など、SLA違反につながりやすい具体的な経路を通知できます。

アクティビティの順序を分析し、根本原因分析や実装後レビューなどの必須ステップを経ずに、直接クローズ状態へ移行したレコードを検知できます。これにより、重大な問題ごとにチームが必要な品質基準に従っていることを確認できます。

問題管理を最適化し、IT修正を迅速化

解決サイクルを30%短縮し、ITのボトルネックを解消します。

無料トライアルを開始

クレジットカードは不要です。数分で設定できます。