Coworkで営業の失注理由を分析する — 四半期の集計手順

四半期ごとの失注理由の振り返りは、Slack・CRM・商談メモに散らばった記録を人手で突き合わせる作業になりがちです。案件ごとにCRMを開き、担当者のSlack投稿を検索し、通話メモを読み直す。ソースを1つずつ回るこの繰り返しが、振り返りそのものを後回しにさせます。Coworkは複数の情報源に並行して接続できるため、この突合作業をひとつの依頼にまとめられます。件数の集計、複数ソースにまたがるパターンの抽出、優先順位付けまでを1回の実行で出力させ、人はその結果から次の営業施策を判断する側に回れます。

Coworkに任せられる範囲

Coworkが担うのは、複数の記録を横断してテーマを拾い上げ、件数で裏付ける工程です。公式のCowork活用例には、通話メモ・Slack・CRM(Salesforceの商談メモと失注理由)・課題管理ツールのLinearという4系統を同時に参照する例があります。テーマごとの言及件数と、ソース横断で繰り返し出てくるパターンを抽出させる使い方です。失注理由に絞れば、同じ枠組みを四半期単位の振り返りに転用できます。

どの失注理由を重く見るか、どの商談から優先的に手を打つかという判断は人に残ります。Coworkが返すのは「何が繰り返し出てきたか」の集計であって、「どう対応するか」の決定ではありません。出力をそのまま報告書に貼って終わる使い方は、ここの取り違えから生まれます。失注先への再接触は失注顧客への再アプローチで扱っています。

通話メモの置き場所で、実行場所が決まる

最初に決めるのは、通話の文字起こしをどこに置くかです。ここで、後から効いてくる実行場所が分かれます。SlackとCRMだけを読ませるなら、どちらもコネクタ経由なので場所を問いません。ローカルフォルダーの文字起こしを読ませる場合は、パソコン側のClaude Desktopが関わります。

ヘルプセンターのスケジュール実行の記事には、食い違って読める記述が同じページに2つあります。手動設定の項目には「Claudeが作業するフォルダー」が任意項目として並び、ローカルのファイルやアプリを要するタスクはローカルでしか動かないとあります。別の注記には、スケジュール実行はアカウントに保存したファイルとコネクタで動き、パソコン上のフォルダーには紐づけられないとあります。通話メモをパソコンに置く運用では、この2つが同時には成り立たない点が判断材料です。毎回自動で回したいなら、文字起こしをコネクタ側(たとえばクラウドのドライブ)へ寄せる設計が堅くなります。

実行場所そのものも動いています。2026年10月6日から、ProとMaxプランの新しいCoworkタスクはクラウドで動き、Settings > Generalの「Only on your computer」の選択肢はなくなります。それ以前にパソコン上で始めたタスクは、そのままパソコンに残ります。

始める前に確認しておくこと

分析の依頼を出す前に、次の4つを順に確認します。

Salesforceの経路には条件があります。プラグインはSalesforceが承認した組織向けのベータで、最新のSales Cloud Enterprise Editionが対象です。まずSalesforce側の管理者が、AgentExchangeから利用を申請します。次にClaude側のOwnerが、組織設定のConnectorsで「Salesforce (Beta)」を選びます。External Client Appのconsumer keyとconsumer secretを入れると有効になります。その後、各メンバーが自分のSalesforceアカウントでサインインします。接続の全体手順はCowork Salesforce連携で先に済ませておくと、依頼文を簡素に保てます。

権限の扱いは、失注分析の範囲を左右します。Salesforce側は本人の既存権限で見える範囲だけが対象で、変更の書き込みは既定で承認を求められます。コネクタ全般も、元のサービスで閲覧できない内容にはClaudeから届きません。分析を任せる本人が見られない失注案件は、集計にも入りません。

指示文をどう設計するか

依頼文で重要なのは、参照させるソースを具体的に列挙し、集計の軸を先に指定することです。件数・横断パターン・代表的な引用の3つを求めておくと、出力が読みやすい形にまとまります。

今期の失注理由を、複数のソースを横断して分析してください。
 
参照するソース:
- 通話の文字起こし: {Downloadsフォルダー内の商談メモ}
- Slack: #sales-notes チャンネルの投稿
- CRM: Salesforceの商談ノートと失注理由フィールド(Closed Lost、直近3か月)
- (あれば)Linearやサポートチケットの関連コメント
 
やってほしいこと:
1. 失注理由のテーマを洗い出し、ソースごとの言及件数を出す
2. 複数のソースにまたがって出てくるテーマを「クロスプラットフォームの兆候」として別枠で示す
3. 各テーマに代表的な引用を1〜2件添える(発言元と日付も)
4. テーマを影響度(失注件数への寄与)で優先順位付けする
 
出力: Markdownの表とテーマごとの短い解説。件数の根拠になった発言元を明記すること。

4番目の指示が効きます。件数だけを並べた表は、どのテーマから手を付けるかの判断材料になりません。影響度で並べ替えさせれば、次のアクションにつながる順序で結果が返ってきます。

引用元の明記も外さない指示です。「価格が理由で3件失注」とだけ言われても、どの商談のどの発言を指すか分からなければ、営業チームへ説明するときにCRMを開き直す羽目になります。

最初の依頼のあと、Claudeから「どのテーマを重視するか」「どう優先順位を付けるか」といった質問が返ることがあります。回答すると、サイドバーで確認できる計画が組まれ、より自律的に進みます。

出力から何を受け取れるか

公式の活用例が示す出力は、テーマ別の件数表、クロスプラットフォームの兆候、優先順位付けされた論点の3段構成です。例では4ソースを集計し、上位のテーマは次の件数でした。

合計で並べると、モバイルアプリが最上位です。ところがCRM(失注理由の記録)の列だけで見ると、モバイルアプリは1件にとどまり、Salesforce連携の8件が最も多くなります。Slackで声の大きい論点と、失注の現場で語られる論点がずれる典型です。

クロスプラットフォームの兆候は、この食い違いを拾う枠です。例では、モバイルアプリが4ソースすべてに現れるため「単に声が大きい利用者の話ではない」と判断しています。一方のSSO連携は全体の件数こそ少ないものの、CRMの失注メモに集中して出てくるため、使われ方の問題ではなく契約を止める要因として区別されています。件数が少なくても失注に直結する論点は、この枠で拾われて初めて優先度の判断材料になります。

失注だけを見ると、原因を取り違える

失注案件だけを集めると、すべての案件に共通する論点まで「失注理由」に見えてしまいます。公式の別の活用例(Claude.aiでのCRM連携による商談準備)が、この罠をよく示しています。ヘルスケア領域の類似9案件を引くと、受注6件・失注3件でした。

連携への懸念は9案件中7件に出ており、受注した案件にも含まれます。この論点だけを見て「連携が失注理由」と読むと誤ります。失注側に偏って出ていたのは、商談期間の長さと、メモに価格が主な反対意見として残っていた点でした。同じ条件の受注案件を並べて初めて、失注に固有の要因が分かれます。

失注分析の依頼文には、受注案件を比較対象として足す指示が有効です。たとえば「同じ期間の受注案件についても同じテーマで件数を出し、失注側で偏って多いテーマだけを別枠にして」と添えます。受注の件数が手元のCRMに揃っているかは、分析の前に確かめておく点です。

出てきた論点を営業活動に戻す

分析結果は、出したままにせず具体的なアクションに変換して初めて価値が出ます。実務でつながりやすいのは3つです。

競合名や価格の論点が繰り返し出てくるなら、その論点を反論トークとしてバトルカードに落とし込めます。CRMの失注理由フィールドに競合名が記録されている場合、競合ごとにパターンを抽出し、実際の反対意見をもとにしたトークスクリプトを作らせる使い方もあります。優先順位付けされた論点をもとに、根拠となる引用付きでロードマップ提案書の下書きを作らせることもできます。プロダクト側への提案には、件数の裏付けと発言の引用が説得材料になります。

特定の顧客が複数のソースで何を言っていたかをまとめて追跡し、再アプローチの材料にする使い方もあります。公式例では「その顧客が通話・Slack・CRMメモで言ったことを全部出して」と依頼します。失注済みの案件でも、理由が製品側の改善で解消していれば再提案の余地があります。

提案書や見積もりの下書きづくりはCowork営業で提案書と見積もりの下書きをどこまで任せるかで扱っています。本記事が扱うのは、その手前にある「終わった商談から何を学ぶか」という振り返りの工程です。分析結果をそのまま提案書作成の依頼に渡せば、振り返りから次の提案書へつなげられます。

気になったテーマを深掘りする

1回の分析で全体像が見えたら、1つのテーマだけを深掘りする追加の依頼を続けて出せます。全体分析と同じセッションの中で、そのまま続けて依頼できます。

モバイルアプリ関連の言及を、4つのソースすべてから全件抜き出してください。
1件ごとに、発言者・日時・何をしようとしていたか・どのくらい強い不満だったかを添えてください。

対象を1テーマへ絞ると、代表的な引用の抜粋だけでは見えなかった発言の温度感まで読み取れます。失注の決め手になった1件だけを商談の担当者に見せて説明したい場面で効きます。

複数のソースから引く依頼では、Slack・Linear・Salesforceへの問い合わせをサブエージェントに分けて同時に走らせるよう頼む方法もあります。実行中は進捗パネルに、どのソースを引いていてどんな結果が出ているかが表示されます。あるソースの件数が想定より少なければ、途中で指示を足して軌道を直せます。

四半期の周期で回すときのつまずき

Coworkのスケジュール実行で選べる頻度は、1時間ごと・毎日・毎週・平日のみ・手動実行で、月次や四半期の選択肢はヘルプの一覧に載っていません。四半期の節目にまとめて分析したい場合は、手動実行のタスクとして登録し、四半期末に自分でトリガーする運用が現実的です。

毎週の集計を積み上げておき、四半期末に「直近13週分をまとめ直して」と依頼する方法もあります。この方法が成り立つのは、Slack・CRMのようにコネクタで読める情報源だけを毎週回す場合です。ローカルフォルダーの通話メモは、前節のとおりスケジュール実行と相性が悪く、四半期末の手動実行でまとめて読ませる形になります。

「価格が原因」という結論だけを毎回出力させると、四半期ごとの変化が見えなくなります。前四半期の結果をあわせて渡し、前回と比べて新しく出てきたテーマを聞く形にすると、振り返りとしての価値が上がります。

複数ソースを並行して引く分析は、単純な質問より読み込む量が増えやすい使い方です。通話メモの量が多い月や、他の重い分析と重なる月は、利用枠の消費ペースを見ておくと安心です。消費の仕組みと目安はCoworkコスト管理にまとめています。

まとめ

失注分析の成否は、指示文より前の「何を読ませるか」で決まります。通話メモをパソコンに置くなら四半期末の手動実行、コネクタだけで読めるなら毎週の積み上げ、と実行の形を先に選びます。出力は失注側だけで読まず、受注案件と並べて、失注に偏って出たテーマを拾います。