この文章を使って、Workflowが期待通りに動作しない理由を診断してください。主な原因は、Messengerと自動化設定、トリガーとオーディエンスの不一致、workflowの優先順位の競合、チームメンバーの操作とタイミング、チャネル設定、Fin AI Agentの競合、自動終了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は、これらの顧客に対しては決して発火しません。

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は、これらの顧客に対しては決して発火しません。

LeadsとUsers向けのconversation ratingsをSimple automations settingsでオンにしている場合、inactivity triggersの正常な動作を妨げることがあります。これにより、他の顧客向けWorkflowsのトリガーが意図せず中断される可能性があります。

この問題を回避するには、次の回避策を使用してください。

基本設定で会話評価を送信する代わりに、Workflowを作成してこれらの評価を送信するべきです。これにより今後の問題を防げます。

Workflowのトリガーとオーディエンスルールを確認してください

Workflowトラブルシューティングツールを使って不一致の条件を特定してください。

「Customer sends their first message」や「Customer sends any message」などの特定のトリガータイプが、どのworkflowが起動するかを決定します。例えば、「Customer sends their first message」は会話ごとに一度だけトリガーされ、「Customer sends any message」はその後の各メッセージでトリガーされます。この理解は、予期しない重複なくworkflowを効果的に構築するために重要です。workflowのトリガー選択と設定が、誰がworkflowにマッチしトリガーされるかを決定します。例えば、APIで作成されたticketsに「When a ticket is created」トリガーを使うと、顧客発信のメッセージが含まれず、workflowが発火しないことがあります。

特定のアクションでworkflowがトリガーされない場合、ターゲット条件の不一致を確認してください。例えば、特定のメールでworkflowがトリガーされない場合、トリガー設定のメール条件が正しいか確認します。インバウンドメールの効果的なルーティングには、「Customer Sends First Message」トリガーを使い、メール属性でフィルターすることを推奨します。なお、「Customer visits a page」などのアウトバウンドworkflowは特定のトリガー用で、通常会話開始とは連動しません。

workflowがメッセージ内容フィルターを使う場合、制限が厳しすぎないか確認してください。「Message content is」は完全一致が必要ですが、「Message content contains」は柔軟でトリガー成功率が上がります。

workflowトリガー設定時に、オーディエンス構成が意図に合っているか確認してください。workflowが「Users」のみを対象に設定されている場合、「Leads」発信の会話ではトリガーされません。適切なworkflow発動のために、対象オーディエンスをすべての関連グループに拡大してください。

「Customer sends their first message」workflow設定時、初めての訪問者がMessengerを開いてworkflowをトリガーすると、その後リードと見なされますが、workflow内ではプロフィールのスナップショットを使うため訪問者として評価されます。

WorkflowがLeadsとUserのみを対象にしている場合、このVisitorにはトリガーされません。すべてのプロフィールタイプを追加して、全員がWorkflowにマッチするようにしてください。

さらに、顧客がメッセージを送信するメールアドレスがworkflowのターゲットオーディエンスとトリガー設定内で適切に定義されていることを確認してください。精度を高めるために「Email to」や「Email recipient」などのフィルターを使用します。転送メールを処理するworkflowは、転送先アドレスが正しく設定され、自動転送が有効になっていることを常に確認してください。

例：

workflowが「Users」を対象にしているのに会話相手が「Lead」の場合（例えば営業時間外の応答）、workflowは期待通りに動作しません。workflowのトリガー設定にUsersとLeadsの両方を含めるべきか常に確認してください。オーディエンスルールの誤設定は、未処理のleadsやusersを生む可能性があります。

Audience targeting rulesはWorkflowの影響範囲に影響します。顧客が指定されたオーディエンス条件に合わない場合、Workflowは発火しません。テスト時、"users only"設定のworkflowは、シークレットモードやユーザーが認識されないブラウザ（訪問者やleadとして識別されることが多い）で失敗することがあります。包括的なテストには、workflowのオーディエンス設定を訪問者、leads、usersすべてを含むよう更新してください。例えば、Usersのみを対象にしたworkflowはLeadsにはトリガーされません。同様に、特定のタグや属性（例：to_drop_off_detected）が必要なworkflowは、条件が満たされないとトリガーされません。

IntercomのWorkflowsは顧客向けとバックグラウンドのworkflowに分類されます。顧客向けworkflowは自動メッセージ送信などの目に見えるやり取りを含み、バックグラウンドworkflowは会話のタグ付けやスレッドのクローズなど顧客には見えない操作を行います。単一のトリガータイプに対しては、顧客向けworkflowは1つだけ実行されますが、該当するすべてのバックグラウンドworkflowは実行されます。この区別により、異なるworkflowが競合せず共存できます。1つの会話で実行される顧客向けworkflowは1つだけです。同じトリガーに複数のworkflowがマッチする場合、Intercomはworkflow設定で最も優先度の高いworkflowを起動します。

会話中に実行できる顧客向けworkflowは1つだけです。顧客向けworkflowを中断し、別の顧客向けworkflowを起動できるチームメンバーの操作には、
​
​開く
開いて再割り当て
コメント送信が含まれます。

スヌーズ

顧客向けworkflowが中断された後、別の顧客向けworkflowが自由に開始できます。

アウトバウンドメッセージへの返信は、「customer sends their first message」に設定されたWorkflowsのみをトリガーし、「customer opens a new conversation」に設定されたものはトリガーしません。この区別により、異なる会話タイプに対してWorkflowsが正しく設定されていることを保証します。例えば、「First message」トリガーは、既存の会話の続きとして扱われるアウトバウンドメールへの返信には発火しません。

Audience targeting rulesはWorkflowの対象者に影響を与える可能性があります。顧客が指定されたオーディエンス基準に合致しない場合、Workflowは発火しません。

Workflowが複数の条件を「AND」で結合していて結果が満足できない場合、いずれかの条件を満たすことでWorkflowをトリガーしたい場合は「OR」ロジックに切り替えることを検討してください。すべての条件を満たす必要がある場合は、属性と値の設定が正しく整合していることを確認してください。Audience targetingで「OR」ルールを使用する場合、1つの条件が真であればルールが適用されます。つまり、個々の条件のいずれかが一致すれば、他の条件が一致しなくてもWorkflowがトリガーされます。

例：

City属性に基づくオーディエンスルールを次のロジックで設定したとします：

「City is not Dublin」OR 「City is not London」。

ユーザーがLondonにいる場合、ルールは次のように評価されます：

つまり、DublinまたはLondonのユーザーは予期せずメッセージを受け取ったりWorkflowをトリガーしたりする可能性があります。

したがって、DublinとLondonの両方のユーザーを除外したい場合は、「OR」ロジックから「AND」ロジックに切り替える必要があります：

「City is not Dublin」AND 「City is not London」。

この設定では：

Workflowには個人データや会社データに基づく特定のトリガーがある場合があります。これらはIntercomで利用可能な標準またはカスタムデータ属性のいずれかです。これらのトリガーの基準と条件を確認し、データが正しく入力され設定ルールに合致していることを確認してください。

例：

Workflowで分岐を使用する場合、次のようにチェックします：

「Company attribute is not」。
​
顧客は条件ルールを満たすために会社に紐づいている必要があります。会社がない場合、その条件が真であるとはみなさず、代わりに別のパスにフォールバックします。

会話がWorkflowロジックでルーティングされる場合、特定の会社が設定されていなければ、システムはユーザーに関連付けられた最新の会社を使用します。また、否定的なORルールを使用した分岐条件は、順序が適切でないと予期しないルーティングを引き起こす可能性があります。セッションで会社を指定し、分岐の順序を確認して正しいルーティングを確保してください。

スケジューリングの使用により、Workflowがいつ、どのくらいの期間ライブになるかを制御できます。Workflowが発火しないのは、スケジュールされた条件が満たされていない場合が多いです。外部要因により、すべてのルールが正しくてもWorkflowが実行されないことがあります。

チームメイトが会話を開いたり、再割り当てしたり、コメントを送信した場合、アクティブな顧客向けWorkflowは中断され終了します。同様に、Workflowに時間遅延がある場合、遅延終了前にチームメイトが返信するとキャンセルされます。さらに、最後のメッセージがチームメイトではなくボットから送信された場合、応答なしトリガーに依存するWorkflowは起動しないことがあります。

Workflowにはカスタム日程スケジュールがある場合があります。例えば、金曜夜から土曜朝までの間のみ発火する設定です。この場合、これらの時間外でWorkflowをテストしても、どのトリガーを選択してもWorkflowは発火しません。例えば、Workflowが土曜の00:00〜08:00 GMTに実行される設定の場合、同日の20:01 UTCのイベントでは発火しません。

Workflowが発火する時間帯として営業時間を設定している場合、営業時間内または営業時間外のいずれかです。Workflowは個別チームのカスタム営業時間ではなく、デフォルトの営業時間のみを使用します。

Workflowsは作成されライブ設定された後に始まった会話にのみトリガーされます。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が上書きされる可能性があります。

顧客メッセージに応答するWorkflowを設定する際、特にユーザーが追加の詳細を追記した場合に、同じWorkflowが会話内で複数回トリガーされるのを防ぎたいことがあります。

このタグ付けシステムは、「Customer sends their first message」や「Customer sends any message」のような条件でトリガーされるworkflowに特に有効で、フォローアップメッセージが自動化を再トリガーするのを防ぎます。

workflowがスムーズに動作するためのベストプラクティスをいくつか紹介します：

workflowが正しいページURLやiOS・Androidデバイスの正しいアプリ内で発火するように設定されていることを確認してください。これらの設定の誤りはworkflowのトリガーを妨げる可能性があります。

現在のページURLターゲティングは、「Where to send」セクションまたはTrigger rule設定内のメインのAudienceターゲティングセクションに追加できます。ただし、配置されるセクションによって機能が異なります：

「現在のページURL」フィルターはIntercom Messengerがインストールされているページにのみ適用されます。つまり、Facebookのような外部プラットフォームから始まる会話のURLはキャプチャされません。これらのやり取りはウェブサイト外で行われるためです。

異なるチャネル（例：FacebookやInstagram）からの会話を正しくフィルタリングするには、「ページURL」フィルターを使用してください。このフィルターは参照元ページや外部ソースを追跡でき、会話が始まった場所に基づいてworkflowを正しくセグメント化しトリガーできます。

会話が複数のアクティブなworkflowのルールに合致する場合、Intercomは最も優先度の高いworkflowのみを実行します。会話内で同時に実行できる顧客向けworkflowは1つだけです。

workflowは設定内の上から下へのリストで優先順位が決まります。一般的なworkflowがリストの上位にあると、より特定のworkflowが下位にあっても実行を妨げることがあります。重要なworkflowが優先されるように優先順位を調整してください。

例：リストの上位にある一般的な「Welcome」workflowは、顧客がVIPであっても下位の特別な「VIP Clients」workflowを上書きします。

これを修正するには、Settings > Workflowsでworkflowの順序を変更します。最も特定かつ重要なworkflowをリストの上位にドラッグし、一般的で包括的なworkflowは下位に配置してください。

Fin AI Agentは時にworkflowと相互作用し、予期しない動作を引き起こすことがあります。Fin関連のworkflow問題への対処法は以下の通りです：

FinのSimple Deployとworkflowが同じオーディエンスに対して有効な場合、Simple Deployが優先され、Finのみが応答します。workflowをトリガーさせるには、オーディエンスターゲティングが重複しないように調整するか、Simple Deployを無効にしてください。

Finが会話をクローズしてもCSAT workflowは自動的にトリガーされません。CSAT調査を送信するには、workflow内で「Let Fin answer」ステップを設定してください。詳細はFin CSATドキュメントを参照してください。

「Get context about issue upfront」に設定されたworkflowは、ユーザーに同じ情報（例：名前、メール）を繰り返し求めることがあります。これを修正するには、Fin AI Agent > Simple Automation > Get context about issue upfrontの設定をユーザーとleads両方でオフにしてください。

FinのSimple Deployが有効だと、カスタムworkflowが上書きされ、訪問者は設定したIntercom workflowではなくFinの展開を見ることがあります。workflowが期待通りにトリガーされない場合は、「Simple Deploy for Fin」を無効にしてworkflowがユーザーにトリガーされるようにしてください。

メールベースのworkflowは、指定されたアドレスからIntercomへの正しい転送がされていないと失敗することがあります。メール転送設定を再確認してください。ここでのエラーはメール処理を妨げることが多いです。転送されたメールにworkflowのフィルター内で意図した受信者アドレスが正しく含まれているか確認してください。さらに、自動転送が「ON」になっていることと、指定された転送アドレスからの受信メールをworkflow設定が完全に対応していることを確認してください。メールがworkflowをトリガーしない場合は、workflowまたはオーディエンスターゲティングで正しいメールアドレスが定義されているか確認してください。サポートメールをworkflowのトリガー条件に追加すると問題解決に役立ちます。

メールが配信リスト経由で転送される場合、DMARC準拠のためヘッダーが書き換えられ、domain条件が不一致になることがあります。

元の送信者情報を保持するには：

再割り当てが評価後に処理されると、workflowが誤ってトリガーされることがあります。

このようなエラーを最小限にするには：

属性マッチングを改善し、誤分類を防ぐために：

自動クローズworkflowsは、顧客の非アクティブ状態や事前定義されたworkflowアクションなど、特定のトリガーや条件に基づいて会話を自動的に閉じます。これによりinboxが整理され、会話の迅速な解決が保証されます。自動クローズworkflowがトリガーされない、早すぎる閉鎖、または予期せぬ中断がある場合はこのセクションを使用してください。

自動クローズworkflowがトリガーされない一般的な理由：

workflow内の各Let Fin answerブロックには独自の自動クローズタイマーがあります。タイマーが短すぎると、顧客が応答する時間が十分にないまま会話が閉じることがあります。これを修正するには、Let Fin answerブロックをクリックし、自動クローズ設定を開いてタイマーの時間を延長してください。

workflowが実行されているのに会話がまったく閉じない場合は、以下を確認してください。

メールベースのworkflowsでは、自動クローズ設定が転送メールに対応していることを確認してください。自動クローズアクションがworkflowのトリガー条件に合致し、転送メールに意図した受信者アドレスが含まれていることを確認して、workflowが正しくマッチできるようにしてください。

これらの点を確認し適切な設定を行うことで、Workflowが発動しない原因を特定できるだけでなく、今後の運用に向けて正しく設定されていることを保証できます。👌

それでもWorkflowのデバッグが必要な場合は、Messengerを通じてサポートチームにお問い合わせください。