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