複数のコールフローで、引継ぎ利用ができますか?
回答済みお世話になっております。
コールフローの利用について確認させてください。
1コールフローで解決できなかった場合、別コールフローに登録されている要員に自動架電したいと考えています。
また、GUI操作でなく自動化したいのですが、enterprise は今のところ弊社の評価対象に入っていません。
Pigeon単体もしくはAlertHub連携で自動的にできますでしょうか?
Pigeon単体の場合、スクリプトを組むことになるのでしたら、恐縮ですがサンプルなどご紹介いただけますでしょうか?
宜しくお願いいたします。
-
正式なコメント
ご質問ありがとうございます。回答させていただきます。
結論としては、現時点の機能では難しいと存じます。
設定用の画面が未実装かつ情報公開が不十分な機能ですが、Pigeonには連絡開始・成功・失敗・中止時にWebhookもしくはメールによる通知を行う機能がございます。これを用いて連絡失敗時にAlertHubの受信スロットにWebhook送信を行うことで、AlertHub側のアクションを発火させ、結果的に「別のコールフロー」を呼び出すことは可能です。
しかし、このWebhook通知の内容には失敗したコールフローを直接特定できる情報が含まれておらず、アクションにより呼び出した「別のコールフロー」でもなお連絡が成功しなかった場合に、再度「別のコールフロー」の呼び出しが行われてしまいます。
Pigeonからの通知内容を改善することでご要望の動きを実現することが可能となりますので、機能改善について速やかに検討させていただきます。何か進展がございましたらコメントにて引き続き報告いたします。
お待たせしてしまい申し訳ございませんが、よろしくお願いいたします。
コメントアクション -
ご返答ありがとうございます。
他の方の投稿ですが、Pigeon架電?(/api/apps/pigeon/results)の連絡結果ステータスが記載されているものがありました。
投稿名:連絡処理結果の一覧のステータスについて
そちらによると7つの結果ステータスがあるようです。(preparing,waiting...succeeded,failed,abortedなど)
それらと今回のご回答の「成功・失敗・中止」は同じ定義を指していますか?
また今回のご回答は、Pigeonの連絡開始・成功・失敗時に通知を行う機能が「設定用の画面が未実装かつ情報公開が不十分な機能」とおっしゃっているのでしょうか?
それとも上記の流れの中のWebhook通知に、失敗したコールフローが直接特定できないため、第2コールフローの利用が「設定用の画面が未実装かつ情報公開が不十分な機能」であるとおっしゃってるのでしょうか?
弊社としては、もし複数のコールフローで引継ぎが出来なかったとしても、初回コールフローの失敗や中止がアラートとして管理できるのならば、まずはそれで一歩と考えております。
機能改善まで視野に入れていただいてありがとうございます。
ですが、まずは初回コールフローが失敗に終わった場合、その完了ステータスを利用したアラート管理が正式な機能として利用できるのか、教えていただけますでしょうか? -
そちらによると7つの結果ステータスがあるようです。(preparing,waiting...succeeded,failed,abortedなど)
それらと今回のご回答の「成功・失敗・中止」は同じ定義を指していますか?7つの結果ステータスのうち、4つは処理中のステータス、3つは処理終了後のステータスとなっており、通知対象となる「成功・失敗・中止」は処理終了後のステータスにそれぞれ対応しております。
- 成功: succeeded
- 失敗: failed
- 中止: aborted
また今回のご回答は、Pigeonの連絡開始・成功・失敗時に通知を行う機能が「設定用の画面が未実装かつ情報公開が不十分な機能」とおっしゃっているのでしょうか?
それとも上記の流れの中のWebhook通知に、失敗したコールフローが直接特定できないため、第2コールフローの利用が「設定用の画面が未実装かつ情報公開が不十分な機能」であるとおっしゃってるのでしょうか?Pigeonの通知機能は正式な機能として公開しており、APIドキュメント(Web画面左上のヘルプアイコンより「API ドキュメント」を開くことで参照可能です)のPigeonカテゴリ内「通知設定の作成」を初めとして、これを取り扱うためのAPI仕様は既に公開しております。
ただし現段階ではAPIによる設定にのみ対応していて操作用の画面がなく、またこの設定に関して取り扱ったマニュアル・記事等がないため、API仕様をもとにAPIを直接叩いて設定を行う必要があり、少々設定のハードルが高い状態にあります。
また通知内容として、現時点ではPigeonの連絡実行ごとに発行される結果IDのみが含まれております。このIDを用いて「連絡処理結果の取得」APIより詳細な情報を取得することは可能です。また同IDをAlertHub経由で別のシステムに送ることもでき、例えば「Pigeon連絡が失敗したらチケット管理システムに起票を行い、またチケット上に連絡結果へのアクセス用のURLを記載する」といった動きが十分に実現可能です。
一方でAlertHubを経由してPigeonの連絡実行に直接繋げることを考えますと、失敗したコールフローが「初回コールフロー」であることをAlertHubのルール機能により判断する必要がございますが、通知内容に結果IDのみを含めている現状ではこの流れを実現することができません。そのため最初にご質問いただいたケースを実現する上では「現時点では機能不足」とさせていただいております。
-
ご回答ありがとうございます。
この件については、Enterprise を含めて検討を始めております。
>>また通知内容として、現時点ではPigeonの連絡実行ごとに発行される結果IDのみが含まれております。このIDを用いて「連絡処理結果の取得」APIより詳細な情報を取得することは可能です。また同IDをAlertHub経由で別のシステムに送ることもでき、例えば「Pigeon連絡が失敗したらチケット管理システムに起票を行い、またチケット上に連絡結果へのアクセス用のURLを記載する」といった動きが十分に実現可能です。
この事例につきまして、APIより取得した情報をもとに、自他システムへの連携をしている設定例を
ご紹介ねがえませんでしょうか?
よろしくお願いします。 -
以下に、参考になりそうなコラム記事のリンクを記載いたします。
- PigeonのAPIに関するコラム
https://kompira.zendesk.com/hc/ja/articles/4403040513689
- Enterpriseでの外部システムとの連携事例
https://www.kompira.jp/column/post_to_redmine/
- Enterpriseのジョブフロー全般の使用例
https://www.kompira.jp/column/startguide/
サインインしてコメントを残してください。
コメント
5件のコメント