Canny

概要

Canny は顧客フィードバックのプラットフォームです。公開（または非公開）のフィードバックボード、feature request への投票、公開ロードマップ、そしてループを閉じるための changelog を備えています。顧客はアイデアを投稿し、互いに投票し、それが「検討中」から「リリース済み」へ進むのを見守ります。そしてチーム側は、Slack やサポートチケット、商談メモに散らばった feature request の代わりに、需要順に並んだ backlog を手にします。AI レイヤーの Autopilot は今やそうした会話から request を自動で抽出し、重複をマージします。Pendo や Productboard がエンタープライズ側を押さえているこのカテゴリーで、SMB に優しい default の選択肢と捉えてください。

Customer Success スタックで採用される理由

• ループを閉じる役割。 CS チームには「X はいつ作るのか」という問い合わせが絶え間なく届きます。Canny では顧客を request に紐付けておき、リリースされた瞬間に投票した全員へ自動通知できます。CSM が follow-up を 1 通も書かずに、backlog の一項目をリテンションの接点に変えられます。
• 投票は実需を映し、声の大きいアカウントを映しません。 重み付けされ重複排除された request リストは、CS と product がロードマップで揉めるとき、逸話を並べたスプレッドシートに勝ります。
• Autopilot が会話を掘り出します。 サポートや営業のスレッド（Intercom、Gong、Zendesk 経由）を読み、feature request を自動で抽出するので、フィードバックの収集は CSM が覚えておくべきもう 1 つの作業ではなくなります。
• CRM のコンテキスト。 Salesforce や HubSpot との同期により、request をアカウント価値（ARR、tier）で重み付けできます。6 桁規模のアカウントからの request が、free ユーザーのボリュームに埋もれずに済みます。

Pricing

• Free — $0、tracked user は 25 が上限。アーリーステージの小さなボードには実用に耐えますが、すぐに上限に達します。
• Core — 100 tracked users で $19/月（年払い）から。200 で約 $49、500 で約 $125、1,000 で約 $249 へとスケールします。
• Pro — 100 tracked users で $79/月（年払い）から。200 で約 $129、500 で約 $279、1,000 で約 $529。
• Business — 5,000 以上の tracked users 向けの custom。

チームが驚く項目が tracked users です。投稿・投票・コメントをした人は誰でもカウントされ、価格は admin の seat 数ではなくこの人数に比例して上がります。人気の出た公開ボードは高額になります。今日の人数ではなく、ローンチ後に見込まれるユーザー数でコストを試算してください。

適しているチーム

実装プロジェクトなしで、今週のうちに公開ロードマップと需要順の request ボードを立ち上げたい、従業員 5〜200 名規模の B2B SaaS の product / CS チーム。顧客にオープンな場で投票してもらい、ループを自動で閉じたい一方で、Productboard 級の優先順位付けフレームワークや Pendo の in-app アナリティクスまでは不要、という場合に正しい選択になります。

中核のニーズが in-product の利用状況アナリティクスやガイド付きオンボーディングであれば、Canny は買わないでください。それは Pendo の仕事であり、Canny はそこに手を出しません。フィードバックが圧倒的に非公開／エンタープライズ寄りで、公開投票ボードが競合にロードマップを晒してしまう場合も避けてください。非公開ボードでも動きますが、それは形の合わないツールに支払っていることになります。

注意点

• tracked user 課金は成功すると跳ね上がります。 バズったボードや大型ローンチは tracked user 数を膨らませ、請求額も膨らませます。Guard: settings でオプションの月間上限額を設定し、tracked user 数を毎月確認して、tier の跳ね上がりが不意の請求ではなく意思決定になるようにしてください。
• 公開ボードは setup だけでなくモデレーションが要ります。 管理されないボードは重複と陳腐化した request で埋まり、放置されているように見え始めます。Guard: 週次でトリアージする担当者を明確に置き、Autopilot の auto-merge と auto-group に頼りつつも目視確認を行ってください。AI のグルーピングはエッジケースの request を誤ってラベル付けします。
• これはフィードバックであり、デリバリーではありません。 Canny は需要を並べますが、エンジニアリングの作業は管理しません。Guard: Linear（または Jira/GitHub）の双方向同期を繋ぎ、ステータスが投票者へ自動で戻るようにしてください。さもないと「リリース済み」のループは、誰かが手作業で Canny を更新するのを覚えているかどうかに依存します。
• AI の品質は専用ツールに後れを取ります。 Autopilot の抽出は便利ですが、Gong 級の会話分析や Claude 駆動の pipeline よりは軽量です。Guard: 自動取得された request は人間が確認する下書きキューとして扱い、確定情報とは見なさないでください。

より重厚なエンタープライズ向けの優先順位付けは Pendo を参照してください。この需要シグナルを health score と並べて取り込む CS プラットフォームは Gainsight、Vitally、ChurnZero を参照してください。