なぜZendeskでエージェントが関与しているのに会話が「deflected」とマークされるのですか?
なぜZendeskでエージェントが関与しているのに会話が「deflected」とマークされるのですか?
Finでは、Finが解決した場合や自動的に応答が不要と判断した場合(通常は受信メッセージが迷惑メールやスパムとしてフラグ付けされた場合)に、会話がdeflectedとしてマークされます。これはエージェントの介入が行われる前に発生します。
Zendeskでチケットにエージェントが割り当てられているのが見えることがあり、内部メモを追加したり再割り当てしたりしているかもしれませんが、公開返信が送信されず、かつFinが以前にメッセージをスパムとしてフラグ付けしていた場合、会話はFinのレポートでdeflectedとしてカウントされます。
仕組みは次の通りです:
Finのスパム検出は特定のメッセージを迷惑メール/スパムと識別し、応答しないことを選択します。
この操作により、会話はFinのレポート(例:Custom Report)でdeflectedとしてマークされます。
しかし、Zendeskは通常通りチケットの処理を続けます。つまり:
エージェントを割り当てることができます。
内部メモを追加できます。
チケットは通常のサポートworkflowsを通過することができます。
この設定により、Finは潜在的に有害または無関係なコンテンツへの対応を回避しつつ、チームは誤ってフラグ付けされたものを確認・対応するための完全な可視性と管理権限を保持できます。
Zendeskのticketフィールド名を更新しましたが、workflowを作成するときにまだ古い名前が表示されます。どうすれば直せますか?
Zendeskのticketフィールド名を更新しましたが、workflowを作成するときにまだ古い名前が表示されます。どうすれば直せますか?
Zendeskでticketフィールドの名前を変更しても、Finのworkflowビルダーに新しい名前が反映されない場合は、統合を手動で再同期する必要がある可能性があります。
ticketフィールド名を更新するには:
FinのworkspaceでSettings > Zendesk Integrationに移動します。
Topicsをクリックします。
Re-syncをクリックします。
その後、ブラウザを更新してください。
これにより、workflowビルダーを含むFinプラットフォーム全体でticketフィールド名が更新され、Zendeskの最新の名前が反映されます。
なぜFinの会話タグがFin Custom Reportに表示されないのですか?
なぜFinの会話タグがFin Custom Reportに表示されないのですか?
これは予期された動作です。Finのworkspace内の会話タグは、FinがZendeskに適用するタグとは異なります。
FinがZendesk ticketsと連携すると、ルーティングやレポートに役立つ特定のタグをZendesk内で自動的に適用します:
fin-involved– Finに割り当てられた会話に追加されます。fin-resolved– Finがチケットを解決したときに追加されます(ソフトまたはハード解決のいずれか)。fin-soft-resolution– 顧客がまだ確認していないFinによる解決を示します。fin-hard-resolution– 顧客がFinの回答が役立ったと確認したときにfin-soft-resolutionに代わって追加されます。fin-routed-to-team– Finが会話を人間のチームメイトに引き継いだときに追加されます。
ただし、これらのタグはFinのworkspace内には表示されず、そのためFin Custom Reportの「Conversation tag」フィルターには含まれません。そのセクションに表示されるタグは、Finのworkspace内で手動で作成・適用したものだけです。
Fin Custom Reportには、Finの動作に基づく関与、解決率、チームへの引き継ぎの内訳が含まれていますが、Zendeskタグに基づくものではありません。
fin-involvedやfin-resolvedのようなタグでレポートをフィルターしたい場合は、それらのタグが適用されているZendeskのレポートツールで直接行うことができます。
なぜチケットがFinに割り当てられているのにテストメールを送ってもFinが応答しないのですか?
なぜチケットがFinに割り当てられているのにテストメールを送ってもFinが応答しないのですか?
重要:Finは現在割り当てられているチケットにのみ応答するよう設計されています。したがって「Finが応答しない」と表示される場合、それは意図された動作である可能性があります。何か(通常はZendeskのトリガー)がチケットの割り当てをFinから外しているかもしれません。
テストチケットがFinに割り当てられているのに応答がない場合、最も可能性が高い理由は、Zendeskのworkflowのステップが欠けているか、Finが応答するための関連知識が不足していることです。
処理時間の目安
Finは通常、メールでの返信に30~60秒かかります。チケットをFinに割り当てた後、十分な時間を待ってから調査してください。
確認手順
Finのworkspaceで会話イベントを確認し、Finのプロセスが開始されていることを確認してください。
workspaceがZendeskなどのサポートされているプラットフォームと統合されていることを確認してください。サポートされていない統合はFinの自動化を完全にバイパスする可能性があります。
以下の点を再確認してください:
Finへの割り当て:トリガーが機能してチケットがFinに割り当てられている場合、それは良いことです。この場合、Finは
fin-involvedタグを適用するはずです。そのタグが表示されない場合、Finがチケットに対してアクションを起こしていない可能性があります。「Finに回答させる」ステップ:workflowに「Finに回答させる」ステップが明示的に含まれている場合にのみ、Finは応答します。このステップがなければ、チケットが正しく割り当てられていてもFinは返信しません。
コンテンツアクセス:設定が正しくてもFinが応答しない場合、Finが応答に必要な関連コンテンツを持っていない可能性があります。Help CenterやFin knowledge baseでカバーされている質問を送信してテストできます。Zendesk用の詳細なセットアップガイドはこちらです:Fin for Zendesk Tickets – Set Up
Fin割り当てトリガーが有効で割り当てを行っている
FinのworkspaceでSettings > Zendesk triggers for Finに移動し、サイドバイサイドの差分表示でトリガーを確認してください。これにより、Zendeskの実際の設定と期待される設定が比較でき、トリガーがInactive、変更されている、または誤設定されているかどうかが簡単にわかります。
またはZendeskでFinが作成したトリガーを確認し、Inactive、変更、順序の乱れがないかを確認してください。
新しいticketsをFinに割り当てるトリガー(通常「Assign to Fin」などと名付けられています)から始めて、新しいticketsが作成されたときにトリガーが発火していることを確認してください。
他のトリガーがFinの割り当てを解除していない
他のZendeskトリガーや自動化で、チケットがFinエージェントに割り当てられた後にAssigneeを変更したり、チケットをFinから移動させるアクションがないか確認してください。
これは予期せずに作動する可能性のある「フェイルセーフ」やルーティングトリガーを含みます。
リブランディング後に接続しているZendeskサブドメインをどのように切り替えますか?
リブランディング後に接続しているZendeskサブドメインをどのように切り替えますか?
組織がリブランディングを行いZendesk domainが変更された場合、新しいZendeskサブドメインに接続するためにFinワークスペースを更新する必要があります。以下の手順に従ってください:
アクティブなチャネルでFinを一時停止:更新中の中断を避けるため、ライブチャネルでFinが一時停止されていることを確認してください。
デプロイに移動:Deploy > Zendesk ticketsに移動します。
新しいサブドメインに接続:
「Connect to the Zendesk API」セクションで、Connectを選択します。
新しいサブドメインを入力します(例:古いdomainを新しいものに置き換えます)。
Zendeskのメールアドレスと新しいAPIトークンを入力してください。トークンはZendeskのAdmin Center:Apps and integrations > APIs > Add API tokenから生成できます。
更新を完了:新しい統合を確定するためにConnect to the Zendesk APIをクリックします。
最後に、Finワークスペースの内容を確認してください:
もはや関連のない古いZendeskサブドメインに紐づくインポートまたは追加されたコンテンツを削除します。
新しいZendesk domainに関連する更新されたコンテンツを追加します。
これらの手順に従うことで、Finワークスペースを新しいZendesk domainにシームレスに切り替え、一貫したサポート体験を維持できます。
Finを使ってサポートアドレスに送られた直接メールに返信できますか?
Finを使ってサポートアドレスに送られた直接メールに返信できますか?
はい。support@example.comへの直接メールがZendeskでticketsを作成する場合、Finはそれらに返信できます。チケットが作成されると(ウェブフォームまたは直接メールから)、workflowのLet Fin handleステップでFinに割り当てることができます。Finはチケットの発信元と同じチャネルを使って顧客にメールで返信します。
トラブルシューティングのためにZendesk APIの接続を切断して再接続した場合、ZendeskでFin用に設定されたトリガーはどうなりますか?
トラブルシューティングのためにZendesk APIの接続を切断して再接続した場合、ZendeskでFin用に設定されたトリガーはどうなりますか?
最近Zendeskの接続を切断/再接続した場合、Finは必要なトリガーを再作成します。そのため、どのトリガーが有効か、カスタマイズが上書きまたは重複していないかを再確認する価値があります。各トリガーの詳細については、Understanding Fin's Zendesk Triggersを参照してください。
切断と再接続の間に何が起こるか
Finは統合セットアップの一環としてZendeskトリガーを作成します。これには割り当て、会話の更新、解決、フェイルセーフアクションのトリガーが含まれます。
APIの再接続はFinのZendeskトリガーを再作成します。再接続中、FinはZendeskエージェントのIDを選択するよう促し、Zendeskで必要なトリガーを(再)作成します。
カスタマイズされたトリガーは影響を受ける可能性があります。以前にFinのデフォルトZendeskトリガーをカスタマイズしていた場合、再接続時に上書きまたは重複する可能性があります。再接続後、Settings > Zendesk triggers for Finに移動し、サイドバイサイドの差分ビューでトリガーを確認してください。これにより、期待される設定とZendeskの実際の設定が比較でき、変更点の特定やカスタマイズの再適用が容易になります。
再接続時にOAuthが必要になる場合があります。ZendeskはAPIトークン認証を廃止しています。まだOAuthに切り替えていない場合、再接続にはOAuthが必要で、OAuthが有効になるまでFinワークスペースに永続的なバナーが表示されます。
Fin workflowsは保持されます。Zendesk APIの切断と再接続はFin workflowsを削除またはリセットしません。変更を加える前にworkflow設定を記録することを推奨します。
ZendeskトリガーはFinではなくZendeskで管理されます。Finと連携する追加のZendeskトリガーや自動化がある場合、再接続後にその状態を再確認してください。
ベストプラクティス
切断前にアクティブなチャネルでFinを一時停止し、予期しないticket処理を避けてください。
再接続後にZendeskトリガーを確認およびテストし、割り当て、解決、フェイルセーフの動作が期待通りか確認してください。Settings > Zendesk triggers for Finのサイドバイサイド差分ビューを使い、すべてのトリガーが期待される設定と一致しているか素早く検証できます。
Zendeskの依存関係の問題に注意。切断時にエラーが発生した場合(例:トリガーの依存関係による)、再接続前にZendeskトリガーや統合の調整や順序変更が必要になることがあります。
FinがZendesk ticketsやフォローアップに応答しない場合、どのようにトラブルシューティングできますか?
FinがZendesk ticketsやフォローアップに応答しない場合、どのようにトラブルシューティングできますか?
Finが応答しない一般的なシナリオ
Finは解決済みticketのフォローアップコメントに返信しません
Finが「solved」とマークされたticketのフォローアップコメントに返信しない場合、以下を確認してください:
フォローアップコメントの種類を確認:Finは公開コメントにのみ返信します。コメントがプライベート/内部としてマークされている場合(Zendeskにリンクされたエージェントのメールアドレスから送信された場合に一般的)、Finは返信しません。非エージェントのメールを使ってコメントが公開されているかテストしてください。
Zendeskトリガーを確認:ticketステータスが「solved」の場合でも、Finに更新を通知するZendeskトリガーが適用されていることを確認してください。さらに、ticketがsolvedにマークされた後もFinが割り当てられていることを確認してください。
Finは割り当てられたticketに応答しません
ticketがFinに割り当てられているが応答がない場合、以下を確認してください:
アクティブなZendeskトリガー:「Finに割り当てられた会話に更新がある場合、Finに通知する」トリガーが有効であることを確認してください。このトリガーがないと、ticketに変更があってもFinは更新されません。
必要なFinトリガー:新しいticketをFinに割り当てるトリガーなど、必要なFinトリガーが有効であることを確認してください。
Finの会話から作成されたZendesk ticketsに会社名を表示させるにはどうすればよいですか?
Finの会話から作成されたZendesk ticketsに会社名を表示させるにはどうすればよいですか?
Zendesk ticketの会社名はFin workflow設定の変数を使って入力されます。ただし、この変数は会話に関与するユーザーがFinで会社に関連付けられている場合にのみ名前を取得できます。関連付けがない場合、会社名フィールドには代替値が表示されます(代替値が設定されている場合)。
Zendesk ticketsに会社名を表示させるために:
Finでユーザーを会社に関連付ける:会話の前または最中に、ユーザーがFinシステムで会社に関連付けられているか確認してください。
Workflow設定を確認:Fin workflowが会社名変数を適切に使用して、Zendesk ticketの希望するフィールド(例:件名)に入力していることを確認してください。
代替値の使用:ユーザーと会社の関連付けがない場合、workflowは実際の会社名の代わりに事前設定された代替値をticketフィールドに挿入します。混乱を避けるために代替値を適切に設定してください。
新しいZendesk ticketの引き継ぎ時にエラーメッセージが表示された場合、どう対処しますか?
新しいZendesk ticketの引き継ぎ時にエラーメッセージが表示された場合、どう対処しますか?
以下のようなエラーが表示される場合:
"新しいZendesk ticketへの引き継ぎに失敗しました。"
Intercomのエラー詳細:
IntercomリクエストID: 00593v4q2hugigda4ptg
Intercom Job ID: vmulk01gct
エラーが発生しました。Intercomサポートにお問い合わせください。
IP制限が設定されていないかご確認ください。通常、これが問題の原因です。設定されている場合、解決方法は2つあります。
制限を解除することができます、または
当社のパブリックIPを許可リストに追加することができます:
米国: 34.231.68.152, 34.197.76.213, 35.171.78.91, 35.169.138.21, 52.70.27.159, 52.44.63.161
ヨーロッパ: 54.217.125.63, 54.246.173.113, 54.216.9.3
オーストラリア: 52.63.36.185, 3.104.68.152, 52.64.2.165
