Zendeskの解決後のアウトバウンド：発生理由と回避策

チケットを解決したばかりで、顧客に簡単なフォローアップを送信する必要があることに気づきました。それは、丁寧な状況確認、コンプライアンス要件、または「解決」をクリックした後に届いた追加情報かもしれません。メッセージを送信しようとすると...何も起こりません。Zendeskでは送信できません。

これは「Zendeskの解決後のアウトバウンド」の制限であり、プラットフォームの最も不満の残る癖の1つです。なぜそれが起こるのか、それについて何ができるのか、そして最新の代替手段が解決後のコミュニケーションをどのように処理するのかを詳しく見ていきましょう。

Zendeskにおける「解決後のアウトバウンド」とは？

Zendeskにおいて、「解決後のアウトバウンド（outbound after solve）」とは、チケットが解決済み（solved）またはクローズ済み（closed）としてマークされた後に、アウトバウンド通信（メール、メッセージ、更新）を送信することに対するプラットフォームの制限を指します。チケットがこれらのターミナルステータスのいずれかに達すると、Zendeskはチケットレコードの整合性を維持するために、アウトバウンドメッセージングをロックダウンします。

これは、いくつかの一般的なシナリオで問題になります。

• フォローアップコミュニケーション（Follow-up communication）: 解決後数日後に顧客に状況確認を行い、問題が本当に解決されたことを確認したい場合
• コンプライアンス追跡（Compliance tracking）: 規制対象の業界では、解決後のアウトリーチを含む、すべての顧客とのやり取りを文書化する必要があります
• プロアクティブなアウトリーチ（Proactive outreach）: チケットが解決された後に入手可能になった追加情報を送信する必要がある場合
• 品質保証（Quality assurance）: マネージャーがクローズ後に内部メモを追加したり、満足度調査を送信したりしたい場合

この制限は、Zendeskがチケットライフサイクルをどのように構築しているために存在します。そのライフサイクルを理解することが、制限を回避するための鍵となります。

解決済み vs クローズ済みチケット：重要な違い

Zendeskには、似たように聞こえるものの、動作が大きく異なる2つの「ターミナル（terminal）」チケットステータスがあります：解決済み（solved）とクローズ済み（closed）です。

解決済みステータス（Solved status）

エージェントがチケットを解決済みとしてマークすると、顧客の問題は解決されたと考えていることを示しています。チケットはアクセス可能な状態のままであり、顧客が返信すると再オープンできます。エージェントは、フィールドの更新、コメントの追加、チケットの変更に対する完全なアクセス権を持っています。

「解決済み」は、「顧客の確認待ちの解決済み」と考えてください。会話は技術的には継続できますが、Zendeskは完了したはずのレコードへの偶発的な変更を防ぐために、特定のアウトバウンドアクションを制限しています。

クローズ済みステータス（Closed status）

クローズ済みチケットはロックされ、アーカイブされます。再オープンすることはできません。顧客がクローズ済みチケットに返信すると、Zendeskは元のチケットを再オープンする代わりに、新しいフォローアップチケットを作成します。エージェントは、クローズ済みチケットを変更する能力が制限されています（API経由でタグなどの特定のフィールドのみを更新できます）。

自動クローズの自動化（The auto-close automation）

デフォルトでは、Zendeskには「ステータスが解決済みに設定されてから4日後にチケットをクローズする」という自動化が含まれています。これにより、チケットは解決済みからクローズ済みに自動的に移行され、顧客が必要に応じてさらに支援を求めるための期間が与えられます。この期間は、ワークフローのニーズに基づいて1時間から28日の間で調整できます。

ほとんどのチームは、チケットを解決済みステータスのまま3〜5日間置いてからクローズ済みに移行し、顧客が必要に応じて同じチケットで再度エンゲージするのに十分な時間を与えます。

Zendeskがクローズ後にアウトバウンドメッセージをブロックする理由

この制限は恣意的ではありません。Zendeskのアーキテクチャは、解決済みおよびクローズ済みのチケットを、データ整合性のために変更されない履歴レコードとして扱います。

技術的な理由（Technical reasons）

Zendeskのチケットロックメカニズムは、履歴レコードを保持するために変更を防ぎます。これは、以下にとって重要です。

• レポートの正確性（Reporting accuracy）: 「解決までの時間（time to resolution）」や「チケットボリューム（ticket volume）」などのメトリクスは、チケットに明確で不変のエンドポイントがあることに依存しています
• 監査証跡（Audit trails）: コンプライアンス要件では、解決済みのチケットを変更せずに維持することが義務付けられていることがよくあります
• データの一貫性（Data consistency）: 解決後の編集を防ぐことで、チケットデータが連携やAPI呼び出し全体で一貫性を保つことが保証されます

ワークフローの哲学（Workflow philosophy）

Zendeskの設計は、アクティブな問題と解決済みの問題の明確な分離を前提としています。チケットが解決されると、プラットフォームは、顧客が再オープンを開始しない限り、会話が終了することを想定しています。この哲学は、単純なサポートワークフローには適していますが、解決後の継続的なコミュニケーションを必要とするチームには摩擦が生じます。

ユーザーの不満点（User frustration points）

この制限は、実際の運用上の課題を生み出します。

• メモを追加できない（Can't add notes）: エージェントは、解決後に明らかになったコンテキストのために、解決済みチケットに内部メモを追加できません
• フォローアップのブロック（Blocked follow-ups）: 顧客体験を向上させる場合でも、プロアクティブな顧客コミュニケーションがブロックされます
• コンプライアンスのギャップ（Compliance gaps）: 規制対象の業界のチームは、元のチケット内で解決後のやり取りを簡単に文書化できません
• 断片化されたレコード（Fragmented records）: 回避策（新しいチケットの作成など）は、顧客とのやり取りの履歴を複数のレコードに分割します

Zendeskでの解決後のコミュニケーションの回避策

Zendeskは直接的な解決策を提供していませんが、チームはいくつかの回避策を開発しました。それぞれにトレードオフがあります。

タグを使用した自動化アプローチ（Automation approach with tags）

一般的な回避策の1つは、Zendeskの自動化システムを使用して、追跡機能を維持しながらチケットを自動的に解決することです。

1. 非アクティブ期間（例：48時間）後にチケットを解決する自動化を作成します
2. 解決する前に、これらのチケットに一意のタグ（「auto_solved」など）を追加します
3. 「auto_solved」タグが付いたすべてのチケットを表示するカスタムビューを作成します
4. このビューを使用して、フォローアップが必要になる可能性のあるチケットを特定します

制限事項（Limitations）: このアプローチでは、解決済みチケットでのアウトバウンド通信は依然として許可されていません。手動で解決されたチケットと自動的に解決されたチケットをより適切に追跡できるだけです。

手動の回避策：新しいチケットを作成する（Manual workaround: Create new tickets）

重要なフォローアップのために、一部のチームは解決後のコミュニケーション専用の新しいチケットを作成します。

1. 解決済みチケットでフォローアップが必要な場合は、新しいチケットを作成します
2. 件名または説明に元のチケット番号を記載します
3. Zendeskのチケットリンク機能を使用してチケットをリンクします
4. 新しいチケットでフォローアップコミュニケーションを処理します

制限事項（Limitations）: これにより、顧客とのやり取りの履歴が分割され、管理上のオーバーヘッドが発生します。また、完全なレコードを1か所に保持するというコンプライアンスの問題も解決されません。

IVRおよび音声の回避策（IVR and voice workarounds）

Zendesk Talkを使用しているチームの場合、一部の制限はボイスメールと通話ログを使用して回避できます。

• 通話に応答がない場合は、アウトバウンドメッセージにボイスメールを使用します
• 通話試行を内部メモとしてログに記録します（ただし、これはクローズ済みチケットでも制限されています）
• IVRを使用して、顧客からの着信通話を適切なエージェントにルーティングします

制限事項（Limitations）: これらの回避策は音声チャネルに固有のものであり、メールまたはチャットの制限には対応していません。

レポートの回避策（Reporting workarounds）

一部のチームは、カスタムビューとレポートを使用して、フォローアップが必要になる可能性のあるチケットを追跡します。

• 解決日とタグでフィルタリングされたビューを作成します
• Zendesk Exploreを使用して、自動解決されたチケットに関するレポートを作成します
• 解決後のフォローアップの外部追跡のためにチケットデータをエクスポートします

制限事項（Limitations）: これにより、手作業が増え、ブロックされた通信が実際に有効になるわけではありません。これは、コミュニケーションソリューションではなく、追跡ソリューションです。

eesel AIが解決後のコミュニケーションをどのように異なる方法で処理するか

Zendeskのアプローチの根本的な問題は、その厳格なチケットライフサイクルです。最新のAI搭載サポートプラットフォームは、サポートをターミナルステートを持つ個別のチケットとしてではなく、継続的な会話として扱うという異なるアプローチを採用しています。

チームメイトのメンタルモデル（The teammate mental model）

eesel AIでは、サポートに異なるアプローチを取っています。厳格なワークフローを構成することはありません。代わりに、ビジネスを学習し、自然に会話を処理するAIチームメイトを雇います。人間のエージェントと同様に、eeselは、恣意的なステータスロックなしに、必要なときにいつでも会話を継続できます。

これは、次のことを意味します。

• 恣意的なチケットロックなし（No arbitrary ticket locks）: 会話はステータスの制約なしに自然に継続されます
• 継続的なコンテキスト（Continuous context）: eeselは、「ステータス」に関係なく、会話の完全な履歴を記憶しています
• 自然なフォローアップ（Natural follow-ups）: 解決後のコミュニケーションは、必要なときにシームレスに行われます
• プレーンな英語でのエスカレーション（Plain-English escalation）: 複雑なトリガー構成ではなく、自然言語を使用して人間を関与させるタイミングを定義します

すべてのやり取りからの継続的な学習（Continuous learning from all interactions）

Zendeskの静的なチケットレコードとは異なり、eesel AIは、解決後のフォローアップを含む、すべてのやり取りから学習します。これは、次のことを意味します。

• eeselの応答に対して行った修正は、今後の会話のためにAIをトレーニングします
• 解決後のコンテキストにより、顧客の理解が深まります
• 複数のチケットにレコードを分割する必要はありません

厳格なステートのない柔軟なワークフロー（Flexible workflow without rigid states）

eesel AIは、会話を厳格な「解決済み」または「クローズ済み」のバケットに強制的に入れることはありません。代わりに、自然言語の指示を使用して、会話がいつ完了し、人間のエスカレーションが必要になるかを判断します。

たとえば、eeselに次のように指示できます。

「顧客が問題が解決されたことを確認した場合は、感謝の意を伝え、会話を終了します。後で再度返信があった場合は、新しいリクエストとして扱いますが、関連する場合は以前のコンテキストを参照してください。」

このアプローチにより、「解決後のアウトバウンド」の問題が完全に解消されます。会話は必要に応じて継続でき、eeselはルーチンのフォローアップを単独で処理し、適切な場合にのみ人間へとエスカレーションします。

Zendeskとの連携（Zendesk integration）

すでにZendeskを使用しているチームの場合、eesel AIは、既存のワークフロー内でAIエージェントおよびコパイロットとして直接連携します。次のことができます。

• Zendesk内にeesel AIをデプロイして、最前線のサポートを処理します
• eeselのAIコパイロットを使用して、人間のエージェントの返信を作成します
• ステータスの制限なしに、eeselにルーチンのフォローアップを処理させます
• AI搭載の柔軟性を獲得しながら、既存のZendesk設定を維持します

チームに適したアプローチの選択

Zendeskの制限が重大な問題になるかどうかは、特定のニーズによって異なります。

Zendeskの回避策で十分な場合

Zendeskの組み込み機能は、次の場合に適切である可能性があります。

• サポートワークフローが単純で、解決後のコミュニケーションのニーズが最小限である
• チケットボリュームが少なく、手動の回避策が管理可能である
• 業界に解決後のドキュメントに関する厳格なコンプライアンス要件がない
• チームがすでにZendeskに投資しており、切り替えコストが高い

代替手段を検討する場合

次のような場合は、eesel AIなどの代替手段を検討してください。

• 解決後のフォローアップコミュニケーションが頻繁に必要な場合
• 完全なやり取りの記録を必要とする規制対象の業界にいる場合
• 時間の経過とともに学習および改善するAI搭載のサポートが必要な場合
• 厳格なステータスの制約なしに、より柔軟なワークフロー管理を求めている場合
• 複雑なサポートシナリオを処理できるAI搭載ヘルプデスクツールが必要な場合

移行の考慮事項（Migration considerations）

Zendeskからeesel AIなどのより柔軟なソリューションへの切り替えを検討している場合は、次の点に注意してください。

• データの保持（Data preservation）: eesel AIは、過去のZendeskチケットから学習し、組織の知識をそのまま維持できます
• ワークフローの継続性（Workflow continuity）: AIは既存のトーンとプロセスを学習し、中断を最小限に抑えます
• 段階的な移行（Gradual transition）: 完全な自動化に移行する前に、人間のエージェントのコパイロットとしてeesel AIから開始できます
• 連携オプション（Integration options）: eeselはZendeskと連携するため、AI機能を取得するためにプラットフォームを完全に切り替える必要はありません

制限なしに解決後のコミュニケーションの処理を開始する

Zendeskの「解決後のアウトバウンド」の制限は、その厳格なチケットライフサイクルアーキテクチャの副産物です。回避策は存在しますが、複雑さが増し、根本的な問題を完全に解決するわけではありません。

eesel AIのような最新のAI搭載サポートプラットフォームは、根本的に異なるアプローチを採用しています。サポートをターミナルステートを持つ個別のチケットとしてではなく、継続的な会話として扱うことで、解決後のコミュニケーションの摩擦を取り除き、時間の経過とともに改善するAI搭載機能を追加します。

Zendeskの制限との格闘にうんざりしていて、フォローアップを自然に処理するサポートソリューションが必要な場合は、eesel AIを無料でお試しください。当社のAIは数分でビジネスを学習し、従来のチケットシステムの厳格な制約なしに、最前線のサポートの処理を開始します。