7月も後半に入って随分と暑くなってきましたね。
梅雨の雨の合間を縫って照りつける日差しは既に真夏のそれです。
一人暮らしで話しかける相手がAlexaかベランダ菜園のナスくらいなのですが、それも収穫の時期を迎えており寂しいことに話相手が少しずつ私の胃の中に消えていっています。
さて、今回は初心者のシステム管理者に向けてSalescloudとpardotの関係について簡単にまとめてみました。
pardotの情報を構成する要素
pardotはCRMであるSalescloud（Salesforce Platform）に連携できるMAツールです。
あくまで”連携できる”なので連携しなくても使うことが可能です。
そのためpardot自体がCRMのような顧客情報を保持しています。
pardotを構成する顧客情報は３つあり、それぞれ「プロスペクト」「アカウント」「商談」と呼ばれています。
この項ではSalescloudのオブジェクトとpardotの要素の関連性を説明します。
Salescloudのオブジェクトとの関係性
一部のオブジェクトに関してSalescloudとpardotは連動しています。
下記の図の通り、Salescloudの「リード」「取引先責任者」「取引先」「商談」の４つのオブジェクトがpardotの「プロスペクト」「アカウント」「商談」に関連しています。
各オブジェクトの詳細は以下です。
プロスペクト
Salescloudの「リード」と「取引先責任者」がpardotの「プロスペクト」にあたります。
Salescloudでは「リード」は取引を開始すると「取引先責任者」に転換されるため、両方のオブジェクトがプロスペクトに対応する形になります。
つまり、プロスペクト内にはSalescloudの「リード」と「取引先責任者」が混在しているわけです。
Salescloudでは「リード」が商談より前の問合せユーザー、「取引先責任者」が商談以降のユーザーを表しています。
一方、pardotのプロスペクトは商談の有無を区別せずに問合せや行動をしたユーザーを表す要素です。
サイトへの訪問やフォームの送信、メールの開封などのアクティビティ、それらの結果のスコアや過去の問合せ履歴といった情報を保持しています。
アクセス方法
「プロスペクト ＞ プロスペクトリスト」からアクセス
アカウント
「取引先」がpardot上では「アカウント」にあたります。
プロスペクトが所属する組織を表す要素です。
Salescloudと同様、プロスペクト（取引先責任者）が所属している会社（取引先）と認識してもらって構いません。
「アカウント」では所属しているプロスペクトのスコアの合計や平均値が確認できます。
また、紐付いているプロスペクトの一覧などの情報を確認できます。
アクセス方法
「プロスペクト ＞ プロスペクトアカウント」からアクセス
商談
Salescloudでいう「商談」はpardotでも「商談」です。
「商談」は「プロスペクト」に紐付いていて、複数の「商談」が紐付いている事もあります。
「商談」は「アカウント」「プロスペクト」と違い、pardot上で管理、制御すべきものという位置づけではなく、Salescloudの情報を紐付けていくもののようです。
動的なリストで利用するセグメンテーションルールでも「商談」はデフォルトの項目しか使えません。
つまり「商談」の項目で複雑なリスト制御は出来ない、するべきではないという事です。
この点、少しまだ理解が甘いと思うのでpardotの「商談」の上手な使い方は学んで別の機会に記事にできればと思います。
アクセス方法
「レポート ＞ 商談」からアクセス
pardot利用のために行うこと
Salescloudとpardotの関連性を理解したら次は実務として何をする必要があるのかです。
ここでは利用にあたっての考え方や手順をまとめました。
もっとも重要なのは「プロスペクト」
pardotを利用するにあたって認識しておかないといけない考え方は「人ありき」という事です。
取引き自体は会社単位で行っていたり、普段やり取りを行う取引先の担当者は契約には関連のないバックオフィスの方だったりすると認識しづらくなる事もありますが、たとえ会社同士の契約、取引きだとしても必ず人が介在します。
pardotに限らずMAツールにおいて判断し行動を行う最小単位は人になります。
一斉に送ったメールでも開封するかしないかは人単位で違いが出ますし、サイトへのアクセスなどアクティビティ、その結果が反映されるスコアに関しても人単位です。
そのため複雑な情報を保持している「プロスペクト」が最も重要な要素となる訳です。
プロスペクトに対して何をすれば良いのか
今回はpardotを単体で利用しているケースではなく、Salescloudと連携している場合のケースで進めます。
まずはpardotで行う施策の計画をします。
次に「リード」「取引先責任者」の持っている情報の中でpardotが制御すべきカスタム項目を作成、連携します。
最後は常に最新の情報を維持しておく事です。
pardot施策の計画設計
MAツールでは出来る事が多いため誰に対して何を行うかを計画する必要があります。
失注したユーザーを掘り起こすにしても、誰も彼もが同じ優先度で良いわけではありません。
それであればMAツールを使う理由は皆無です。
Salescloudの特定の項目から判断できる優先度や顧客の属性、アクティビティによるスコアの変動から想定される期待度を加味してどういったユーザーに対してどんなアプローチを仕掛けるかを計画する事が肝心です。
カスタム項目の作成
pardotのデフォルト項目はSalescloudのデフォルト項目とある程度一致しています。
しかし、顧客の情報はデフォルト項目だけで賄えるものではないため、Salescloud側にもカスタム項目が多く設定されているはずです。
カスタム項目はpardotには自動で反映されないためpardot側でプロスペクトのカスタム項目を作成する必要があります。
とは言え何でもかんでもカスタム項目で持たせるとメンテナンス性が落ちてしまうので、上述の計画にてSalescloud側のカスタム項目のどれがpardot上にも必要になるのかを考えて項目を作成していきます。
例えば「リード」の『取引が開始出来なかった理由』というカスタム項目が【競合他社に決定した】となっているユーザーのみにメールを送付する場合は、pardot側にも『取引が開始出来なかった理由』というカスタム項目を作ってSalescloudの項目と紐付けないとセグメンテーションルールに適用させられません。
最新の情報を維持
SalescloudはCRMでありSFAです。
CRMの特性上、顧客情報は常に最新に更新されているのが理想です。
しかし、営業活動においては顧客それぞれの情報が最新であるかよりも受注できるかどうかの方が優先度が高く、営業担当の関心事としてもそちらに注目が行きがちになります。
その結果、実態は顧客管理よりも商談管理となりやすく情報の更新が後回しにされる恐れがあります。
pardotをメインで使うマーケティング担当やシステム管理者は顧客と直接やりとりする事がないため、顧客に関する最新の情報を最も理解しているのは一般的に「リード」であればインサイドセールス担当、「取引先責任者」ならフィールドセールス担当になるかと思います。
つまり情報を最新の状態で維持するためには営業担当者に協力を仰ぐ必要が出てくる訳です。
実施する施策のメリットを説明し、最新の情報に保つためのルールやフローをシステム管理者、営業内の推進役と連携して作るなども必要になってきます。
この点に関しては会社ごとに対応するのがマーケティング担当者だったりシステム管理者に一任したり、営業内の推進役が取りまとめたりと誰が責任を持つかは様々だと思いますが一番一筋縄ではいかない部分であることは間違いありません。
余談
余談ですが、顧客情報が最新に保たれていないという点に関して、入力をしている営業担当が入れていないから悪いというわけではありません。
営業の最大の仕事は商談を受注にするであり、顧客情報を最新にする事ではないため優先度が低くなるのは至極当然ですし、営業活動に専念してもらったほうが会社としても良く、しかもその情報を利用するのは自分たちではないとなれば尚更です。
だからこそ、実施のメリットを説明して互いの協力がプラスになるというコミットメントを取ることが重要になってきます。
まとめ
いかがでしたでしょうか。
pardotはSalescloudと連携することで色々と出来るかわりに構造が複雑になりがちです。
概念としてざっくりでもそれぞれの関連性を理解しておくと何が出来て何が出来ないのかが分かりやすくなります。
また、CRMと連携する性質上影響範囲が自分以外に及ぶという点も認識して利用する必要が出てきます。
それらの点を理解して使いこなせれば非常に協力なツールです。
自分もまだまだ勉強中ですが、使いこなして行きたいですね。
