クライアントからの電話で 5 分以内にプロジェクトを変えることができます。
範囲が変わります。ブロッカーが出現します。クライアントは 1 つのオプションを承認し、別のオプションを拒否します。締め切りが動きます。誰かがアクセスを送信すると約束します。通話に参加していなかったチームメイトも、何が変わったのかを知る必要があります。
通話メモのほとんどはここに当てはまります。
会話は保存されますが、プロジェクトの更新にはなりません。
役立つバージョンは、「クライアントと電話がありました」ではありません。役立つバージョンは、次のとおりです。これは新しいステータス、ここは変更内容、ここは次のステップの所有者、そしてここがチームが次に行うべきことです。
電話でプロジェクトの作業が変わるとき
クライアントからの問い合わせをプロジェクトの更新のレビューに変える
Superscribe Phone は、会話がまだ新しいうちに、ビジネス通話を概要、プロジェクトの更新、フォローアップ、CRM コンテキスト、タスク、チケット、請求対象の詳細に変換するのに役立ちます。
ショートバージョン
プロジェクト更新ワークフローへの適切な通話メモには、次の内容が含まれている必要があります。
- 現在のプロジェクトのステータス
- 通話中に何が変わったのか
- 何が決まったか
- 何がブロックされているか
- 次の各ステップの所有者は誰ですか
- クライアントが負っているもの
- あなたのチームが負っているもの
- 期限またはタイミング信号
- アップデートが存在する場所
テストは簡単です。
電話に出られなかったチームメイトは、何が変わったのか、次に何をすべきなのかを理解できたでしょうか?
そうでない場合でも、メモは依然としてソース資料です。プロジェクトの更新にはなっていません。
プロジェクトの更新はトランスクリプトではありません
トランスクリプトは時間順に並べられます。
プロジェクトの更新は有用性順に並べられます。
実際のクライアントとの通話では、重要な部分がきちんとした順序で到着することはほとんどありません。クライアントは、早期に阻害要因に言及し、後で解決策を承認し、終了近くにタイミングを変更し、全員が終了するときに責任者を追加する可能性があります。
トランスクリプトにはこれらすべてを含めることができますが、それでも使用するのは困難です。
プロジェクトの更新では、会話をチームが行動できる形式に再構築する必要があります。
ステータス: フィールド マッピング エラーにより、オンボーディングのインポートが遅れています。決定: 現在のサインアップ フォームを維持し、最初にインポート マッピングを修正します。クライアントは水曜日までに古い CSV エクスポート ポリシーを支払う義務があります。チームは木曜日までに2つのクリーンアップオプションを所有している。リスク: 法務部門がデータ条項を検討していない場合、デモの日付が変更される可能性があります。
それはあまりきれいな転写ではありません。
動作するアップデートです。
これは後ろと同じギャップです メモをタスクに呼び出す。呼び出しによって作業が作成されますが、その作業は、形状、所有者、目的地があって初めて役に立ちます。
プロジェクトの更新に必要なもの
プロジェクトの更新情報は、要約メールとは異なる質問に答える必要があります。
クライアント向けの要約では、「クライアントは何を見る必要があるか?」と尋ねられます。
プロジェクトの最新情報では、「チームが知っておくべきことは何ですか?」と尋ねられます。
これらは関連していますが、同じものではありません。
1. ステータス
プロジェクトの現在の状態から始めます。
良い：
インポートのクリーンアップは依然としてフィールド マッピングによってブロックされていますが、サインアップ フォームが原因とはみなされなくなりました。
弱点:
インポートのクリーンアップについて説明しました。
「議論済み」ではチームにはほとんど何も伝わりません。ステータス行には、何が変更されたか、または作業が現在どのような状況にあるのかを示す必要があります。
2. 決定
決定を事実として書きます。
良い：
見積もりが 4 時間未満にとどまる場合、クライアントはオプション B を承認しました。
弱点:
クライアントはオプション B に興味があるようでした。
電話会議で決定が得られなかった場合も、その旨を明確にしておきます。
まだ決定はありません。クライアントはオプション B を承認する前に法的審査を希望しています。
これにより、チームは「おそらく」を「はい」として扱うことができなくなります。
3. ブロッカー
ブロッカーは見えるようにする必要があります。
一般的なメモの段落内に隠れてはいけません。
良い：
ブロッカー: クライアントは古い CSV エクスポートを保持する必要があるかどうかを確認していません。
この行は、プロジェクトがまだうまく進められない理由をチームに伝えます。
4. 所有者
次のステップには必ずオーナーが必要です。
所有権が不明瞭な場合は、その旨を伝えてください。
正直に「所有者が不明」である方が、推測して間違った人にタスクを送信するよりも優れています。
有用な所有者行は次のようになります。
- マリアさんは木曜日までに改訂されたオンボーディングチェックリストを送信する予定です。
- クライアントは、移行パスの前にエクスポート保持要件を確認します。
- サポート所有者が権限チケットについて不明瞭です。
5. 目的地
更新では、各出力がどこに属するかを示す必要があります。
一部の詳細はプロジェクト ボードに記載されています。 CRMに属する人もいます。一部はサポート チケットに属します。クライアントのフォローアップ メールに含まれるものもあります。一部は内部に留まるべきです。
これが理由です 通話メモからフォローアップメールへ プロジェクトの更新は同じドキュメントであってはなりません。同じ呼び出しで両方にフィードを送信できますが、各出力には異なる表現が必要です。
シンプルなプロジェクト更新形式
通話メモを手動でプロジェクトの更新に変換する場合は、この構造を使用します。
プロジェクト：
クライアント、アカウント、チケット、またはプロジェクト名。
状態：
何が変わったのか、またはプロジェクトの現在の状況。
決定事項：
何が承認、拒否、遅延、または未解決のままになったか。
ブロッカー:
何が進歩を止めているのか。
次のステップ:
所有者、タスク、目的地、タイミング。
クライアントのフォローアップ:
クライアントに返送する必要がある場合、何を返送する必要がありますか。
内部コンテキスト:
チームが知っておくべきことはすべて、クライアントの電子メールに記載すべきではありません。
その構造は意図的に退屈です。
退屈なプロジェクトの更新は簡単にスキャンできます。やり直しを防ぎます。彼らは、電話の内容を個人的に話すことを求めずに、誰かを仕事に参加させました。
共有する前に確認してください
AI は、通話メモをプロジェクトの更新草案に変えるのに役立ちます。
レビューのステップは依然として重要です。
プロジェクトの更新が間違っていると、実際の損害が発生する可能性があります。提案が決定になることもあります。緩やかな期限が、確実な期限になる可能性があります。社内の懸念が、誤って顧客に向けられる可能性があります。タスクは、そのタスクを所有することに同意していない人に割り当てられることがあります。
より良いフローは次のとおりです。
- 通話を記録する。
- 有用な部分をステータス、決定、ブロッカー、所有者、宛先として構造化します。
- 通話がまだ新しいうちに確認してください。
- プロジェクトの更新を適切な場所に送信します。
これにより、プロジェクトボードを中途半端な音符で埋めることなくスピードが得られます。
Superscribeの役割
Superscribe Phone は、ビジネス通話後のレイヤー向けに構築されています。
これにより、通話は、別のクリーンアップ ジョブではなく、概要、プロジェクトの更新、フォローアップ、CRM コンテキスト、タスク、チケット、請求対象の詳細の確認に役立ちます。
重要なのは、すべての単語を保存することではありません。
重要な部分は、呼び出しによって作成された作業が、次の呼び出しによってメモリ内で置き換えられる前に、有用な場所に確実に配置されるようにすることです。
プロジェクトの作業を変更する電話の場合
ステータス、阻害要因、次のステップをまとめて管理する
次のように使ってください Superscribe ビジネス上の通話をプロジェクトの更新、フォローアップ、CRM メモ、タスク、チケット、請求対象のコンテキストのレビューに変換します。
実際的なルール
チームに通話内容を読むように依頼しないでください。
電話のおかげで何が変わったかを伝えてください。
それが、保存されたメモと役立つプロジェクトの更新の違いです。