担当者未定
ルールに一致しなかった新規チケットや、振り分け先に技術担当者がいないチケットを確認します。割り当て結果を明記したうえでトリアージキューに残すため、担当者が空欄のまま見落とされるのを防げます。
従業員の問題を受け付けて担当者を割り当て、待機、解決、再オープンまで対応を追跡します。
サンプルデータで試せます。フィールド、ビュー、ワークフローをチームに合わせて調整してください。
ルールに一致しなかった新規チケットや、振り分け先に技術担当者がいないチケットを確認します。割り当て結果を明記したうえでトリアージキューに残すため、担当者が空欄のまま見落とされるのを防げます。
従業員への情報確認待ちとベンダー対応待ちを区別します。待機開始時刻、不足情報、フォローアップ担当者を記録します。
解決内容を残し、従業員が業務を再開できるか確認します。解決の記録と、確認を経たクローズは別の段階です。
理由を記録して問題を再オープンし、次の対応サイクルへ進めます。関連のない重複チケットを作らず、以前の解決内容と作業履歴を維持します。
「会議室のディスプレイに信号が届かない」という報告も、部屋、支障のある業務、影響、従業員が試したことが分かれば対応に着手できます。
振り分けルールがチームと、設定されていれば担当者を選びます。実質的な初回応答は、その後の進捗メモとは分けて記録します。
各対応に判断の理由を残します。担当変更には新しいチーム、担当者、変更理由を記録し、作業レコードには実際の所要時間を分単位で記録します。
修正内容と解決時刻を記録し、確認のうえでクローズします。不具合が再発した場合は、新たな症状を添えて同じチケットを再オープンします。
| 報告された影響 | 優先度 | 判断の理由 |
|---|---|---|
| 1人に影響・業務継続可能 | 低 | 業務を妨げない質問は、障害への対応を優先してから対応できます。 |
| 1人に影響・業務に一部支障 | 通常 | 限定的な支障を広範囲の障害と同じ扱いにせず、応答を計画します。 |
| 業務停止、または拠点全体に影響 | 高 | 業務を停止させている問題に、明確な担当者と応答目標を設定します。 |
| 拠点全体で業務停止 | 緊急 | 広範囲の業務停止をすぐに把握できるようにします。 |
このサンプルは、社内の従業員とシェアードサービスチーム向けです。顧客サポート用の標準受信トレイ、メール会話の同期、コンタクトセンター向けの各種チャネルは備えていません。
チケットはトリアージキューに残り、ルール不一致の結果が記録されます。サポート責任者が手動で割り当て、今後のチケットに適したルールを追加できます。
広く閲覧できるサポートキューに、機密性の高い従業員情報を入れないでください。機微な情報を収集する前に、別アプリを使うか、レコードとフィールドの権限を慎重に設定し、許可された人事(HR)担当者だけがアクセスできるようにしてください。
チケットのポリシーで認められた待機理由の場合だけ、解決時間の計測を一時停止します。サンプルのポリシーでは従業員からの情報待ちは対象ですが、ベンダー待ちは対象外です。初回応答と解決の時間は別々に計測します。
はい。再発した理由を記録します。以前の作業はチケット履歴に残り、新たな解決サイクルの営業時間内の時間を加算します。クローズしていた期間は対応時間に含めません。
このサンプルでは作成されません。従業員はJodooの問題報告フォームを使います。メールやほかのチャネルからの取り込みには別途連携設定が必要です。標準の共有受信トレイが主な要件なら、パッケージ型ヘルプデスクを選んでください。
サンプルのキューを開き、社内サポートチームに合わせてカテゴリ、担当範囲、対応レコードを調整してください。