上手い人は何を見ているのか　－エクスパンションの属人技を分解する－

過去に関わった自由診療クリニックで、施術の成約率が目立って高いカウンセラーがいた。

同じメニューを案内している。
同じ価格を提示している。
同じ院内で、同じようにカウンセリングをしている。

それなのに、その人が担当すると成約率が明らかに高かった。

単に押しが強いわけではない。
むしろ、無理に売り込んでいる印象は薄かった。

もちろん、成約率の高さには経験や説明力、顧客との相性など、さまざまな要素があったはずだ。

ただ、横で見ていて特に印象に残ったのは、その人が「売るべき施術」ではなく、相手の迷い方を見ているように感じられたことだった。

何に不安を感じているのか。
何をまだ言葉にできていないのか。
どこまで納得していて、どこから先で止まっているのか。
今、背中を押すべきなのか。
それとも、まだ判断材料を渡す段階なのか。

そういうものを、会話の中で自然に拾っていた。

一方で、これまで複数のSaaSサービスを使ってきた経験の中でも、機能提案が上手いと感じる担当者に出会ったことがある。

こちらも似ていた。

単に新機能を紹介するのではない。
「この機能、便利ですよ」と押してくるのでもない。

こちらの運用を聞きながら、

「それ、今はどうやって回していますか」
「その作業、毎回発生していますか」
「他の担当者でも同じように対応できますか」
「そこが自動化できると、何が一番楽になりますか」

というように、今の運用の限界を探ってくる。

そのうえで、こちらがまだ気づいていなかった困りごとと、追加機能の価値を接続してくる。

このとき、提案は売り込みではなくなる。

「ああ、たしかにそこは困っていた」
「それなら検討する意味があるかもしれない」

そう思える形になる。

もちろん、医療のカウンセリングとSaaSのエクスパンションは同じものではない。
扱う商材も、意思決定の構造も、責任の重さも違う。

ただ、共通しているように見えたことがある。

少なくとも、自分が見てきた上手い人には共通点があった。

上手い人は、結果だけを見ていない。
「買うか、買わないか」だけを見ていない。

その前にある、迷いの兆候を見ている。

この記事では、SaaSのCSや営業の専門家としてではなく、複数の現場で「提案がうまい人」を観察してきた立場から、エクスパンションの属人技を少し分解してみたい。

ここでいうエクスパンションとは、既存顧客に対して追加機能や上位プランを提案し、提供できる価値を広げていく活動のことだ。

上手い人は、困りごとの兆候を見ている

顧客は、いつも明確に困っているわけではない。

「この機能が欲しいです」
「この課題を解決したいです」
「追加費用を払ってでも導入したいです」

そんなふうに言語化されていれば、提案はしやすい。

だが、現場では多くの場合、困りごとはまだ言葉になっていない。

代わりに現れるのは、もっと曖昧なサインだ。

毎回、同じところで確認が増える。
本来とは違う使い方で運用している。
Excelや手作業で補っている。
特定の担当者だけが対応できる。
設定変更や例外対応で何とか回している。
「今はこれで大丈夫です」と言いながら、実はかなり無理をしている。

こうした状態は、表面上は大きな問題に見えない。

業務は止まっていない。
クレームにもなっていない。
明確な要望にもなっていない。

だから見過ごされやすい。

しかし、上手い人はここを見ている。

「これは単なる運用のクセなのか」
「それとも、既存運用の限界が出ているのか」

その違和感を拾っている。

既存運用の限界を拾っている

追加機能の提案は、機能説明から入ると届きにくい。

使う側にとって必要なのは、「何ができるか」だけではなく、「今の運用を変える理由があるか」だからだ。

新しい機能が自分たちの業務にどれくらい効くのかは、使う側にとっても最初から正確に測るのが難しい。

むしろ使う側が見ているのは、

「今の運用を変えるほどの理由があるのか」
「導入する手間に見合うのか」
「現場に説明できるのか」
「本当に今やるべきなのか」

という判断だ。

だから、上手い人は機能そのものより先に、既存運用の限界を見る。

今のやり方で、どこまで回っているのか。
どこから無理が出ているのか。
どこに人の頑張りが埋まっているのか。
どこにミスや属人化のリスクが出ているのか。

そのうえで、追加機能を「新しいもの」としてではなく、「今の限界を超えるための選択肢」として接続している。

ここが大きい。

ただの機能紹介ではなく、現場の文脈に接続されている。

上手い人は、次に何を回収すべきかを見ている

さらに上手い人は、その場で提案するだけではない。

次に何を確認すべきかを見ている。

たとえば、

その運用は誰がやっているのか。
どれくらいの頻度で発生しているのか。
手作業でどれくらい時間がかかっているのか。
ミスが起きると何に影響するのか。
その業務は今後増えるのか。
他部署でも同じような運用をしていないか。
もし自動化できたら、何が変わるのか。

こうした情報を、会話の中で自然に集めている。

本人は「条件回収をしている」と意識していないかもしれない。

だが実際には、提案に必要な判断材料を少しずつ集めている。

その結果、提案のタイミングや説明の切り口が合いやすくなる。

顧客の納得材料が揃ってくるからだ。

属人技に見えるものの正体

この動きは、外から見ると属人技に見える。

「あの人は顧客理解が深い」
「あの人は提案がうまい」
「あの人は勘がいい」

もちろん、それは事実だと思う。

ただし、そのままにしておくと再現しない。

上手い人の頭の中で起きていることが、外に出てこないからだ。

何を見ているのか。
どこで違和感を持っているのか。
何を確認しているのか。
どの条件が揃うと提案に進むのか。
逆に、どの条件が足りないとまだ提案しないのか。

ここが外部化されないと、組織として学習しづらい。

結果として、追加機能の提案は「できる人だけができる仕事」になりやすい。

属人技を否定するのではなく、分解する

ここで大事なのは、属人技を否定しないことだ。

上手い人の感覚は、現場経験の蓄積から生まれている。
顧客との会話の中で磨かれてきたものだ。
簡単にマニュアル化できるものではない。

だからこそ、雑に標準化すると失敗する。

「この条件ならこの機能を提案しましょう」
「この課題にはこのプランを案内しましょう」

という単純な対応表にしてしまうと、現場の文脈が抜け落ちる。

顧客の迷いは、そんなに単純ではない。

必要なのは、上手い人の判断を奪うことではない。

上手い人が無意識に見ているものを、少しずつ言語化することだ。

エクスパンションは、買わせる技術ではない

エクスパンションは、買わせる技術ではない。

本来見るべきなのは、顧客の困りごとがどこに生まれているかだ。

まだ言葉になっていない困りごと。
現場が力業で吸収している負荷。
既存運用ではそろそろ限界が出そうな箇所。
追加機能によって、初めて意味を持つ改善余地。

そこに追加機能の意味が接続されたとき、提案は押し売りではなくなる。

自由診療クリニックのカウンセラーも、SaaSの機能提案が上手い担当者も、見ていたのはおそらくここだったのだと思う。

相手を説得する前に、相手がどこで迷っているのかを見ている。
提案する前に、判断に必要な材料が足りているかを見ている。
売る前に、今それを検討する理由があるのかを見ている。

この順番があるから、提案が自然に届く。

上手い人の勘を、条件回収の型にする

上手い人の勘は、貴重な資産だ。

だが、勘のままでは共有できない。

担当者が変わると失われる。
チームが変わると途切れる。
新人には伝わらない。
仕組みにも残らない。
当然、AIに学習させることも難しい。

だから必要なのは、勘を否定することではなく、その中身を少しずつ取り出すことだ。

どんな兆候があったのか。
どんな会話があったのか。
どんな運用の限界が見えたのか。
どの条件が揃ったから提案に進めたのか。
逆に、どの条件が足りなかったから提案しなかったのか。

そこを取り出していくと、エクスパンションは個人のセンスだけに依存しなくなる。

少なくとも、見るべき兆候や次に回収すべき条件を、チームで共有しやすくなる。

誰が見ても同じ提案ができる、という意味ではない。

顧客の迷いを検知し、判断材料を集め、提案の間合いを整える活動として見えてくる、ということだ。

次に考えたいこと

では、この属人技をどうすれば外部化できるのか。

単にチェックリストにすればよいのか。
提案トークを標準化すればよいのか。
CRMに入力項目を増やせばよいのか。

おそらく、それだけでは足りない。

必要なのは、顧客の困りごとを見つけるための条件を、現場が自然に回収できる仕組みだ。

そしてそれは、少し視点を変えると「ゲーム」に近い。

提案することをゴールにするのではなく、
提案に必要な条件を回収していくゲームとして設計する。

エクスパンションを、売り込みではなく、条件回収のプロセスとして捉え直す。

次回は、その話を考えてみたい。

次回予告：
エクスパンションを“条件回収ゲーム”として設計する

このマガジンは、現実世界の構造や変化に気づくのが遅れがちな自分自身を戒めるために書いている、思考整理のログです。

記事内の内容は、筆者自身の経験や観察をもとにした個人的な考察であり、特定の企業・業界・職種・個人を批判・断定するものではありません。

ここで用いている言葉や構造化は、現場で起きている複雑な事象を捉え直すための仮説です。正解ではなく、読者自身の現場や経験を見直すための視点としてお読みください。