顧客とサービス
顧客、連絡先、影響を受けた製品、注文、サービスを選択または特定します。
カスタマーサポート受付フォーム
トリアージに十分な情報を提供するカスタマーサポートチケットフォーム
顧客には発生事象と影響を尋ね、優先度、担当、社内ルーティングはサービスチームが決めます。
適切な受付により、顧客に組織図を理解させることなく、最初の確認の往復を減らせます。
JodooのFreeプランなら最大5ユーザーで始められます。クレジットカードは不要です。
- IDを再入力せず、稼働中の顧客レコードを選択
- 顧客の言葉で影響と緊急度を確認
- 同じ案件をキュー、更新、解決履歴へ連携
サンプルデータ入りのサポートチケット10件新規、待機、期限間近、目標超過、エスカレーション済み、解決済み、再開の案件。導入後に調整アプリを作り直さずに、項目、ルート、ビュー、ダッシュボードを変更します。
- 01顧客を特定
- 02問題を説明
- 03影響を説明
- 04有用な証拠を添付
- 05トリアージへ送信
- 06明確な次の手順を受け取る
社内判断の前に、観察可能な事実を尋ねる
フォームは入力を完了できるほど短く、不要なやり取りを防げるほど十分な情報を得られるものにします。
問題概要
サービスチームがキューを確認しやすいよう、平易な一文で記載します。
発生したこと
手順、期待した結果、実際の結果、顧客がすでに試したことを記録します。
影響、緊急度、証拠
誰が影響を受けているか、何が妨げられているか、いつまでに支援が必要かを尋ね、必要に応じてスクリーンショットやファイルを添付してもらいます。
顧客にチケットの振り分けをさせない
顧客向け項目と担当者向け項目は、読む人が異なります。
社内担当者を尋ねない
顧客が、どのチームや専門家が案件を引き受けるべきか知っていることはほとんどありません。
技術的な重大度を尋ねない
影響と緊急度を確認し、サービスチームがポリシーとアカウント情報に基づいて優先度を決めます。
非公開メモを見せない
社内調査、商取引上の背景、スタッフ間の議論は、顧客向け更新と分けます。
期待値は明確にする
送信後、受け付けた内容、応答予定時期、更新の共有方法を説明します。
フォームは、責任ある作業を開始して初めて役に立つ
確認メールだけではサービスプロセスになりません。送信されたレコードは見えるキューに入り、責任ある担当者が割り当てられ、次回の顧客向け更新予定を持つ必要があります。必要情報が不足している場合も、元の問題、証拠、送信時刻を失わずに追加情報を依頼できるようにします。
検証
顧客と、開始に十分な背景を確認します。元の送信内容を保持したまま、不足している確認事項を記録します。
トリアージ
顧客に社内の重大度ルールを理解させるのではなく、顧客が示した影響と緊急度を用いてカテゴリ、優先度、サービスポリシーを適用します。
割り当て
作業開始前に責任が見えるよう、チーム、担当者、次の対応を明示します。
更新
現在の状況、チームがまだ必要としている情報、次回確認の予定を顧客へ伝えます。
確認
解決が有効だったか、顧客への影響が続いているか、同じ案件を再開すべきかを記録します。
カスタマーサポート受付フォーム に関する質問
カスタマーサポートチケットフォームにはどの項目が必要ですか？+
顧客、連絡先、影響を受けた製品またはサービス、問題概要、発生事象、影響、緊急度、すでに試したこと、証拠が、顧客向け項目の有力な基準です。
フォームで優先度を尋ねるべきですか？+
通常は顧客に影響と緊急度を尋ねます。サービスチームがポリシー、アカウント情報、現在の対応余力に基づいて優先度を決めます。
フォームの長さはどの程度が適切ですか？+
最初の受付は要点に絞ります。カテゴリ固有の詳細には条件付き項目を使い、必要に応じてトリアージ後により深い技術資料を収集します。
送信後はどうなりますか？+
チケットを作成し、受付を通知し、担当と約束を設定し、適切なキューへ入れ、次回更新を明確にします。
Jodooで問題種別ごとに異なる質問を表示できますか？+
はい。管理者は項目の条件表示を設定できますが、各経路で必要な項目だけが表示され、不要な項目が非表示になることをテストしてください。
完全なサービスサイクルを試す
サポートチケットフォームを使う実際のサービス作業を開始するフォームを顧客に提供
稼働中のフォームを開き、顧客向けの質問を確認し、送信されたチケットが担当、更新、解決へどう進むかを見ます。