今や目にしない日がないというほど、あらゆるインターネットのサービス内でチャットボットが活用されるようになりました。

実際に自社でもチャットボットを活用して、人件費を削減したり、様々なビジネス目標を達成しようと奮起している企業が多いのではないでしょうか。
特にECの業界においては、新規獲得やオンボーディングなどのビジネスゴールに対して、LP（ランディングページ）やFAQページ、解約ページとチャットボットの活用の幅がかなり広がっています。

本記事では、これからチャットボットの活用を検討しているEC企業や、既に導入しているが自社でうまく活用できていないEC企業の担当者の方に向けて、チャットボットの設計から運用までのフローを解説します。

チャットボットの種類

チャットボットには、シナリオ型とAI型という種類に大別されます。
以下に特徴を記しますが、これらの解説はすでに多くの記事でされているため、詳細について知りたい方はぜひ検索してみてください。

シナリオ型

シナリオ型のチャットボットは、利用者が選んだ選択肢ごとに、特定の回答を返すというタイプになります。
事前に選択肢に対応する回答を準備するため、シンプルな問い合わせに対して常に同じ品質を保つことができるという特徴があります。

AI型

一方でAI型のチャットボットは、自然言語処理（NLP）という人工知能技術を用いたチャットボットであり、利用者が自由に入力したテキストに対し、その入力内容の意図を読み取って回答を返します。
どんな入力に対しても回答を返すことができるため、シナリオ型に比べて複雑な問い合わせや要望に対応することができるという特徴があります。

チャットボットを活用する目的

EC企業がチャットボットを導入する主な目的は、下記のように多岐に渡ります。

新規獲得のサポート

サービスのLP（ランディングページ）や、EF（エントリーフォーム）で使用することで離脱を防いだり、適切な情報提供をしてCV（コンバージョン）に繋げることができます。

顧客満足度（NPS）の調査

既存の顧客に定期的に「この商品を周りの人に勧めたいと思いますか？」といった質問をすることで、サービスに対する顧客ロイヤリティを測定することができます。

解約の抑止・受付

解約専用のページにチャットボットを設置し、顧客から解約理由を聞き出したり、それぞれの解約理由に対する切り返しをしたりすることで、顧客の態度変容を促すことができます。
また、解約意思の高い顧客はチャットから解約できるようにすることで、窓口の負担を大幅に減らすことができます。

FAQ対応

商品の利用方法や請求など、顧客からの問い合わせが多い質問に対してチャットボットで答えることで、カスタマーセンターの問い合わせを減らすことができます。

チャットボットの運用に必要な手順

ここからは、EC企業がチャットボットを活用するために、導入初期の設計段階から導入後の運用・メンテナンスまでに必要な手順について解説します。
また、この記事では「チャットボットを活用する目的」に挙げた弊社のチャットボットSmashが特化している「解約の抑止」の内容で解説します。

初期の要件定義・分析

チャットボットの導入には、まずはチャットボットで実現したいビジネスゴールの定義をすることから始めます。ビジネスゴールは、「質の高い商品の利用客の増加」など、そのサービスに関して自社が達成したい目的のことです。そしてそのために必要な指標として、「LTVを⚪️％改善」「顧客の定期購入期間を×ヶ月増加」などのKPIの設計をします。
KPIに用いられる指標として下記のようなものが例として挙げられます。

• LTV（ライフタイムバリュー：顧客生涯価値）

• 新規入会数

• MAU（月間アクティブユーザー数）

• 解約率

• ROI（費用対効果）

• ユニットエコノミクス

ビジネスゴールとその評価指標の定義と同時に、チャットボットを運用する上で社内の運用メンバーをアサインする必要があります。
必要な役割は下記の通りです。

• カスタマーサポート：顧客対応を中心に行い、現場の意見として各担当者にフィードバックをする役割

• システム担当者：チャットボットの設置環境の構築や、データ連携などの開発を担当する役割

• シナリオライター：チャットボットのシナリオ作成、修正、メンテナンスを行う役割

• チェッカー：文言やデザイン、連携のチェックを実施する役割

• デザイナー：チャットボットのデザイン全般を担当する役割

• データサイエンティスト：レポートを作成し、初期分析に用いるデータやチャットボットで取得したデータ分析をする役割

必要なメンバーをアサインできたら、これまでに社内で蓄積した顧客データを、データサイエンティストを中心に分析し、ビジネス状況を把握します。
データには顧客の購入回数や決済方法、マイページの訪問回数などの顧客行動データと、入会日や解約日などの契約・解約データがあります。
これらのデータを用いて、解約しやすい/しにくいペルソナや、それぞれの顧客に対して有効なコンテンツなどの仮説を設計します。

解約データを用いた代表的な表やグラフについては下記記事で解説しています。

環境構築

チャットボットを使用する目的や初期の分析を終えたら、設置する環境を構築します。
顧客が実際に利用するページである本番環境に加え、サイトのアップデートをするための開発環境、本番に反映する前に最終チェックを行うステージング環境を用意します。

シナリオの設計

環境が準備できたら、チャットボットの流れを設計します。
今回は「チャットボットの種類」で紹介した「シナリオ型」のチャットボットの設計を例に取ります。
シナリオの設計には、顧客からヒアリングする項目を下記のように決定します。

• 解約の意思

• 解約理由

• （他社に乗り換える場合）移行先の商品名

• 再入会の意思

ヒアリング項目が決まったら、それぞれの分岐の中で訴求するコンテンツを用意します。
商品サイト内に既に活用できるコンテンツがあるか、新たにチャットボット用に準備すべき訴求コンテンツがあるかを確認し、解約の意思や解約理由の選択肢に応じてコンテンツを当てはめます。
顧客に解約を考え直してもらうためのコンテンツを含むURLを案内するだけでなく、チャットボットの中で動画やバナーを活用してシンプルで理解しやすい設計にすることも重要です。
また、解約以外にも割引、スキップ、プラン変更などのオプションも準備することで、機会損失を防ぐことができます。

おおまかなシナリオの流れができたら、データサイエンティストを中心に、シナリオ内で訴求するコンテンツの効果検証の方法を整理します。
コンテンツを出しわけてABテストをする場合、必要なデータ数やおおまかな実施期間、結果によって取るべきアクションを事前に想定しておきます。

さらに、システム部門と連携すべきことがいくつかあります。
解約やスキップ、プランの変更などの処理をチャットボット内で行う場合は、システム部門と連携してAPIなどの準備が必要です。
商品が複数ある場合は、契約中の商品連携や商品ごとの解約処理などをできるようにする必要もあります。
また、チャットボットのログとして残すデータについても事前に確認・準備をします。回答内容だけでなく、タイムスタンプやUID、デバイス情報など何をデータとして取り込むことができ、必要かを決めておきましょう。

デザインの設計

シナリオがどれだけ素晴らしいものであっても、デザインがわかりにくかったり、ダサいと利用してもらえません。デザイナーは、顧客がつい使いたくなるようなデザインのチャットボットにしないといけません。
開きたくなるようなボタン、回答したくなるようなアイコン、思わず本音で答えたくなるような聞き出し方などです。

シナリオとデザインの設計ができたら、チャットボットを実装します。
実装の際に、文言が誤っていたり、チャットボットを設置するサイトのCSSの影響でデザイン崩れが起こることはよくあります。
必ず想定通りのシナリオ、デザインになっているかをチェッカー、シナリオライター、デザイナーを中心に確認しましょう。

シナリオ運用

実際にチャットボットが稼働し始めたら、頻繁にメンテナンスを行うことになります。

シナリオについては古いコンテンツの差し替えなどを行います。
システム面では、これまでのチャットボットの稼働で生じたエラー対応や、処理の追加を行います。
顧客から上がってきた緊急の問い合わせがあれば、カスタマーサクセス部門が問い合わせの対応を行い、システム部門は緊急の問い合わせが入力された際のアラート設定を必要に応じて行います。
デザインも長期間同じものを利用すると、開封率や回答率が下がってくるため、定期的なメンテナンスが必要になります。

レポートの作成

「シナリオの設計」で準備したログデータを活用し、レポートの作成をします。
レポートは一目で回答状況がわかるようにし、期間ごとのトレンドや特異点を把握するためのもので、次項「施策の振り返り」に繋げるための重要な要素です。

必要なレポート項目の設定

レポート項目として代表的なものを下記に挙げます。

• 属性情報（男女比、デバイス比等）

• 解約抑止率

• 解約の意思

• 解約理由

• 移行先のサービス

• 再入会の意思

これらの集計を日次・週次・月次と期間ごとに行うことで、施策の振り返りが行いやすくなります。

BIツールの比較検討・選定

レポートに必要な項目が出揃ったら、レポート作成をするためのBIツールを検討します。
Excelだけでもデータ分析は可能ですが、様々な機能を有する各種BIツールを使用すれば、よりわかりやすく必要なレポートが得られやすくなります。

自社の予算内か、欲しい機能を有しているかなどを基準に選定をしましょう。
代表的なBIツールにはSalesforceのTableauやMicrosoftのPower BIなどがあります。
特定のサービスとの連携に強かったり、閲覧のみが可能な低価格で利用できるライセンスがあったりと様々です。

BIツールの設定

BIツールが決定したら、レポートの作成とデータ接続や権限などの設定を行います。
データ接続については、日々のレポートであればバッチ処理の設定をします。
権限は、限られたメンバーのみに編集権限を与え、他のメンバーには閲覧権限のみを与えるようにします。

施策の振り返り

レポートまで準備ができたら、施策の振り返りを行います。実際にシナリオ内で使用しているコンテンツが効果的であったかどうか、レポートデータをもとに分析・判断をします。
ABテストであれば、2つの施策を実施している箇所のデータを比較し、回答率や解約率に差が生じているかを有意差検定などの統計手法を用いて検証します。
有意差が出ていれば、効果が強いコンテンツを残し、出ていなければもう少しデータを収集するのか、ABテストを終了して他の切り口で施策を実施するかの判断をします。
さらに、いずれの場合もそのような結果が得られたと考えられる原因を考察し、次の施策考案に生きる示唆を得ます。

ABテスト以外にも、レポート内のデータが特異な傾向を示していないか注意深く見る必要があります。

最後に

以上、EC企業が自社でチャットボットを運用するために必要な流れを説明しました。
初期の要件定義から、メンテナンス・振り返りまで必要なフローは非常に多いです。
また、本来アサインすべきメンバーも多く、各フェーズにおけるメンバーの役割も多岐に渡ることがわかりました。
チャットボットを自社で運用するのは意外と大変です。
現在チャットボットを自社で運用しているものの、なかなか結果を出せていなかったり、運用がうまくいっていなかったりする場合は、適切なビジネスゴール設定ができているか、適切なチーム編成となっているかを今一度再考を検討した方がいいかもしれません。これからチャットボットを活用しようと考えている場合は、自社に必要なメンバーが揃っているか振り返ってみてはいかがでしょうか。

弊社Smashでは本記事で解説した全フローを一気通貫で運用しています。
EC業界における最新事例がございますので、ぜひお気軽にお問い合わせください。