2026 年 5 月 18 日、Zendesk は「解決済み」という言葉の意味を変えました。自動対応の結果を 3 つに分割し — contained resolution、assisted escalation、そして verified resolution — 課金対象を 3 つ目だけにしたのです。verified resolution とは、LLM による評価が「実際に要望が満たされた」と確認した会話であり、判定はセッションウィンドウの終了時点、既定では最初のメッセージから 72 時間後に行われます。この変更前は、質問したあと 3 日間黙っただけの顧客も解決としてカウントされ、割当を消費していました。
その週にエージェントが賢くなったわけではありません。変わったのはメーターです。このスタックが向き合っているのはまさにその問題です。AI サポートの導入では、ボードデックに載る数字を作っているのは、その数字に対して報酬を受け取っているベンダー自身であり、課金単位の定義はベンダーごとに違います。このスタックは、解決したという主張を検証でき、エスカレーション経路をエージェントベンダーが握らず、会話が終わったあとに顧客が何をしたかまで見える構成です。
構成
- Zendesk または Pylon が system of record です。 エージェントが触れた会話はすべて、スレッド全体が付いたチケットとして残ります。いずれ実施する監査は、ベンダーのダッシュボードのエクスポートではなくチケットのクエリだからです。コンシューマ向け・マルチチャネルの volume なら Zendesk が既定解。サポートが実際に Slack や Teams の共有チャネルで、名前の付いたアカウント単位で起きているなら Pylon です — 「チケット」が顧客自身の workspace 内のスレッドである B2B の motion です。Pylon は公開していたシート価格を demo ゲートの内側に引っ込めたので、見積もり前提の項目として扱ってください。
- Fin（Intercom）または Decagon が解決レイヤーです。 記事から回答するのではなく、エンドツーエンドで解決しバックエンドのアクションまで実行するエージェントを 1 つだけ置きます。Fin は 1 outcome あたり 0.99 ドル、月間最低 50 outcome の従量課金。Decagon は価格を公開しておらず、利用分の前に年間プラットフォーム費用が約 50,000 ドルから始まると報じられています。詳細な比較は Decagon vs Fin にあります。
- Notion がナレッジベースであり、これはドキュメントではなく部品です。 Fin は Notion をネイティブのコンテンツソースとして接続し、24 時間ごとに再同期し、そのコンテンツを Fin 側で編集させません — 変更は Notion で行います。この制約こそが利点です。返金ポリシーが変わる場所を 1 か所、オーナーを 1 人に強制するからで、エージェントの回答が人間の言うことと食い違わずに済む理由はそこにしかありません。
- Pendo は、ベンダーのメーターが構造的に測れないものを測ります。 Agent Analytics は自社プロダクト内の会話 UI を計測し、行動分析と session replay に接続して、プロンプト量、リテンション、サジェストプロンプト採用率、会話が破綻する箇所を報告します。Pendo は 350 を超えるエージェントと週 250 万件のプロンプトを計測していると公表しています。ベンダーのメーターは会話が終わったことを教えますが、Pendo は同じ人が 20 分後に戻ってチケットを起票したかどうかを教えます。
- n8n がエスカレーション経路と 2 つ目のログを握ります。 エスカレーションのたびに workflow が起動し、タイムスタンプ、インテント、エージェントの確信度、引き継ぎ理由を、エージェントベンダーが制御できない保存先に自前で書き込みます。スタック内で最も安いレイヤーであり、請求の争いに勝てるようにするレイヤーです。
名前の付いた引き継ぎ
- Notion でポリシーが変わる → 24 時間以内にエージェントの回答が変わる。 1 ページ、1 オーナー、1 回の再同期。エージェント側のエディタに乖離する複製を持ちません。
- 顧客が会話を開始 → エージェントが解決を試みる → いずれにせよ system of record にチケットが残る。 contained でも、エスカレーションでも、解決でも、スレッドは Zendesk か Pylon に存在します。会話を見えないところで解決するエージェントは、監査できないエージェントです。
- エージェントが引き継ぐ → n8n がルーティングして記録する。 workflow がキューを割り当て、引き継ぎ payload を添付し、人間が見る前に独立したエスカレーション記録を書き込みます。
- セッションウィンドウが閉じる → ベンダーが結果を確定 → n8n が突合する。 月に 1 度、課金された解決数を、記録されたエスカレーション数と 7 日以内に再オープンされたチケット数と突き合わせます。再オープンを生んだ解決は、成功ではなく請求上の論点です。
- プロダクト内エージェントの会話が終わる → Pendo が journey を先へ運ぶ — リテンションと定着のデータへ。正直な deflection の数字が最終的に姿を現すのはそこです。
コストを決める分岐
どちらのエージェントも Zendesk 上で動くので、これは移行の判断ではありません。どのメーターを買うかの判断です。そして、値付けを始める前に知っておくべき前提条件があります。
Fin を Zendesk messaging で使うには Sunshine API が必要で、これは Zendesk Suite Professional、Enterprise、Enterprise Plus にしか含まれていません。 Suite Professional は年払いでエージェント 1 人あたり月 115 ドル、Suite Team は 55 ドルです。Fin の導入がメールと問い合わせフォームのチケットだけなら、この前提条件なしに Fin を Zendesk チケットの担当として割り当てられます。Web・モバイル・WhatsApp の messaging で使いたくなった瞬間に、helpdesk の請求はおよそ倍になります。エージェントを値付けする前に、そこを値付けしてください。
2 つ目のルールはもっと単純です。メーターは 1 つだけ動かすこと。 Zendesk はコミット済みの automated resolution を 1.50 ドル、pay-as-you-go を 2.00 ドルで課金し、プランに応じてエージェント 1 人あたり月 5・10・15 件の割当が付きます。Fin は 1 outcome あたり 0.99 ドルです。解決するのが Fin なら、Zendesk の AR 割当は使われないまま残り、読んでいないメーターに料金を払ったことになります。まずエージェントを選び、そのエージェントに必要なプランを買ってください — 両方ではありません。
コストの実際
シート 12、月間 6,000 会話、現実的な解決率 40%（月 2,400 解決）の B2B SaaS サポート組織の場合：
- Zendesk ネイティブのエージェント： Suite Professional 115 ドル × 12 シート = 年 16,560 ドル。割当はエージェント 1 人あたり月 10 件なので 120 件が included、残り 2,280 件を 1.50 ドルで課金 = 年 41,040 ドル。合計約 年 57,600 ドル。
- Zendesk 上の Fin： messaging が必要なら helpdesk の下限は同じ 16,560 ドル、加えて 2,400 × 0.99 ドル = 年 28,512 ドル。合計約 年 45,000 ドルで、Zendesk の割当は未使用のまま残ります。
- Decagon： 報じられている約 50,000 ドルのプラットフォーム費用が 1 件の解決より先に発生するため、単価で競うのはこの例よりかなり上の volume に達してからです。
- n8n Pro： 月 60 ユーロで 10,000 execution、年 720 ユーロほど。エージェントの費目に比べれば誤差です。
- Pendo： MAU 課金で、無料 tier より上は見積もりのみ。計測レイヤーが無料だと決めつける前に数字を取ってください。
値段の付いていない費目はナレッジベースです。誰かがオーナーにならなければなりません。名前の付いた兼任オーナーを予算に入れてください。古びたナレッジベースは、0.99 ドルの outcome を「人間にも対応費を払う再オープンチケット」に変える最も確実な方法です。
バリエーションと乗り換えの基準
- Zendesk の代わりに Pylon — volume の半分以上が Slack や Teams の共有チャネルから来る場合。コンシューマ向けの Web・モバイル motion で乗り換えてはいけません。匿名トラフィックにアカウント中心のモデルを買うことになります。
- Pendo を外す — エージェントが Web ウィジェットとメールにしかおらず、プロダクト内の接点がない場合。計測すべき journey がなく、ベンダーのメーターと n8n のログで足ります。エージェントを自社アプリに組み込んだ時点で戻してください。
- n8n を helpdesk ネイティブのトリガーに替える — エスカレーション件数が少ない場合。基準は、ログをエージェントベンダーが書き換えられない場所に置く必要が出たとき、またはルーティングが 3 つ目のシステムのデータに依存し始めたときは n8n を残す、です。
このスタックが置き換えないもの
- サポート戦略ではありません。 計測とルーティングはしますが、エージェントにどのインテントを解決させてよいかは決めません。そのスコープ設計はチケット deflection エージェントテンプレートの仕事です。
- カスタマーサクセスのスタックではありません。 解決はリテンションではありません — 顧客リテンションスタックを参照してください。
- ナレッジベースを書いてはくれません。 ここにあるどのレイヤーも、内容がすでに正しいことを前提にしています。
- 人間のエスカレーション対応力を置き換えません。 エージェントが 40% 解決するなら、残る 60% は人間が対応し続けます。しかもより難しい 60% です。
注意点とその対策
- 課金単位はベンダーごとに違い、定義は動きます。 Zendesk は 2026 年 5 月に変えました。Decagon は契約ごとの交渉です。対策： 署名前に解決の定義を書面で取り、更新時にもう一度読み直してください。
- containment は解決ではありません。 諦めた顧客も contained になります。対策： 7 日以内の再オープン率と、エージェント対応会話の CSAT を対の指標として追ってください — CSAT を参照。
- 72 時間のセッションウィンドウがフィードバックループを遅らせます。 まずいプロンプト変更がメーターに現れるまで 3 日かかります。対策： 1 時間以内に動く n8n のエスカレーション率を先行指標として見てください。
- 再同期の空白は、エージェントを自信満々に間違わせます。 Notion の再同期は 24 時間ごとです。対策： 金銭や entitlement に関わるポリシー変更では手動再同期を強制し、反映されるまで変更を保留してください。
- 文脈なしに届くエスカレーションは、エージェントがいないより悪いです。 対策： 引き継ぎ payload を n8n が検証するスキーマにし、検証失敗をルーティング障害として扱ってください。うまくいかなかったときはエスカレーション RCA を回します。
適合ルール
向いているのは： 月 2,000 会話以上を捌いており、そのうち実際に相当数が再現性のある tier-1 インテントで、誰かが deflection の数字を説明する場に立たされる場合 — ボード、CFO、あるいは更新交渉です。最もよく合うのはサポートシート 10〜50 の規模で、volume がメーターを正当化でき、代わりに指標を組んでくれる分析チームがいない層です。
向いていないのは： 月数百件のチケットに満たない場合。ヘルプセンターと人間でキューが捌け、エージェントは元が取れないポリシー保守を足すだけです。volume の大半が再現性のある質問ではなく個別の技術調査である場合も、ナレッジベースのオーナーを誰も名指しできない場合も向きません。後者の欠落は、どのエージェントを買っても必ずスタックを壊します。
1 つだけやるなら： エージェントを動かす前に n8n のエスカレーションログを立ててください。月 60 ユーロ、作業は半日、そしてこのスタックの中で唯一、エージェントベンダーが作っていない記録です。