いま携わっているプロダクト内で、Intercom をがっつり使っている。個人的にもすごく好きなサービス。最近ちょっと面白いなと思うことがあったのでまとめてみる。
Intercomとは
Intercomはカスタマーサポート (CS) 向けのSaaSで、チャット形式のサポートツールを主軸に、顧客管理やマーケティングメールの配信など、CSに留まらず所謂CRM (顧客関係管理) までをカバーしてくれるサービス。最近のSaaSだとちらほら使ってるのを見かける。
Intercomの価値はこの図がよく表している。CS、マーケティング、行動分析、課金など目的の違いだけを見てシステムを導入した結果、ひとりの利用者にまつわる情報が分散してしまうというのはよくある話。CSはGmailで、マーケティングメールの配信はMailchimp、行動分析はMixpanel、課金はStripeでみたいな。Intercomはそれら分散しがちな顧客にまつわるあれこれをまとめてくれる。
プロダクトを作る人間として、目的はどうあれプロダクトと顧客の接点から得られる情報は、どんな些細なものでも無駄にしたくない。単なるCSのSaaSという以上の価値をIntercomに感じるので、すごく気に入っている。もちろんこの手の役割を担う製品は、CRMの分野で昔からあるんだけど (Zendeskとか)、うまくスタートアップ向けにパッケージング (機能の分け方や料金設計含め) していたり、プロダクト設計の巧さを感じる。
CSは最近だとCustomer Successと呼ばれたりもするが、IntercomもCSとは何なのか、何を考えどうすべきなのかというのを積極的に発信している。自社ブログも超気合が入ってるし、電子書籍を出版したり、Podcastをやったりもしている。この辺りのコンテンツマーケティングみたいなのもすごく参考になる。
前置きが長くなったけど、IntercomはIntercom自身のサポート対応も凄く丁寧で考えられている。海外製品のサポートに問い合わせると、時差もあるので返答に1日かかることはザラだけど、Intercomは遅くとも2, 3時間で初回返答が得られる。内容も変に堅苦しくなく、テンプレ対応ではなく親身に接してくれるな、というのを言語の壁を超えて感じる。Intercomを使い始めて3ヶ月ぐらい立つが、サポートを求めたり、フィードバックを送ったり、2-30回はやりとりしていると思う。
Jobs To Be Done
話は飛んで、JTBD: Jobs To Be Done という考え方がある。詳しくはググるとすぐ出てくるけど、日本語だと 片付けるべき仕事 とかそんな感じ。僕の理解だと、製品作るにあたって、利用者の要望をそのまま実現するんじゃなくて、利用者の言葉の裏にある、「何の仕事を片付けたいのか」を考えましょう的な話。
マーケティングとかリーンスタートアップとかでよく言われる、「もし顧客に、彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい』と答えていただろう。」とか「ドリルを買いに来た人が欲しいのはドリルではなく穴である」とか、これ系の話を総じてJTBDと言うらしい。
Intercomはプロダクトを作るにあたって、このJTBDの考え方を大事にしているらしい。この話は、以前参加した、SaaS Conference Tokyo 2016でもIntercomのマーケティング担当が話してて凄く面白かった。
Intercom Educateでテーブル記法が使えない件に文句を言った話
話の本題。つい最近Intercom Educateというナレッジベース (ヘルプ記事を書くためのCMSみたいなもの) がリリースされた。ここ数日触ってるものの、まだリリースされたばかりなのもあってちょっと機能が貧弱で、ちょくちょく問い合わせたりフィードバック送ったりしている。
先日いち利用者として困ったのは、テーブル (表) を書くための記法がサポートされていないこと。ヘルプを見てみると、なんと表は画像として埋め込めって書いてある…。HTMLタグのべた書きもできないらしい…。
このときは「はーまじかよ！」とおもって、思わず記事の下にある ? ボタンを押した。すると自動でチャットが開き、「ごめん、なんかできることある？」と自動返信が来た。
Intercom Educateにこの自動返信機能があるのは知っていた （このヘルプ記事もまたIntercom Educateでできている）ので、「はいはいあの機能ね」と思いつつ雑に「Please support table syntax.」とチャットに書いて、ページをそっ閉じした。
“美学 aesthetics"に反するからやらない
そうすると、数時間後IntercomのCS担当からこんな返信がきた。 (原文一部抜粋)
For the time being this isn’t possible as it would ruin the aesthetics of our help center and thus cause damage to the overall look and feel of your article - we instead recommend you take a picture of the table for the time being and upload it in its place ? I’ll provide your feedback to the team all the same - is there a particular use case or reason you could give me for wanting to see the table as a syntax option within the article editor?
ようは「ヘルプセンターの美学を損なうから、 テーブル記法のサポートはできない」「記事の見た目を損なう」「表は画像で埋め込め」だそう。
これには、お前らの美学とか知るかよ！と思ってイラっとしたので、こんな感じで返した。(実際は英語)
その方針は残念。画像として表を埋め込むと、記事を読んでる人がコピペしたくてもできないじゃん。それって利用者に不便かけてるよね。ヘルプセンターの美学よりも、利用者の利便性のほうが重要じゃないの？ それと、記事のローカライズの観点でも、表を画像として埋め込むのは筋が悪いよね。テキストを翻訳するのに比べると、画像の翻訳ってめっちゃ手間なんだけど。
自分で書いたことだけど、めっちゃ正論だと思う。同じようなフィードバックを送ってる人たくさん居るだろう。 そしたら5分後に返信がきました。
Understood Takaya - thanks very much for the feedback here and I’ll make sure to pass it on? I must emphasise that when I say aesthetics, I’m not only talking about looks - we also believe that each product has a job to be done and we want to make sure functionality is at its height. This means that, sometimes, the ‘aesthetics’ may interfere with the functionality of the product and make things unusable, not visible, or disturb the layout in a way which wouldn’t benefit the users ability to use the product. We therefore avoid these situations, and tables are a syntax which can currently strongly disturb this - however, we are working on improving what extra HTML components we will support and ensuring they fit in with our overall product without taking away from the users experience. Once again, thanks for understanding, and if you have any more feedback then let me know ?
僕の解釈だと、「美学ってのは見た目だけのことをいいたいんじゃない、俺達はどのプロダクトにもJTBDを大事にしてる」「テーブル記法は美学 (JTBD) を損なう。美学はときに利便性を妨げるかもしれない。」「美学を損なわずにいい感じテーブル作れる方法に取り組んでる」ってことらしい。
僕自身も記事を書くプロダクトを作っているので、この話はよくわかる。MarkdownにしろHTMLにしろ、テーブルをテキストで書くのは大変難しい。
JTBDでいえば、僕がIntercom Educateを通して片付けたい仕事は、「自分のプロダクトの利用者のために、分かりやすいヘルプ記事を書く」ことであって、「表をテーブル記法で記述する」ことではない。テーブル記法を使うのは慣れていても難しいし、間違いなく時間かかる。記法を実装し、それを記事にテーブルを入力する方法として安易に提供することは、利用者の仕事を増やしてるともいえる。
結果としては、短期的には不便を被ってるんだけど、Intercomのプロダクトに対する思想が改めて見えたし、じゃあ期待して待ってるよって素直に思えた。
改めてIntercomすごいなと思った
相手を見て話を選んでる感
正直、初回の返事でいきなり"美学 aesthetics“なんて言ったのは悪手だと思う。ニュアンスが分からないのもあり実際イラッとした。ただ、最後の返答は納得感あった。これはたぶん僕のIntercom上のプロフィール (RoleにProduct Managerって書いてる) を見た上で、"美学"なんて話をしてきたんだと思う。
プロダクトの思想がサポートチームにも行き渡ってる
Intercom自身もスタートアップとはいえ、地理的に離れた拠点が複数あるような規模の組織なのに、プロダクトチームだけじゃなくてサポートチームにまでちゃんと思想が行き渡ってる。組織の規模が大きくなればなるほど、プロダクトの思想への理解はブレるのが普通だと思う。前述したSaaS Conferenceの話やIntercomの自社メディアを見てると、プロダクトの思想を会社として大切にしているのは知っていたが、それを行動として直接見せつけられた感覚だった。
正論に流されない
なんでもそうですが、正論言うのは簡単。今回僕が送ったフィードバックなんて、世界中から色んな人がIntercomに同じこと言ってると思う。その正論に流されて、プロダクト作って良い物ができるかと言われたらそんなことは無い。安易に正論に流されないようにするのは、プロダクトを作る上で大事なことだと思う。
僕自身も自分のプロダクトでCS対応してて思うのは、フィードバックに対して「検討しますね」って言って終わるほうが絶対に楽。でもそこで正直に「美学に反するからやらない」って返すのは凄い。でも、実際そう返すのは怖い。だからこそ、相手を見て話を選ぶのが大事であり、その思想の体現として、Intercomでは顧客ごとに属性が紐付けられるようになっている。
とはいえ…
さっさとテーブル書けるようにしてくれ頼む 🙏（ってのが利用者の素直な気持ちなのはまた事実だから難しい…）
