共有チャンネルでのサポートが強い理由は 1 つです。顧客がすでに仕事をしている場所から動かなくて済むからです。そして同じ理由で壊れます。Slack のメッセージにはキューも担当者も時計もなく、顧客のワークスペースが Slack の無料プランなら メッセージ履歴は 90 日 で消えます。修正を約束したスレッドは、それが効いてくる更新の商談より先に期限切れになります。
このスタックはたった 1 つのルールの上に立っています。Slack はインターフェースであり、それ以上ではない。記録も、時計も、エンジニアリング側の証跡も、ナレッジも、すべて自社が管理する場所に置きます。以下の構成要素はどれも、この 4 つのうち 1 つをチャンネルの外へ出すために存在します。
値段を計算する前に確認すべき前提が 2 つあります。Slack Connect は 参加する各組織が有料プランであること を求めます。顧客のプランは顧客の問題ですが、それがそのまま自社の問題になります。Enterprise+ では無料プランのパートナーがアップグレードなしで参加できます。1 つの Slack Connect チャンネルには最大 250 組織 が入り、この運用で扱うどのアカウント数よりも余裕があります。
構成
- Slack は顧客がすでに開いている画面です。 このスタックのどこにも、顧客にポータルへログインさせる要素はありません。それがこの方式の商業的な根拠のすべてです。ヨーロッパからは
slack.com/pricingが EUR で表示されます。Pro は 年払いで 1 ユーザーあたり月 6.75 ユーロ(月払いは 8.25 ユーロ)、Business+ は 年払いで 15 ユーロ(月払いは 18 ユーロ)です。チャンネルに外部ゲストが何人いても、支払うのは社内シート分だけです。 - Pylon が記録と時計です。 接続した顧客チャンネル(パブリック、プライベート、そして顧客側が開始した Slack Connect チャンネル)を監視し、関連するメッセージをまとめて、誰かがコマンドを打たなくても追跡対象の issue を作ります。Internal Threads があるので、Pylon のシートを持たないメンバーも Slack の中でその issue を扱え、双方向に同期されます。issue の SLA は 3 種類(初回応答、次回応答、解決)あり、さらに Team SLA は issue がそのチームに割り当てられた時点で開始します。作成時点ではありません。ソリューションエンジニアがスレッドを 1 週間抱えても、サポートの数字が焼かれずに済みます。Support Hours を設定すれば夜間と週末が違反件数を膨らませることはなく、違反時には指定したチャンネルへ Slack 通知が飛びます。
- Linear がサポートには閉じられないチケットの半分を引き受けます。 Pylon のサイドバーモジュール、またはトリアージチャンネルの
Create Ticket 📦ボタンから、顧客の issue が AI 生成タイトル付きの Linear issue になります。Linear のコメントは Pylon の内部ノートとして戻り、Pylon 側の返信は Linear のコメントとして進みます。Pylon は Linear の issue 上にネイティブモジュールを埋め込むため、エンジニアはサポートツールを開かずにどのアカウントが止まっているかを読めます。Customer Requests の設定を有効にしてください。リクエストが revenue、tier、規模、ステータスを持つ Linear の顧客レコードに紐づき、「エンタープライズ 3 社が求めている」が優先度会議での逸話ではなく数字になります。 - Notion は社内ランブックであって、顧客向けの KB ではありません。 Pylon 自身のナレッジベースと過去 issue は ライブで 再インデックスされます。一方、Training Data として追加する外部コンテンツは公開 URL またはクロール対象のベース URL で、プランに応じて 7 日または 30 日ごと に再インデックスされ、Notion は文書化された取り込み元に含まれていません。この 2 つの事実は同じ結論を指します。非公開の Notion ページはエージェントに届かず、クロール用に公開した Notion Site は 3 週間前に変更した返金ポリシーで回答します。顧客向けの回答は Pylon の KB に置き、Notion には社内ランブック、エスカレーションの分岐、アカウント文脈という、自社チームだけが読むものを残します。
- AI エージェントは既定路線ではなく分岐です。 Pylon の Support Agent、Slack Agent、Connectors は、Pylon 自身のドキュメントでいずれも ベータであり、ベータ参加者に限定されたアクセス と明記されています。取り得る道は 2 つです。ベータに入るか、自前のエージェントを持ち込むか。持ち込みの経路は文書化されています。issue とメッセージのイベントを受ける Webhook、返信とフィールド書き込みのための REST API、そして
mcp.usepylon.comでホストされる MCP サーバー(AuthKit 経由の OAuth 2.0、Member または Admin ユーザーのMCP Accessロールが必要)です。公開ツールはsearch_issues、get_issue、get_issue_messages、create_issue、update_issue、search_accounts、get_account、update_account、get_contact、get_user、get_meで、ツール単位・組織単位のレート制限があり、超えると429が返ります。この面に Claude を向けて返信の下書きと文脈収集をさせ、顧客チャンネルへの投稿は人間が行います。
名前のある受け渡し
- 顧客が共有チャンネルに書く → Pylon が追跡 issue を作る → SLA の時計が動き出す。
/ticketコマンドもポータルもなく、顧客に行動変更を求めません。 - issue がチームにルーティングされる → そこで Team SLA が動き出す。 全体の SLA は作成時点から走り続けるので、顧客体験とチームのパフォーマンスを別々の数字として見られます。
- サポートで直せない →
Create Ticket 📦→ Linear issue とアカウントレコード上の Customer Request。 エンジニアには埋め込まれたアカウント文脈が渡り、プロダクトマネージャーには revenue で重み付けされたリクエスト一覧が渡ります。 - Linear issue が完了 → Pylon の issue に通知が入り「On You」へ移動する。 誰かがチャンネルに戻り、報告したバグが出荷されたことを顧客に伝えます。Slack と Jira の自作構成で必ず死ぬ工程であり、顧客が覚えているのはこの工程です。
- 記事のないまま issue が閉じる → 記事が必要だと印を付ける → Gaps のキューに入る → Copilot が下書きする → Pylon の KB に公開するとライブで再インデックスされる。 Pylon は接続済みドキュメントがカバーしていない頻出質問のトピックも自動生成します。実際に消化すべきバックログはこれです。
- チャンピオンがチャンネルを退出 → Pylon がそのアカウントのトリアージチャンネルに通知し、その人物がまだ在籍しているかどうかまで伝えます。これがないと、更新の商談で初めて気づくことになります。
コストの目安
サポートと CS 合わせて 8 シート、顧客チャンネル約 60 本を担当するチームの場合です。
- Slack: Business+ が年払いで 1 ユーザー月 15 ユーロ。サポート 8 シートで年間およそ 1,440 ユーロ ですが、実務では全社で払っている費目です。
- Pylon: 見積もり制です。
usepylon.com/pricingはデモ予約へリダイレクトするため、以下の数字は見積もりではなく交渉のアンカーとして扱ってください。最後に公表された価格は、年払いで 1 シート月 Starter 59 ドル、Professional 89 ドル、Enterprise 139 ドル、最低 3 シート(Enterprise は 7 シート)でした。AI Assistants は 1 シート月 50 ドル 追加、AI Agents は 月 100 ドル から 30 日間の issue 件数に応じて上がり、Account Intelligence は 顧客アカウント 1 件あたり月 10 ドル、最低 50 アカウントでした。Professional 8 シートで年 8,500 ドル 前後、Assistants を足すと 13,300 ドル 近く、60 アカウント分の Account Intelligence でさらに約 7,200 ドル 乗ります。 - Linear: Free は 2 チーム・250 issue までで、実際のエンジニアリング組織は 1 四半期で超えます。Basic は 年払いで 1 ユーザー月 10 ドル、Business は 16 ドル で、Linear Asks、ゲストを含むプライベートチーム、Zendesk と Intercom のコネクタはこの階層です。Customer Requests は Free を含む全プランにありますが、Free では手動または Slack からの作成に限られます。
- Notion: Free、Plus が 1 メンバー月 9.50 ユーロ、Business が 19.50 ユーロ。ワークスペースの一部を自社ドメインの Notion Site として公開するなら、年払いで 1 ドメイン月 8 ドル です。
サポート 8 シートの総額はおおむね年 16,000〜26,000 ドル に着地し、その 60〜80% を Pylon が占めます。予算を左右する問いはツールの選定ではなく、Pylon のどのアドオンを実際に入れるかです。
差し替えの判断
- Linear の代わりに Jira を使うのは、エンジニアリングがすでに Jira で動いていて動かせない場合です。受け渡し 3 と 4 は Pylon のチケット連携で維持できますが、Linear の顧客レコードは失われ、revenue で重み付けしたリクエスト一覧は Jira のフィールドかスプレッドシートで作り直すことになります。サポートの機能ひとつのためにエンジニアリングを移設してはいけません。
- Slack Connect の代わりに Microsoft Teams を使うのは、顧客が Microsoft 中心の企業である場合です。Pylon は Teams も一級のチャンネルとして扱い、スタックの残りは変わりません。この差し替えを決めるのは顧客の居場所であって、好みではありません。
- 解決レイヤーを Fin(Intercom)にする のは、Pylon のベータ枠を待つより計測済みのエージェントを今日ほしい場合です。Fin は outcome 単位で課金し、独自のナレッジソース設計を持ち込みます。そのメーターを監査する議論は AI サポートエージェントスタック にあり、本当の論点がデフレクションの経済性なら、そちらが読むべきページです。
- Notion を外す のは、ランブックがすでに Pylon の KB に内部コレクションとして置かれている場合です。2 つ目のナレッジの住処が見合うのは、サポート以外のチームがそこに書くときだけです。
このスタックが置き換えないもの
CS プラットフォームではありません。ヘルススコア、更新フォーキャスト、プレイブックの自動化は別の買い物です。CS リテンションスタック を参照してください。インシデント連絡でもありません。60 アカウントに障害を告知する場所として Slack Connect のチャンネルは不適切で、ステータスページは別途必要です。QA プログラムでもありません。これらのチャンネルが生む会話を採点するのは サポート品質保証 の領域です。プロダクト分析でもなく、静かになった顧客がまだ機能を使っているかどうかは、ここからは分かりません。
適合の条件
選ぶべき なのは、サポートが B2B かつ指名アカウント制で、インバウンドの半分以上が Slack か Teams の共有チャンネルから届き、顧客チャンネルが 20〜300 本の範囲にあり、エンジニアリングがすでに Linear にいる場合です。採算が合うのは、コンタクト単位ではなくサポートシート単位で払うからです。
選ぶべきでない ケースは 3 つです。Web ウィジェット経由の匿名トラフィックや消費者向けの量は、アカウント中心の課金モデルとかみ合いません。顧客チャンネルが 10 本未満なら、Slack と Linear の無料プランと共有メールエイリアスで費用ゼロのまま失うものもありません。そして顧客の法務が監査する契約 SLA がある場合は、既存のヘルプデスクを解約する前に、Pylon の SLA 定義とレポートが MSA の文言と一致するか確認してください。契約書の「初回応答」とサポートツールの「初回応答」は、同じ事象とは限りません。