ボクココ

サービス開発を成功させるまでの歩み

ポッドキャストに出演した話 (収録内容付)

ども、@kimihom です。

今回は縁があって Salesforce 界隈でおなじみの migration.fm というポッドキャストにゲストとして参加させていただいた。そして恐れ多くも2回に渡って公開していただくこととなった。

まずは時間ある時にでも聴いていただけたら幸いだ(それぞれ1時間くらい)。以下、概要とともにリンクをご紹介する。

16 Customer Success! (kimihom)

16: Customer Success! (kimihom)

  • migration.fm を運営されている倉谷さんと知り合ったきっかけ
  • Heroku コミュニティの運営に対する思い
  • 本当のカスタマーサクセスとは

17 Where is Silicon Valley in Japan?

17: Where is Silicon Valley in Japan? (kimihom)

  • 新しい技術 (AI, BigData, IoT…)
  • 日本のシリコンバレー。現時点ではないが、福岡が最有力?
  • よいサービスの作り方。信念を通しつつも顧客と向き合うこと

自分で聴いてみて感じたこと

自分のコミュニケーション能力の低さを露呈してしまった感がものすごく出ている出演だったと思うw 何せ普段、リモートワークで誰とも喋らずにただひたすらプログラミングやこうして記事を書いていることが多い中で、いきなり声でのポッドキャスト出演となれば誰だって難しいだろう。きっと聴く人のことを意識して喋るってのもまたスキルの一つとしてあるのだと思う。私には圧倒的にその能力が無く、素人っぷりが出てしまった。

ただ MC の倉谷さんはさすがの進行力でうまくバランスを取っていただいたと思う。私の素人っぷりの喋りでもなんとか聴いてもらえるような内容になったと思っていただいていることを願う。

話した内容で Part 16 は Heroku コミュニティネタ以外はボクココに書いたことがベースになっているので、読者の方であれば慣れ親しんだ話題に聞こえるかと思う。 Part 17 は割と未来のことって感じであまり記事で書いていない話題に触れているけど、ちょっとだらだら話しちゃったな〜と反省。"このビジネスはいける" 的な話は、最終的にはお前がやれよなんだよなぁ。まるで VC が起業のサービスネタについて喋っているような感じになってしまった。聞く人にとってはそう思われてしまうような感じだっただろうけど、話した本人としてはとても楽しかった。

話し上手か下手かはさておき、私は今回のポッドキャストのような内容を話すことが好きで、そういうのを情熱もって話してくれる人と交流を深めていきたい。そんな意味では良いアピールにもなったと思う。

いつか自分のポッドキャスト bokukoko.fm をやってみても面白いかもな〜と検討したけど、ポッドキャストをやる側になると MC の立場になるわけで、聞く力が間違いなく大事になる。 それはそれでスキルとして磨いていければ良いんだろうけど、やっぱ私はこうしてブログでひたすら思いを書きまくるってスタイルの方が今までやってきた経験を踏まえて自分に合ってるなと感じた。

私は友人や知人にブログを書きましょう、読みにいきますから とよく言ってるんだけど(それでも書いてくれない泣)、ポッドキャストで情報を発信していく人が今後もっと増えても良いんじゃないかな〜。ポッドキャストは移動中に目を使わなくても情報を"聞ける"って意味でありがたいものになるはずだ。最近自分の目がしょっちゅう疲れるんだけど、そうなるとマジで何もやることがなくなるので結局目を使うみたいな循環の繰り返しだった。ポッドキャストはそんな私の一つの良い対処法の一つでもある。知り合いがポッドキャストをやっているのであれば尚更聞きたいし、配信者の方と今後もっと多く巡り会えたら良いな。

終わりに

今回はお誘いいただき & 聴いていただきありがとうございました。ポッドキャストに出演するって機会はほとんどないと思うので、良い経験になった。

実際はポッドキャストって言っても、収録が始まれば普段のトークをしている感じだったので(それのせいで聴きづらい感じになっちゃってるかもしれないけど)楽しく参加することができた。

何か思い出した時にでも定期的にこの収録を聴いていきたい。私にとってそんなポッドキャストの収録だった。

勝手に好きな技術の Twitter サポートを始めてみた話

ども、@kimihom です。

私は HerokuTwilio (あとちょっとだけ Stripe)の User Group のコミュニティの運営として活動に協力しているわけだけども、イベント開催以外でこれらのテクノロジーの普及に向けて何かできることはないかと思っていた。

そんな矢先、ふと Twitter で Heroku や Twilio の検索をしてみると、これら技術に関する問題や疑問をツイートしている方が何人かいた。

思い返してみると、確かにどっかの質問サイトに投稿したところで、実際に見て回答してくれる人ってのは少ないかもしれない。私自身、テクノロジーで何か困ったことがあったらまずは公式ドキュメント + ググってみて、それでもダメならソース読むか US サポートに依頼するみたいなくらい極端な解決方法しかなかった。

この間でもうちょっと助けになってくれる人がいたら、その技術をより使っていきたいと思ってくれるかもしれないし、その技術自体が好きになってくれるかもしれない。私としては Heroku や Twilio を好きな方と一緒に盛り上げていきたいと思っているので、どんどんコミュニティのメンバーが増えていって欲しいと考えている。

問題をそのままにしてしまうと、その技術自体の興味が薄れてしまったりやりたくなくなったりしてしまうことがよく起こる。きっと私も同じような経験をすればそうなるに違いない。結果としてその技術自体も日本で流行らなくなり、ノウハウもたまっていかずに衰退していく。そうなれば、今まさにその技術を使っている私にも大きなダメージを食らうことになってしまう。

てことで、定期的に Heroku と Twilio のツイートで何か困ってそうな方がいて自分が助けになれそうなものに関しては積極的にリプライしていこうと決めた次第である。念のためだが、別にこれら2つのサービスからお金とかもらってるわけではない。

ちなみに Heroku の日本語サポートは Enterprise 契約していないと対応してくれないそうで(!)、ここは私が一役買わないといけないなと強く感じた次第である。Twilio は技術サポートに問い合わせれば回答はくれる。ただ、 Twitter での Twilio に関するタイムラインは見てないようなので、そこは私が時間空いた時に(勝手に)引き受けようと思う。

実際に Twitter サポートを始めてみた

早速、何人か困ってそうな方にツイートをすると、ツイートした問題が解決には至ってない場合が多く、こうして私が何か言わなければそのまま問題が放置されていたような状態だった。

Heroku は解決が難しい(Heroku が原因ではない)場合が多いので大変だけど、話をするだけでも自分自身の勉強につながる。Heroku がどうやって使われているのか、どんな時に使いたいのかを知ることで、自分の技術や興味の幅が広がるので良いことだ。

反対に Twilio は私自身が Twilio のほぼ全てのサービスを触ってやり込んでるので、助けになることが必ずあるはずだと思っている。Twilio 自体が日本ではまだまだ盛り上がりに欠ける部分があるので、こうしたサポートの側面からでも貢献できたらと思う。

そんなこんなで始めてみたはいいものの、公式の Twitter Web サイトを使っていると毎回検索バーに行って最新順で並び替えるという手順を踏まないといけないので地味にめんどくさいw。ここは何かしらの方法で解決していきたい。

てことで困ったらツイートしてみてね

Heroku や Twilio で困ったらツイートしてみて欲しい。もちろん私はこれが本業ってわけじゃないので返信の頻度は下がるけど、困ってそうなツイートを見かけたらフォロー関係なくつぶやいていきたいと思っている次第である。

Heroku と Twilio は本当に素晴らしい技術なので、皆さんもぜひ始めて欲しい。

困っても大丈夫。私がきっと付いている。

Twilio の AuthToken と API Key の違い

ども、@kimihom です。

今回は Twilio ネタ。地味だけどこういうのって調べようと思わないと知らない内容だと思うので記事にしてみた。

AuthToken と API Key の違い

まず Twilio には API アクセスするために、AccountSID と AuthToken の2つが出てくる。これは Twilio をコードで使ったことがある方なら誰でも見たことのある項目のはずだ。基本的に、AccountSID と AuthToken の2つを使えば、どんな API リクエストでも実行が可能だ。

それゆえに、AccountSID と AuthToken のペアはマスターキー的な感じになっているので、できる限りあまり使いたくはないと思うだろう。AuthToken は特に大切に扱うべきだ。なぜなら AccountSID は割と公開された情報なので AuthToken がバレた瞬間に誰もが全ての API を実行できるような感じになってしまうからである。 Twilio の API 呼び出しは無料じゃないので、これは痛いところである。

きっと読者の皆さんも、AWS のアカウント管理で IAM をうまく使って管理をされているはずだ。Twilio ではどうすれば良いのか。

そこで Twilio には API Key という概念を提供して API 利用に応じてうまく分けようとしている。API Key には 2つの役割(Standard と Master) が用意されている。基本的には Standard の API Key を使うことで深刻な API(アカウントの作成/削除など) の利用を禁止することができる。てことで API Key を利用するなら Standard で作ることになるだろう。

Twilio は何でも API Key でできるのか?

うまく API Key を活用すれば、 AccountSID, API Key SID, API Key Secret の3つを保存するだけで Twilio REST API のアクセスが可能になる。つまり、データベースにサブアカウントごとの AuthToken を保存する必要がなくなる!

ここで Twilio の落とし穴にご注意を。Twilio の AccountSID と AuthToken でしかできない行動ってのがいくつかある。

  • Twilio Client の ケイパビリティトークンの生成 (なんでやねん)
  • API Key の作成

私がハマったのはこの2つ。もしかしたら他にもあるかもしれないので、 API Key で API アクセスを運用する際にはご注意を。 Twilio Client のケイパビリティトークンがなぜ AuthToken でしか生成できないのか、全くもって意味不明。これ Twilio の設計がイケてないんじゃないかと思ったほどだが、何か理由があるのだろう。ちなみに他の Chat, Video, Sync などのトークン生成は API Key と AccountSID で作れる。

終わりに

今回は Twilio の小ネタをご紹介した。Twiliio Client のケイパビリティトークン以外の API アクセスは、基本的に API Key ベースの API アクセスにした方が安全に Twilio を利用できると思う。

Admin の AccountSID と AuthToken だけ環境変数で持つようにして、サブアカウントの個々のリソースアクセスは API Key ベースでアクセスするって感じがいいんじゃないだろうか。

さて、いよいよ再来週になったが Twilio Developer Meetup、まだ空きがあるみたいなので参加検討いただけると幸いだ。ちなみに私も LT する予定なのでお楽しみに。

twiliomeetup.doorkeeper.jp

1人エンジニアでサービスを成長させるために実施したい4つのこと

ども、@kimihom です。

1人エンジニアでサービスを成長させるために実施したいことについてまとめてみる。

ローンチ前と後の違い

サービスローンチ前の開発ほど楽しいものはない。誰かに何かを言われるわけでもなく、ただこれを作る!と決めたものを夢中になって作っていける。間に割ってくる人もいない。いかに早く、そして良い物を作り上げることがローンチ前の使命だ。

ローンチした後からは別物となる。少数の見込み顧客がつきながら、その様子を見ながら開発していかなければならない。当然開発だけって状態ではなくなってきて、サーバーの運用やバグの修正、顧客サポートなどあらゆるタスクが入ってくる。

この時点でうまく人を雇ったりするのも1つの手かもしれないが、私はローンチ後も2年以上、ずっとエンジニア1人でやってきた。同じような人が今後出てきた時のために、私からの言葉として以下の文章をまとめる。

インフラを無駄にこだわらない

これはローンチ前に設計しなきゃいけない話ではあるんだけど、ローンチ後にインフラ整備をするようなケースがあったりする。それははっきり言って時間の無駄だ。一体なぜ現状アクセスがほとんどない(そして将来アクセスがくるかどうかもわからない)サービスのインフラで、将来のデータ量やアクセス数を気にしなければならないのか?

1人でやってるって場合は、ローンチ後も基本的にアプリケーションのコードをひたすら改善していくことが求められる。Infrastructure as Code だとか、マイクロサービスなんて話題は出てこない。

インフラは既にある信頼された PaaS を利用しよう。これによってデプロイ周りやインフラの構成など、自前で構築せずともベストプラクティスな環境を利用できる。

値段が高くなるなんてことは気にする必要はない。自前でインフラを持つことによってかかるインフラエンジニア1人のコスト or 自分でインフラに試行錯誤に使う時間に比べたら、PaaS にそれなりのお金を払うなんてことは本当に微々たる料金だ。しかも長年の経験と知恵で研ぎ澄まされてきた PaaS は雇ったインフラエンジニアよりも優秀な成果を生むだろう。

同じように、自前でやらなきゃいけない部分はサービスのコアの部分に集中させ、それ以外の一般的な部分(検索やDB, KVS)も外部の Addon という形で導入しよう。これによってサービスとは関係ないインフラレベルで問題が起きた時は自分で調べるのではなく、サポートに問い合わせてその分野の一流のプロフェッショナルにお願いすることができる。これだけでインフラ管理の手間がなくなる。同様に、ログ管理やメトリクス管理など、これらもPaaS の提供するアドオンで構成すれば、インフラは一流インフラエンジニアが構築した並みの環境を用意することができる。

改めて、1人でサービスを開発するのなら一番大事なのは、サービスのコア部分の開発だ。そのサービスで顧客に一番価値を届けられる部分を磨き続けること。それにいかに時間を費やすことができるかが勝負だ。そこさえ極めていけば、他の企業が10人かかって同様のサービスを出してきても対等に立ち向かえるサービスを作り上げることができる。

ぶっ壊すことを恐れない

実際にサービスを公開してみたら、顧客は違う機能を求めている傾向が強かった。そんなことがよく起こる。そん時にシステムを0から作り直さないといけないくらいのレベルでもぶっ壊していった方が、最終的にはいい結果を生む。なーに、0から作り直すっていったって、たかだか数ヶ月の時間をかけて作ったシステムではないか! 恐れずぶっ壊していこう。変に以前のサービス内容にこだわって変更しないままビジネスが成長しないことの方がよっぽど恐るべきことである。

だから、私は0->1のフェーズでテストコードをガリガリと書くのをオススメしない。1人でサービスを作ってローンチしたなら、テストコードを書く価値ってのはそこまで高くない。自分の中で設計図が全て頭に入っているので、他のメンバーが意図しない修正をされる心配もないのである。逆にテストコードを書けば書くほど、先ほどのぶっ壊すって選択をしづらくさせる。

こういう判断も、人が多ければ多いほど遅くなるだけだ。スピード感ってのは0->1のフェーズでは最も大切だけど、人が多いだけで遅くなってしまう。エンジニアは本当に限られた少数精鋭でやるべきだと考えている。私みたいにエンジニアは1人でも全然問題ない。

顧客管理の自動化を検討する

顧客が50, 100 と増えてきたら、顧客を自動で管理できるような体制を整えることを検討しよう。俗にいう管理ツールの整備だ。

具体的には CRM に顧客を登録して、チャットやメールなどの履歴、ユーザー行動、現状の設定状況などを全て一元管理できるような仕組みを用意することが望ましい。CRM の用意が難しいのなら、自前で社員の誰もが気軽に(そしてセキュアに)顧客情報にアクセスできる環境を用意しよう。これによってエンジニアだけでなく、ビジネスやマーケティング / サポートの人が顧客情報に手軽にアクセスできるようになり、新規顧客獲得の分析や、サポートの品質向上など、あらゆる面においてサービスの改善に役立ってくる。

サービス成功において大事なのはサービスの機能だけではない。こうした顧客情報をいかにして管理して社内で共有していくかってのもサービスの成功に重要な要素だ。

これによって社内の無駄な連絡コストも減る。みんなが CRM に情報を入力していくようなベースを整えていければ完璧だ。

情報を発信する

0->1 を作り上げたサービス開発のノウハウってのは情報の宝庫だ。ゼロから技術を使って構築した経験ってのは他の人も確実に欲しい情報で、拡散されやすい性質を持っている。

その技術を使ってどうやって実現したか。どこで詰まって、どうやって解決したか。何の情報が参考になったか。ブログを書くだけでなく、イベントに登壇したっていいかもしれない。私自身、ローンチ後はかなりのイベントに参加して知見を共有していった。そして今でも可能な限りイベントに参加してこれまでの経験をシェアするようにしている。

登壇履歴と資料 - ボクココ

ブログや登壇によってエンジニアとしての価値を高めることもできるし、サービスの宣伝もできる。0->1をやったのに何も情報発信をしないってのはあまりにも勿体無すぎる選択だ。1人エンジニアの場合はコードを書くだけでなく、こうしたアウトプットも必ず求められる。

終わりに

今回の4つのことは、私がやってきて正解だと思ったことに絞って紹介した。

1人エンジニアってのは時に孤独を伴うが、自分の理想のシステムを求め続けられるって意味でなかなかエキサイティングなことだと思っている。自分の極めたい技術のコミュニティに入れば、情報交換だってできる。だから自分のシステムは思い切って1人で作り上げるくらいの気迫を見せて欲しい。

サービスに対して情熱的なエンジニアが増えていって、いいサービスが増えて行くといいなと思う。

Twilio TaskRouter が目指すもの

ども、@kimihom です。

f:id:cevid_cpp:20170711192614p:plain

Twilio をちょっとかじってると、 TaskRouter という言葉を目にすることがある。たいていの場合、「何やらよくわからんもの」くらいな感じでスルーしてしまいがちなんだけど、この TaskRouter は Twilio の目指す世界観を深く表しているサービスなのでご紹介しようと思う。

TaskRouter とは

TaskRouter とは、コンタクトセンターにやってくる全ての電話/メール/チャット/その他作業を “Task” として定義し、待機しているオペレーター(以降 Worker) に Task を最適に分配するシステムのことである。Worker にはそれぞれスキルを定義することができて、やってきた Task に対して優先度付けを行い、最適な Worker に Task を割り当てることができる。このスキルには Worker の話せる言語をセットしたり、サポート/営業 といった部署で振り分けたり、最初に電話を受ける担当みたいなことをセットしたりできる。また、Worker が一定時間 Task に対応してくれなかったら別の Worker に再アサインするような仕組みまで用意されている。

あらゆる問い合わせが大量にやってくるコンタクトセンターを想像してみて欲しい。そこにはあらゆる種類の問い合わせと、あらゆる種類のチャネル(電話/メール/SNS) での問い合わせがやってくる。それらを上から一つずつ対応していくってのも無理なくらい問い合わせが来た場合には、優先度付けして対応していかないといけないんだけども、それらを都度マネージャーみたいな人が手動で割り当てるのって時間の無駄だよねって発想が根底としてある。

このマネージャーの振り分け判断基準みたいなのを、全て自動化しようってのが TaskRouter の考え方だ。

Twilio としてはオムニチャネル化を目指している傾向が強く、TaskRouter はそのオムニチャネル対応を可能にする手段と言えよう。オムニチャネルとは、全てのチャネル(電話/メール/SNS etc) を同一の端末で対応ができるような統合的なチャネルサポートと本記事では定義する。

TaskRouter を使うメリット

やって来る問い合わせが逐次で対応できないくらい大量に来る場合に、 TaskRouter を検討するのが良いと思う。

基本的に、TaskRouter を使う場合は全ての着信はキューに溜め込む必要がある。そのキューに入れた通話やメールに対してどれが一番先に対応しないといけないのかを TaskRouter が判断して、各 Worker に通知を送るのだ。大規模コールセンターを想定しているくらいだから、デフォルトで着信をキューに入れるってのは当然の話かもしれないが、それじゃ困る(普通にブルルって着信を鳴らしたい)って場合は TaskRouter の利用は向かない。

TaskRouter には JavaScript SDK が用意されている。この JavaScript SDK を利用することで、Worker がログインした時点で今対応しなきゃいけない Task が出て来た時にポップアップ表示できるような仕組みを構築できる。裏では WebSocket によるプッシュ通知が行われているような仕組みだ。私たちはその Task がやって来たら コールキューで待っている電話を繋ぎに行ったり、メール返信したりするような UI と機能を構築すればいいことになる。

また、TaskRouter を使えば リアルタイム/統計 の分析ができるのも大きな魅力だ。誰が今どんな対応をしているのかってのはスーパーバイザー的な立ち位置の人には必要な機能だ。また今月どのくらいの通話があったのかなどの分析も TaskRouter を使えば標準 API を呼ぶだけで取ってこれるってのも、TaskRouter を使って得られる魅力だろう。TaskRouter を使わなければ、これらの仕組みを自前で DB に保存して取得しなければならない。

そしてさらに ワークフォースマネジメント(Worker の勤怠管理的な)のを実現するのにも TaskRouter は役に立つ。今後、これら付加的な機能は Twilio Addon として他の企業の提供するワークフォースマネジメントツールと連携される予定なので、もし興味があれば調べてみていただきたい。これらは最近の大規模コールセンターシステムの機能でよく言われている話なので、コールセンター業界にいる方なら知っていることも多いかと思う。

参考資料

US のランディングページ www.twilio.com

日本語のドキュメント

Twilio TaskRouter - Twilio

終わりに

今回は Twilio の最難関と言っても過言ではない TaskRouter の概要について紹介した。今月(7月)末に Twilio Developer の集まるイベントがあるので、もしよければこちらの参加も検討いただけたら幸いである。ぜひ有意義な情報交換をしましょう!

twiliomeetup.doorkeeper.jp

顧客管理の重要性について改めて思うこと

ども、@kimihom です。

f:id:cevid_cpp:20170710184018p:plain

(初めて Canva で作成してみた)

唐突ではあるけども、皆さん、顧客管理してますか? 今回は顧客管理の重要性について改めて記していこうと思う。

顧客との接点の全てを記録しよう

企業活動ってのは当然一人でするものではない。ある時セールスの佐藤さんが A 株式会社とメールをやり取りし、面談に行ったとしよう。その A 株式会社は後に顧客となり、サポートの 鈴木さんが担当することになった。果たして、鈴木さんは A 株式会社の情報をどれだけ把握することができるだろうか?

ここが企業の強さを左右すると思う。サポートの鈴木さんに何も情報がなければ、きっと鈴木さんは佐藤さんに確認するような手順を踏むことになるだろう。これが2人だけならまだしも、10人100人と関係者が増えていくにつれ、そんな記憶ベースの管理は破綻する。結果として情報が分断されてしまって最終的には A 株式会社に同じことを聞く、もしくは知らない前提で対応するという行動を取ってしまう。それでは当然、顧客満足度を上げることはできないし、むしろ低下する一方である。そんな顧客対応の繰り返しが、やがて企業の存続を危ぶむほどになるのである。

顧客との接点全てを管理できれば、先ほどのようなトラブルは無くなる。担当者が変わっても、顧客情報を閲覧すれば、今まで誰がどんな対応をして今どういう状態なのかを一瞬で把握することができる。誰かに教えてもらわずとも、最高の引き継ぎができた状態で顧客と接することができるようになるのだ!

これは企業が大きくなればなるほど、時間が経てば経つほど、顧客が増えれば増えるほど、大事になってくる。

顧客管理ソフト(CRM) に全ての情報を集約する

CRM はそのために存在する。顧客との接点全てを Web 上で保存し、顧客とのやりとりを誰もが管理できるようになるシステムである。

完璧な CRM 運用をすれば、メールが来た瞬間、誰がいつどんな対面や電話対応をしたのかが一瞬で把握できるようになる。これは顧客満足度の上昇だけでなく、仕事の効率化にも繋がり、ビジネスをより飛躍させることができる。だからこそ、成功している企業こそ顧客管理をしっかりとしているのだ。

CRM 活用の先には、"優良顧客"にはどんな特徴があって、どういうことをしたらそうなったのかといった分析も可能になる。正しい顧客を呼び込むことができるようになり、正しい顧客に正しいサービスを提供することができるようになるのである。

顧客管理がビジネスの成功を左右すると言っても過言ではない、と最近は思う。

いかにして自動化するか、テクノロジー企業の腕の見せ所

分断された情報をどうやって一つにまとめるのかってのが課題となってくる。メールでやり取りしたら、わざわざその CRM に手入力しなければならないのか?電話するたびにメモをそこに保存しなければならないのか?対面するたびに?キャンペーンメール送るたびに?

実際、全ての情報を入れる必要があるのだから、どんな方法であれ顧客とのやりとりを保存しなければならない。顧客とのやりとりをいかにして CRM に蓄積し、手軽に参照できるようにするか。エンジニアの腕の見せ所である。

顧客との接点は以下のようなものが存在する。

  • サービス利用(Web/アプリ上での会員情報や行動履歴)
  • 対面
  • 電話
  • メール
  • SNS
  • その他新しいコミュニケーションチャネル (チャットやビデオ通話など)

まずは顧客情報を登録することが先手だ。住所、電話番号、メールアドレス、SNSアカウントなど。これらの情報を元に、 CRM 上の顧客を一意にすることが必要である。そうしたら検索によってマッチする顧客の活動として書き出したり、予定として登録したりできるようになる。

少なくとも顧客を"マージ"するような機能のある CRM の利用を検討したほうがいいだろう。そうじゃないと顧客がメールや電話番号ごとに分断されてしまい、本来の CRM のメリットを活用することができないからだ。完璧な顧客情報のベースがあって初めて、その先の顧客の検索や活動情報の入力ができるようになるのである。

んで、CRM 登録の一部は自動化できるけど、一部はどうしても手作業が入ってしまう。その手間を惜しまず、完璧な顧客管理を目指していく姿勢が絶対に必要だ。ただ単にシステム連携して書き出しっぱなしにしているようだと、ゴミデータがどんどん溜まっていくだけで何のメリットも享受することができないのである。

顧客管理を徹底した先に見える理想像

セールスの佐藤さんは A 株式会社と以前コンタクトを取り、 CRM に住所とメールアドレス、面談内容を入力した。ある日、A株式会社は顧客となり、会員情報として電話番号を入力していただいた。入力ある日、A株式会社からメール問い合わせがあり、鈴木さんが担当することになった。鈴木さんは以前どんな対応をして来たのかを CRM で確認し、既存顧客への返答として最適なサポートをした。半年経って、再び A 株式会社から電話がかかって来て、今度は高橋さんが担当した。当然、高橋さんは半年前の記録を見ることができるので、A株式会社が忘れてたようなことまでサポートでき、最終的に A株式会社はロイヤルカスタマーになった。

CRM を本気で運用している会社はここまで既に実現している。このような顧客管理は、会社全体で取り組んでいかないと実現は不可能だ。

一人一人が CRM を入力/整備しながら完璧を目指していく。そんな姿勢によって初めて、ビジネスを成功に導く CRM となることができるのではないだろうか。

誰でも情報を入力できる環境ってのが大事で、そこが徹底されている企業は、強い企業になると思う。

終わりに

顧客管理の徹底は、特にスタートアップ時期だと忘れがちなことだと思うんだけど、ぜひしっかりと顧客管理のできる企業が増えていってほしいと思う。

しっかりと顧客情報のベースが CRM にあって、自社の社員が情報を入力/整備できるような仕組みを整えてこそ、初めて顧客管理が始められる。顧客との接点全てを記録しなければならないから、手入力が時に必要になることだって当然存在する。そこを勘違いして全部自動化でやろうとすると必ず失敗するので気をつけてほしい。

まずは一人一人が顧客管理の重要性を理解し、できる限り CRM に情報を入力していくことから初めてみてはいかがだろうか。

実はこんなにあった Twilio のサービスを紹介

ども、@kimihom です。

f:id:cevid_cpp:20170707220201p:plain

みなさんは Twilio 使っているだろうか?「あ〜あの電話かけられる API でしょ」という方は、それはもう3年以上前に出会ったっきりで終わっていることだろう。あれから Twilio はアメリカで上場を果たし、さらなるサービス提供を進めている。てことで今回は日本で Twilio を使って何かやっていく場合に有益になるそうなサービスを全て紹介していく。もしかすると、今すぐにでも欲しい API が見つかるかもしれない。

twilio.kddi-web.com

プログラマブル Voice

まずは一番メジャーな音声通話の API 。050/0800/0120 番号を取得し、その番号に対してあらゆる命令を投げかけることができる。例えば API で電話を発信できちゃったり、通話中に API を呼んで何かに切り替えたりと、複雑な音声技術を API を呼ぶだけで実現できてしまう。 今でも Twilio 最大の強みは Voice だと思うので、まずは Voice で感動を味わってみていただきたい。API で「すごっ」と思う数少ない経験をすることができるだろう。

プログラマブル Fax

Fax を API で呼ぶことのできる仕組み。 PDF や PNG 画像で Fax を送ることができ、またさらに受信もできる。Twilio の提供する 050 番号なので、その番号は Fax もできるし電話もできるような番号にすることが可能だ。特に日本は Fax 文化が強いので、電話/Fax を組み合わせた何かが出て来てくるのが望まれていると思う。

プログラマブル Video

Twilio のビデオ通話のプラットフォームだ。日本では Skyway がメジャーだとは思うが、 Twilio もビデオ通話のプラットフォームを提供している。今までの Twilio Video は P2P 接続のみのサポートだったが、つい最近、サーバーを経由したビデオ通話(SFU) を提供している。これにより、通話の録画や同時100人までの通話が可能になった。

プログラマブル Chat

Twilio のチャットのプラットフォームである。一般的なチャットを作るには、 ユーザー/会話部屋/メッセージ/招待/権限・・・などなど、共通の実装が必要になる。これらを全て API で提供し、基本的なチャットをサーバーのコードを限りなく少なくし、データ自体も Twilio に保存してくれるような仕組みを提供している。これによって誰でも本格的なチャットシステムを構築することが可能になる。

Sync (beta)

Sync はまさに Firebase のリアルタイムデータベースのようなものだと考えていただいて良いかと思う。Firebase は基本的に JSON のみのモバイルにフォーカスされたプロダクトかと思うが、 Sync には JSON(ドキュメント) によるデータ同期の他に、 List や Map といった同期のためのデータ構造を用意してくれる。先ほどの Chat の部分のデータプッシュ周りのみにしたシンプルなサービスである。

Proxy (beta)

Proxy は匿名コミュニケーションのプラットフォームだ。Airbnb や Uber を使ったことがある方なら経験がある通り、知らない相手とやりとりするために間に仮の番号を発行し、その番号を通して電話やメッセージをやりとりすることでプライバシーを守るための仕組みを提供してくれる。 Proxy を使えば、利用する番号を良い感じに調整してくれたり、相手と結びつけを行ったりすることを簡単にしてくれる。今後は プログラマブル Chat / Facebook Messenger といったチャネルでの匿名通話が可能になるとのこと。

Channels (beta)

存在するあらゆるチャンネル LINE/メール/Slack/Twitter/Facebook/Alexa を使って相手とメッセージの送受信が可能になるプラットフォーム。相手が LINE でこっちが Facebook といったコミュニケーションを可能にしてくれる。通常、こういうのを作るには全てのプラットフォームに対応した SDK を用意し、そのための実装が必要だったが、Channels によって決まったコードを書くだけであらゆるチャンネルに対応したコミュニケーション・ハブを構築できる。

Notify (beta)

Notify は通知をするためのプラットフォームだ。サービスで色々なチャネルを提供していると、ユーザーに通知を送りたいデバイスがどんどん増えてくる。iOS, Android, Facebook Messenger, SMS など。これらにおいて優先度(今開いているデバイスが優先度高)をつけ、反応しなかったら次の優先度のデバイスに通知するようなスマートな通知を提供することができる。

プログラマブル Wireless (beta)

電話機能付きの プログラム可能な SIM カードの提供。API を通じて SIM の操作が可能で、日本でもローミングを使って通信が可能。まだ SIM 自体が前回の Signal カンファレンスで配れた段階なので、まだ一般の手に普及するには時間がかかるが、音声通話付き SIM ということで Twilio Voice との連携などが可能になる。

Authy

2段階認証のためのプラットフォーム。Google Authenticator が有名かとは思うが、 Authy は電話/SMS/アプリといったチャネルでの2段階認証が可能で、今後はアプリのプッシュ通知で認証を通すといった手軽さを実現できる。アメリカでは Authy はかなりの人気アプリなんだけど、日本語化されていないせいか日本での普及は今ひとつといったところ。日本語化に期待したい

タスクルーター

電話/SMS/チャット/ビデオ通話 といったあらゆるチャネルのサポートを一元管理し、大量の問い合わせが来た時に最適な1つの問い合わせにオペレーターを紐づけるための仕組み。Twilio としては電話だけでなくあらゆるチャネルを提供しているため、タスクルーターを使ってどんなチャネルから問い合わせが来ても、スマートに顧客とのやりとりができるようにしたいと考えている(Contexual Communication: 文脈を把握した会話)。

Runtime (beta)

Twilio を利用するには、従来は何かしらプログラムを動かせるサーバーが必要だった。しかし Runtime の Functions を使えば実行可能なコードを Web 上で記述し、実行することができる。AWS でいう Lambda + API Gateway のような仕組みが Twilio で使えるという感じ。電話操作する何か作りたいんだけど、サーバー用意するまでもないといった場合には便利。また S3 のようなファイルストレージである Assets も提供しているため、頑張れば Runtime だけでそれなりのシステムを作ることができる。

終わりに

きっと多くの読者の方は今の Twilio はこんなにあったのか!と思ったことだろう。実際アメリカでは相当多くの開発者が Twilio を使って手間をかけずに高品質なサービスを作り上げている。車輪の再発明は終わりにしよう。もっとユーザーに価値を与えられる部分に力を入れていくために、Twilio は大きな力になってくれることだろう。

ベータ多すぎ?確かに多いけどそういうのをいち早く飛びついた方が、最初の素晴らしいサービスを提供できるのではないかな。

ところでそんな Twilio なんだけど、今月末に東京で割と大きめなイベントをやるからチェックしてみてね!

twiliomeetup.doorkeeper.jp