問題管理を改善する

この6つのステップに沿って、ワークフローを効率化しましょう。

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

問題管理

Zendesk Support

プロセスを選択

接続済みのワークスペースで作業を続けるには、プロセスを選択してください。

利用可能なプロセス

利用可能なシステム

課題(10)目標(12)6つのステッププレビュー成果データよくある質問(4)

ITの安定性に向けてZendesk Supportの問題管理を最適化

プロセスマイニングを使うと、手作業での確認では見落とされがちなボトルネックや構造的な遅延を明らかにできます。チケットが滞留している箇所や、チーム間を何度も行き来している状況を特定し、解決までの各段階を見直せます。こうした可視化により、管理業務に追われるのではなく、影響の大きい修正にチームの力を集中できます。

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

詳細を表示

ITの安定性を保つうえで、問題管理の最適化が重要な理由

問題管理は、安定したITインフラを支える基盤です。インシデント管理がサービスの迅速な復旧を目指すのに対し、問題管理ではインシデントの根本原因を特定し、取り除くことに重点を置きます。Zendesk Supportを利用する多くの組織では、同じ問題が何度も発生するたびに対応する状況が続いています。根本原因に適切に対処できていないためです。その結果、運用コストの増加、サービス可用性の低下、対応に追われて前進できないサポートチームなど、大きな負担が生じます。

このプロセスの最適化で目指すのは、対応の迅速化だけではありません。正確な原因特定と再発防止も重要です。問題管理のワークフローを見直すことで、時間の経過とともにインシデントの総数を減らせます。受け身の対応から先回りしたサポートへ移行すれば、経験豊富な技術担当者が繰り返しの修正作業から離れ、事業の成長につながる重要なプロジェクトに取り組めます。問題がシステム内をどのように進むかを把握できなければ、調査がどこで滞るのか、解決が遅れるのはなぜかを特定するのは困難です。

プロセスマイニングでZendeskの業務の流れを可視化

プロセスマイニングでは、Zendeskのデータから問題レコードごとの実際の経過を再構成します。平均解決時間を示す静的なレポートを見るだけでなく、イベントが実際に発生した順序を確認できます。問題の特定から実装後のレビューまで、各ステップを可視化できます。文書化されたプロセスと実際の業務の進め方の違いを把握するうえで、この透明性が役立ちます。

技術チームの業務記録を分析すると、どこで進捗が滞るのかを特定できます。たとえば、回避策が見つかった後、恒久対応の緊急性が薄れて問題レコードが停滞しているケースが見つかるかもしれません。サポートグループ間の過剰な引き継ぎや、変更リクエストの承認待ちなど、表面化しにくいパターンやボトルネックも明らかになります。データに基づいて分析することで、推測に頼らず、改善効果が大きい段階に取り組めます。

調査の流れで優先して改善すべき領域

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

もう1つの重要な領域は、解決策の提案から恒久対応の実施までの遅れです。多くの組織では、解決策を作成しても、変更管理プロセスとの連携が不十分だったり、手続きが煩雑だったりして、バックログに残ることがあります。プロセスマイニングでは、遅延の長さを正確に把握できます。また、回避策がどの程度機能しているかも確認できます。回避策を公開してもインシデントの増加が止まらない場合は、回避策が見つけにくい、または効果が不十分である可能性があり、速やかな方針の見直しが必要です。

解決プロセスを効率化して得られる効果

問題管理を適切に最適化すると、組織全体に効果が広がります。まず、根本原因の調査にかかるサイクルタイムを測定可能な形で短縮できます。調査が速くなれば恒久対応を早期に実施でき、インシデントの再発件数も減少します。その結果、サービスレベル合意の遵守率が高まり、事業部門の関係者からの信頼向上にもつながります。

対応の迅速化に加え、プロセスを見直すことで技術面の成果の質も高まります。すべての問題について、解決内容の検証と実装後のレビューを徹底すれば、新たな問題が環境に持ち込まれるのを防げます。解決した問題から学び、システムの耐障害性を高める継続的な改善のサイクルが生まれます。また、技術スタッフは繰り返し発生する問題への対応に費やす時間が減り、複雑でやりがいのある課題に取り組めるため、疲弊の軽減にもつながります。

データに基づく問題管理の始め方

Zendesk Supportの問題管理を改善するには、個人の経験談だけに頼らず、実際のプロセスデータを確認することから始めます。まず現在の状態を可視化し、待機時間が長い段階や、常に負荷が高いサポートグループなど、着手しやすい改善点を見つけます。その結果をもとに、技術チームの現実的な目標を設定し、より複雑な根本原因調査に必要なリソースを確保する根拠を示します。変更を実施した後もプロセスの流れを継続的に確認し、改善が定着しているか、新たなボトルネックが生じていないかを確かめます。サポート組織を先回りして対応できる体制へ変えるには継続的な取り組みが必要ですが、Zendeskのワークフローを適切に把握できれば実現できます。

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

よくある問題と課題

影響している課題を特定

調査が長引くと、重大な問題が何週間も未解決のまま残り、技術的負債やインシデントの再発につながります。根本原因の分析に時間がかかるほど、サポートチームは受け身の対応を続けることになり、ITサービスの安定性が損なわれるうえ、Zendesk Supportの担当者の負担も増します。調査手順が明確でないことや、トラブルシューティング中に過去のデータを参照できないことが、遅延の原因となる場合があります。

当社のソリューションは、「問題の特定」から「根本原因の特定」までの経過を可視化し、調査が滞る箇所を明らかにします。サポートグループ間の流れを確認することで、リソースのボトルネックを特定し、引き継ぎを効率化して恒久対応を早められます。これにより、技術チームはプロセス上の事務的な遅れに時間を取られず、影響の大きい調査に集中できます。

問題の根本原因に対処できなければ、同じインシデントがサービスデスクに繰り返し寄せられ、貴重な時間とリソースが失われます。この繰り返し対応に追われると、チームは戦略的な改善に取り組めず、同じ障害を何度も経験する利用者の不満も高まります。インシデントと根本原因の関係が明確でなければ、組織は同じ問題への対応にコストを払い続けることになります。

Zendesk Supportの問題レコードとインシデント件数の関係を分析し、影響の大きい問題を特定します。プロセスマイニングを使うと、正式な変更リクエストを通じて根本原因を解消せず、回避策に頼り続けていないかを確認できます。実際のインシデント件数やサービスデスクの業務量の削減効果に基づいて、問題解決の優先順位を決められます。

技術チームが一時的な対処法を見つけても、ナレッジベースに公開しなければ、最前線の担当者は利用者を迅速に支援できません。情報共有が不十分だと、インシデントの解決に時間がかかる一方で、正式な問題レコードは調査中のまま残ります。組織に蓄積された貴重な知識が、Zendesk Support上で共有されず、個人のメモやメールのやり取りに埋もれてしまうこともあります。

ProcessMindは、「回避策の特定」から「回避策の公開」までの移行を追跡し、知識共有がワークフローに定着しているかを確認します。回避策が見つかっても文書化されていないケースを特定し、ナレッジ管理の改善に役立てられます。既知の回避策をインシデント対応者がすぐに参照できるようにすることで、利用者が解決を待つ時間を短縮できます。

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

SLA期限の属性とリアルタイムのプロセス進捗を照合し、期限超過前にリスクのあるレコードを通知します。Zendesk Supportで重大な問題への対応が遅れているサポートグループを確認し、必要に応じて業務を再配分できます。こうした先回りの監視により、サービスレベル合意の遵守を支援し、影響の大きい問題に必要な対応を確実に行えるようにします。

問題レコードが有意な進展のないまま複数のサポートグループ間を行き来し、不要な遅延が生じることがあります。担当範囲が不明確であること、チーム間で共有される情報が不足していること、調査段階で責任の所在が曖昧であることなどが、こうした引き継ぎの原因です。問題レコードが恒久対応に近づかないまま、経過時間だけが増えていきます。

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

根本原因の特定は解決の半分にすぎません。解決策を見つけても、恒久対応の完了まで進められない組織は少なくありません。変更リクエストの開始や修正の適用が遅れると、原因が判明していても環境は新たなインシデントのリスクにさらされます。問題管理チームと変更管理チームの連携不足が、知識を行動に移せない原因となることがあります。

「解決策の作成」から「恒久対応の適用」までの流れを追跡し、実装段階での停滞箇所を特定します。変更管理との連携状況を測定し、特定した修正が速やかに適用されているかを確認できます。変更承認の待ち時間を明らかにすることで、技術的な原因特定から実際の解決までのワークフローを改善できます。

実装後のレビューを省略すると、組織は複雑な問題から学び、再発を防ぐ機会を逃します。体系的なフィードバックの仕組みがなければ、その後の問題調査でも同じ非効率が繰り返される可能性があります。正式な完了確認が行われないと、サービスの継続的な改善が進まず、ITの成熟度も停滞しかねません。

ProcessMindは、レビューのアクティビティを行わずに「解決の検証」から「クローズ」へ直接進んだ問題レコードを特定します。こうした抜けを明らかにすることで、チームがZendesk Supportのライフサイクル全体に沿って対応し、継続的な改善に役立つ知見を記録できるようにします。データに基づくこの方法により、重大な問題から得た知識を組織内に蓄積し、予防策の改善につなげられます。

問題レコードの分類が誤っていたり、根本原因を示す属性が不足していたりすると、有意義な傾向分析は困難です。データ品質の問題によってITの不安定さを招く要因が見えにくくなり、インフラ投資に関する適切な判断も妨げられます。「問題カテゴリ」が実際の根本原因と一致しなければ、長期的な戦略計画も誤った前提に基づくことになります。

Zendesk Supportのプロセス全体で、「問題カテゴリ」や「根本原因カテゴリ」などの属性がどのように使われているかを分析します。データが欠けている箇所や、ライフサイクルの後半で変更される箇所を特定することで、データ入力の基準を改善し、問題データからより正確なインサイトを得られます。投資や対応を優先すべき業務サービスや構成アイテムを、具体的に特定するのにも役立ちます。

恒久対応の複雑さを避けるため、一時的な回避策に頼り続けるチームもあります。目の前の症状は抑えられても、インフラの根本的な不安定さは残り、IT部門の長期的な保守負担が増します。こうした一時対応が積み重なると、小さな変更が大きな障害につながりかねない不安定な環境になります。

当社のプラットフォームは、回避策が公開されている一方で変更リクエストが開始されていない、長期化した問題レコードを検出します。状況を可視化することで、一時的な対処から恒久対応への移行を優先し、技術的負債の増加を抑えられます。回避策の公開後に経過した時間を監視し、より安定した長期的な解決策へ進むようチームに促せます。

問題レコードが登録されても結論に至らず、更新のないまま何か月もアクティブな状態で残ることがあります。こうしたレコードはキューを圧迫し、パフォーマンス指標を歪めるだけでなく、事業環境に未解決のリスクを残します。より緊急性の高いインシデントへの対応に追われて忘れられ、やがて別の危機を引き起こすこともあります。

「調査開始」から「解決策の作成」までのようなアクティビティ間に長い空白があるレコードを自動で特定します。管理者はバックログを確認し、停滞した調査を再開するか、Zendesk Supportで不要になったレコードを正式にクローズできます。非アクティブなレコードを整理すると、問題管理の実際のキャパシティと業務量をより正確に把握できます。

一般的な目標

成功の基準を定義

調査に時間がかかるほど、システムがリスクにさらされるため、原因を迅速に特定することが重要です。根本原因の特定にかかる時間を短縮すれば、事業への影響を抑え、組織全体のサービス継続性を守れます。調査が速くなれば、ITチームは受け身のトラブル対応から、安定性を高める先回りの改善へ移行できます。

ProcessMindは、Zendesk Supportで問題を特定してから根本原因を発見するまでの流れを可視化します。調査が滞る段階を特定できるため、管理者は技術専門家の配置を見直し、診断手順を効率化できます。こうしたボトルネックを特定することで、調査段階の期間を最大30％短縮できます。

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

プロセスマイニングを使って、問題レコードと頻繁に発生するインシデントのパターンを関連付けて分析できます。再発防止につながった解決策と、根本原因に対処できなかった解決策をProcessMindで確認できます。頻発するインシデントの原因となる問題を優先して対応することで、チケットの再発件数を20％削減できます。

恒久対応を進める間、効果的な回避策は利用者への影響をすぐに抑えます。回避策を文書化して速やかに公開すれば、利用者のダウンタイムを短縮し、サービスデスクの担当者が関連するインシデントを早く解決できるようになります。回避策の手順を標準化することで、技術的な知識が特定のチームだけにとどまるのを防げます。

ProcessMindは、Zendesk Supportで回避策の特定からナレッジベースへの公開までにかかる時間を追跡します。一時的な解決策が知られていても共有されていないケースを通知し、情報共有を促します。回避策を参照できる機会を増やし、既知の問題でサービスを復旧するまでの平均時間を短縮できます。

優先度の高い問題でサービスレベル合意を守ることは、事業に欠かせないシステムの安定性を保つうえで重要です。目標を継続して達成することで関係者の信頼を得られ、影響の大きい問題に必要な対応を行えます。目標を達成できなければ、障害の連鎖や生産性の低下につながるおそれがあります。

ProcessMindでは、アクティブなすべての問題レコードについて、SLAの状況をリアルタイムで確認できます。期限超過につながるプロセス経路を特定し、違反が発生する前に管理者が介入できるようにします。こうしたインサイトを使って対応経路の停滞を解消することで、重大な問題の解決において100％の遵守率を達成できます。

問題の解決には、複数の専門技術チームの連携が必要になることがあります。グループ間で円滑に引き継げば、情報の欠落を防ぎ、複雑な問題の解決で生じやすい待機時間を短縮できます。引き継ぎを改善すると、ライフサイクル全体が速く進み、連絡ミスも大幅に減ります。

プラットフォームでは、Zendesk Supportのサポートグループ間で引き継ぎが発生する箇所を可視化します。各引き継ぎの待ち時間を測定し、部門間の分断を特定して連絡経路の改善を支援します。管理者は引き継ぎの手順を見直し、グループ間の移管中に問題レコードが保留状態で残る時間を短縮できます。

根本原因が判明したら、速やかに実装へ移る必要があります。調査から変更リクエストの開始までの時間を短縮すれば、システムをできるだけ早く安定した状態に戻せます。この移行の遅れは、事務手続き上の障壁や部門間の連携不足が原因となることがあります。

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

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

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

正確な分類は、有意義な傾向分析やリソース計画の基盤です。データが正確であれば、ITサービスの品質や事業の成果に最も大きく影響する領域へリソースを配分できます。分類が誤っていると、管理レポートの信頼性が損なわれ、根本原因も特定しにくくなります。

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

回避策に頼りすぎると、技術的負債が増え、事業の長期的な安定性が損なわれます。問題管理の最終的な目標は、一時的な対処から、根本的な脆弱性を取り除く恒久対応へ移行することです。回避策の状態が長期間続く問題を減らすことは、成果を測る重要な指標です。

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

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

ProcessMindは、Zendesk Supportで最後のアクティビティやステータス変更からの経過時間に基づいて、非アクティブな問題レコードを検出します。一定期間進捗がないレコードについて、管理者がアラートを自動化したり、担当者の再割り当てを開始したりできます。先回りして監視することで、問題レコードの放置を防ぎ、バックログを運用しやすい状態に保てます。

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

ProcessMindでは、優先度の高いレコードと通常のレコードのライフサイクルを詳しく分析できます。重大な問題に適切な緊急度で対応しているか、手順上の障壁がどこにあるかを特定します。このインサイトをもとに重要な業務を優先し、目標期間内に解決する重大な問題の割合を高められます。

問題の調査には多くのリソースが必要で、経験豊富なエンジニアが何時間も対応することがあります。分析プロセスを効率化すれば、専門家は事務作業に費やす時間を減らし、複雑な技術的調査や新たな取り組みに集中できます。分析コストを抑えることで、問題管理業務を継続しやすくなります。

ProcessMindは、調査の種類ごとに必要な作業時間と期間を数値化し、効率的な解決経路を特定します。このデータは、技術サポートチーム全体でベストプラクティスを標準化するのに役立ちます。組織はこうしたインサイトをもとに、品質を保ちながら問題解決あたりの平均コストを削減できます。

Zendeskの問題管理を進める6つのステップ

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

実施内容

Zendeskの問題管理データ構造に合わせて事前設定されたExcelテンプレートをダウンロードします。

データテンプレートガイドを見るテンプレートをダウンロード

重要な理由

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

期待される結果

Zendeskの問題追跡にすぐ使えるデータテンプレート。

分析でわかること

根本原因を特定し、問題管理の遅延を解消

ProcessMindはZendeskのワークフローを可視化し、調査が滞る箇所や修正が遅れる原因を明らかにします。最初のチケット登録から恒久対策の完了まで、実際の解決サイクルを把握できます。

解決までの各ステップを可視化
根本原因分析の遅延箇所を特定
修正実施のボトルネックを特定
サポートチーム間の対応の一貫性を測定

Discover your actual process flow

Identify bottlenecks and delays

Analyze process variants

Design your optimized process

実証された成果

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

Zendesk Supportのデータをプロセスマイニングで分析すると、問題解決のボトルネックを特定し、根本原因を的確に分析することで、インシデントの再発を防げます。

0 %

根本原因分析の迅速化

診断時間の短縮

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

0 %

インシデント件数の削減

推奨データ

まず、プロセスマップを明確にするために、特に重要な属性とアクティビティから始めましょう。

イベントログを初めて作成する方はこちら：プロセスマイニング用イベントログの作成方法.

属性

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

問題レコードに設定された緊急度です。

重要な理由

SLA遵守状況やリソースの優先順位を分析するため、ケースの分類に必要です。

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

重要な理由

組織単位の分析や、部門間のボトルネックの特定に役立ちます。

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

重要な理由

個人単位のリソース分析が可能になります。

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

重要な理由

完了状況に応じてケースを絞り込めます。

この問題レコードに関連付けられたインシデントチケットの数です。

重要な理由

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

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

重要な理由

コンプライアンスと契約上のパフォーマンスを測定するために必要です。

問題の分類（例：ソフトウェア、ハードウェア、ネットワーク）。

重要な理由

技術分野やビジネスサービスごとにデータを分けて分析できます。

特定された問題の根本原因（例：コードの不具合、設定エラー）。

重要な理由

障害のパターンを分析し、長期的な改善の方向性を定めるのに役立ちます。

アクティビティ

追跡・改善するプロセスのステップ

Zendesk Supportで問題チケットを新規作成する段階です。問題がシステムに初めて記録された時刻をイベントとして記録し、通常はプロセスの開始点となります。

重要な理由

エンドツーエンドの解決サイクルの開始時刻を定め、その後のリードタイム指標のベースラインとなります。

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

重要な理由

部門間の待ち時間を測定するサポートグループ引き継ぎ分析ダッシュボードに必要です。

受動的な「新規」状態から、対応を開始した状態への移行を示します。担当者が問題を確認し、診断を始めたことを表します。

重要な理由

滞留中の問題レコードに関する指標の算出に使われ、根本原因分析の平均所要時間を示す重要業績評価指標（KPI）の起点となります。

問題に対する一時的な対処方法を文書化し、共有する段階です。Zendeskでは、回避策が利用可能であることを示す専用タグやカスタムチェックボックス項目で記録されることが一般的です。

重要な理由

回避策公開コンプライアンスダッシュボードに反映され、調査が長引く間もユーザーに一時的な対処方法が提供されているか確認できます。

問題の根本原因が特定された段階です。通常、担当者がカスタムの「Root Cause」テキスト項目またはドロップダウンカテゴリに値を入力した時点で記録されます。

重要な理由

根本原因調査の迅速化ダッシュボードに欠かせない節目であり、診断の効率を測定する際にも使われます。

技術的な解決策が環境に導入されたことを示します。通常、チケットが完全に解決される前のカスタムステータス変更や専用タグで追跡します。

重要な理由

診断から導入までの時間を測定する修正導入効率ダッシュボードに必要です。

問題を正式に「解決済み」とする段階です。Zendeskでは、標準のシステムステータスが「解決済み」に設定されると、修正が確認され、ケースが完了したことを示します。

重要な理由

SLAパフォーマンスとリスクの算出、および問題SLA遵守率の主要な終点です。

チケットがロックされ、それ以降変更できなくなるライフサイクルの最終イベントです。Zendeskでは通常、「解決済み」になってから4日後に自動でクローズされます。

重要な理由

レコードのライフサイクルが完全に終了したことを示し、データ保持や過去の実績報告に使われます。

よくある質問

Zendeskの問題管理で、プロセスマイニングはどのように役立ちますか？

プロセスマイニングでは、既存のZendeskイベントログを使って、問題レコードがシステム内を実際にどのように進むかを可視化します。見えにくいボトルネックや標準手順からの逸脱を特定し、調査がどこで滞っているかを把握できます。

分析には、Zendeskのどのデータ項目が必要ですか？

まず、問題レコードID、ステータス変更ごとのタイムスタンプ、ステータス更新や担当変更などのアクティビティ名が必要です。優先度、カテゴリ、担当グループなどの項目があれば、より詳細な絞り込みや根本原因の分析に役立ちます。

このツールを使って、繰り返し発生するインシデントを減らせますか？

インシデントと問題レコードの関係を可視化すると、恒久的に解決されず、回避策で繰り返し対処されている問題のパターンを特定できます。状況が見えることで、関連するサポートチケットをまとめて減らせる、効果の大きい修正を優先できます。

導入後、改善に役立つインサイトはどのくらいで得られますか？

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

引き継ぎの遅れが、どのチームや部門で発生しているか特定できますか？

はい。問題レコードがサポートグループや技術チーム間を移動する状況を追跡できます。引き継ぎが滞る箇所や、レコードが長時間処理されずに残っている箇所を特定し、リソースの配分を見直せます。

プロセスマイニングを利用するために、現在のZendesk設定を変更する必要はありますか？

いいえ。プロセスマイニングは、Zendeskがすでにバックグラウンドで記録している監査ログを分析します。正確な結果を得るために、ワークフローの変更やカスタム項目の追加、担当者の作業方法の変更は必要ありません。

重大な問題のSLA遵守状況を、どのように確認できますか？

各プロセス段階にかかった時間を、設定したサービスレベル目標と照らし合わせてモニタリングします。診断から修復への移行が遅れるなど、SLA未達につながりやすい経路を特定できます。

根本原因を適切に分析せずに、問題レコードがクローズされていることを検知できますか？

アクティビティの順序を分析し、根本原因分析や導入後レビューなどの必須手順を経ずに、レコードが直接クローズされている場合に検知できます。これにより、重大な問題ごとに必要な品質基準が守られているか確認できます。

問題管理を改善し、ITの問題をより迅速に解決

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

無料トライアルを開始しましょう

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