Intercomを導入した話（実践編）
こんにちは、くるくる＠LAPRASです。
新型コロナの影響でリアルイベントがなくなってしまったので、オンラインで発信していこうということでLAPRASのエンジニアを中心にLAPRASアプトプットリレーという企画を立ち上げました。私はエンジニアではありませんが、この企画に乗っかって最近の学びをシェアさせていただこうと思います。
今冬Intercomを本格的に導入たので、その導入の振り返りをまとめてみました。今回は実践編です。（概要編は こちら ）
Intercomのセットアップ
Intercomのセットアップに入る前に、改めてこのツールを使って何をしたいのかをリストアップし、業務フローを想定しておきました。その上でそれぞれの業務の実現方法を検討し、必要なデータが得られるように設計しました。
ちなみに、公式の手順はちゃんとヘルプ “I’m setting up a new Intercom workspace for Support” にスタートガイドがあるのでそちらをご一読ください。
TEST環境を作る
Intercomでは workspace ごとにテスト環境を作ることができます。動作検証や設定を試してみる場合はこちらで行うと良いです。埋め込まれた側のサービスでも普通に動作します。実はこの機能は当初あまり使いこなせてなかったです…。
本番環境とは発行されるapp_idが異なるので、Webサービスであれば
- Production = Intercom本番環境のapp_id
- Staging = IntercomTEST環境のapp_id
といった形式で切り替えてもらうなど、サービス側と連携した環境構築をしておきましょう。app_idはworkspaceごとに発行され、 Settings > Installation から確認可能です。ステージング環境と本番環境で同じapp_idを使用すると、検証用のデータが本番環境に入り込んだりするので絶対やめましょう。
ちなみに公式のドキュメントが分かりにくいのですが、app_idの横に赤字で書いてあるのがそのworkspaceのapp_id（なんか他にも呼び方があった）です。大事なものなので、あなたのworkspaceのIDはこれだよ！と大々的に書いて欲しいですね…。
People dataを設定する
Intercomのユーザーデータの種類には、Visitor、Lead、Userの3種類があります。今回は主目的がユーザーサポートなので、Userデータを用意しました。
Settings > [workspace name] data > People data を開くとデフォルトの項目が設定されています。Create attributeでこれらに加えて必要なカスタム項目を作っていきました。PeopleだけでなくCompaniesにも項目を設定することが可能なので、BtoBのサービスで利用する場合はこちらも使うと良さそうです。
設定できるのは、
Text（文字列）、Number（整数）、Decimal number（小数点を含む数字）、True or False（真偽）、Date（日付）、List（配列）
のみです。Dateは実際には時間も入る模様。attributeのデータを使用してand/orで細かく配信条件として設定することができますので、想定している切り口での条件設定が可能かどうか、事前にシミュレーションしておくと良いでしょう。
また、これらのattributeの他にも Tag というプロパティがあります。PeopleやConversationに対し柔軟に設定できるので、一時的にユーザーをセグメントしたい場合などはこちらを利用することでPeopleの構造をシンプル化できます。
Peopleデータのインポートは、すでに動いているサービスにデータを取り込む場合、基本的にはCSVアップロードを使用することになりそうです。ここで注意をしなければならないのが、CSVアップロードで投入できないattributeがあることです。デフォルトで設定されているattribute (Default attribute) は一部の項目のみCSVアップロードで設定可能で、大半がCSVではデータを入れることができません。それらの項目を使用したい場合には、エンジニアにコマンドを叩いてもらうか、custom attributeに似たような項目を設定してそちらで代用することになります。（custom attributeはCSVに対応しています）
連携するデータと画面、タイミングなどの認識合わせ
Intercomを実際にサービスと連携させて使うには、開発者と画面へのインストールや必要なデータ連携についての認識合わせを行い、インストール作業を行ってもらう必要があります。以下の内容について認識合わせを行い、まずは動作検証のためにステージング環境に組み込んでもらいました。
以下について認識合わせを行います。
- 利用する画面（URL） →スニペットを埋め込む対象
- 連携する項目（連携先項目名、データ型、連携内容） →Peopleに持たせる項目
- 連携するタイミング →ユーザーのライフサイクルに合わせて設計します
連携内容が食い違っているとあとで大変なので、シンプルなサービスでも表などに書き出して網羅的に把握するようにしましょう。利用する画面はそのままMessenger（右下に出る吹き出し）を表示させる画面になります。Messengerの表示/非表示は画面毎にコントロールできないので、その点を踏まえて決定しましょう。連携する項目については、データ型の他に「表示名を連携するのか、システムの内部的なコードを連携するのか」は明確にしておきます。項目をメールなどのコミュニケーションで使用する場合は、ここの値がそのまま表示されるので、表示項目を連携した方が良いでしょう。
連携するタイミングはユーザーのライフサイクルに従って、アカウントと各項目の、
Create（アカウントのサインアップ）→Update（データの変更）→Delete（アカウントの削除）
のタイミングを網羅します。忘れがちなのが、Createのタイミングで「初期値を設定すること」と、アカウント削除のタイミングでIntercom側のアカウントも削除（使用不能にする）することなので、注意しましょう。
デベロッパー用のドキュメント群はこちらにまとまっています。
エンジニアとのコミュニケーションで気をつけた方がいいと感じたのは、仕様策定を丸投げしないということでした。製品開発を行ってくれているエンジニアはWebエンジニアリングのプロですが、CRMを始めとした業務システムのプロではないのです。なので、ユーザーのライフサイクルと必要なデータやタイミングなどは、直接的にユーザーを見る役割の人物（PdMやCS）が責任を持って見ていく必要があります。この辺りは業務とシステム双方の知見が必要とされる領域で、実は多くの企業で浮きがちな役割なのではないかと思っています。
ある程度準備が済んだところで機能を一つずつセットアップしました。サービス内に表示させる機能のプレビューをするためにはインストール（サイトへのスニペットの挿入）が必要なので、先に済ませておきましょう。
ここではちょっと設定の難しかった機能について触れます。
■ チャットボット
IntercomのチャットボットはOperatorから設定できます。チャットオペレーターの離席時に使うTask Bot、カスタム応答を作成できるCustom Bot、ヘルプ記事と連携するResolution Botがあります。Botで一連の対応を行うためにはCustom Botを使用します。
Custom BotにはFor Users、For Visitors、From a button、From new conversationsがあり、ページ毎に出し分ける場合はFrom new conversationを使います。
チャットの設定類はOperatorではなく Messenger （メニューの下の方）で設定する必要があるので、こちらでメッセージのランチャー（フキダシ）の表示等を設定しておきましょう。ランチャーの表示はUser/Visitorで設定できますが、画面毎には設定できないので注意しましょう。
実はこのMessenger、表示をONにすると、インストールしたページの他に ヘルプセンター にも表示されるようになります。Botを設定する際は忘れずにヘルプセンターのURLでも表示されるように設定しておきましょう。
■ プロダクトツアー
プロダクトツアーは現在はOutboundの中に分類されています。
画面にポップアップまたはポインターを表示するシンプルなものです。ポインターを使用すると、該当の要素が見つからない場合はポップアップとして表示するなど、エラー時の回避処理も行なってくれるようになっています。
また、各ステップのビューや離脱率も見ることができるのと、強制表示させるURLを生成できるので、自動的に表示させるだけでなく、ユーザーが見たい時に見てもらうといった使い方も可能になっています。
Intercomにはアンケート機能が無いため、CSATやNPSといった調査は連携サービスを利用する必要があります。連携できるアプリケーションはApp Storeから探すと出てくるので、連携内容比較しつつ選ぶ必要があります。SalesforceやHubspot、Google Analyticsなどのポピュラーなアプリケーションとの連携もあるのですが、聞いたことのない謎アプリもあったりします。情報を不必要に分散させたくなかったので、ちょうど良いものを見つけるためにひたすらサインアップして機能調査をするという苦行を行いました。
連携アプリは次に見ていくSlack連携のように、App Store内で設定を行うか、各機能の側でアプリを呼び出す形で設定します。Intercomの外部アプリ連携はどのようなシーンで利用するかきっちり想定されている為、あまり柔軟な設定はできないケースが多い印象です。外部連携を前提で導入する場合は想定している連携ができるのか注意が必要です。
現在はWootricというサービスを使用しています。App Storeから検索してインストールを行うと、In-app メッセージなどでWootricを呼び出せるようになり、回答が自動でPeopleデータに連携されます。
LAPRAS社ではコミュニケーションの基幹としてSlackを使用しているので、どのようなツールを使うにもSlack連携が必須です。こちらはApp Storeから設定します。
通知されるパターンが決まっていて、新規ユーザーができた時、サインアップされた時、companyが作られた時、conversationが発生した時に通知できるようになっています。
個人的にはもう少し連携する項目を柔軟に設定できると嬉しいので、改善を期待したいところです。
データ移行＆GoLive
一通りの動作検証を行ったら、データ移行を行い、運用に入ります。
ユーザーサポートの文脈でIntercomを導入する場合は、全くの新規サービスでないかぎり、サービス側からのデータ移行が必要になります。
データ移行はぶっつけ本番でやるものではないので、必ずGoLiveする前に本番データの投入テストとAPIから連携されるデータのチェックを行なっておきましょう。大概何かが起こっています…。また、最終的に投入するデータはデータ連携を開始した後の最新断面のものを入れるようにしましょう。タイミングを間違うと古いデータが残ってしまったり、新しいデータが上書きされてデグレが発生するので注意しましょう。
まとめ
ざっくりですが導入を振り返ってみました。
やはり大変だったのは、事前に何ができるか分からない中、あたりを付けて調べて…ということを繰り返しながら意思決定していかないといけないことだったかと思います。SaaSはとにかく機能アップデート速く、ヘルプも最新のものが無かったりするので手探りで進めていかなくてはなりません。その時点ではベストだと思えた選択肢も後から振り返るとそうでもなかったかも…となることも多々あるので、ベストな選択肢を探すのも大切ですが、最後は思い切りが必要です。
情報が少なくて苦戦した部分もあったので、この記事が多少は悩めるCS担当などの助けになればと思います。
