Workflowが期待通りに動作しない理由を診断します。会話が間違ったチームに行く、間違ったinboxにルーティングされる、割り当てが期待通りに機能しない、またはWorkflowが完全にスキップされる場合など。主な原因はMessengerと自動化設定、トリガーと対象の不一致、Workflowの優先順位の競合、チームメンバーの操作とタイミング、チャネル設定、Fin AI Agentの競合、自動終了Workflowの失敗です。
この記事はIntercomでWorkflowsを構築・管理するチームメンバー向けです。ここで説明する修正を適用するにはWorkflowsビルダーへのアクセスが必要です。
トラブルシューティングチェックリスト
Workflowが全くトリガーされない、会話が間違ったチームやinboxにルーティングされる、割り当てが期待通りに機能しない場合、まず以下の主要なポイントを確認してください。
基本設定：Messengerはアクティブで、Workflowsは正しい対象に対して有効になっていますか？
ルールとトリガー：対象、チャネル、トリガーの条件は意図した通りに設定されていますか？
Workflowの優先順位：期待しているWorkflowの代わりに、より一般的な別のWorkflowが動作していますか？
タイミングとチームメンバーの操作：チームメンバーの返信、スケジューリング、営業時間がWorkflowの実行を妨げていませんか？
高度な条件：Ticketのステータスなど特定のデータポイントが完全に一致していますか？
会話が間違ったチームやinboxに行っていますか？
会話が間違ったチームに割り当てられたり、間違ったinboxに届いたり、ルーティングが期待通りに機能しない場合、原因はほぼ以下のいずれかです。
より優先度の高いWorkflowが代わりに動作している — 以下の「他のWorkflowが優先されている可能性は？」を参照してください。
対象が狭すぎる — Usersのみを対象とするWorkflowはLeadsをスキップし、割り当てられないかフォールバックにルーティングされます。「なぜ対象ルールが正しい顧客にマッチしないのか？」を参照してください。
割り当てステップが欠落している — Workflowに明示的なAssign to teamまたはAssign to teammateステップが含まれていない場合、会話はUnassignedに戻ります。割り当てWorkflowの記事を参照してください。
Workflowが全くトリガーされていない — Workflowが発動しなければ割り当ても発生しません。この記事を読み進めて原因を診断してください。
割り当てに関する問題（未割り当ての会話、ラウンドロビン、チームの可用性）についての完全なガイドはManage and troubleshoot assignment Workflowsをご覧ください。
Workflowトラブルシューティングツール
Workflowトラブルシューティングツールを使って条件の不一致を特定します。不一致が見つかった場合は、該当するトリガールール、対象設定、またはデータ属性をWorkflowで期待される状態に更新し、同じ会話で再テストして問題が解決したか確認してください。
Workflowsの概要に移動します。
「Troubleshoot」をクリックし、会話のURLを貼り付けます。
結果を確認して、どの条件が一致し、どれが一致しなかったかを確認します。ツールはWorkflowのトリガーを妨げているルールを強調表示します。
注意：トラブルシューティングツールは条件を順に評価し、条件が一致しない時点で停止します。つまり、最初に不一致となった条件のみが表示され、残りの条件は評価されません。
なぜMessengerがWorkflowをトリガーしないのか？
Workflow自体を確認する前に、Messengerと自動化設定が会話開始を許可するよう正しく設定されているか確認してください。
インバウンド会話設定
Control inbound conversation volumeはMessengerの設定で、誰が会話を開始できるかを制限できます。これにより顧客が会話を開始できなくなるため、「Customer opens a new conversation in the Messenger」「Customer sends their first message」「Customer sends any message」などの会話ベースのトリガーを持つWorkflowsはこれらの顧客に対して発動しません。
無効化されたMessenger
Show the Messenger LauncherはMessengerの設定で、顧客からMessengerを非表示にできます。Messengerが顧客から隠されている場合、「When a customer visits your site」「When a customer clicks on a website element」「When a customer opens the Messenger」などMessengerとのやり取りを含むWorkflowはこれらの顧客に対して発動しません。
Automationの基本
LeadsとUsers向けのSimple automations設定でconversation ratingsをオンにしている場合、inactivity triggersの正常な動作を妨げることがあります。これにより他の顧客向けWorkflowsのトリガーが意図せずブロックされることがあります。
この問題を回避するために、以下の回避策を使用してください。
基本設定で会話評価を送信する代わりに、Workflowを作成してこれらの評価を送信するべきです。これにより今後の問題を防げます。
なぜ正しいトリガータイプが発動しないのか？
メールとアウトバウンドトリガーの不一致
「Customer sends their first message」や「Customer sends any message」など特定のトリガータイプがWorkflowの起動を決定します。例えば「Customer sends their first message」は会話ごとに一度だけトリガーされ、「Customer sends any message」はその後の各メッセージでトリガーされます。この理解はWorkflowを効果的に構築し、予期しない重複を避けるために重要です。Workflowで選択するトリガーと設定方法が、誰がWorkflowにマッチしトリガーされるかを決定します。例えばIntercomのAPIを使って作成されたチケットに「When a ticket is created」トリガーを使う場合、顧客発信のメッセージが含まれないことがあり、Workflowが発動しないことがあります。
メッセージ内容フィルター
特定のアクションでWorkflowがトリガーされない場合、対象条件の不一致を確認してください。例えば特定のメールでWorkflowが発動しない場合、トリガー設定のメール条件が正しいか確認します。インバウンドメールの効果的なルーティングには「Customer Sends First Message」トリガーを使い、メール属性でフィルターすることを推奨します。アウトバウンドWorkflow（例：「Customer visits a page」）は特定のトリガー用で、通常会話開始とは連動しません。
メッセージ内容フィルターを使う場合、制限が厳しすぎないか確認してください。「Message content is」は完全一致が必要ですが、「Message content contains」は柔軟でトリガー成功率が高まります。
プロフィールタイプの不一致（Users、Leads、Visitors）
Workflowトリガー設定時に、対象設定が意図に合っているか確認してください。WorkflowがUsersのみを対象とする場合、Leads発信の会話ではトリガーされません。すべての対象グループを含めるよう対象ルールを拡張し、適切にWorkflowが起動するようにしてください。
「Customer sends their first message」Workflow設定時、初めて訪問したユーザーがMessengerを開いてWorkflowをトリガーすると、その後Leadと見なされますが、Workflow内ではプロフィールのスナップショットを使うためVisitorとして評価されます。
WorkflowがLeadsとUsersのみを対象とする場合、このVisitorではトリガーされません。すべてのプロフィールタイプを追加して、全員がWorkflowにマッチするようにしてください。
さらに、顧客がメッセージを送信するメールアドレスがWorkflowの対象とトリガー設定で適切に定義されていることを確認してください。例えば「Email to」や「Email recipient」などのフィルターを使い精度を高めます。転送メール用Workflowは転送先アドレスが正しく設定され、自動転送が有効になっていることを必ず確認してください。
例：
「Customer opens a new conversation in the Messenger」トリガーでWorkflowを設定し、これらの会話すべてにタグを付けるステップを追加しました。
顧客がOutboundから送った投稿に返信しました。
この会話はタグ付けされません。なぜならMessengerで会話を開始しておらず（Outboundメッセージに返信したため）、タグ付けの対象外だからです。
すべての会話にタグを付けたい場合は、代わりに「When customer sends any message」というトリガーを使用してください。
ターゲットは正しい人（Users と Leads）ですか？
ワークフロー（例えば、営業時間外の応答）が「Users」を対象としていて会話相手が「Lead」の場合、トリガーが発動せず自動化が期待通りに動作しません。トリガー設定でUsersとLeadsの両方を含める必要があるか常に確認してください。対象ルールの誤設定は未処理のleadsやusersを生む可能性があります。
Audience targeting rulesはWorkflowの対象者に影響します。顧客が指定された対象条件に合致しない場合、Workflowは発動しません。ワークフローをテストする際、「users only」に設定されたワークフローは、シークレットモードやユーザーが認識されないブラウザ（訪問者やleadとして識別されることが多い）では失敗することがあります。包括的なテストのために、ワークフローの対象設定を訪問者、leads、usersなど関連する参加者タイプすべてを含むように更新してください。例えば、Usersのみを対象とするワークフローはLeadsには発動しません。同様に、特定のタグや属性（例：to_drop_off_detectedのようなタグ）が必要なワークフローは、それらの条件が満たされないと発動しません。
複数のワークフローがトリガーされるはずなのに、なぜ一つだけしか実行されないのですか？
顧客向けワークフローとバックグラウンドワークフローの違い
IntercomのWorkflowsは顧客向けワークフローとバックグラウンドワークフローに分類されます。顧客向けワークフローは自動メッセージ送信など顧客に見える操作を含み、バックグラウンドワークフローは会話へのタグ付けやスレッドのクローズなど顧客に見えない操作を行います。重要なのは、単一のトリガータイプに対しては一つの顧客向けワークフローのみが実行されますが、該当するバックグラウンドワークフローはすべて実行されることです。この区別により異なるワークフローが競合せず共存できます。会話ごとに一つの顧客向けワークフローのみがトリガーされます。複数のワークフローが同じトリガーに一致する場合、Intercomはワークフロー設定で最も優先度の高いものを実行します。
会話中に実行できる顧客向けワークフローは一つだけです。顧客向けワークフローを中断し、別の顧客向けワークフローをトリガーできるのはチームメイトの操作で、以下が含まれます：
開く
開いて再割り当て
コメント送信
スヌーズ
注意：顧客向けワークフローはステップを実行中だけでなく、顧客の返信待ちの間もそのスロットを保持します。つまり、チケット作成や新しい顧客メッセージなどの後続イベントは、最初のワークフローがアクティブな限り新しい顧客向けワークフローをトリガーしません。例えば、記事提案ワークフローが会話でアクティブかつ入力待ちの場合、「When a ticket is created」ワークフローは最初のワークフローが中断または無効化されるまで発動しません。これを解決するには、ブロックしているワークフローを無効化または一時停止するか、チームメイトの操作（開く、再割り当て、コメント、スヌーズ）で中断してください。
注意：バックグラウンドワークフローはチームメイトの操作に依存せず自動で実行され、チームメイトが返信やスヌーズしても停止しません。
顧客向けワークフローが中断された後、別の顧客向けワークフローが実行可能になります。
アウトバウンドメッセージへの返信は「customer sends their first message」に設定されたワークフローのみをトリガーし、「customer opens a new conversation」に設定されたものはトリガーしません。この区別により異なる会話タイプに適切なワークフロー設定が保証されます。例えば、「First message」トリガーはアウトバウンドメールへの返信では発動しません。これらは既存会話の継続と見なされるためです。
なぜ私の対象ルールは正しい顧客にマッチしないのですか？
Audience targeting rulesはWorkflowの対象者に影響します。顧客が指定された対象条件に合致しない場合、Workflowは発動しません。
AND / ORルールは意図通りに機能していますか？
ワークフローが複数の条件を「AND」で結合していて結果が不満足な場合、いずれかの条件を満たせばワークフローをトリガーしたいなら「OR」ロジックに切り替えることを検討してください。すべての条件を満たす必要がある場合は、属性と値の設定が正しいか確認してください。「OR」ルールを対象設定で使う場合、いずれか一つの条件が真であればルールが適用されます。つまり、個々の条件のいずれかが一致すれば、他の条件が一致しなくてもワークフローがトリガーされます。
例：
City属性に基づく対象ルールを次のように設定したとします：
「City is not Dublin」OR 「City is not London」。
ユーザーがLondonにいる場合、ルールは次のように評価されます：
まず、「City is not Dublin」をチェックします → ユーザーはLondonにいるため、この条件はtrueです。
「OR」ルールは一つの条件が真であればよいため、ワークフローは二つ目の条件をチェックしません（CityがLondonでないかどうか）。ルールはすでに満たされているため、ワークフローは進行します。
つまり、DublinまたはLondonのユーザーが予期せずメッセージを受け取ったりワークフローをトリガーしたりする可能性があります。
ORルールはいずれかの条件が満たされるとトリガーされます。
否定的なORルールは、一つの条件が真になると他の条件が無視されるため、意図しないマッチを引き起こすことがあります。
すべての条件を満たす必要がある場合はANDルールを使用してください。
分岐条件は特定のワークフローステップ内ではなく、対象ルールで設定してください。
これにより、対象となる会話のみが最初からワークフローにルーティングされます。
したがって、DublinとLondonの両方のユーザーを除外したい場合は、「OR」ロジックから「AND」ロジックに切り替える必要があります：
「City is not Dublin」AND 「City is not London」。
この設定では：
ユーザーはDublinにおらず、かつLondonにもいない場合にワークフローがトリガーされます。
どちらかの都市にいる場合、対象ルールは一致せずワークフローはトリガーされません。
重要なポイント
IntercomのWorkflow対象ルールを設定する際：
ORルールはいずれかの条件が満たされるとトリガーされます。
否定的なORルールは、一つの条件が真になると他の条件が無視されるため、意図しないマッチを引き起こすことがあります。
すべての条件を満たす必要がある場合はANDルールを使用してください。
個人データと会社データ
ワークフローには個人データや会社データに基づく特定のトリガーがある場合があります。これらはIntercomで利用可能な標準またはカスタムデータ属性のいずれかです。トリガーの条件や基準を確認し、データが正しく入力され設定ルールに合致していることを確認してください。
例：
ワークフローで分岐を使用する場合、次の条件をチェックするとき：
「Company attribute is not」。
条件を満たすには顧客が会社に紐づいている必要があります。会社がない場合、条件が真と判断せず別の経路にフォールバックします。
会話がワークフローのロジックでルーティングされる際、特定の会社が設定されていない場合はユーザーに最も最近更新された会社が使用されます。否定的なORルールを使った分岐条件は順序に注意しないと予期せぬルーティングを引き起こす可能性があります。セッションで会社を指定し、分岐の順序を確認して正しいルーティングを確保してください。
「Last heard from」を使った対象ルールは直前にメッセージを送った連絡先にマッチしない
ワークフローで「Last heard from is unknown」や「Last heard from is more than X days ago」のような対象ルールを使うと、直前にメッセージを送った顧客に対してワークフローが発動しないことがあります。プレビューでは対象に見えても実際には発動しません。
これは予期された動作です。受信メッセージが届くと、Intercomはワークフローの対象マッチングが行われる前に連絡先の「Last heard from」タイムスタンプを更新します。マッチング評価時には連絡先は直前に連絡があった状態となり、両条件はfalseとなり送信者に対してワークフローは発動しません。
注意：対象サイズプレビュー（例：「980 people in your audience」）は現在の属性値を読み取り誤解を招くことがあります。実際のマッチングは受信メッセージ更新後に評価されるため、プレビューに表示される連絡先が実際にはマッチしないことがあります。これはMessenger、メール、SMSなどすべての受信チャネルに当てはまります。
推奨される代替案：
すべてのinboundメッセージに連絡履歴に関係なく対応するには：「Last heard from」ルールを完全に削除し、関連チャネルのLeadsとUsersをターゲットにしてください。
まったく新しい連絡先のみをターゲットにするには：「Signed up is unknown」を使用してください。この属性はinboundメッセージによってリセットされないため、競合状態はありません。
休眠中の連絡先に再アプローチするには：「Last contacted is more than X days ago」を使用してください。「Last contacted」属性は最後に送信したoutboundメッセージの日時を記録し、顧客からの返信では更新されないため、マッチング時点で正確です。
タイミング、スケジューリング、またはチームメンバーのアクションがworkflowをブロックしている可能性はありますか？
スケジューリングの使用により、Workflowが有効になる時間と期間を制御できます。Workflowが発動しないのは、スケジュールされた条件が満たされていない場合が多いです。外部要因により、すべてのルールが正しくてもworkflowが実行されないことがあります。
チームメンバーが先に返信またはアクションを取りましたか？
チームメンバーが会話を開いたり、再割り当てしたり、コメントを送信すると、アクティブな顧客向けworkflowが中断・終了することがあります。同様に、workflowに時間遅延がある場合、遅延終了前にチームメンバーが返信するとキャンセルされます。さらに、最後のメッセージがチームメンバーではなくbotから送信された場合、応答なしトリガーが発動しないことがあります。
スヌーズされた会話と応答なしトリガー
スヌーズされた会話をトリガー条件に使うworkflowでは、顧客が応答しなくなるまで会話が継続してスヌーズ状態である必要があります。チームメンバーや自動タイマーによって会話がスヌーズ解除されると、顧客が後で応答しなくなっても非アクティブトリガーは発動しません。
注意：会話がスヌーズ解除され、その後顧客が応答しなくなっても、応答なしトリガーは再発動しません。トリガーを再度機能させるには、顧客が最初に返信して会話を再開し、その後会話がスヌーズ状態のまま再び応答しなくなる必要があります。
カスタム日付スケジュール
Workflowにはカスタム日付スケジュールが設定されている場合があります。例えば、金曜夜から土曜朝までのみ発動するなど。この場合、これらの時間外でWorkflowをテストしても、どのトリガーを選択しても発動しません。例えば、Workflowが土曜の00:00〜08:00 GMTに設定されている場合、同日の20:01 UTCのイベントでは発動しません。
営業時間
Workflowが発動する時間帯として営業時間を設定している場合があります。営業時間内または営業時間外のいずれかです。Workflowは個別チームのカスタム営業時間ではなく、デフォルトの営業時間のみを使用します。
営業時間ルールはWorkflowのトリガー設定ではなく、条件分岐としてWorkflow内に組み込むことを推奨します。
トリガー設定は顧客がMessengerとやり取りした時に評価されますが、分岐は会話中にリアルタイムで評価されるため、時間ベースの条件処理に優れています。
Workflowsは遡及的に適用されません
Workflowは作成・公開後に開始された会話にのみトリガーされます。Workflow作成前に始まった会話には適用されません。既存の会話を扱うには手動管理するか、既存の会話属性に作用するバックグラウンドworkflowを使用してください。
チャネル設定がworkflowを妨げている可能性はありますか？
WorkflowがEmail、SMS、ソーシャルメディアなどの特定チャネルに設定されている場合、そのチャネルが正しく接続されてアクティブであることを確認してください。チャネルの切断がWorkflowが発動しない原因かもしれません。また、workflowのチャネル設定がユーザーの操作方法と一致しているか確認してください。例えば、workflowが「email」のみでトリガーされる設定で、ユーザーがMessengerで操作するとworkflowは発動しません。Email workflowの場合、設定でEmailチャネルが有効になっていることを確認してください。このチャネルが有効でないとEmail会話はworkflowをトリガーしません。例えば、Web、iOS、Androidチャネルを対象とするworkflowはEmail会話では発動しません。
Emailを含むworkflowでは、トリガー設定でEmailチャネルが正しく設定されアクティブであることを確認してください。また、Simple Deployが有効になっている場合、Email workflowを上書きする可能性があります。
注意：
「When customer sends their first message」workflowで顧客向け要素が含まれる場合、同じ顧客が開始した新しい会話間に2分以上の間隔が必要です。2分未満の場合、workflowは発動しません。この制限は顧客向けworkflowのみで、タグ付けや会話割り当てなどのバックグラウンドworkflowには適用されず、実行されます。
特にinboundのemail会話では、同じ送信者から数秒以内に複数のメールが届く場合、「Customer sends their first message」トリガーで捕捉されるのは最初の1〜2通のみです。その後の同時送信メールは「Customer sends any message」トリガーにのみマッチします。会話が自動化なしで未割り当てで届く場合、このバースト現象が原因かもしれません。対処法として、影響を受けた会話内でCmd/Ctrl + K > Trigger reusable workflowを使い手動で再利用可能workflowを起動してください。
同じworkflowが複数回トリガーされるのを防ぐには？
顧客メッセージに応答するworkflowを設定する際、特にユーザーが追加情報を送る場合に、同じworkflowが会話内で複数回トリガーされるのを防ぎたいことがあります。
解決策：会話タグを使ってworkflowトリガーを制御する
workflowが実行された会話に特定のタグ（例：「Pricing」）を追加してください。
workflowがトリガーされる前に、このタグがないことを確認するよう設定してください。
この方法により、各workflowは会話ごとに一度だけトリガーされ、重複した自動応答を防げます。
workflowで参照されるタグは会話タグであることを確認してください。ユーザータグは会話レベルのフィルターやworkflowでは使用できません。
このタグ付けシステムは、「Customer sends their first message」や「Customer sends any message」などの条件でトリガーされるworkflowに特に有効です。フォローアップメッセージが自動化を再トリガーするのを防ぎます。さらに、タグは会話ごとに一度だけ適用されます。既にタグが追加されている場合、workflowは再適用しません。
なぜworkflowが正しいページURLでトリガーされないのですか？
Workflowが正しいページURLやiOS・Androidアプリ内で発動するよう正しく設定されているか確認してください。設定ミスがworkflow未発動の原因になることがあります。
URLターゲティングのベストプラクティス
現在のページURLターゲティングは、「送信先」セクションまたはトリガールール設定内のメインのAudienceターゲティングセクションに追加できます。ただし、配置場所によって機能が異なります。
Audience Targeting：ここでのURL設定は最後に訪れたページに基づいてユーザーをターゲットにします。このデータは常に最新とは限らず、不正確なworkflow発動につながることがあります。
送信先：ユーザーが現在いる実際のページに基づくより信頼性の高いターゲティングを提供します。通常、望ましい結果に一致します。
注意：送信先セクションでURLターゲティングを使用すると、iOS・Androidのinbound botが無効になります。モバイルアプリはURLを認識しないためです。URLターゲティングが重要な場合は、Web Messenger用のbotとiOS・Android用のURLルールなしbotを別々に作成してください。
シングルページアプリ（SPA）での現在のページURL
workflow条件の現在のページURL属性はMessengerセッション開始時に追跡されたURLを反映しており、顧客の実際の現在ページではありません。SPAではページ全体のリロードなしにナビゲーションが行われるため、URLが古く見え、顧客が現在見ているページと一致しないことがあります。
注意：これはSPAのナビゲーション処理の既知の制限です。Messenger JSは完全なページ読み込み時のみ再初期化されるため、動的なURL変更は自動的に追跡されません。
回避策：Intercom Messenger JS APIを使い、SPAのルート変更時に現在のURLをカスタムデータ属性としてプッシュしてください。そのカスタムデータ属性をworkflowのURL条件として使用し、現在のページURLに依存しないようにできます。
API作成会話のタイミング問題
'現在のページURL'条件に依存するworkflowはAPI作成会話で失敗することがあります。URL報告時とAPIによる会話作成時にタイミング差があり、URL条件が間に合わない場合があります。APIで会話を作成しURLベースのトリガーに依存する場合は、慎重にテストするかURL以外の条件を使用してください。
workflow分岐内のURL条件
workflow分岐内のURL条件は会話作成時に評価されます。会話開始後に顧客が別のURLに移動しても、分岐条件は更新されず、Elseパスが選択されます。これを考慮して分岐ロジックを設計し、Messenger JS APIで更新されるデータ属性を使った動的URL追跡を検討してください。
なぜFacebook/Instagram会話で「現在のページURL」が機能しないのか
「現在のページURL」フィルターはIntercom Messengerがインストールされているページにのみ適用されます。つまり、Facebookなどの外部プラットフォーム発の会話のURLはキャプチャされません。これらのやり取りはウェブサイト外で行われるためです。
異なるチャネル（例：FacebookやInstagram）からの会話を適切にフィルタリングするには、「Page URL」フィルターを使用してください。このフィルターは参照元ページや外部ソースを追跡でき、会話が始まった場所に基づいて正しくWorkflowsをセグメント化しトリガーできます。
記事ページでWorkflowsがトリガーされない
記事ページでworkflowがトリガーされない場合は、記事URLをブロックしている可能性のあるオーディエンス除外ルールを確認してください。
設定 → Messenger → Messenger Widget → Messenger Launcherを表示に移動し、URLベースの条件付き表示ルールが有効かどうかを確認してください。
ルールがhelp centerドメイン（例：
intercom.com/help/*）に一致するURLでMessengerを非表示にしている場合、記事ページでMessengerが読み込まれません。Messengerがないと、Messengerのやり取りに依存するWorkflowは発動しません。これを修正するには、help centerのURLパターンに例外を追加するか、不要な場合は除外ルールを削除してください。
注意：これはMessengerのやり取りを含むWorkflows（例：「顧客がページを訪れたとき」「顧客がMessengerを開いたとき」）にのみ影響します。バックグラウンドWorkflowやメールWorkflowはMessengerの表示設定に影響されません。
他のworkflowが私のworkflowより優先されている可能性はありますか？
会話が複数の有効なworkflowのルールに該当する場合、Intercomは最も優先度の高いものだけを実行します。会話内で同時に実行できる顧客向けworkflowは1つだけです。
他のWorkflowが先に実行されていますか？
Workflowsは設定内の上から下へのリストで優先順位が決まります。一般的なworkflowがリストの上位にあると、それがトリガーされ、より具体的なworkflowが実行されないことがあります。重要なworkflowが優先されるように優先順位を調整してください。
例：リストの上位にある一般的な「Welcome」workflowは、顧客がVIPであっても下位の「VIP Clients」workflowを上書きします。
なぜチームに割り当てると既存の個人割り当てがクリアされるのですか？
会話が個人のチームメイトに割り当てられた直後にチームに割り当てると、その個人割り当てはクリアされます。workflowのロジックで同じステップまたは次のステップでチーム割り当てがある場合、チーム割り当てが個人割り当てを上書きします。これを避けるには、意図的にチーム割り当てを行う場合を除き、連続して両方の割り当てを行わないようにしてください。
これを修正するには:
Fin AI Agentの設定がworkflowをブロックしている可能性はありますか？
Fin AI Agentは時にWorkflowsと干渉し、予期しない動作を引き起こすことがあります。Fin関連の一般的なworkflow問題への対処法は以下の通りです。
FinとWorkflowの優先順位（Simple deploymentの場合）
同じオーディエンスに対してFinのSimple deploymentとWorkflowsが有効な場合、Simple deploymentが優先され、Finのみが応答します。Workflowsをトリガーさせるには、オーディエンスのターゲティングが重複しないよう調整するか、Simple deploymentを無効にしてください。
Fin Workflowのクローズ時にCSATを有効にする
Finが会話をクローズした際、Customer Satisfaction Score（CSAT）Workflowは自動的にトリガーされません。CSAT調査を送信するには、Workflow内で「Let Fin answer」ステップを設定してください。詳細はFin CSATドキュメントを参照してください。
古い会話でCSATが送信される
WorkflowでトリガーされたCSAT調査は、最後のメッセージが7日以上前でも会話終了時に送信されることがあります。これは7日間の無応答制限がIntercomの一般的な自動CSATにのみ適用され、workflowトリガーの調査には適用されないためです。
除外タグがあってもCSATが送信される場合がある
Workflow条件がORロジックを使用している場合や、除外タグ（例：「no_csat」）が同じ述語グループに含まれていない場合、CSAT調査が送信されることがあります。これを防ぐには:
条件をANDロジックで単一の述語グループにまとめ、除外タグを他の条件と一緒に評価するよう設定してください。
CSAT Workflowのターゲティング問題
CSAT Workflowはターゲティングが厳しすぎると特定のユーザーやチャネルでトリガーされないことがあります。例えば、ログインユーザーに限定するとleadsは除外されます。すべてのユーザーを含めるには:
WorkflowのオーディエンスをUsersとLeadsの両方に更新してください。
Fin-first WorkflowでCSATが送信されない場合のステップバイステップ修正
Workflow BuilderでFin-first workflowを開きます。
「Let Fin answer」ステップを編集します。
「会話評価（CSAT）を依頼する」を有効にし、送信タイミング（例：解決確認後または非アクティブ時）を指定します。
Workflowを保存して有効化します。注意：Simple Automation CSATは人間が返信した会話にのみ適用され、Fin解決の会話にはWorkflowでCSATを処理する必要があります。
ユーザーが繰り返し同じ質問をされる
「問題のコンテキストを事前に取得する」に設定されたWorkflowsは、ユーザーに同じ情報（例：名前、メール）を繰り返し尋ねることがあります。これを修正するには、Fin AI Agent > Simple Automation > 問題のコンテキストを事前に取得するをUsersとLeads両方でオフにしてください。
FinのSales会話でメールキャプチャプロンプトが表示されない
Workflowステップでリードのメールアドレスを取得するよう設定しているのに、FinのSales会話でプロンプトが表示されない場合は以下を確認してください。
「問題のコンテキストを事前に取得する」の競合：Fin AI Agent > Simple AutomationでLeadsに対して「問題のコンテキストを事前に取得する」が有効だと、FinのSales Workflowでのメールキャプチャステップが抑制されることがあります。Fin for Salesは独自にリードの資格確認を行うため、両者が競合し、メールプロンプトがスキップされる可能性があります。これを修正するには、Simple AutomationでLeadsの「問題のコンテキストを事前に取得する」を無効にし、Workflow内の専用メールキャプチャステップに依存してください。
Workflowの優先順位の競合：より優先度の高い顧客向けWorkflowがメールキャプチャWorkflowの代わりに実行されている可能性があります。Workflowの優先順位を確認し、Fin for Sales Workflowが一般的なキャプチャやWelcome Workflowより上位にあることを確認してください。
リードに既にメールアドレスがある場合：Intercomが以前のセッションでリードのメールアドレスを保持している場合、メールキャプチャステップはスキップされることがあります。メール属性が不明な場合のみステップを表示するオーディエンスルールを追加してください。
注意：Fin for Sales Workflowのメールキャプチャステップには、リードのメールが既に知られている場合のフォールバック分岐を必ず含めてください。そうしないと、リードの再訪時にステップがWorkflowの残りの実行を妨げる可能性があります。
FinのSimple deploymentによる干渉
FinのSimple deploymentが有効だと、カスタムWorkflowが上書きされ、訪問者は設定したIntercom WorkflowではなくFinの展開を見ることがあります。Workflowが期待通りにトリガーされない場合は、「Simple Deploy for Fin」を無効にしてWorkflowがユーザーにトリガーされるようにしてください。
Fin Workflowがメール処理に失敗する
メールベースのWorkflowは、指定されたアドレスからIntercomへのメール転送が正しく行われていないと失敗することがあります。メール転送設定を再確認してください。ここでのエラーはメール処理を妨げることが多いです。転送されたメールがWorkflowのフィルター内で意図した受信者アドレスを正しく含んでいるか確認してください。また、自動転送が「ON」になっていること、Workflow設定が指定された転送元からのメールを完全に処理できることを確認してください。メールがWorkflowをトリガーしない場合は、Workflowまたはオーディエンスターゲティングで正しいメールアドレスが設定されているか確認してください。サポートメールをWorkflowのトリガー条件に追加すると問題解決に役立ちます。
メール転送とWorkflowルール
メールが配信リスト経由で転送される場合、DMARC（Domain-based Message Authentication, Reporting and Conformance）準拠によりヘッダーが書き換えられ、ドメイン条件が一致しないことがあります。
元の送信者情報を保持するには:
配信リスト（例：Google Groups）を避け、サーバー側ルーティング（例：GoogleやMicrosoft 365のリダイレクト）でメールを転送してください。
workflow評価におけるレースコンディションの防止
Workflowsは、評価後に再割り当てが処理されると誤ってトリガーされる可能性があります。
このようなエラーを最小限に抑えるには：
除外条件が最初に適用されるように条件の順序を確認する。
再割り当てシナリオでWorkflowsを徹底的にテストする。
Finによる誤分類の回避
IntercomのworkflowでFinが会話を誤分類している場合は、属性の説明を改善してマッチングを向上させてください：
各属性に対して明確で文脈に沿った説明を書く。
顧客のフレーズに一般的に関連するドメイン固有のキーワードを追加する。
サンプル会話で説明をテストする。
なぜ自動クローズworkflowが期待通りに動作しないのか？
自動クローズworkflowは、顧客の非アクティブ状態や事前定義されたworkflowアクションなどの特定のトリガーと条件に基づいて会話を自動的に閉じます。これによりinboxが整理され、会話の迅速な解決が保証されます。このセクションは、自動クローズworkflowがトリガーされない、早すぎる閉鎖、または予期せぬ中断が発生する場合に使用してください。
注意：自動クローズ機能は放棄されたworkflow会話にのみ適用されます。通常のチャットやユーザーの応答を待つアウトバウンドメッセージはアクティブとは見なされず、自動クローズされません。
自動クローズWorkflowの設定
自動クローズworkflowを作成するには、IntercomアプリのFin AI Agent Workflowsに移動します。+ New workflowを選択し、テンプレートFollow up with inactive customersを選びます。非アクティブタイマーを設定して、workflowをトリガーするまでの顧客の応答待機時間を決定します。期間は3秒から14日までです。適用するチャネル（例：Web、iOS、Android、email、SMS）を指定します。
なぜ自動クローズworkflowがトリガーされなかったのか？
自動クローズworkflowがトリガーされない一般的な理由：
該当期間中の障害を確認してください。アクティブなインシデントがworkflowの実行を妨げている可能性があります。
トリガー条件が会話の状態と一致していることを確認してください。例えば、対象が「Users」のみの場合、workflowは「Leads」にはトリガーされません。対象ルールを拡大して関連するすべてのプロフィールタイプを含めてください。
自動クローズworkflowが不適切に実行される場合、最も一般的な原因は：
Simple deploymentの競合：同じ対象に対してFinのSimple deployment（一段階のFin設定で完全なworkflowロジックなし）が有効な場合、優先されて自動クローズworkflowのトリガーを妨げることがあります。これを解決するには、Simple deploymentを無効にするか、対象の重複を避けるように調整してください。
チームメイトの操作によるworkflowの中断：会話の開封、再割り当て、コメントなどのチームメイトの操作は、アクティブな自動クローズworkflowを中断し、会話の閉鎖を妨げることがあります。非アクティブトリガーに依存するworkflowは、チームメイトの操作で非アクティブタイマーがリセットされると失敗する可能性があります。
2分間のクールダウン：顧客向けアクション（メッセージ送信など）を含むworkflowは、同一顧客に対してトリガー間に2分のクールダウンがあります。これは自動応答ループを防ぎますが、その間に会話が再開された場合、自動クローズが発動しないことがあります。安定した自動クローズのためには、顧客向けメッセージステップではなく、閉鎖やタグ付けなどの非表示バックグラウンドアクションのみを使用した別workflowを作成してください。
なぜ自動クローズworkflowが予期せずトリガーされたのか？
自動クローズworkflowが不適切に実行される場合、最も一般的な原因は：
対象ルールを確認してください。特にOR条件は1つの条件が満たされればよいため、いずれかの条件が真の場合に顧客が意図せずworkflowにマッチすることがあります。
会話状態の変化を確認してください。例えば、チケットが「waiting_on_customer」にマークされると、トリガー条件を予期せず満たすことがあります。
なぜ会話が早すぎるか、または全く閉じないのか？
タイムドチャットクローズにタグを使用する
特定期間後にチャットを閉じるには、タグベースの方法を使用します：
顧客に促す際に会話タグ（例：「Agent?」）を追加する。
顧客が応答した場合はタグを削除する。
指定時間後にこのタグが付いた会話を閉じるworkflowを設定する。
会話がエージェントに割り当てられた際にタグが削除されるようにして、早期閉鎖を防ぐ。
workflow内の各Let Fin answerブロックには独自の自動クローズタイマーがあります。タイマーが短すぎると、顧客が十分に応答する前に会話が閉じることがあります。これを修正するには、Let Fin answerブロックをクリックし、自動クローズ設定を開いてタイマーの時間を延長してください。
さらに、「Let Fin Answer」ブロック内の「3分後に放棄されたFin会話を閉じる」という設定を確認してください。この設定を無効にすると、会話はチームメンバーが手動で閉じるまで開いたままになります。
workflowが実行されているのに会話が全く閉じない場合は、以下を確認してください：
割り当てルールがworkflow終了後に会話を再開していないか確認する。
Set expectation for human supportオプションを無効にすると、Auto-close abandoned workflow conversationsのチェックボックスも無効になります。これは人間へのエスカレーションが設定されている場合のみ利用可能です。エスカレーションなしで自動クローズを目指す場合は、workflowを調整してください。
自動クローズ設定はworkflowのトリガータイプに合わせて一貫性を持たせてください。例えば、非アクティブトリガーには同じブロックで非アクティブタイマーを設定する必要があります。
workflow設定で「If Fin has answered the question」オプションがチェックされていることを確認してください。これにより新しい会話の自動クローズが保証されます。
メールworkflowの自動クローズ
メールベースのworkflowでは、自動クローズ設定が転送メールに対応していることを確認してください。自動クローズアクションがworkflowのトリガー条件と一致し、転送メールに意図した受信者アドレスが含まれていることを確認して、workflowが正しくマッチできるようにします。
注意：再利用可能なworkflowでCloseアクションステップを追加することは、複雑な分岐フローで確実に閉じる最も信頼できる方法です。再利用可能なworkflowで非アクティブタイマーのみに頼らないでください。
訪問者トリガーworkflowでデータコネクターが失敗する理由は？
データコネクターは識別されたコンタクトとアクティブな会話が必要です。ページ訪問時にworkflowがトリガーされてすぐにデータコネクターが実行されると、識別されていない訪問者では失敗します。訪問者トリガーworkflowでデータコネクターを確実に使用するには：
ページ訪問時にworkflowをトリガーする。
ボタン付きのメッセージを表示する。
ボタンがクリックされた後にデータコネクターを実行する。この時点で会話が存在し、コンタクトが識別される。
これらの点を確認し、適切な設定を確認することで、Workflowが発火しない潜在的な原因を特定できるだけでなく、将来の運用に向けて正しく設定されていることを保証できます。👌
それでもWorkflowのデバッグが必要な場合は、Messengerを通じてサポートチームにお問い合わせください。
注意: iOSおよびAndroidのモバイルMessengerでは、Workflowステップで追加された埋め込み記事カードはユーザーに表示されません。モバイルユーザーがHelp Centerのコンテンツにアクセスできるようにするには、ハイパーリンク付きテキストを使用するか、記事に直接リンクするURLボタンを追加してください。