国の委託事業等では、活動日報を提出する必要がある場合があります。年間に一つのプロジェクトだけが回っている状態であればさほど苦労はないのですが、複数のプロジェクトを兼任するようになってくると、人力での日報管理には限界が出てきます。 一番まずいのがダブルブッキングです。一人の人間が同じ時刻に複数のプロジェクトの仕事を行い、複数のプロジェクトの人件費を計上するということはあってはならず、整合性の確認の為に何度も精査が必要になるというのが常態化していました。目視でデータを見比べ、その人の時間が適切に割り振られている事を証明するというのはミスが出やすく且つ確認作業も重労働になります。こういった時間を0にするための取り組みを紹介します。 Googleカレンダーの情報をマスタとして利用する カレンダー情報は誰もが利活用しているのですが、これをマスタデータとして利用しています。どんな人でもスケジュールの登録は行います。終わったあとに実際にかかった時間を調整してくれれば良いのです。 Googleカレンダーの情報はカレンダーAPIを利用して取得することが出来ます。今回作ったプログラムでは、取得した情報を月ごとのテーブルに変換して表示しています。 チェック作業は、プロジェクトメンバーの個人がGoogleカレンダーを見てダブルブッキングが無いかどうかを確認するだけです。それさえなければ不整合が起こることはありませんので、ダブルチェック要員などが軒並み不要となりました。 Googleカレンダーの情報から帳票を作る このように、Googleカレンダーの情報を元にして各種帳票を作ることが出来ます。データの修正はGoogleカレンダーのデータを修正するだけで即時反映されますので微調整の手間もかかりません。 事例に戻る

Slackを使っていると、チャンネルのタイムラインの中で様々な情報が行き交います。単純に目を通しておけば良い内容から、自分がアクションをしなくてはいけない情報まで、様々です。Slackを使いこなし、組織の規模が増えていけば行くほど、メッセージの数は増大し、自分に宛てられたメッセージについて検討する時間が増えていきます。 Slackで送られたタスクは忘れがち 一つや２つなら問題ないタスク管理も、数が増えてくることでだんだんと忘れてしまいます。Slackにはデフォルトで「メンション＆リアクション」や「スレッド」という機能が備わっているのですが、これはあくまでも情報の羅列であって情報の整理には向きません。数が少ないうちはすべて見ることができますが、量が増えてくるとこの画面を見るのがつらくなってきます。スレッドは新しい投稿が加わると上に上がってくるのですが、タスクを終えて一言加えると最新情報としてあがってきます。つまり、未対応のpostが埋もれていってしまうのです。これがなかなかつらい。特にモバイルを使っていると顕著に辛くなってしまいます。 だったら解決済みのスレッドはアーカイブできればいいじゃないか、そう思ったときに作ったのがTASUKARU-TaskAll-というアプリケーションです。 メンションを羅列し、用済みになったスレッドはアーカイブしていく。それだけで必要な情報だけが残っていきます。シンプル。 最もシンプルな使い方はこれです。これだけで自分に何が残っているのかが把握できるようになります。 ToDo管理もSlackでしたい メンションの管理だけでなく、ToDo管理もSlackでしたいと思ったことはありませんか。私はあります。詳しい話はこちらで書いたので読んでもらうと詳細がわかるのですが、Slackで誰かにToDoを渡したい、自分のToDoも管理したいと言うときに使える機能です。 先程の画像にToDoボタンがあると思うのですが、これを押すと、今現在抱えているタスクリストが表示されます。 タスクの割当は、メッセージ内に .todo もしくは to.do という文字列を含めるだけ。含めた状態でpostをすると、スレッドにアプリが介入し、ToDoを立ち上げてくれます。 ToDoには担当者・締切日・進捗率・アサインした人・タグを設定する事ができます。これらを使って管理していくという使い方です。 リバネスではタスクの受け渡しには基本的にこれを使うことにしています。口頭やslackでメンションしただけというものはタスクをお願いしたことにはならないという認識を全員がもつことが重要。(もちろん一瞬で終わるようなものについてはこの限りではないのですが) 以上のような形で、カスタムアプリを作ることでSlackの利用環境を向上させることができました。 スライドにある通り、インストールして使っていただけますので、是非ご活用ください。 リンクはこちら ・TASUKARUについて ・インストールはこちらから 事例に戻る Slackを使っていると、チャンネルのタイムラインの中で様々な情報が行き交います。単純に目を通しておけば良い内容から、自分がアクションをしなくてはいけない情報まで、様々です。Slackを使いこなし、組織の規模が増えていけば行くほど、メッセージの数は増大し、自分に宛てられたメッセージについて検討する時間が増えていきます。 Slackで送られたタスクは忘れがち 一つや２つなら問題ないタスク管理も、数が増えてくることでだんだんと忘れてしまいます。Slackにはデフォルトで「メンション＆リアクション」や「スレッド」という機能が備わっているのですが、これはあくまでも情報の羅列であって情報の整理には向きません。数が少ないうちはすべて見ることができますが、量が増えてくるとこの画面を見るのがつらくなってきます。スレッドは新しい投稿が加わると上に上がってくるのですが、タスクを終えて一言加えると最新情報としてあがってきます。つまり、未対応のpostが埋もれていってしまうのです。これがなかなかつらい。特にモバイルを使っていると顕著に辛くなってしまいます。 だったら解決済みのスレッドはアーカイブできればいいじゃないか、そう思ったときに作ったのがTASUKARU-TaskAll-というアプリケーションです。 メンションを羅列し、用済みになったスレッドはアーカイブしていく。それだけで必要な情報だけが残っていきます。シンプル。 最もシンプルな使い方はこれです。これだけで自分に何が残っているのかが把握できるようになります。 ToDo管理もSlackでしたい メンションの管理だけでなく、ToDo管理もSlackでしたいと思ったことはありませんか。私はあります。詳しい話はこちらで書いたので読んでもらうと詳細がわかるのですが、Slackで誰かにToDoを渡したい、自分のToDoも管理したいと言うときに使える機能です。 先程の画像にToDoボタンがあると思うのですが、これを押すと、今現在抱えているタスクリストが表示されます。 タスクの割当は、メッセージ内に .todo もしくは to.do という文字列を含めるだけ。含めた状態でpostをすると、スレッドにアプリが介入し、ToDoを立ち上げてくれます。 ToDoには担当者・締切日・進捗率・アサインした人・タグを設定する事ができます。これらを使って管理していくという使い方です。 リバネスではタスクの受け渡しには基本的にこれを使うことにしています。口頭やslackでメンションしただけというものはタスクをお願いしたことにはならないという認識を全員がもつことが重要。(もちろん一瞬で終わるようなものについてはこの限りではないのですが) 以上のような形で、カスタムアプリを作ることでSlackの利用環境を向上させることができました。 スライドにある通り、インストールして使っていただけますので、是非ご活用ください。 リンクはこちら ・TASUKARUについて ・インストールはこちらから 事例に戻る

提供中のアプリについてのご紹介です。 TimeLine for Slack。詳細はこちら 組織全体が見えづらくなってきた 在宅ワークや人数や拠点数の増加によって組織全体が見えづらくなってしまっていませんか。SlackはDigital HQであると宣言し、私たちもかねがね同意しているのですが、オフィス勤務時と決定的に違うことが一つだけあります。それが行き過ぎた最適化です。 オフィスに出勤していると顔が見える範囲のことはなんとなく察しが付きます。表情が見えたり、声が聞こえてくるというなんとなく漂っている情報がインプットされることで、人間はたくさんの情報を得ていると言えます。(一方でそれがノイズで集中できないというパターンもあります) リモートワークでは当然こういったセンサーを働かせることは出来ません。Slackを使いこなしていて、チャンネルが細分化していけば行くほど、リモートワークで他のチャンネルで何が起きているのかを目にする機会がなくなっていきます。 一つのチャンネルに全ての投稿を流すアプリ TimeLine for Slack そこで作ったのがこちらのアプリケーションです。アプリをインストールして設定をすると、全ての公開チャンネルに投稿されたメッセージが一つのチャンネルに流れます。パソコン版のSlackアプリを使っている場合は、分割ビューにタイムラインチャンネルを設定しておくことで、どこで誰がどんなことをしているのかが目に入るようになります。 オフィスに出勤していれば「小耳に挟む」ことが出来たような情報のやり取りが、Slack上にTimeLineチャンネルを作ることで実現することができるのではないか？という提案アプリになっています。 < 事例へ戻る

リバネスがSalesforceを導入したのは2013年末でした。これまで何度も色々なところで発表してきたことですが、2013年当時リバネスは業務量過多によって事業成長の頭打ちを迎えつつありました。その原因は貧弱なITインフラと適切なワークフローがなかったことに起因します。 2013年当時のリバネスの問題 今でも少なくない組織がやっていることだと思うのですが、営業管理をスプレッドシートを使って行っていました。事業は徐々に成長を始めたタイミングで、これまでのような管理のままだとそもそもデータが重すぎて入力するだけで数分かかってしまうという状態になっていました。スプレッドシートを好む人は少なくないと思うのですがそれはなぜでしょう。答えは簡単で自由度が高いからです。基本的に自由記述欄のみなので簡単に拡張が出来たりと便利な面はたしかにあるのですが、自由記述が故に情報の入力ルールが守られなかったり、誤って他人のデータを変更してしまったり、数値を書かないと数式がエラーになるのに気付かずに全角数字で入力したら集計用のシートがだめになってしまったり。スプレッドシートは脆弱なのです。 こういった問題を解決するための銀の弾丸として選ばれたのがSalesforce社が提供するSales Cloudでした。 ワークフローをSalesforce式に変えていく 一番効果があったのはこれです。それまでのリバネスの商談管理は本当にひどかったと今では思いますが、例えば上述のスプレッドシートですが情報が記述されるタイミングはいつだったと思いますか？答えは「契約が決まったタイミング」です。そのため、今仕掛中の案件が何件あるのかを把握することは出来ませんでした。誰がどこにどんな提案をしていたのかは、本人のみぞ知るところとなり、社内全体で共有するという文化がありませんでした。 Sales Cloudの導入で変わったのはワークフローです。誰かに何かを提案したら商談を立ち上げ、立ち上がった商談を元に現在提案中の金額が把握できるという状態にしました。こうすることによって売上の見通しがつくように変わっていったのです。それまでどんぶり勘定でしかなかった事業計画は、実態を伴った数字によって構成されるように徐々に変わっていきました。そのおかげで事業計画の達成率は100%前後で推移するようになり、計画的に成長していくことができる組織へと変わっていったのです。 副産物 課題はもう一点ありました。実はリバネスでは請求漏れが多発していたのです。せっかく完了した仕事があっても、請求書を送らなかったら入金はありません。そもそもの情報管理がスプレッドシートで信頼性が低いこともあり、請求漏れに気付くのは個人の記憶に頼る以外になく、非常に心もとなかったことを覚えています。これまでに実装してきたように、商談はまだ種状態のころから登録されており、その状態は常に管理され続けるようになりました。しかもそれまでのように、誰かが情報をまとめてレポーティングする必要はなく、ただ特定のURLをクリックすればいいだけで分かるように変わったのです。 請求漏れは、商談についた完了予定日(CloseDate)を使って確認がされるようになり、終わっていなければすぐに指摘できるように変わりました。おかげで請求漏れは二度と発生することはありませんでした。 (別件ですが、請求書を送ったあとに入金を確認するという流れの中にも多大な煩雑さがあり、最大2億円を超える未入金が蓄積したことがあるのですが、それについての解決方法については別途書きたいと思います) 間違いの始まり 日本企業の特性としてよく聞く話としてあげられるのが「自社用カスタムの過剰要求」です。自分の組織はこういうワークフローが組まれているからそれに合うようにカスタマイズして欲しいという話です。もちろん頑張って資金と工数を投入してカスタムすれば出来ないことはないのですが、それはなにか意味がある行為でしょうか。 業務用ツールを導入する場合、そのポテンシャルを100%以上引き出せるような使い方のほうがコストパフォーマンスが良くなるはずです。自社向けカスタマイズに固執していて業務効率向上がおざなりになってしまうと本末転倒。必要なのはツールの思想に自分の組織を寄せていくという柔軟性です。 ありたい理想像をそのツールを導入した上で描くことができるのであれば、ツール導入だけではなく組織変容を合わせて行っていく必要があります。 異文化導入によって組織を強化していく リバネスではこのような方法で組織を強化してきました。Salesforceが顕著ですが、Slackを導入した際には情報のオープン化を大々的に進めています。これまでのように限られた人のみが情報を得られる状態ではなく、誰もが欲しいタイミングで欲しい情報を得ることができる体制を作ったのです。検索すれば情報にありつくことができるということは、情報を残しておくことで誰かの役にたつことができるというインセンティブを与えることができるのです。 このように、ツールの導入とともに組織文化をアップデートし、ワークフローを最適化しながら成長できる組織にしていくお手伝いができればと考えているのが私達リバネスナレッジのチームです。

スケジュール管理、どのように行っていますか？ リバネスではもっぱらGoogleカレンダーを使っています。一方で、Salesforceにもスケジュールという機能が提供されており、活動オブジェクトに予定を入れておくと、その後のトラッキングが容易になるといったオプションがあり、これを使わないというのももったいないというのが現状です。 リバネスでは、Salesforceのスケジュール機能で作られた予定に報告機能を付与し、営業報告等の各種報告事項を記載してもらうようにしています。これの何が良いのかというと、イベントが有った時にわざわざ記録用のレコードを立ち上げる必要がないということです。誰が、いつ、という情報までは入っていますのであとはどこでどんなことをしたかを書いて保存すればよいだけです。 スケジュールの情報をSalesforceでも確認したい そういう事はままあるとおもいます。毎日Salesforceを開くのであればついでにスケジュールチェックもしておきたいということもあるでしょう。 かんたんにスケジュールをSalesforceに連携するのであれば、Einstein 活動キャプチャを使いましょう。GoogleもしくはOffice365と連携し、カレンダー情報を取得してくれます。(これは同製品の別機能ですが、メールのやり取りを商談の取引先責任者の役割に紐付いた人とマッチングさせることで、商談にメールのやり取り履歴を自動的に表示してくれます。これは他の方法では実現がかなり難しいのでおすすめ機能です。) これはSalesCloud Einsteinライセンスが必要ですが、非常にかんたんなソリューションで個人的にはおすすめです。以下の画像のように、Google Calendarとの同期したカレンダーを見ることができるようになります。 かんたんではあるのですが一点注意点があります。このカレンダーレコードはGoogle Calendarの情報をミラーリングしているだけでSales Cloud側にレコードがあるわけではありません。そのため、こちらを編集して情報を追加するといった上述したような使い方は出来ません。あくまでも予定の確認が便利になるよという機能になっています。 Googleカレンダーの予定をSalesforceのEventオブジェクトに同期する これにはアプリケーションの開発が必要になるので少しむずかしいかもしれませんがやる価値は十分にあります。 リバネスの場合はPHPもしくはPythonを用いたアプリケーションを書いて両者を同期するようにしています。 GoogleカレンダーからはGoogle Cloud Platformにアプリケーションを作成しアクセストークンを取得します。これを用いて予定を取得するという方法です。取得した情報はSales Cloud側に作った接続アプリケーションを通してEventオブジェクトに登録します。これを定期的にスクリプトを実行することで実現しています。(リバネスの場合は3分毎に同期) カレンダーの情報は更新されることが多いですので、更新されたレコードについてはその更新情報をSalesforce側のレコードにも伝えるようなスクリプトになってます。 こうすることによって、打ち合わせが終わったにも関わらず報告がなされていないレコードを見つけ出すようなスクリプトを走らせることが出来ます。これを使って報告を促すアラートをSlackに投げ、Slack側から情報を更新してもらうということができるのですが、それについては別の事例で書きたいと思います。 お気軽にご相談ください リバネスナレッジでは、無料相談をSlack上で受け付けています。 こちらのリンクより、Party on Slackというワークスペースにご参加ください。 https://lne.st/gptcom #質問_salesforce チャンネルにご連絡ください。お待ちしております。 Salesforce管理者あるあるを解消したい Salesforce Adminという役割は、Salesforceが進化するに従って拡張しています。それにも関わらず、一人で担当しているという組織も少なくないのではないでしょうか。ある程度運用できても、果たしてそれが効果的な施策になっているかどうか相談できる相手がいない。自分たちがやっている施策について壁打ち相手になってくれる人がいないという声を少なくない数耳にします。リバネスナレッジでは、これまで培ってきたノウハウを元に、皆さんの課題を紐解き解決していく為のチームです。まずはワークスペースよりご連絡ください。(もちろん問い合わせフォームからの連絡も歓迎しています) < 事例へ戻る

Sales Cloudを使い始めて最初にこれはなんだろうと思ったことがあります。 リード(Lead)と取引先責任者(Contact)です。 取引先責任者は取引先オブジェクトに所属する形で存在しています。一方でリードは個人そのもので組織とは関連付けられていません。 リードとは？ リードは見込み顧客のことを指します。これから商談が始まる可能性のあるリストのことで、新規商談を作る際のアプローチ先として活用されます。展示会や問い合わせフォームからの流入で既存顧客ではない場合にそれらのリストをリードとして登録し、ここにアプローチした結果商談化することが出来た場合は、取引の開始ボタンから商談を作成することが出来ます。 取引先責任者とは？ これは取引先を親とする、子のレコードとして存在します。ある組織に所属した人として登録されており、先程リードから取引の開始ボタンを押した際にコンバートされる先のレコードになっています。 商談には取引先責任者の役割という関連リストがあり、そこに紐付けることで、商談に対する取引先責任者がどんな役割を持っているかを確認できるようになっています。 理想的な管理方法について リードを活かすには、リードリストの管理が必要です。なぜかというとそれをやらないと、有用なアプローチ先リストとしてのリードが成り立たなくなってしまうからです。 具体的にはどんなメンテナンスが必要かというと、既存取引先と会社名が同じ場合は取引先責任者にコンバートする必要があります。リードから商談が始まった場合は、同じ組織所属の人を取引先責任者にコンバートして提案が重複しないようにする必要があります。理想的にはそういうことなのですが、これがなかなか徹底できない。なぜかというと、リードの会社名は基本的に自由記述欄ですので、名刺スキャンでのデータ化なら良いのですが、リードの人が自ら情報提供したり、誰かが手打ちで入力したりすると既存の取引先名と違ってしまったりということは往々にしてよくあります。 弊社リバネスでは、ある程度運用期間が経過してからベストプラクティスに気付いたため、リードと取引先責任者がぐちゃぐちゃになってしまっていました。そうなると、あまり効率の良い使い方ができなくなってしまいます。 効率の良い顧客管理方法を求めてプロスペクト方式へ 上述したとおり、リバネスではリード管理が崩壊してしまいましたのでより効率の良い方法が必要でした。個人のリストが２つのオブジェクトにまたがって存在することで情報効率が劇的に下がります。レコードには重複が存在するようになり、レポートやビューを使った単一オブジェクトでの情報のフィルタリングはできません。私達はこれらのリストを元に、さらなる商談可能性の発掘などの情報探索をしたいのですが肝心のリストが分割されていては作業効率が激減してしまいます。 さて、リバネスはPardotというSalesforce社が提供するメールマーケティングシステムを導入しています。PardotはSalesCloudと連携し、リードと取引先責任者をプロスペクトという顧客リストに同期してくれます。結論から言えば、SalesCloudの顧客管理もこのプロスペクト方式でよいではないかと考えました。 結果的には、リードもしくは取引先責任者にリンクを持ったリバネスIDというオブジェクトに統合しました。 こうすることで、全ての個人情報はリバネスIDオブジェクト内で検索すれば出てくるようになりました。その他に顧客に関連する情報はリバネスIDにぶら下げて存在させることにより、どの人がアクティブなのかを常に把握できるように変わっています。 もちろん、リードと取引先責任者にリンクが張ってあることからPardotからくるデータにもアクセスすることができるようになっています。 工夫点 リード・取引先責任者・リバネスIDという3オブジェクトが存在するのですが、これらの情報に乖離があるのは好ましくありません。そのため、リンクされたレコードがあった場合は、修正点を関連するレコード全てに反映しています。 例えば電話番号が変わったり住所が変わったりという事があれば、全てにその情報を反映させています。これらはフローによってSalesCloud上で実現できます。 まとめ 以上のように、人間一人一人に関するレコードはリード or 取引先責任者方式ではなく、プロスペクト方式にしてしまったほうが取り回しがかんたんになります。リードを使った管理方法もよく作られて入るのですが、メンテナンスがされていなかったりで実質機能しなくなった場合にはこのような方法を検討しても良いかもしれません。 気になった場合はお知らせ下さい。 < 事例へ戻る

Project Brief リバネスでは会員向けサービスの提供を始めていましたが、当初は会員数も少なく、メールベースでのやり取りがほとんどでした。それがだんだんと人数が増え、手作業でのやり取りが限界に来たこともあって、オンライン上へのやり取りへと切り替えることにしました。 オンラインへの切り替えには2段階あり、まず最初のステップではサービスとして上手くいくかの確証がなかったため、スピード重視でシステムを立ち上げています。その後、オンラインサイトが軌道に乗ってきた段階で更に会員数を伸ばすために利用するサービスを変更しています。 The Challenge 第一段階では、オンラインサイトによるサービス提供が上手くいくかどうかを確かめる必要がありました。これまでの作業がオンラインによってどの程度軽減することが出来、顧客満足度に寄与するのかを図る必要がありました。会員向けのオンラインサービスの本格的な提供は初めてだったこともあり、Salesforceのコミュニティクラウド(現在のExperience Cloud)を利用して短期間で立ち上げサービス提供を始めました。 その後、当事業は軌道にのり、会員数が増えたためにライセンスフィーが大きくなってきました。そのため、コミュニティクラウドでの経験を経て、Heroku上に作成したWebサイト(リバネスID)へと乗り換えています。 The Solution 利用したサービスは、Salesforce社のExperience CloudとHerokuです。 前者は会員向け情報がSalesforce(Sales Cloud)に同期することが特徴です。会員サービスのフロントエンドは管理画面からクリックしていくことで作成が出来るため構築がかんたんです。会員はサイトから様々な情報を入力することになりますが、これらの情報はシームレスにSalesCloudに同期するため、スタッフはいつもの見慣れた画面で情報を確認することができます。学習コスト0で新しいサービスを構築することが出来ました。 その後、会員数が増えるとともに、ライセンス数も増加傾向になりました。今後の成長によるコストの増大を考えると、いわゆるWebサービスを構築したほうがベターだと考えました。ここではSalesforce社のHerokuというサービスを利用しています。HerokuにはHeroku ConnectというSales Cloudへの情報同期の仕組みが備わっています。これを利用することでExperience Cloudと同様に情報をSales Cloudに同期することができ、スタッフのワークフローを変えずに成長することが出来ました。 当初の要件は、以下のとおりです。 ・会員サイトの経験が少ない ・そもそも当該サービスにWebサイトがあっているか不明 ・Webサービス化することで、様々な業務コストが激減する予感はする このような状態では何も確信がなく、巨大なコストを払うのは難しいという状態でした。そのため、Salesforceがリリースしている会員向けサービスであるExperience Cloudを採用することにしたのです。コストは、登録される会員数*ライセンスフィー(当時は500円/月でした)のみで始められます。極めて小さな投資で手軽に会員向けサービスをスタートできるということもあってスムーズにスタート出来ました。 立ち上げたサイトには、これまでのお客様リストを読み込んで招待状を出します。程なくしてこれまでメールでのやり取りを基本としていたサービスがオンラインサービスへと移行されました。情報はお客様自らが、Experience Cloud上で作成した入力フォームに登録してくれます。私達は入力された情報を元に、リストを作成し、業務に活用することができるようになりました。 情報はSales Cloud側でVisualforce pageを利用することで帳票として出力することが出来ます。スタッフはいつでも最新の情報にURLのクリックひとつでアクセスできる様になりました。これまでのように、お客様からメールで頂いた情報を、エクセルに転記してまとめ、差し込み印刷で出力するといった膨大な手間が０になったのです。コピー&ペーストのミスもなくなり非常に有意義な導入事例となりました。 導入は成功し、会員数が伸びていった 当初一つのみだった導入サービスは、その後社内に知れ渡りあらゆるサービスに導入され始めました。最大で10程度のサービスがExperience Cloud上で展開され、ライセンス数も増加していきました。こうなると、段々と年間のライセンスコストが気になってきます。今後、様々なサービスに同じ展開で導入することを考えると、当初300程度で運用されていたライセンス数は6千人を超えるという試算になります。ということは年間コストが3600万円程度かかる計算になります。 このような試算をした段階で次へのステップを考え始めたのです。 Heroku上に会員サイトを構築し移行 Salesforce社はその他にもHerokuというサービスを持っています。Herokuは自社でサーバーを構築せずとも様々なサービスを構築することができるPaaS（Platform as a Service）と呼ばれす種類のサービスです。Herokuには更に、Heroku ConnectというSales Cloudと同期するための機能が搭載されています。 これまでExperience Cloudで行っていたような体験をそのまま移行するためにはHerokuに移行するのが一番でした。 [...]