自動化スタジオでのブロックの作成

自動化スタジオでのブロックの作成

注意
自動化スタジオは、プロフェッショナルプランとエンタープライズプランのユーザーが早期アクセスの申請に基づいて利用できます。早期アクセスをご希望の場合は、こちらのフォームからご申請ください。

自動化スタジオでは、イベントとブロックを組み合わせて処理の流れを作成します。イベントはルールを開始するきっかけで、ブロックではルール内で実行する処理や条件を設定します。
このページでは、イベントと各ブロックを使用できる場所と使用方法について説明します。

イベント  

イベントは自動化の流れを開始するきっかけであり、ルールを実行するタイミングを決定します。たとえば、問い合わせの作成時に自動化処理を実行する場合、問い合わせの作成が処理を開始するイベントになります。

1件のルールに、問い合わせの作成、項目の更新、コメントの更新など複数のイベントを設定できます。これにより、異なる状況で共通の処理を実行できます。

各イベントに条件を設定すると、イベントが発生するたびではなく、指定した条件を満たした場合にのみ処理を実行できます。
たとえば、イベントの条件を「ステータスが［未完了］」に設定すると、この条件を満たした場合にのみ処理が実行されます。


注意事項
メモ： 
  1. ［ごみ箱に移動］イベントは単独で選択する必要があり、同じルール内の他のイベントと組み合わせることはできません。
  2. ルールを有効にするには、イベントを1件以上設定する必要があります。同じイベント（例：［問い合わせの作成］）を1件のルールに複数回追加することはできません。
  3. 1件のルールには、処理、条件、遅延ブロックを合わせて最大50件のブロックを追加できます。

イベントの使用例  

問い合わせ作成時の自動返信
zPadのサポートチームには、毎日多数の顧客から問い合わせが寄せられます。問い合わせごとに個別の受付確認メールを手動で送信すると時間がかかり、顧客の問題解決に充てる時間が減ってしまいます。効率を高め、適切なタイミングで連絡するため、サポートチームでは問い合わせが作成されるたびに受付確認メールを自動送信する必要があります。

処理の設定
  1. イベント：問い合わせの作成
  2. 条件：［商品名］が「zPad」
  3. 処理：メールの返信を送信する
    1. メールの内容：
      ${tickets.contactId.$firstName} 様
      お問い合わせいただきありがとうございます。
      zPadに関するお問い合わせを受け付けました。48時間以内に解決方法をご案内します。
      zPadサポートチーム
［問い合わせの作成］イベントによって、問い合わせの送信直後に受付確認メールが送信されます。手作業なしで、顧客にすぐ受付完了を知らせることができます。条件によってzPadに関する問い合わせだけが対象になるため、必要な問い合わせに絞って自動化処理を実行できます。

エスカレーションされた問い合わせのサポート部門の管理者への割り当て
多数の顧客から問い合わせを受けるサポートチームでは、一部の問い合わせがSLAの期限を超え、ステータスが［エスカレーション中］になる場合があります。未解決の問題、顧客からの返信の遅れなど、解決までに時間がかかることが原因です。長期間未完了の問い合わせは顧客体験に悪影響を与える可能性があるため、早急な対応が必要です。

エスカレーションされた問題に迅速に対応するため、ステータスが［エスカレーション中］の問い合わせが新しく作成された場合、または既存の問い合わせのステータスが［未完了］から［エスカレーション中］に変更された場合に、問い合わせをサポート部門の管理者へ自動で割り当てます。

処理の設定
  1. イベント1：問い合わせの作成
  2. 条件：問い合わせのステータスが［エスカレーション中］
  3. イベント2：項目の更新
  4. 条件：問い合わせのステータスが［未完了］から［エスカレーション中］に変更された
  5. 処理：問い合わせをサポート部門の管理者に割り当てる。
1件のルールに複数のイベントを設定することで、問い合わせの作成時と、その後のステータス変更時のどちらのエスカレーションも検出できます。どちらのイベントでも同じ処理を実行します。エスカレーションの発生時点にかかわらず同じ対応が行われ、イベントごとに別のルールを作成する必要がありません。


処理ブロック 

処理ブロックでは、項目の更新、タスクの実行、通知の送信、インスタントメッセージの送信など、自動化ルールで実行する処理を設定します。1つの処理の流れに複数のブロックを追加でき、設定した順序で実行されます。
注意事項
メモ：［内容の生成（Zia）］処理は、1件のルールにつき1回だけ設定できます。

処理の連結  

処理の連結では、前の処理の結果を次の処理で順番に利用できます。一部の処理では出力変数が生成されます。その変数を後続の処理に渡すことで、処理の流れの中で情報を引き継げます。

変数の関連付けを分かりやすくするため、各処理ブロックには設定時に1、2、3などの重複しない番号が自動で割り当てられます。この番号は処理の出力変数の先頭に付加されます。同じ処理の流れにある複数の処理から生成されたデータを区別しやすくなります。

関連するタブの項目の参照  

処理を設定する際は、現在のデータに関連付けられている別のタブの項目を参照できます。

たとえば、問い合わせから、その問い合わせに関連する連絡先の項目を参照することが可能です。別のタブを開いて情報を探す手間を省くことができます。参照した項目を条件、処理、通知で利用することが可能です。


処理ブロックの使用例 

Ziaの［内容の生成］を使用した個別のトラブルシューティングガイドの作成
ITチームでは、問い合わせの要約機能を使用してやりとり全体を要約し、トラブルシューティングガイドを作成しています。ただし、Ziaによる標準の問い合わせ要約は内容を調整できないため、チーム固有の要件に合ったガイドを作成することが困難です。

そこでITチームでは、要件に合わせた問い合わせの要約を生成する処理の流れを作成します。生成した要約を使用し、チームの要件に合ったトラブルシューティングガイドを作成します。
  1. 処理の設定
  2. タブ：［問い合わせ］タブ
  3. イベント：問い合わせの作成
  4. 処理1：内容の生成
    1. コンテキスト：
      1. 最新のやりとりの内容：${tickets.$recentThreadContent}
      2. 件名：${tickets.$subject}
      3. 説明：${tickets.$description}
      4. ステータス：${tickets.$status}
      5. 作成日時：${tickets.$createdTime}
      6. 商品名：${tickets.productId.$productName}
    2. プロンプト：
      指定したコンテキストを使用してサポートの問い合わせを分析し、担当者向けの社内用トラブルシューティングガイドを作成してください。
      <問題の概要>
      <現在の状況>
      <考えられる原因>
      <必要な情報>
      <推奨する次の対応>
  5. 処理2：コメントを追加する
    1. 本文：処理1で生成したトラブルシューティングガイド
処理の連結により、［内容の生成］の出力が［コメントを追加する］に直接渡され、個別のガイドが問い合わせに自動で投稿されます。関連するデータの項目を参照できるため、［商品名］などの情報をそのまま利用できます。別途検索する処理を作成する必要はありません。生成する内容に詳しい情報を含めることができます。


交換承認時の物流データの更新
顧客から破損商品の報告があると、サポートの問い合わせが作成され、元の注文に対応する既存の物流データに関連付けられます。サポート担当者は依頼内容を確認し、商品の交換を承認するかどうかを判断します。 

承認後に物流データを手動で更新すると、更新を忘れて交換品の発送準備が遅れる可能性があります。交換が承認されたことを物流チームへすぐに知らせるため、［問い合わせ］タブでステータスが「確認中」から「交換承認済み」に変更されたら、［物流］タブの関連データのステータスを「交換対応待ち」に自動で更新します。

処理の設定
  1. イベント：項目の更新
  2. 条件：問い合わせのステータスが「確認中」から「交換承認済み」に変更された
  3. 処理：データを更新する 
    1. データID：物流ID
    2. タブ：［物流］タブ 
    3. 項目の更新処理：  物流データのステータスを「交換対応待ち」に更新する。
関連付けられている［物流］タブのデータを参照できるため、そのデータを自動で更新できます。処理ブロックによってチーム間の手動連携が不要になり、更新漏れを防止できます。また、物流チームはすぐに交換品の発送準備を開始できます。

条件ブロック

条件ブロックでは、自動化の流れに条件分岐を追加します。指定した条件を評価し、条件を満たした場合にのみ処理を続行します。条件を満たさない場合、その経路の処理は終了します。

たとえば、条件を「優先度が［高］」に設定すると、優先度が［高］の場合にのみ後続のブロックが実行されます。
注意事項
メモ：
  1. 条件ブロックに条件を追加するときは、関連するタブの項目も参照できます。
  2. 現在、条件ブロックでは条件を満たした場合の経路のみ利用できます。条件を満たす場合と満たさない場合の両方に分岐するIf/Elseには、現在対応していません。
  3. 条件ブロックの後には必ず処理ブロックを追加する必要があります。条件ブロックを処理の流れの最後にすることはできません。
  4. 別の条件ブロックの直後に条件ブロックを追加することはできません。

時間に基づく比較条件の使用  
条件ブロックでは、時間に基づく条件用の比較方法を利用できます。
比較方法
内容
例
期間
問い合わせの作成から経過した時間を評価します。
午前10時に問い合わせが作成されたとします。現在時刻が午後1時の場合、［期間］の値は3時間です。
期限までの期間
問い合わせの期限またはSLAの期限までに残っている時間を評価します。
問い合わせを午後5時までに解決する必要があるとします。現在時刻が午後2時の場合、［期限までの期間］の値は3時間です。
 
これらの比較方法を使用すると、カスタム関数を使用せずに、現在時刻を基準とした条件を条件ブロック内で直接設定できます。

条件ブロックの使用例  

優先度に基づく自動割り当て
ある小規模な新興企業のチームでは、性能に関する問い合わせを経験豊富な担当者に自動で割り当て、それ以外の問い合わせは通常どおり担当者に割り当てる必要があります。

処理の設定
  1. 実行条件：問い合わせの作成
  2. 条件ブロック：件名に「性能の問題」を含む
  3. 処理：問い合わせを割り当てる
    1. データID：問い合わせ番号
    2. 担当者：担当者
    3. サポート担当者名：川根 太郎
条件ブロックでは、実行時に問い合わせを条件で絞り込みます。そのため、性能に関する問い合わせだけで割り当て処理が実行されます。その他の問い合わせはこの経路を通りません。問い合わせの種類ごとに別のルールを作成することなく、作業量を適切に分散できます。

エスカレーションによるSLA違反の防止
ITヘルプデスクでは、SLAに違反する可能性がある問い合わせを事前に特定し、適切なチームへの通知とともに自動でエスカレーションする必要があります。
処理の設定
  1. 実行条件：問い合わせの更新
  2. 条件ブロック：期限まで2時間、かつ問い合わせのステータスが［解決済み］ではない
  3. 処理1：［データを更新する］で、優先度を「重大」に設定する
  4. 処理2：［メールの返信を送信する］で、通知先のチームを選択する
条件ブロックの時間に基づく比較方法を使用すると、期限までの残り時間に応じて動的に条件を評価できます。期限まで2時間以内で、まだ解決されていない問い合わせだけがエスカレーションされます。更新のたびに不要な通知を送らず、必要なタイミングで対応できます。

分岐ブロック  

分岐ブロックでは、自動化の流れを複数の独立した並列経路に分けます。各経路は同時に実行されます。互いに依存しない処理を、順番を待たず並行して実行できます。


たとえば、優先度が［高］の場合は、顧客へすぐに受付確認メールを送信し、問い合わせをL1のサポート担当者に割り当てます。優先度が［中］の場合は、受付確認メールを送信し、L2のサポート担当者に割り当てます。優先度が［低］の場合は、受付確認メールを送信せずにL3のサポート担当者へ直接割り当てます。
分岐ブロックに3つの経路を追加すると、これらの条件をそれぞれ独立して処理できます。
注意事項
メモ：分岐ブロックの直下に別の分岐ブロックを追加することはできません。分岐ブロック同士の間には、処理、条件、遅延のいずれかのブロックを追加する必要があります。


分岐ブロックの使用例  

商品に基づく問い合わせの割り当て
ジルカー電子株式会社では、zPhone、zPad、zWatchの3商品を販売しています。顧客から問い合わせがあったときに、受付確認メールを送信し、該当する商品のサポートチームに問い合わせを振り分ける必要があります。

処理の設定
  1. イベント：問い合わせの作成
  2. 処理：メールテンプレートを使用して顧客に受付確認メールを送信する
  3. 分岐：
    1. 経路1：
      1. 条件ブロック：［商品名］が「zPad」
      2. 処理：問い合わせを「zPadサポート」チームに割り当てる
    2. 経路2：
      1. 条件ブロック：［商品名］が「zPhone」
      2. 処理：問い合わせを「zPhoneサポート」チームに割り当てる
    3. 経路3：
      1. 条件ブロック：［商品名］が「zWatch」
      2. 処理：問い合わせを「zWatchサポート」チームに割り当てる
分岐ブロックではすべての商品条件が同時に評価され、一致する経路だけが実行されます。商品種別にかかわらず並列に処理されるため、条件を順番に確認する場合のような遅延なく、すぐに問い合わせを振り分けられます。

契約種別に基づく問い合わせの自動割り当て
ある組織では、顧客の契約種別に基づいて問い合わせの割り当てを自動化する必要があります。有料ユーザーの場合は、受付確認メールを送信し、問い合わせの優先度に応じて割り当てます。有料ユーザーではない場合は、別のチームへ問い合わせを割り当てます。

処理の設定
  1. イベント：問い合わせの作成
  2. 分岐：
    1. 経路1（有料ユーザー）：
      1. 条件ブロック：関連する連絡先の［項目の種類］が「有料ユーザー」である
      2. 処理：メールテンプレートを使用して顧客に受付確認メールを送信する
      3. 分岐：
        1. 経路1.1：
          1. 条件ブロック：優先度が［高］
          2. 処理：L1チームに割り当てる
        2. 経路1.2：
          1. 条件ブロック：優先度が［高］ではない
          2. 処理：L2チームに割り当てる
    2. 経路2（有料ユーザー以外）：
      1. 条件ブロック：関連する連絡先の［項目の種類］が「有料ユーザー」でない
      2. 処理：L3チームに割り当てる
分岐ブロックでは、有料ユーザーと有料ユーザー以外の処理を独立した経路に分け、契約種別に応じた経路を実行します。各経路内に条件ブロックを入れ子にして、さらに細かく振り分けます。このように分岐ブロックと条件ブロックを組み合わせることで、複数段階の条件に基づく振り分けができます。

遅延ブロック  

遅延ブロックでは、自動化の流れを指定した時間、または指定した日時まで一時停止します。フォローアップメールや確認通知の送信など、時間が重要な処理に役立ちます。
処理が遅延ブロックに到達すると、それ以降のすべての処理が一時停止します。指定した待機時間が経過した後に、後続の処理が再開されます。


注意事項
メモ：
  1. 遅延ブロックには、最短10分、最長120日の待機時間を設定できます。
  2. 指定可能な期間を超える待機時間を設定した場合、遅延ブロックとそれ以降のブロックは実行されません。
  3. 日時項目（例：期限）を基準に処理を予定した後、その項目の値を変更しても、すでに有効になっている予定済みの処理には影響しません。
  4. 処理が遅延ブロックに到達すると、それ以降のすべての処理が一時停止します。指定した待機時間が経過した後に、後続の処理が再開されます。
遅延ブロックを設定するには、待機時間または特定の日時のいずれかを指定する必要があります。特定の日時を使用する場合は、指定した日時の前、同時刻、後に処理するよう時間差を設定できます。
たとえば、24時間後にメールを送信する場合は、24時間の遅延ブロックを追加し、その後にメールを送信する処理ブロックを追加します。

メモ
留意事項：
  1. 遅延ブロックを経路の最後のブロックにすることはできません。処理を実行するには、遅延ブロックの後に処理ブロックを1件以上追加する必要があります。

  2. 同じ経路に複数の遅延ブロックを設定することはできません。
  3. ルールに3日間の遅延ブロックを追加すると、問い合わせが更新されてから3日間待機します。同じ問い合わせが3日以内に再度更新された場合、既存の待機は上書きされ、最新の更新時点から3日間の待機があらためて開始されます。
    たとえば、1日目に問い合わせが更新されたとします。処理は遅延ブロックによって4日目に実行されるよう予定されます。
    同じ問い合わせが2日目に再度更新されると、以前の予定は取り消され、処理は5日目に実行されるよう再設定されます。
  4. 遅延処理は特定のタイムゾーンを基準にするものではありません。設定した実行時刻に基づいて実行されます。
  5. 遅延ブロックを削除すると、その遅延ブロックによって作成された実行待ちの予定処理もすべて削除されます。
  6. 同様に、ルールを削除すると、そのルールによって作成された予定処理もすべて削除されます。
  7. 処理済みのデータをごみ箱に移動すると、そのデータに対する実行待ちの処理は実行されません。予定された実行時刻より前にデータを元に戻すと、実行待ちの処理は予定どおり実行されます。

遅延ブロックの使用例  

解決後のフォローアップ
サポートチームでは、問い合わせの解決から2日後に顧客へフォローアップメールを送り、引き続きサポートが必要かどうかを確認する必要があります。これにより、解決内容に満足していない場合でも、顧客はその後のサポートを簡単に依頼できます。

処理の設定
  1. イベント：問い合わせの更新
  2. 条件：問い合わせのステータスが［完了］に変更された
  3. 遅延ブロック：2日
  4. 条件ブロック：ステータスが［完了］
  5. 処理：メールの返信を送信する
  6. メールの内容：
    1. こんにちは。問題が解決しているかどうか、確認のためご連絡しました。引き続きサポートが必要な場合は、このメールにご返信ください。
遅延ブロックによってフォローアップの送信前に2日間待機するため、顧客が解決状況を確認する時間を確保できます。適切なタイミングでフォローアップすることで、顧客を継続してサポートできます。また、引き続きサポートが必要な場合も簡単に依頼できます。

問い合わせの自動フォローアップとエスカレーション
あるサポートチームでは、問い合わせの対応開始から完了までを一連の処理として自動化する必要があります。

新しい問い合わせが作成され、30分間未割り当てのままの場合は、問い合わせをサポート担当者に割り当て、優先度を［高］に設定して、その担当者に通知します。

問い合わせが7日を超えて完了していない場合は、担当者とサポート部門の管理者に通知し、問い合わせをエスカレーションします。
処理の設定
  1. イベント：問い合わせの作成
  2. 分岐：
    1. 経路1（未割り当ての問い合わせの通知）：
      1. 遅延ブロック：30分
      2. 条件ブロック：問い合わせが未割り当て
      3. 処理1：問い合わせをサポート担当者に割り当てる
      4. 処理2：サポート担当者に通知する
      5. 処理3：問い合わせの優先度を［高］に更新する
    2. 経路2（長期間未完了の問い合わせのエスカレーション）：
      1. 遅延ブロック：7日
      2. 条件ブロック：問い合わせのステータスが［完了］ではない
      3. 処理1：担当者とサポート部門の管理者の両方に通知する
      4. 処理2：問い合わせのステータスを［エスカレーション中］に更新する
遅延ブロックによって、問い合わせの対応過程に時間に基づく確認点を設定できます。30分の遅延では未割り当ての問い合わせを早期に検出し、7日の遅延では長期間未完了でエスカレーションが必要な問い合わせを特定します。分岐ブロックと組み合わせることで、問い合わせの作成時から両方の確認を独立して実行できます。手動で追跡せずに、問い合わせの対応状況を自動で管理できます。