← Tenderely BPM
モジュール
ヘルプデスク とサポートチケットを 一つのフローで管理
サポートがメール経由で届いても、常に欠けているものが二つあります。誰がそのリクエストを担当しているのか、そしてどのくらい待機しているのか、です。インボックスはキューではありません。Tenderely BPM はリクエストをレコードに変え、担当者を割り当て、システムが時間を計測できるようにします。
サポートプロセスで何が繰り返されるか？
01
リクエストの受け取り
どのような形で届いても、一つの形式に統一する必要があります。自由形式のメッセージは優先度が付けられません。
02
分類と優先度
件名と緊急度が設定されるまで割り当てはできません。すべてが緊急のキューはキューではありません。
03
割り当て
チケットには担当者が必要です。「誰かに」任せたものは誰の責任にもなりません。
04
SLA 追跡
初回応答と解決時間が契約上のものであれば、測定する必要があります。測定されない約束は守られません。
05
解決とナレッジ
同じ問題が再び発生したとき、以前の対応が検索可能である必要があります。
06
フィードバック
クローズ後の満足度質問は、サービスが実際に改善したかを示す唯一のデータです。
現在、どこで破綻しているか？
チケットはインボックスに分散している
共有アドレスへのメールではキューが形成されません。誰が何をしているか不明なため、同じものが二度応答されたり、返信されなかったりします。
何も測定されていない
「4 時間以内に返信します」と言われても、測定されないため、実際にどのくらい時間がかかるか不明です。
同じ質問が二度解決されている
先月解決した問題が今月もう一度調査されます。対応方法が誰かの頭の中に留まっているからです。
ワークロードが見えない
誰がいくつのチケットを担当しているか、誰が負担過剰か、は聞かないと分かりません。
Tenderely BPM で何が変わるか
01
チケットは構造化データになる
公開フォームはすべてのリクエストを一つの形式に統一し、件名、緊急度、添付ファイルをソート可能なフィールドにします。
02
システムが SLA を計測する
ステップには期限が付き、SLA 超過が近いチケットと既に超過したチケットは分けて表示されます。
03
すべてのチケットに担当者がいる
ロールまたは個人に割り当てられ、放置されず、引き継ぎ時に履歴とともに移動します。
04
履歴は検索可能である
クローズされたチケットも記録に残るため、類似の問題は以前の解決方法を見つけられます。
05
リクエスター自身が自分のチケットを追跡できる
顧客または従業員がリンクされた外部ユーザーとして接続し、自分のチケットのみ表示され、メールで通知されます。
よくある質問
リクエストはメール経由で届くことはできますか？
+
公開フォームリンク、またはウェブサイトに埋め込まれたフォームは、リクエストを一つの形式で集め、プロセスに直接落とし込みます。インバウンドウェブフックで外部システムからチケットを開くこともできます。
SLA は件名によって異なりますか？
+
はい。条件付き分岐は緊急度または顧客タイプで異なる期限を設定し、SLA 超過が近いチケットは自動で警告を発します。
内部サポートに使用できますか？
+
はい。同じ構造は IT、HR、施設管理などの内部デスクとして機能し、ユニットおよびロール単位の権限で、どのチームがどのリクエストを見るかを決定できます。