なぜ顧客ミーティングの準備がそれほど重要なのですか？
私はRiellで、毎日eeselのサポートキューを担当しています。そのため更新まわりのやり取りが身近で、準備なしで臨むことの代償を何度も目にしてきました。
特に印象に残っている痛い例があります。eeselの月額799ドルのプランを使っていた英国の自動車フィンテック企業が、「高すぎる」という理由で解約しました。8回の請求サイクルで約311回のAIとのやり取りがあり、チームの評価も好意的だったのにです。eeselの共同創業者Amoghは後にこれを書き残しています。eeselは製品で負けたのではなく、価値を誰も説明しなかったことで失いました。予算削減に動く財務チームに対してです。誰も数字を手にその会話に臨んでいませんでした。
10日後には逆の結果になりました。私は、ある化粧品ブランドを解約リスクとして共有しました。月額800ドルは見合わず、自社でツールを作ると言っていたのです。チームは理由を把握したうえで会話に臨み、使い方に合った従量課金を提案して、月額約200ドルで継続してもらえました。
この2つの結果を分けたのは、準備して臨んだかどうかだけです。だからTownのミーティング準備の仕組みを読むときも、まさにそうした通話の前に使いたい立場で読みました。Townをまだご存じなければ、同僚のTown AIレビューで製品を紹介しています。要するに、専用の@town.comメールアドレスを持ち、受信トレイ、カレンダー、各種アプリをまたいで動く個人向けAIアシスタントです。
顧客ミーティングの前にTown AIは何をしますか？
Townの主な準備ツールは Meeting Brief というルーティンです。Townのルーティンページによると、「参加者リスト、メール履歴、過去のミーティングノート、最近の企業ニュースを読み取り、準備が必要な通話の前に短い準備ノートを送る」とされています。すべてのアカウントに含まれるので、インストールするものはありません。
ルーティンは、Townieに普通の言葉でメッセージを送って設定します。デフォルトでは次のことを依頼します。
- 対象のミーティングを選ぶ。 「外部の、初めての、重要度の高い」ミーティングを準備し、社内スタンドアップや定例の1:1は飛ばします。
- 出席者を調べる。 相手が誰か、その人とのメール履歴、所属企業の最近のニュースです。
- 約束事を拾い出す。 前回お互いに約束したことを、過去のスレッドやミーティングノートから、未解決の項目を先頭にして集めます。
- 新しい動きを記す。 役職の変更、発表、相手が返信を待っているスレッドなどです。
このブリーフで一番気に入っているのは、構成の順番です。デフォルトでは、伝えるべき、または尋ねるべき一点から始まるノートを求め、次に出席者、その後にコンテキストが来ます。「通話の少し前に届くよう調整され、何時間も前に埋もれてしまうことはない」とのことです。更新やエスカレーションの通話なら、先頭のその一行に「9月に2回、SSOのバグについて問い合わせがあった」といったリマインドがほしいところです。
ブリーフに返信すれば、同席者について掘り下げて尋ねることもできます。個人のカレンダーにも同じ準備がほしい場合は、会議の予約までこなすツールをまとめた私の AI scheduling assistants のガイドをご覧ください。
顧客ミーティングの準備に役立つTownのルーティンはどれですか？
Meeting Briefは複数あるうちの一つです。Townのルーティンライブラリにはミーティング関連のまとまりがあり、それぞれ実行されるタイミングが異なります。
| ルーティン | 実行タイミング | 内容 | 自動で動くか |
|---|---|---|---|
| Meeting Brief | 通話の直前 | 短い準備ノート：伝える一点、出席者、未解決の項目 | はい、リサーチのみ |
| Attendee Research Brief | 外部ミーティングの約1日前 | LinkedIn、メール履歴、企業ニュース、共有Driveのドキュメント | はい、リサーチのみ |
| Standing 1:1 Prep Doc | 定例の1:1の数時間前 | 未解決の項目と保留中の判断をまとめた継続ドキュメント | 下書きのみ、共有はしない |
| Board Meeting Prep | キーワード付きで資料を転送したとき | 数字に結びついた4つの質問を含む7セクションのメモ | あなたのDriveに書き込む |
| Post-Meeting Debrief Drafts | 録画または文字起こしが完了したとき | 担当者付きのデブリーフと、フォローアップメールの下書き | メールは確認のため保留 |
出典：Townのルーティンページ Attendee Research Brief、Standing 1:1 Prep Doc、Board Meeting Prep、Post-Meeting Debrief Drafts。
顧客対応の仕事でまず有効にするなら、Attendee Research Brief です。出席者のメールドメインで社内と社外のミーティングを見分けるため、「毎週のチーム定例は静かなまま」で、顧客、見込み客、候補者とのミーティングだけにブリーフが届きます。
Standing 1:1 Prep Doc は社内の1:1向けですが、その考え方は定期的な顧客チェックインにも応用できます。「前回未解決だったことを引き継ぎ、毎週白紙から始めるのではなく、続きのスレッドにする」というものです。主要アカウントと毎週通話があるなら、まさにこの形がほしいはずです。
Townの標準ルーティンのドキュメントには、ラベル付きメールが届いたときに新しい連絡先とその会社を調べる Contact Research Dossier と、録画されたミーティングの文字起こしが終わったときに「合意したことと、話し合っただけのことを分ける」Meeting Action Hand-Off も載っています。
カスタマイズする前に知っておきたい点がドキュメントにあります。標準ルーティンの設定、モード、追加の指示は変更できますが、「標準ルーティンの根本のロジックを書き換えたり、新しいデータソースを組み込んだり」することはできません。標準版が使わない情報源を取り込むブリーフがほしいなら、カスタムルーティンを作ります。
顧客ミーティングのブリーフを作るために、Townは何を読み取りますか？
すべて、あなたが接続したものから取得されます。Townの連携ページには、ミーティングブリーフが利用できるツールが並んでいて、顧客対応の仕事で役立つものは4つのグループに分かれます。
- メールとカレンダー： Gmail、Outlook、Google Calendar。すべてのルーティンに必要な基盤です。
- 通話ノートと録画： Granola、Fathom、Fireflies、Gong、Zoom、そしてTown独自のRecordings機能。
- CRM： HubSpot、Salesforce、Attio、Pipedrive、Affinity、Copper。HubSpot連携で読み書きできる内容は、同僚の Town AI for HubSpot の記事で解説しています。
- 人物・企業リサーチ： LinkedInとClay、そして企業ニュースのためのウェブリサーチ。
Town内蔵のRecordingsは、一見よりも準備に大きく効きます。通話中にウェブ、Mac、iOSアプリで録音すると、Townが文字起こしし、ミーティングノートも作成できます。「どこでも同じアシスタントが同じメモリを持っている」ので、来月のブリーフは今月の通話で話した内容をすでに把握しています。録音はデフォルトで自分だけが見られます。
ノートをGranolaに保存している場合、TownのGranolaドキュメントによれば、接続は読み取り専用です。Townはノートや文字起こしを検索しますが、作成や編集はしません。そこに記録されていないミーティングは、「取得できるものがありません」。
独立したノートツールを使い続けたい場合は、私の meeting notes app のガイドと Otter AI のレビューで選択肢を紹介しています。Zoom AI にも独自の要約機能が組み込まれています。
顧客との通話で、Townのミーティングブリーフが拾えないものは何ですか？
サポート履歴です。更新、エスカレーション、QBRでは、最も重要なコンテキストがヘルプデスクにあることがよくあります。未解決のバグや請求への不満、同じ連携に関する3件のチケットなどです。顧客が最初の5分で持ち出すのは、たいていそうした内容です。
Townの連携ページには、サポートツールとしてFrontとPylonが載っています。Zendesk、Freshdesk、Gorgiasは載っていません。そのため、Zendeskを使う会社の標準Meeting Briefは、顧客のチケットを見られません。たまたまメールに入っていれば別です。
ただし、回避策はあります。TownはカスタムMCPサーバーに対応しており、ドキュメントでも使用例として「社内のCRMやヘルプデスクを照会する」が挙げられています。設定でサーバーを追加し、カスタムルーティンで有効にすると、そのルーティンがサーバーのツールを呼び出せます。ヘルプデスクのMCPサーバーを構築・保守できる人がいて、ブリーフがカスタムルーティンである場合に使える方法です。標準ルーティンには新しいデータソースを追加できないためです。
さらに、知っておきたい小さな点が2つあります。
- ブリーフは個人単位です。 各自のTownieは、自分の受信トレイ、ノート、メモリを使います。TownのTeamsドキュメントではチームメイト同士でルーティンを共有できますが、アカウントマネージャーに届くブリーフは本人のアカウントから作られ、共有のアカウント記録からではありません。直近のエスカレーションをサポート担当者が対応していたなら、その文脈はヘルプデスクにあり、アカウントマネージャーの受信トレイにはありません。
- 人物リサーチには上限があります。 Townの料金ページでは、人物リサーチの検索回数がStarterで月10回、Proで50回、Powerで150回、Teamで1ユーザーあたり75回に制限されています。1日に外部との通話が3件ある多忙なアカウントマネージャーは、月末までにProの50回に達することがあります。
サポートチームがFrontを使っているなら、Townはそこにも接続します。待機中のスレッドを表示して返信を下書きでき、送信にはすべてあなたの承認が必要です。同僚の Town AI for Slack の記事でも同じ個人単位の形が示されていて、Front自身の Front AI copilot も比較する価値があります。全体像については、help desks with CRM と Zendesk CRM integration のガイドをご覧ください。
ミーティング準備にはTownのどのプランが必要ですか？
購入の前に、少し立ち止まって確認したいところです。Meeting Briefは「新しいTownアカウントすべてに付属」しますが、自動で実行されるかどうかはプランによります。
| プラン | 月額 | ミーティングブリーフ | 人物リサーチの検索 |
|---|---|---|---|
| Free | $0 | なし（Weekly Briefing が唯一のルーティン） | なし |
| Starter | $15（月払いのみ） | オンデマンドで月15件 | 10 |
| Pro | 年払い$49 / 月払い$59 | 自動 | 50 |
| Power | 年払い$99 / 月払い$119 | 自動 | 150 |
| Team | 年払い$59 / 月払い$71（1席あたり） | 自動 | 1ユーザーあたり75 |
出典：Town pricing と Plans and Pricing docs、2026年10月に確認。
理由はトリガーです。Townのトリガーのドキュメントでは、カレンダー開始トリガーが、デフォルトでミーティングの15分前、または1時間前、あるいは5分後に作動すると説明されています。Townのプランのドキュメントには、ミーティング開始トリガーにはPro以上、または有料のチームプランが必要とあります。Starterで動くのは、1日1回までのスケジュールトリガーだけです。
つまりStarterでは、ブリーフは自分で依頼することになり、月15件までです。週に数回しか顧客との通話がない創業者なら十分です。月に40件の外部ミーティングがあるアカウントマネージャーなら、実質的にはProからになります。1回の実行あたりのクレジットも固定ではなく、長いメール履歴を読むブリーフは、初回ミーティング用のブリーフより多く消費します。クレジットと超過分については、同僚の Town AI pricing の記事で解説していて、Townは登録時にProの7日間トライアルを提供しています。
Townのミーティング準備は、自動で実行しても安全ですか？
準備については、はい。私が読んだミーティング準備ルーティンは、どれも設計上リサーチ専用です。
- Meeting Brief のデフォルトには「自分でリサーチしてブリーフを作る。出席者に連絡したり、カレンダーに触れたりしない」とあります。
- Attendee Research Brief のページには「読み取って報告するだけで、それ以上のことはしない」とあります。
- Debrief Drafts ルーティンは、フォローアップメールが外部宛てなので、「私の確認のため」の下書きとして保留します。
これは、他の人に連絡する操作がデフォルトであなたの承認を待つという、Townの全体的なModes and Approvalsモデルとも一致します。Townの共同創業者Jean-Denis Grezeは、ローンチ時にこの姿勢をこう要約しました。
"And it only acts when you say so."
もう一つ確認したいのは、ブリーフの配信先です。ブリーフを受信トレイではなくSlackチャンネルに送る設定にすると、チャンネル全員に顧客についてのメモが見えてしまいます。Townのルーティンはデフォルトで受信トレイに届くので、設定を変えた場合にのみ問題になります。
Townはまだ新しく、G2やCapterraのレビューはなく、ミーティングブリーフについて具体的に語る公開の投稿も見つけられませんでした。最も明確な外部のシグナルは、導入の広がりについてです。投資家のswyxは、Townが自分のチームに広がった様子をこう語っています。
"i brought it into our company one day and a few weeks later was shocked to hear that it had just organically spread to @liamcbride and the rest of our team with no further hyping or enablement from me."
顧客ミーティングの準備のために、Townをどう設定しますか？
私なら次の順で進めます。合計で約30分です。
- サインアップ時にメールとカレンダーを接続する。 標準のMeeting Briefが動き出すのに必要なのはこれだけです。
- ノートツールとCRMを接続する。 前回の発言にはGranolaまたはFathom、アカウントの記録にはHubSpotまたはSalesforceです。
- 対象にするミーティングをTownieに伝える。 顧客対応なら、「自社ドメイン外の人とのミーティングはすべてブリーフを作り、社内の定例は飛ばして」といった指示です。
- Attendee Research Briefを追加する。 ルーティンの設定メッセージを送れば、15分前のブリーフに加えて前日のブリーフも届きます。
- RecordingsまたはDebrief Draftsを有効にする。 各通話が次のブリーフにつながります。
標準版が読み取らない情報源を加えたブリーフがほしい場合は、Townのルーティンウィザードが、普通の言葉での依頼からカスタムルーティンを作ってくれます。
まだアシスタントを選んでいる途中ですか？ 同僚の Town AI alternatives の記事では、Townを Instinct AI や Orchid AI と比較しています。自分でエージェントを作りたい場合は Lindy があります。
顧客ミーティングの準備にサポート履歴を加えるには？
最初に埋めたいのはこの部分です。一番よく問題になるのを見ているからです。アカウントマネージャーが更新の前に「知っておくべきことはある？」と私に尋ねるとき、答えが本人の受信トレイにあることはほとんどありません。チケットのキューにあります。
eeselは、特定の仕事のために採用できるAIチームメイトの集まりで、ここで役立つのがAIヘルプデスクのチームメイトです。eeselのSlackドキュメントによると、Slackのスレッドでメンションして、接続済みのヘルプデスクの検索を頼むと、スレッド内で見つけた内容を返します。つまり、通話の前に「@eesel list Acme's open tickets」と頼めば、Townが読み取らないブリーフのサポート側の情報が手に入ります。
何が得られるのか、具体的に挙げます。
- チームで一度だけ接続する。 Zendesk、Freshdesk、Gorgias、Frontへの接続は一度で済み、各自が設定する必要はありません。
- 受信トレイではなくヘルプデスクを読む。 検索はチケットそのものに対して行われるため、たまたまCCに入っていたスレッドに限られません。
- 実行前に確認する。 チケットを変更する依頼をすると、同じスレッドに Approve、Deny、Review in eesel を備えた承認カードが投稿されます。
2つのツールは並べて使うのに向いています。Townはメール、カレンダー、CRMから準備を整え、eeselがヘルプデスクを担当します。顧客との通話がエスカレーション中心なら、ticket summarization と AI churn prevention for support のガイドで、警戒すべき兆候を早く見抜く方法をさらに詳しく解説しています。
次の更新の通話の前に、eeselを試す
次の更新やエスカレーションの通話の前に、顧客がサポートに何を伝えたかをSlackでeeselに尋ねてみてください。あなたのZendesk、Freshdesk、Gorgiasにあるチケットを調べてスレッドで答えるので、未解決のバグに不意を突かれずに済みます。
プランはeeselの料金ページにある固定のクレジットバンドルで、500クレジット月額299ドルから。先に試せる無料プランもあります。ヘルプデスクとSlackチャンネルを1つ接続して、カレンダーの次の顧客について尋ねてみてください。eeselを試す
よくある質問
Town AIは顧客ミーティングの準備をしてくれますか？
はい。Townにはすべてのアカウントに Meeting Brief ルーティンが付属します。参加者リスト、メール履歴、過去のミーティングノート、最近の企業ニュースを読み取り、準備が必要な通話の前に短い準備ノートを送ります。別の Attendee Research Brief は、外部ミーティングの約1日前に実行されます。同じことができる他のアシスタントについては、私の AI personal assistants のまとめをご覧ください。
ミーティングブリーフを自動で受け取るには、Townのどのプランが必要ですか？
Proで、年払いなら月額49ドル、月払いなら59ドルです。Townの料金ページでは、ミーティングブリーフの自動送信はPro以上に含まれ、月額15ドルのStarterはオンデマンドで月15件までです。ミーティング開始時のトリガーにも、Proまたは有料のチームプランが必要です。プランの全一覧は、私の Town AI pricing の解説にあります。
Town AIのミーティングブリーフには何が含まれますか？
Meeting Brief ルーティンによると、最初に「伝えるべき、または尋ねるべき一点」が来て、次に出席者、その後にコンテキスト（メール履歴、前回の約束事、未解決の項目、前回の会話以降の新しい動き）が続きます。接続したメールやカレンダー、GranolaやFathomなどのノートツール、HubSpot などのCRMから読み取ります。
Town AIのミーティング準備にサポートチケットは含まれますか？
主要なヘルプデスクからは、標準では含まれません。Townの連携ページにはFrontとPylonが載っていますが、Zendesk、Freshdesk、Gorgiasはありません。自分で設定するカスタムMCPサーバー経由でヘルプデスクを追加することは可能です。その設定なしでチケットを調べたい場合は、eeselのような AI helpdesk agent が、依頼に応じて顧客のチケットを取得できます。
Town AIは会議の出席者に勝手に連絡しますか？
準備ルーティンはリサーチ専用です。Meeting Brief のプロンプトには、出席者に連絡したりカレンダーに触れたりしないと書かれており、Attendee Research Brief は読み取って報告するだけです。通話後のフォローアップメールは、確認用の下書きとして保留されます。Townの承認モデルは、私のレビューで取り上げています。
Town AIは顧客ミーティング中にメモを取れますか？
はい。Town Recordingsは、ウェブ、Mac、iOSアプリからミーティングを録音して文字起こしし、ミーティングノートを作成できます。そのノートは次の準備ブリーフに活用されます。Granolaに保存したノートも読み取れます。専用のノートツールを使いたい場合は、私の meeting notes app のガイドをご覧ください。
Town AIはカスタマーサクセスチームに向いていますか？
一人ひとりで使う形です。各アカウントマネージャーが自分の受信トレイとメモリを持つ自分専用のTownieを使うため、ブリーフは個人単位で、共有のアカウント記録ではありません。創業者やアカウントマネージャーには向いています。チーム全体向けのツールについては、私の AI tools for customer success の一覧をご覧ください。