メール履歴を資産として活用できる状態にする話

こんにちは。エンジニアのharada_hiです。投稿を大分サボっていたことを反省しています。
直近でチーム内のメールの一括送信オペレーションの改善を行っておりました。今回はその中でのメールの履歴管理のあり方に関してをテーマとして取り上げています。メールオペレーションに関してなんらか課題感を持っている方の一助となれば幸いです。

■ 1. そもそもの課題

まずはそもそもメールオペレーションの改善でどういった課題を解きたかったのか？という点について触れていきます。

自社サービスを使っていただいている方に向けて一定の条件に当てはまる　対象に向けてメールを一括に送りたい場面というのはビジネス上必ず発生するかと思います。セミナーの案内、システム上重要な連絡などなど様々考えられるのではないでしょうか。
当然メールを一括で送信するだけであればメールツールを使えば可能です。今回踏み込んで解決しようとした点は以下の3点です。

1. 適切な単位での履歴管理
2. 様々な情報を利用した可能な限りパーソナライズされたメール
3. 未購読を選択したユーザーの適切な管理

1は以下のような背景です。

・後から本当にこの連絡をしたんだっけ？という不毛な時間をなくす
・直近に何通もメールを送るようなことをしていないかの可視化
・メールの効果測定の簡易化

2、3は書いたままです。
「メールツールであれば当然できるのでは？」と感じる話かもしれません。ただしこの部分を低コストかつ分かりやすく実現できるか？みたいな点は、複数チームの基盤として考える際には検討する余地のある話だと考えています。
この点はメールツールの選定基準みたいな話なのですが、前提の多い話で整理が厄介だったので一旦今回のnoteのスコープからは外しています。
興味のある方はご連絡ください。
(なんとなくこっちのテーマの方がニーズあるようにも感じていますw)

■ 2. メール履歴を適切に管理したい単位について

適切な管理の単位は会社や事業、メールを管理する部門によっても異なってくる部分ではあります。ここでまとめている話は、私の所属しているプレイド(BtoB SaaS)における契約済のクライアントに対してのメールアプローチという前提をご認識ください。

弊社のサービスの場合、1会社の複数部門にサービスが導入されるケースがあります。そして弊社のカスタマーサクセスはこのそれぞれの部門ごとに動くような形となります。これを弊社ではプロジェクトという概念で管理しています。

この形式で載せているのは弊社Salesforce上のラフなER図です。
弊社のカスタマーサクセスの活動情報はこのプロジェクトに相当する場所に集約させています。必然的にプロジェクト単位でメールの履歴を確認したいという形となります。
当然送信する相手は人ではあり、人に紐づく形でも履歴は残ります。ただし一番確認する頻度や編集する頻度が多い単位はこのプロジェクトです。このプロジェクトに紐づくことが前章で書いた目的を達成するために非常に重要なことと捉えておりました。

このプロジェクトに紐づけて管理するというのは弊社のこれまでの運用による部分ではあり、プロジェクトに紐づけての管理がどの場面でも当てはまるわけではありません。
しかしこのプロジェクトに相当する単位はどこの場面においても存在するのではないかと考えています。管理したい単位 = 一番情報を見ている単位 と捉えて、それがどこにあたるのかを考えるのが良いかと思います。

・ 適切な管理を実現するために必要な前提

プロジェクトに紐づけるという管理方法を実現するに当たってもう一点満たさなければいけない前提があります。
それは人の情報の管理です。
AプロジェクトにいるXさんにメールを送ったとした際に、その履歴情報はAプロジェクトに紐づく必要があるわけです。
つまりXさんがAプロジェクトに属しているというデータ管理をする必要があります。
この管理のためにプロジェクトに紐づくアカウントというデータを管理しています。

このアカウントのデータは以下のデータより自動連携で作成しています。
・実際にサービスを利用している人のデータ
・商談に関わっている人のデータ
そのため手動作成することはなくデータが作られる状態を担保しています。
実現したい状態を作るに当たって継続的に発生するオペレーションを増やすということは可能な限り避けるべき点だと考えています。そもそも人が活動しやすい状態を作るために整えている話なので本末転倒になりかねません。

またこのアカウントの管理情報ではサクセス担当者が手動で入力する情報を付加できるようにしています。
主にはサービスのメイン担当者である、こういうスキルを持っている人であるといった情報です。これは自動で取れるデータだけで機械的にメールを送るということを可能な限り避けた運用をするためのものです。この点は方向性としては良いと考えていますが、まだまだ試行錯誤しているポイントです。一定検証が進んだらまたアウトプットできればと考えています。

■ 3. どのような形でデータを残すか

私がこれまで見てきたメールシステムのデータの残り方はそれぞれのイベントごとにデータが残る形でした。

上記がデータのイメージです。この形でも色々と弄れば十分に効果計測は可能です。ただし一定データを加工するスキルは求められます(上だけ見たら大したことはないかもしれませんが、ここまでシンプルなことは基本的にないはずです・・・)。

今回上記のような構成を以下のような構成に再整理して管理するようにしています。

簡単に言ってしまうと「メール」と「対象者」 という軸で一意になるように集計させたものです。この構成を作れると誰に対して送り、誰が開封し、誰がクリックしたのかが明白となります。また「メール」単位での効果測定を対象者のセグメントごとに実施するなども非常に集計しやすい状態だったりします。
とはいえこの形はあくまで「人」の単位での集計です。この内容のデータより詳細な分析をする際に利用するために管理するようにしていますが、前章で記載したように「プロジェクト」の単位で管理したいのでもう一段ブレイクダウンさせています。

ここまでくるとかなり情報が落ちているのではないか？と感じる方もいるかもしれません。ただしここで落ちてしまっている情報は本当に普段使いするのか？しやすいのか？という点を考えていただくと良いかと思います。
今回のこの構成もあくまでプロジェクト単位でなんのメールが送られたか？それは開封やクリックなどのアクションがされたのか？がパッとわかる点に重きをおいています。そこから更に深堀たいのであれば、人に対する履歴にもすぐにアクセスできるような構成を作っています。

最後に今回紹介した範囲のER図です。

ちょっと複雑に見えるかもしれませんが、あくまでプロジェクトを中心にして情報を整理しているという形で見てもらえればと考えています。

■ 4. おわり

今回のnoteは以上です。
履歴管理なんかよりも別のところ気になります！という声もありそうな気するので、そうした方はtwitterでとかで連絡もらえればと思います。
https://twitter.com/harada_hi320

宣伝を一本挟みますが、こう言ったビジネス上のオペレーションをエンジニアリングで加速させていく仕組みを作るエンジニアを採用していたりします。
https://www.wantedly.com/projects/602853

弊社に興味があるとかは不要なので、こうしたポジションに興味があるや今やっていますという方とは是非是非情報交換したいと思っていたりするので、同じようにtwitterなどで連絡いただけると嬉しいです！