サポートプロセスでは何が繰り返されるのか？
01
リクエストの受け付け
どのような形で届いても、1つの形式に統一する必要があります。自由形式のメッセージでは優先順位付けできません。
02
分類と優先度付け
件名と緊急度が設定される前に割り当てることはできません。すべてが緊急のキューはキューではありません。
03
割当
チケットには担当者が必要です。「誰かが」対応するのに放置されたチケットは、結局誰も対応しません。
04
SLA追跡
初回応答時間と解決時間が契約上の義務であれば、測定する必要があります。測定されない約束は守られません。
05
解決とナレッジ
同じ問題が再度発生したとき、以前の解決策を見つけられる必要があります。
06
フィードバック
クローズ後の満足度調査は、サービスが実際に改善したかどうかを示す唯一のデータです。
今日、どこが破綻しているのか？
チケットが受信トレイに散らばっている
共有メールアドレスへのメールはキューを形成しません。誰が何を担当しているのか分からないため、二重対応や未対応が生じます。
何も測定されていない
「4時間以内に返信」と言われていても、実際には測定されていないため、実際の対応時間は不明です。
同じ質問が2回解決される
先月解決した問題が今月また調査されます。解決策がその人の頭の中にとどまっているからです。
業務負荷が見えない
誰が何枚のチケットを抱えており、誰が溺れているのかは、聞いてみるまで分かりません。
Tenderely BPMで何が変わるのか？
01
チケットは構造化データになる
公開フォームがすべてのリクエストを統一した形式で収集します。件名、添付ファイル、ビジネスへの影響（影響を受けるプロセス、ユーザー数、回避策、期限）がフィールドとなります。AIがこれらの回答から優先度を設定し、不確実な場合はマネージャーが選択します。
02
システムがSLAを計測する
ステップに期限が設定され、期限切れまぢかのチケットと既に超過したチケットが分離されます。営業期限の前日にリマインダーが送信されます。
03
すべてのチケットに担当者がいる
ロールまたは個人に割り当てられ、放置されることなく、引き継ぎ時も履歴とともに移行します。
04
履歴が検索可能である
クローズされたチケットは記録に残るため、類似の問題が以前の解決策を見つけられます。
05
リクエスター自身が追跡できる
顧客または従業員がリンクされた外部ユーザーとして接続し、自分のチケットのみを見て、移行時にメール通知を受け取ります。
よくある質問
リクエストはメールで届くことはできますか？
+
公開フォームリンク、またはウェブサイトに埋め込まれたフォームが、リクエストを統一した形式で収集し、プロセスに直接ドロップします。インバウンドウェブフックを使用して外部システムからチケットを開くこともできます。
SLAは件名によって異なるようにできますか？
+
はい。条件付き分岐により、緊急度または顧客タイプに応じて異なる期限を設定でき、期限超過まぢかのチケットは自動的に警告を発します。
社内サポートに使用できますか？
+
はい。同じ構造はIT、HR、施設管理などの社内デスクとして機能し、ユニットおよびロールレベルの権限によってどのチームがどのリクエストを見るかが決定されます。