Zoho CommandCenterにおけるシグナルの活用

お知らせ：当社は、お客様により充実したサポート情報を迅速に提供するため、本ページのコンテンツは機械翻訳を用いて日本語に翻訳しています。正確かつ最新のサポート情報をご覧いただくには、本内容の英語版を参照してください。

Signals とは？

Signalsは、ビジネス内で発生するあらゆるやり取りやイベントを検知・取得し、リアルタイムでシステムに通知できる、Zoho の高度なバスサービスです。Zoho CommandCenter では、これらの Signal を判定条件として使用し、レコードをジャーニー内のあるステージから別のステージへ移動させます。

Zoho Desk でチケットが作成された
Zoho CRM の見込み客タブでデータが作成された
送信したメールがバウンスした
メールは開封されたが、顧客がリンクをクリックしていない
見込み客がニュースレターを購読した
顧客がウィッシュリストの商品をカートに移動した
Zoho Invoice で請求書が作成された

これらは、ビジネス環境内のタッチポイントに対して顧客が行うインタラクションの一例です。これらのインタラクションやイベントは、CommandCenter 内で個別の Signal として設定できます。イベントが発生するたび（つまりインタラクションがあるたび）に、対応する Signal が有効化され、元のステージにあるレコードがトリガーされて次のステージへ移動し、顧客ジャーニーが進行します。

イベントの発生によってジャーニーが前に進みますが、イベントが必ずしも顧客の行動とは限りません。Signal は、ユーザー（たとえば、マーケターが送信するウェルカムメール）や、システム自体（たとえば、Webサイトから API が呼び出された場合）によってトリガーされることもあります。

したがって、Signals は顧客ジャーニーを駆動するバックボーンとなり、イベントを検知して、開始から完了までの進行をオーケストレーションします。

CommandCenter における Signal の種類

Signal はイベントの発生を表すことが本来の意味・目的ですが、CommandCenter には次の 4 種類の Signal があります。

データ Signalは、CRUD（Create、Read、Update、削除）イベントを取得する Signal です。

例：データの作成、最終更新時刻の更新、データの編集、データの削除など。

User Signalは、顧客・見込み客・組織内ユーザーなど、人によって開始される Signal で、メール、通話、Web フォーム送信などが含まれます。
例：Web フォームの送信、受信メールの受信、発信通話の試行など。

アプリベース Signal：Zoho CommandCenter と連携認証された Zoho アプリケーションからのイベントです。

例：アンケートページへの訪問、Web セミナーへの登録受付、Desk チケットの受信など。

カスタム Signal：ジャーニー内でデータの移動をトリガーできる、任意のカスタム機能や動作です。

例：見込み客が商品のウィッシュリスト登録を行う、カートを放棄する、MRP ツールで需要の低下が検知されるなど。

Path Finder と Journey Builder における Signal の役割

Signals は、Zoho CommandCenter 内の Path Finder と Journey Builder の両方で利用でき、データを起動して動かすことを主な目的としています。

Path Finder における Signals

Path Finderでは、これらはタッチポイント Signal と呼ばれ、ジャーニーの発見と関連付けに役立ちます。

たとえば、Zoho CRM で送信される外部送信メールを、遷移用の Signal として設定できます。

Path Finder は、インタラクションを検出し、それらのイベントを対応する CRM レコードに関連付けます。Signal の一連の流れが有効化されると、それぞれのタッチポイントが同時に接続され、顧客が実際にたどっているパスを表現します。

参照：Path Finder を使用した顧客ジャーニーの発見

Zoho CRM で外部送信メールが送信されると、その Signal がトリガーされ、そのステージが有効化されます。次の Signal がトリガーされると、直前に有効化されたステージが現在のステージと接続されます。この「発見・関連付け・有効化」のプロセスによって、顧客ジャーニーを表すパスが形成されます。

Journey Builder における Signals

Journey Builder は、顧客がたどる望ましいジャーニーを構築するための機能です。Journey Builder の Signal は、顧客レコードがジャーニーの進行に応じて、あるステージから次のステージへ移動するための判定条件として機能します。

Signal が検知されるということは、顧客・ユーザー・システムのいずれかがイベントを実行したことを意味し、それによって前のステージにあるデータがトリガーされ、次のステージへ移動します。Journey Builder の観点では、これは顧客が設定したパス上を前進していることを示します。

Journey Builder の Signal は、遷移（Transition）の一部として利用できます。

Zoho CommandCenter での Signal の設定

Zoho CommandCenter は、チャネル横断のオーケストレーションを可能にするスタンドアロン製品です。さまざまなツール・アプリケーション・プラットフォームからデータを取り込み、Signal を介して、ビジネス要件に応じてイベントを取得できます。

Zoho CommandCenter に表示される Signal の一覧は、Path Finder と Journey Builder の両方で共通です。

利用できる Signal は次のとおりです。

システム標準 Signal：Zoho アプリケーションを認証することで利用できる標準 Signal。
カスタム Signal：サードパーティアプリケーションやチャネルでのイベントを取得するための Signal。

メモ:

1 つの Zoho サービス内に複数の組織がある場合、パス／ジャーニーの設定ページで、Signal を処理する対象組織を選択できます。
Zoho CRM で CommandCenter を利用したことがある場合、Zoho CRM はデフォルトで Zoho CommandCenter と連携されます。
Zoho CRM と連携されているすべてのアプリケーションの Signal も、Signal の一部として一覧表示されます。次のように表示されます。
認証後にアプリケーションとの連携を解除した場合、そのアプリケーションの Signal はミュート（無効化）されます。

システム標準 Signal の認証

システム標準 Signal とは、Zoho エコシステム内の各種アプリケーションを連携した際に利用できる標準／ネイティブの Signal です。

現在、次のアプリケーションの Signal を CommandCenter と連携認証できます。

Zoho CRM
Zoho Desk
Zoho Invoice
Zoho SalesIQ
Zoho Survey
Zoho Backstage
Zoho Commerce
Zoho Books
Zoho Web セミナー
Zoho Inventory
Zoho Billing

Zoho Backstage でチケットを販売してトレードショーを開催するとします。

各チケット注文に対して、アジェンダ、座席順、会場情報などを送信し、代わりに RSVP、食物アレルギー、付き添いの有無などの回答を、Backstage の Signalを使って収集します。
これらの注文を CRM の顧客レコードに関連付け、CRM ベースの Signalを使ってナーチャリングし、ファネルを進めます。
その後、インタラクションや関心度に応じて、商談が成立し、受注が行われ、請求書が作成されます。
Invoice ベースの Signalを使用することで、支払いプロセスを最適化できます。

このように、Zoho CRM で作成・認証したアクション可能な Signal を活用し、複数のアプリケーションをまたいで顧客の購買サイクル全体を最適化できます。

これらのアプリの Signal を Zoho CommandCenter で認可・認証するには、次の手順を実行します。

CommandCenterアプリケーションに管理者権限でログインします。
画面右上の設定をクリックし、Configuration Blocks > Signals に移動します。
Signal 設定ページで、認証可能な Zoho サービスがすべて表示されます。

認証済みのアプリは、Authenticated apps に一覧表示されます。
サブスクリプションはあるものの、まだ CommandCenter と接続していないアプリは、「To Be Authenticated」セクションに表示されます。
CommandCenter で利用可能なその他のアプリは、Other Supported Apps セクションに表示されます。

利用可能なアプリケーションを認証するには、

「To Be Authenticated」セクションで対象アプリのAuthorizeをクリックします。
表示される認証ポップアップで、Signal を取得したい組織またはポータルを選択します。
Authorizeをクリックします。
これにより、アプリケーションはAuthenticated Apps セクションに移動し、そのサービスのデフォルト Signal が Path Finder と Journey Builder の Signal 一覧に表示されます。

メモ:

ユーザーは、CommandCenter と、認証対象アプリ側の組織の両方で管理者である必要があります。
サブスクリプションが失効している場合、そのアプリケーションを認証することはできません。
また、認証後にサブスクリプションが失効した場合、そのアプリの Signal を使用しているジャーニーは無効または機能しない状態になります。

カスタム Signal の接続

カスタム Signal は、サードパーティの各種ツールやアプリケーションで発生する任意のイベントを CommandCenter に取り込むために作成するリンクです。

これは、API を介してアプリケーションを接続し、エンドポイントでイベントが発生した際に必要な値やデータを収集することで実現します。これらの値（プロパティとも呼ばれます）は、顧客ジャーニーの発見とオーケストレーションのために取得されます。

たとえば、別のモバイルアプリや Web サイトでのアクションをトリガーとする独自のカスタム Signal を作成し、それを CommandCenter に関連付けることができます。

カスタム Signal を作成するには、

Signal 設定ページでCustom Signalsタブをクリックします。

+Create Signalボタンをクリックし、カスタム Signal の名前を入力します。

必要に応じて説明を追加します。

Add additional signal detailの項目で、カスタム Signal リンクに付加したいプロパティを追加します。

名前とデータ型を指定します。
使用できるデータ型は、Text、Integer、Double、Date、Datetime、Boolean、メールです。
Signal の要件を満たすまで、必要なプロパティを追加していきます。
保存をクリックします。
これらのプロパティは、作成された Signal リンクにスラッグとして付加されます。
この操作により、この Signal が、CommandCenter 組織で作成された Signal の一覧に追加されます。
任意のタイミングで、リンクに含まれるプロパティを追加または削除したり、新しいリンクを再生成したりできます。
このリンクを、いずれかのパス設定やジャーニーの一部として関連付けている場合は、「関連付け」セクションでまとめて確認できます。

メモ:

カスタム Signal リンク内の digest 以降の値は、アプリケーション内で Signal をトリガーするために使用されます。これらの値が外部に漏えいすると、（識別用の値が一致した場合などに）レコードが誤って遷移し、処理に影響を及ぼす可能性があります。これを防ぐため、カスタム Signal はクライアント側ではなくサーバー側から呼び出すことを推奨します。漏えいの可能性がある場合は、数秒で新しいカスタム Signal リンクを取得できます。
Signal プロパティの追加、削除、再生成を行うと、Signal リンクの構造が変更されます。設定済みの Signal ソース側で、リンクの変更または差し替えを忘れないようにしてください。
カスタム Signal とそのプロパティを作成したら、任意のアプリケーションと API を連携し、Signal トリガーの受信を開始できます。

豆知識:

カスタム Signal は 1 回限りの利用に制限されません。作成後は、複数のジャーニーや Path Finder の設定で再利用できます。

こちらをクリックして、カスタム Signal の作成方法をご確認ください。