技術と魚

技術調査、開発Tips、及びしょうもない文章

Webサーバー指向営業のススメ

「プロダクトの説明ができる人がお前しかいない!」とCEOに言われ、イベントの商談ブースに駆り出されたスタートアップのCTOこと私です。 さあ困った困った、私の脳に営業というアプリはインスコされておりません。

しかしエンジニア脳に特化してしまった以上、もはやシステム思考を切り離すことは不可能。よし、ならば、それを駆使しようではないか

というわけで自身を営業サーバーであると考えました。そうすれば、普段どおり設計・実装・起動が可能です。すると、営業というのは極めてWebサーバーに近いシステムであると分かりました。

f:id:norainu234:20190131231033p:plain

目次

コネクションの確立 (名刺交換とアイスブレイク)

日本では、通信確立のための標準的なプロセスとして名刺交換が採用されています。交換のメソッドを押さえるだけで、初期のコネクションの確立が十分に可能です。この段階で通信に必要となる最低限の情報(会社名・部署・氏名等)が交換できるという点では、日本の商談プロセスというのはデファクトの標準のもとである種の効率を生み出していると言えます。なるほど、そう考えると、名刺交換とは悪くない文化なのかもしれません。言ってしまえばRFCみたいなものというわけですね。

アイスブレイクも、追加的な情報交換のために有用です。この実装は OPTIONAL です。無くても機能しますが、相手によっては効果的な通信を行える可能性があるため、 RECOMMENDED な仕様であるということです。

人間は機械と異なり情報の信用度が0%~100%の間になり得ます。もし、最初の挨拶で「関西弁かな?」と思っても、「この人は関西ノリが通用する」と断定するためには追加の情報が必要である可能性があります。そのような場合に自分の情報の信用度を上げるためにICEBREAKメソッドを通じて情報を交換する仕組みを利用できます

Acceptヘッダを正しく読む (属性で話し方を合わせる)

例えば、自分がややオタク寄りのプロトコルには精通しているので、もし相手もそうした傾向がある場合、"ノリを合わせる"というメソッドが利用できます。そうすることで、無駄のない情報交換が利用できる可能性があります。

つまり、適切にAcceptヘッダ(相手が受け入れてくれる表現方法)に応じて切り替えることで、固有の表現を使い情報を圧縮したり複雑な表現をしたりできます。

ただし、基本的にtext/plainで返せる、つまり、標準の日本語で伝えられる状態にしておくことは、常に適切な通信を行えるサーバになる上では MUST の仕様です。明確でわかりやすい日本語こそが重要であるということです。

要求リソースだけを返すRESTful営業はダメ

Webサービス上で、「Dataを見る」をクリックしたとして、ただ単に「リソース(Data)が見つかりましたor見つかりませんでした」を返すだけでは、「で、どうすればええねん」となってユーザが離脱してしまうように、営業も、言葉通りにお客さんの質問に最低限答えているだけでは「じゃ、ありがとうございました」と言って帰ってしまいます。要するに、営業はRESTful APIではありません。

ユーザ(顧客)が本当に求めているものを理解して、+aでヒントや選択肢を返してあげる必要があります。 おお、これは、我々が普段Webサービスで苦労していることそのものではありませんか。

ログの取得 (温度感を知る)

得に顧客に刺さるポイントが知りたいような初期フェーズのサービスでは、「どういうポイントで好感をもったか」を知りたいものです。このログを見ながらビジネスのパフォーマンスをチューニングするわけなので極めて重要です。喋りながら、「この発言に対して、こんな反応でした」というログを取得して永続的なデータストアに取り込まなければなりません。

これを正しく機能させ続けるのは一日に多くのお客さんに対応していると本当に大変な作業なので、セールスな人たちに依頼する際は、リスペクトを持ちましょう。マジで。

パフォーマンス is King (素早く簡潔に応答)

「う〜〜〜ん」と時間をかけて考える営業ほどダサいものはありません。遅いWebサービスと同じくダサいです。速度はできるだけ追求しましょう。

非同期処理の活用 (「後ほど」フレーズ)

それでもすぐに対応できないようなタスクをシュッと要求してくるお客さんは多いものです。その際には非同期処理が有効です。「後ほどメールでお送りします!」等のメソッドをうまく利用しましょう。

UI/UX (喋り方の一貫性、話し声、方言)

急にテンションが上ってきてタメ語っぽくなってしまったり、声がでかくなったり小さくなったりしたら、そこが気になってしまいますよね。なので、そこは安定させる必要があります。どうでもいいことでもお客さんの脳リソースを無駄に使わせてしまうのはデザインとして良くありません。Webサービスに自然にオンボーディングできるのが重要なのと同様に、自然に会話に溶け込める一貫性は重要な要素であることは間違いなしです

旧ブラウザ対応 (単語の説明)

もしかすると、お父さん世代が訪れることも有り得ます。そのような場合に備え、polyfillをしっかり適用しましょう。ナウい横文字ビジネス語が非対応であることは十分に考えられます。


いかがでしたでしょうか。サーバーのように考えて営業を実装することで、突然商談担当を任命されても、いつも面している馴染み深い問題との同一視で対応ができるのです。

あと、僕は一日で5件x25分の商談をやったらメモリリークやプロセスのハングアップにより脳がWindows95のように遅くなってしまったので、帰って寝て再起動しました。やはり得意な人に任せるべきです。

ちなみに、弊社はエンジニアを営業に強制的に行かせたりはしませんのでご安心ください😉