チケットワークフローへのサポートコールは、顧客が電話を切った後にエージェントが覚えていることに依存すべきではありません。

実際の問題が現れるのは電話会議です。

お客様は何が壊れたのか説明します。ブラウザ、アカウント、エラー メッセージ、試した回避策、問題を緊急にする期限について言及します。エージェントは質問をし、仮定をテストし、次のステップを約束します。

そして通話が終わります。

チケットがメモリから始まる場合、有用な詳細がすぐに漏洩し始めます。

その結果、次のようなチケットが作成されます。

「お客様から電話がありました。ログインの問題。調査中です。」

それだけではサポートとしては十分ではありません。

それがパンくずリストです。

電話サポートがチケットとして利用可能になる時期

サポートへの問い合わせをチケット対応の出力に変える

Superscribe Phone は通話をキャプチャし、後でクリーンアップする別のトランスクリプトではなく、レビュー済みのチケット、メモ、フォローアップ、タスク、請求対象のコンテキストに変換するのに役立ちます。

Superscribeを無料で試す 30分無料。カード不要。

ショートバージョン

チケットワークフローへのサポートコールでは、次の 7 つのことを把握する必要があります。

• 顧客の正確な問題
• 影響を受けるユーザー、アカウント、デバイス、システム、または環境
• すでに試した手順
• エージェントが通話中にテストした内容
• 現在の影響と緊急性
• 次の所有者と次のアクション
• 顧客に何を言い返すべきか

通話録音またはトランスクリプトは情報源です。

チケットは機能するコンテキストです。

次のサポート手順は数時間後に、別の人によって別のシステムで実行される可能性があるため、この違いは重要です。チケットに有用な通話コンテキストが含まれていない場合、チームは顧客に同じ質問を再度尋ねる必要があります。

そのため、サポートが実際よりも遅く感じられます。

電話によるサポートチケットが希薄になる理由

サポートへの電話は、チャットやメールと違って面倒です。

顧客は必ずしも問題を順番に説明するとは限りません。彼らは通話の途中でエラー メッセージを覚えていました。最後の近くで、影響を受けた 2 人目のユーザーについて言及しています。彼らは「それは毎朝起こる」と言っていますが、それがパスワードのリセット後に始まったことを明らかにするのは後になってからです。

その間、エージェントは 3 つのジョブを実行します。

• 顧客の話を聞く
• ライブでのトラブルシューティング
• 後で役立つ痕跡を残そうとしている

3番目のジョブは通常負けるものです。

エージェントが不注意だからではありません。

なぜなら、その電話はすでに注意を消費していたからです。

通話の後、別のキュー項目、別の顧客、別のエスカレーション、または約束された更新がある可能性があります。チケットメモはメモリの圧縮バージョンになります。

• 「ユーザーはログインできません。」
• 「プリンターの問題」
• 「VPN がダウンしました。」
• 「お客様がアプリが遅いと言っています。」
• 「開発者に確認してもらう必要があります。」

これらのメモは厳密にはチケットです。

それらは良い引き継ぎではありません。

チケットにはトランスクリプトとは異なる役割があります

トランスクリプトには、話された内容が保存されます。

チケットは次に何が起こるかを説明します。

Zendesk や Jira Service Management などのツールは、チームにフィールド、コメント、ステータス、リクエスト タイプ、内部コンテキストを保存する場所を提供します (Zendesk 開発者ドキュメント, アトラシアンのサポート).

ストレージがボトルネックではありません。

ボトルネックは、詳細が曖昧になる前に、通話を適切なチケットの内容に形作ることです。

有用なサポート チケットは次のような答えを提供する必要があります。

• 何が壊れているのでしょうか？
• 誰が影響を受けますか?
• どれくらいひどいですか？
• どうすればそれを再現したり調査したりできるでしょうか?
• すでに試みられたことは何ですか?
• 次のアクションは何ですか?
• 顧客は次に何を期待していますか?

だからこそ 通話メモはトランスクリプトではありません。トランスクリプトは完成しているかもしれませんが、チケットは使用可能である必要があります。

ワークフロー：通話、構造、レビュー、ルーティング

最もクリーンなサポート コールからチケットへのワークフローには 4 つのステップがあります。

1. 通話をキャプチャする

電話は真実の源でなければなりません。

書きかけのメモではありません。

次の通話後のエージェントの記憶ではありません。

細かい詳細がチケットを変えるため、キャプチャは重要です。 「ログインの問題」は、お客様が、管理対象のラップトップでのみ発生する、SSO 後のみ、ホテルの Wi-Fi に接続している場合のみ、または 1 つの役割のユーザーのみに発生すると言う場合には、まったく異なります。

これらの詳細によって、チケットがパスワードのリセットであるか、ID プロバイダーの問題であるか、ネットワークの問題であるか、権限のバグであるか、または顧客への教育によるものであるかが決まります。

ソースが弱い場合、チケットは弱く始まります。

2. サポートコンテキストを構造化する

生の通話テキストはチケットとしては多すぎます。

チケットには、呼び出しの整形バージョンが必要です。

• 問題の概要: 問題の最短の正確なバージョン
• 顧客への影響: 誰がブロックされているのか、なぜそれが重要なのか
• 環境： アカウント、デバイス、ブラウザ、バージョン、場所、統合、またはシステム
• 症状： 正確な動作、エラー、タイミング、またはパターン
• 試した手順: 顧客とエージェントがすでにテストしたもの
• 再現の手掛かり: 何が再びそれを引き起こすのか
• 次のアクション: 所有者、アクション、および予想される更新
• お客様向けのメモ: 顧客が次に聞くべきこと

これは、サポート コールを誰かが対応できるチケットに変えるレイヤーです。

3. チケットがチームの思い出になる前に確認する

生成された生のメモをチケット キューに直接プッシュしないでください。

サポートへの問い合わせには、推測、機密性の高いアカウントの詳細、不満、部分的な診断、およびプライベートな内部メモが含まれることがよくあります。チケットは、すべての文を公式の歴史に変えることなく、有用なコンテキストを保存する必要があります。

レビューでは次の違いを確認します。

• 「SSO が壊れています。」
• 「顧客から 2 人のユーザーの SSO ログインが失敗したと報告がありました。ID プロバイダーのログを確認する必要があります。」

1つは証明されていない結論です。

もう1つはサポートチケットです。

4. 作業が行われる場所に出力をルーティングする

チケットは、チームが実際に作業するシステムに到達する必要があります。

サポートの問題の場合は、チケットを作成または更新します。エンジニアリングが必要な場合は、再現手順と影響を含めます。顧客の成功が必要な場合は、期待と約束された更新を維持します。請求可能なサポート時間が発生する場合は、その理由を新しいうちに保管してください。

これは強いものの背後にあるのと同じパターンです ビジネスコールのフォローアップワークフローの背後にある同じ論理です。顧客が電話を切った時点では、通話は完了していません。有用な出力が次のワークフローに到達すると完了です。

実用的なサポート チケット テンプレート

通話後にチケットを手動で書き込む場合は、これを使用します。

問題の概要:

顧客への影響:

影響を受けるユーザー、アカウント、またはシステム:

環境:

症状:

すでに試した手順:

再現の手掛かり:

次のアクション:
- 所有者:
- 期限または更新時間:

お客様向けの更新:

内部コンテキスト:

こちらが記入済みのバージョンです。

問題の概要:
ユーザーは管理対象ラップトップから SSO ログインを完了できません。

顧客への影響:
財務責任者は、今日の終了前に請求書の承認をブロックされています。

影響を受けるユーザー、アカウント、またはシステム:
アクメアカウント。ユーザー: 財務責任者。デバイス: 会社の MacBook。

環境:
クロム。 Office Wi-Fi とモバイル ホットスポットの両方をテスト済み。

症状:
ログインは SSO にリダイレクトされ、空白のページでアプリに戻ります。パスワードエラーは表示されません。

すでに試した手順:
ブラウザのキャッシュをクリアしました。シークレットモードで試してみました。同じアカウントの別のユーザーがログインできることを確認しました。

再現の手掛かり:
昨日、顧客の IT 部門が ID プロバイダーのルールを変更した後に開始されました。

次のアクション:
- 所有者: サポートは ID ログのレビューにエスカレートします。
- 更新期限または更新時間: お客様は 2 時間以内の更新を期待しています。

お客様向けの更新:
SSO ハンドオフを確認中です。午後 3 時までに最新情報をお知らせします。

内部コンテキスト:
請求書の承認がブロックされるため、時間に敏感です。まだアプリの停止が確認されているとは考えないでください。

そのチケットが次の人にスタート地点を与えます。

また、顧客が通話全体を繰り返すことも防止されます。

チケットに入れてはいけないもの

優れたサポート チケットはゴミ捨て場ではありません。

省くべき内容:

• 次のアクションに影響を与えない長いトランスクリプトセクション
• 事実として書かれた推測
• 電話による感情的なフィラー
• 必要のない顧客の個人情報
• 内なる責任
• 未確認の根本原因

チケットは具体的である必要がありますが、騒々しいものであってはなりません。

後で完全な通話記録が必要になった場合は、ソース資料として保管してください。メインチケットには、すぐに使えるバージョンが含まれている必要があります。

Superscribeの役割

Superscribe Phoneは、作業を生み出す通話のために作られています。

これは、サポート チームや小規模サービス オペレーターの場合、通話がレビュー済みのチケット メモ、タスク、フォローアップ、CRM アップデート、エスカレーション コンテキスト、または請求対象のサポート トレイルになる可能性があることを意味します。

重要なのは、より見栄えの良いトランスクリプトを作成することではありません。

ポイントは、電話から役立つチケットまでの経路を短縮することです。

通話により電話システムの外部で作業が発生すると、Superscribe Desktop が次の層をカバーします。エンジニアリングの引き継ぎ、顧客の最新情報、社内メモ、または請求書の説明を、それが属するフィールドに直接書き込むことができます。

呼び出しによってコンテキストが作成されます。デスクトップディクテーションはフォロースルーをキャプチャします。

同じ理由でその橋は重要です サポートコールからの自動インシデントレポート 案件。サポート作業は、引き継ぎが完了するかどうかによって決まります。

次のサポート コールがこのサポート コールを上書きする前に

チケットのコンテキストを新しいうちにキャプチャします

次のように使ってください Superscribe Phone サポート コールをレビュー済みのチケット、メモ、フォローアップ、および請求対象のコンテキストにする必要がある場合。

Superscribeを無料で試す 30分無料。カード不要。

よくある質問

サポート コールからチケットへのワークフローとは何ですか?

サポート コールからチケットへのワークフローは、電話によるサポートの会話をキャプチャし、有用な問題のコンテキストを抽出してレビューし、それを所有者と次のステップとともにチケット システムにルーティングします。

通話記録だけでサポート チケットとして十分ですか?

通常はそうではありません。トランスクリプトには会話が保存されますが、チケットには簡潔な問題の概要、影響、環境、トラブルシューティングの履歴、再現の手掛かり、および次のアクションが必要です。

電話によるサポート チケットには何を含めるべきですか?

これには、問題、影響を受けるユーザーまたはシステム、顧客への影響、症状、すでに試行された手順、再現の手掛かり、所有者、次のアクション、および顧客向けの更新が含まれている必要があります。

サポート チケットは通話から自動的に作成されるべきですか?

自動的にドラフトすることもできますが、重要なチケットはチームの記憶に残る前にレビューする必要があります。レビューでは、未検証の診断、機密性の高い詳細、不明確な約束を見つけることができます。