通話メモはゴールではありません。
それらが原材料なのです。
役立つ部分は、メモが誰かが実際に実行できるタスクになるときに発生します。クライアントが提案書の修正を求めてきました。リンクを送信することを約束します。チームメイトは統合をチェックする必要があります。サポートの問題にはチケットが必要です。それは要約のどこかに出てくるので、どれも終わっていません。
メモは仕事にならなければなりません。
これがタスクへの通話メモの背後にある本当の仕事です。会話から次のステップを取り出し、それらに所有者を与え、欠落しているコンテキストを追加して、忘れられない場所に保管します。
通話メモを仕事にすべきとき
電話をレビューされたタスクとフォローアップに変える
Superscribe Phone は、次の電話ですべてが頭から追い出される前に、ビジネス通話を概要、タスク、フォローアップ、CRM コンテキスト、チケット、請求対象の詳細に変換するのに役立ちます。
ショートバージョン
タスクへの通話メモのワークフローを適切に行うには、次のことを把握する必要があります。
- 次に何をすべきか
- 誰がそれを所有しているのか
- 誰がそれを要求したのか
- クライアント、プロジェクト、取引、チケット、またはそれが属するアカウント
- 期日または約束のタイミング
- 送信すべきフォローアップメッセージ
- 阻害要因、リスク、または未解決の質問
- 呼び出し後にタスクが存在する場所
このタスクは、通話に参加していない人にとっても理解できるものでなければなりません。
「クライアントのフォローアップ」とのみ表示されている場合は、ワークフローは失敗しています。それは任務ではありません。これは、別の人が通話を再構築する必要があることを思い出させます。
電話メモがタスクリストとして機能しない理由
ほとんどの通話メモには会話の順序が保存されます。
タスクは会話の順序どおりには機能しません。
クライアントは 4 分で実際の依頼について言及し、11 分で範囲を変更し、20 分で期限を追加し、全員が別れを告げているときに所有者に確認する可能性があります。トランスクリプトにはそのすべてが含まれます。通常の要約では、そのすべてが記載される場合もあります。
ただし、タスクには整形されたバージョンが必要です。
輸入リスクに関するメモと新しい SSO 要件を含む、改訂されたオンボーディング チェックリストを木曜日までに Priya に送信します。
それは使えるんです。
タスクには、所有者、受信者、期日、およびタスクがあいまいな ToDo アイテムにならないようにするコンテキストが含まれています。
これは背後にある同じ問題です アクションアイテムへのコールトランスクリプト。トランスクリプトはすべてを保存することができますが、次のステップは不明のままになります。
タスクには宛先が必要です
「タスクを作成する」ということは、どこに行えばよいのか尋ねるまでは簡単そうに思えます。
1 回の呼び出しで、いくつかの異なる種類の作業が生成される可能性があります。
- 配信チームのプロジェクトタスク
- アカウント履歴の CRM メモ
- 応援チケット
- クライアントへのフォローアップメール
- 期限のカレンダーリマインダー
- 後で使用する範囲または請求書
これらは同じオブジェクトではありません。
すべてが 1 つの一般的なタスク リストに収まった場合でも、チームは後でそれを並べ替える必要があります。より良いワークフローは、通話コンテキストがまだ新しいうちに宛先を決定することです。
コンサルタントにとって、それはクライアントの約束がプロジェクト委員会に反映され、アカウントのコンテキストが CRM に反映され、フォローアップ メールの草案が即座に作成されることを意味するかもしれません。
IT サポート チームの場合、トラブルシューティングの詳細はチケットに含まれ、顧客の更新情報は返信スレッドに含まれます。それが理由です サポート通話メモ 単純な要約よりも詳しい構造が必要です。
便利な構造
通話メモをタスクに変換する場合は、このチェックリストを使用してください。
1. コミットメントを抽出する
約束、要求、決定、妨げとなるもの、未解決の質問を探します。
例：
- 「金曜日までに最新の価格を送ってもらえますか？」
- 「SSO がこの設定をサポートしているかどうかを確認するエンジニアリングが必要です。」
- 「権限の問題についてサポート チケットを開きます。」
- 「見積もりが 4 時間以内であれば次に進みましょう。」
これらは単なる通話の文章ではありません。
それらは住む場所を必要とする約束なのです。
2. 不足しているフィールドを追加します
タスクはメモリに依存すべきではありません。
ツールに導入する前に、以下を追加します。
- 担当者
- クライアントまたはアカウント
- プロジェクトまたはチケット
- 期日
- ソースコール
- 短い文脈メモ
- 次に目に見えるアクション
弱点:
- SSOを確認してください。
役立つ：
- アレックスは、木曜日のオンボーディング コールの前に、Acme の SSO 設定が請負業者のアカウントをサポートしているかどうかを確認します。 Acme 実装チケットに回答を追加します。
2 番目のバージョンでは再構築作業が削除されます。
3. タスクとメモを分離する
役立つ詳細がすべてタスクになるわけではありません。
一部の詳細は参照コンテキストです。
- クライアントは Slack よりも電子メールを好みます
- 予算承認は財政を待っている
- 本番環境の問題はパスワード ポリシーの変更後に始まりました
- 関係者は移行のタイミングを心配しています
これらの詳細は、メモ、CRM レコード、チケット、またはアカウント履歴に残る必要があります。すべてをタスクにしてしまうとノイズが発生します。
最適なワークフローは以下を分離します。
- タスク、誰かが行動しなければならないため
- メモ: 誰かがコンテキストを必要とする可能性があるため
- クライアントは応答を期待しているため、フォローアップ
- ビジネスには履歴が必要なので、記録します
この分割により、通話メモが別のテキストの山ではなく、有用な作業出力になります。
リアルタイム キャプチャが役立つ理由
次の通話が始まるのが早すぎるため、通話後のクリーンアップは脆弱です。
記憶が鮮明なまま電話を切ります。 10分後、別のお客様から電話がありました。昼食までに、2 つのデッドラインと 1 つのブロッカーが融合しました。
リアルタイム キャプチャでは、詳細が最新である間に通話がすでに形成されているため、この変更が行われます。コンテキストが失われる前に、タスク リストを確認し、所有者を修正し、フォローアップを送信できます。
それは、すべてのタスクをやみくもに自動化する必要があるという意味ではありません。
これは、メモリから通話を再構築する前に、最初のドラフトが存在する必要があることを意味します。
それも理由です クライアント通話メモ ソフトウェア 重要です。キャプチャ手順は、会話後に通常発生する管理作業を軽減する場合にのみ価値があります。
シンプルな通話メモとタスクのテンプレート
各クライアント呼び出しの後に、次の出力を作成します。
通話概要
クライアント、トピック、決定事項、現在の状態を 1 つの段落で説明します。
タスク
各タスクには以下を含める必要があります。
- 担当者
- アクション
- クライアントまたはプロジェクト
- 締切
- 行き先
- ソースコンテキスト
フォローアップドラフト
何が合意されたか、次に何が起こるか、各ステップの所有者が誰であるかを確認する短いメッセージ。
CRM、チケット、またはプロジェクトのメモ
タスク リストを超えて存続する必要がある耐久性のあるコンテキスト。
これにより、1 回の呼び出しから 4 つの有用な出力が得られます。タスクリストはそのうちの1つにすぎませんが、次のステップが消えてしまうことを防ぐものです。
Superscribeの役割
Superscribe Phone は、ビジネス電話の後、会話を仕事にしなければならない瞬間のために作られています。
目標はトランスクリプトを保存することだけではありません。
目標は、通話が意味をなすうちに、通話をレビュー済みのメモ、タスク、フォローアップ、CRM コンテキスト、チケット、請求対象の詳細に変えることです。
それが、「通話メモがどこかにある」と「次のステップがすでに始まっている」の違いです。
電話の多い仕事の場合
通話後のタスクリストの再構築を停止する
Superscribe Phone を使用すると、詳細が薄れる前に、通話メモをタスク、フォローアップ、およびワークフロー対応のコンテキストに変換できます。