若くて経験の浅い企業や、大きくて堅い企業では、次の3段階のエラーが原因でサポートの問題が発生します。
1.控訴に同意する
2.申し立てを処理する
3.統計を取る。
今日、私たちは、軽率な実装が得意と思われる良いアイデアが失敗であることが判明した場合に、リクエストの受信を整理する際の3つの典型的な間違いを分析します。
サイトにアドレスを書きましょう
顧客の考え：顧客が住所を選択し、目的の部門にすぐに書き込めるようにします。 そうすれば、内部でお互いに手紙を送る必要がなくなり、ルーターとして働く別の人も必要なくなります。 そして、上司の住所を公開します。苦情があれば、顧客は直接書くことができます！
ここでは、クライアントのさまざまな部門でルーティングをハングアップしました
実際：決して。 なりません。 あれ。 そして、そうなります。 サイトのクライアントは多数のアドレスを見、迷子になり、最終的にどこにでも書き込みます。 従業員は引き続き部署から部署に手紙を送り、1日あたりの労働時間に30分を費やしています。 同時に、部門のすべての専門家が、手紙が誰に宛てられ、間違った場所に送られたかを知っているわけではありません。 それは技術サポート部門に必要であり、通常のサポートに送られました。 または、2回送信します。通常のOutlookでは、同僚が1時間前にこの手紙を経理部に送信したことは表示されません。 したがって、必要な手紙は失われ、問題は解決されず、顧客は怒っています。
その後、チーム内の松葉杖が発明され始めます。 または、別の部門に異動する場合、私たちの部門全体をコピーに入れて、手紙が転送されたことを確認しますか？ そして、数時間の会議をまとめて、どの文字を誰に送信するかを話し合い、形式とタイミングを決定しましょう。 これはすべてでたらめであり、動作しません。
サイトに電子メールのリストがある場合、間違いを犯して間違った受信者を選択するのは簡単です。 たとえば、ウェブサイト：「会計-支払いの問題」。 そして、質問がある場合-私の関税でいくら支払うべきですか？ 支払いに関するものですか、それとも一般的な情報ですか？ 明確ではありません。 クライアントは、どの「支払いの問題」が会計に関係しているかをどのように知るのか。
方法： 1つのエントリポイント-クライアントに最適。 彼には、書き込み先のアドレスを把握する時間がありません。 彼に1つの明確なメールを送ってください。 すでに手紙を分析しているので、クライアントは気にしません。
-そして、誰が手紙を転送しますか？ それで、私たちは到着した主題に関する手紙の少なくとも一部を持っています！
外部からのリクエストが別の部門に届く場合、正しい配布への最初のステップは、リクエストの件名を選択して、多数のアドレスを返信フォームに置き換えることです。 選択したトピックに応じて、目的の部門の電子メールにこのフォームを選択します。
部門の電子メールのリストではなく質問のリストをクライアントに表示することにより、クライアントの頭で定式化された問題を提案されたトピックに関連付けるのに役立ちます。 これは、クライアントの言語での会話です。
OBIオンラインストアからのフィードバック-多くのトピックがありますが、選択すると便利です
トピックを正しく作成すれば、ルーティングのエラーが少なくなります。 しかし、まだ間違った手に落ちたそれらの手紙をどうするか？
2番目のステップは、チーム内の文字のリダイレクトを麻酔することです。 これを行うには、1つのプログラムですべての顧客の問題に対処する必要があります。 他のレシピはありません。 すべての従業員が応答を必要とするすべての要求を入力および表示するプログラムのみ。 ここでは、ソリューションのチェーンを見ることができます。 ここでは、どの部署で質問が行き詰まっているかを確認できます。 最初の行のサポートチームが既にヘルプデスクで作業している場合でも、Outlook、Skype、Slackなどの2番目の行に質問を送信します。 ヘルプデスクでは、決定の終わりは見えません。 Outlookの2行目-コミュニケーションの始まりは見えません。 そのため、クライアントが最初の行に再度書き込みを行ったときに、ソリューションのステータスのプロンプトは表示されません。
Yuzdeskに質問を委任するために、グループまたは特定の従業員に割り当てる機能があります。 これは1つのボタンにすぎません-要求が見失われることはありません。 サポートのみが顧客の質問への回答を支援する部門であり、これは彼らの主要な活動ではないため、プログラムで作業して要求が割り当てられるのを待つ必要はありません。 メールでの作業に使用-再学習する必要はありません。 メールで通知を受信し、メールから返信できます。 コメントは目的のリクエストにプルされ、チェーンは1か所に保存されます。
内部コメントは、他の部門とのコミュニケーションのチェーンを1か所に保つのに役立ちます
3番目のステップは、顧客の問題のルーティングを自動化することです。 これを行う方法については、自動化に関する記事で説明しました。
顧客とのより多くのコミュニケーションチャネルが必要
彼らの考え：ソーシャルネットワークでグループを作成し、Telegram、Votsap、Viberでアカウントを作成し、サイトでチャットします。 顧客はそれを好むでしょう、彼らは今彼らが好きなように連絡することができ、私たちは彼らに選択肢を与えます、庭で21世紀 これは競合他社とは大きく異なります。
実際 、VK のグループには代理店にSMMを実施するタスクが与えられましたが、1つの質問に明確に答えたり、顧客をサポートメールに送ったりすることはできません。 このことについては、この研究でさらに詳しく話しました。
せいぜい1日に1つのメッセージがメッセンジャーに届きます。最悪の場合、従業員は複数のタブの間で破れ、サイトの知識ベースにある典型的な質問に答えます。 しかし、なぜ愚かな顧客はそれを読まないが、すぐにサポートに書き込みます。 他の部門に対処する必要がある質問については、一般的にはごみです。
クライアントはTelegramに書き込みます。
-サイトに500エラーがあり、支払いができません。
-画面を送ってください！
-ここ。
-ありがとう、私たちはそれを私たちの技術部門に渡し、あなたに手紙を書きます。 後で支払うようにしてください..
さらに内部では、これが起こります。 従業員が郵便で技術部門に手紙を書きます。 注意する時間はすでにあります-テレグラムから、問題に関するコミュニケーションが別のチャネルにこぼれました。 最良の場合、従業員はリマインダーをどこかに設定し、技術部門を「蹴る」ことを忘れないように、最悪の場合、「TECHOTDEL、1時間でチェック」という紙に自分自身を書きます。 技術部門はすでに3月8日を祝っており、翌日には手紙が届きます。 その後、従業員と技術部門の間の通信が開始されます。この通信は、いつでも「誰かが手紙を見なかったが、私たちは答えた」という事実によって中断されます。
一方、クライアントは再び書き込みを行っていますが、彼のエラーは消えていません。 メッセージは別の従業員に届きますが、技術部門で既に問題が解決されていることを彼は知りません。 そして再び彼は手紙を書きます。 次は何だと思います。
方法：クライアントは、どのチャンネルに連絡するかを気にしません。 彼にとっての主なことは、問題を解決することです。 3日以内にはお勧めしません。 電話のみで作業する方法を知っている場合は、電話で電話を受けます。 顧客と話す方法がわからない場合は、郵便局のみに手紙を書きましょう。 従業員がそこですぐに答えられない場合のメッセンジャーまたはチャットの使用とは何ですか？ お客様は新しいコミュニケーションチャンネルに喜んでいただけることを期待しており、これらのチャンネルが単なる装飾である場合にのみ、顧客は不満を感じるでしょう。
ファッショナブルなチャネルでメッセージを受信するだけでなく、問題を解決するには、さまざまなメッセンジャー、チャット、メール、電話でクライアントとの通信の履歴が必要です。 2番目のタスクは、オンラインでは解決できない「長い」問題の対処方法を見つけることです。
これを行うために、YuzdeskをTelegram、Viber、Facebook、およびVkontakteメッセンジャーと統合しました。 さまざまなメッセンジャーからのメッセージは、単一のオペレーターウィンドウに入り、自動的にリクエストになります。 さらに、リクエストを別の部門に再割り当てし、オフラインで解決できます。
チケット番号はお客様に送信する必要があります
彼らの考え：チケット番号が記載された電子メールの受信について、自動返信をクライアントに送信します。 申し立てが既に登録されていることをクライアントに知らせます。 彼は私たちをもっと信頼するでしょう。 そして、彼が電話して尋ねたとき-私のチケット番号100500はどうですか、すぐにチケットを見つけて答えます！
実際、誰も単語チケットを知らず、その番号をどこで探すべきかを知りません。 会社の注文番号、バウチャー番号、請求書番号、住宅ローン、取引、その他の内部識別子と同じ方法で。 クライアントが尋ねる：どこを見るか、検索するか、検索するか、検索するか、「折り返し電話します」が見つからず、カートはそのままです。 その結果、サポートは問題の解決により多くの時間を費やします。
方法：自動返信では、クライアントが答えを待つ時間をより適切に通知して、心配せずに手紙を投げるようにします。
クライアントが再度連絡する場合は、すぐに電話をかけるデータ（名前、電話番号、電子メール、質問）でクライアントを識別します。 あなたの識別子を覚える必要性からクライアントを取り除きます。 ストーリーがクライアントのプロファイルの1か所に保存されている場合、誰といつクライアントと通信したかに関係なく、適切な治療法を簡単に見つけることができます。
チケット番号をクライアントに送信することは、それがあなたのプロセスに役立つだけであり、顧客の印象を傷つけない場合、犯罪ではありません。 チケット番号を使用したシステムが会社に定着した場合、件名を変更せずに番号を呼び出して手紙に答えるように顧客に教えました。握手します。
私を覚えて
- サイトに複数のメールを表示しないでください。 質問のトピックをクライアントの言語で定式化し、フィードバックフォームに追加します。 ヘルプデスクで既に内部のルーティングを自動化します。
- すべてのチャネルの呼び出しは、1つのシステムに保存する必要があります。 古い通信チャネルでプロセスを確立するまで、新しい通信チャネルを追加しないでください。
- あなたにとってではなく、彼にとって都合の良いクライアントを特定してください。