お客様からの問い合わせ対応を科学する
この記事はお客様との商談で挙がる技術的な問い合わせにどのように対応すべきかを体系的に整理することを試みた記事で、Mastering Technical SalesのChapter16/Managing Questionsを元に作成しています。
質問の仕分け
お客様は様々な理由で質問します。最も大切なことは、質問の背景と出どころを把握することです。最も簡単な方法はお客様に"何故そんなこと聞くんですか？”と質問することですが、この方法は直接的すぎてお客様に失礼です。質問をカテゴライズして整理しながら背景と出どころを探ることが現実的と思われます。
サービスの妥当性を確認する質問
サービス提供者のサービスの妥当性を確認する質問です。
Availabilityは99.95%とありますが、仮にSLAの違反があった場合御社側にどんなペナルティが発生しますか?
SoWに"Applicationの改修作業は御社の責任範囲外"と記載がありますが、詳細な内容をご説明下さい。
このタイプの質問が挙がるケースは、商談ステージを前に進めるチャンスと思われます。ミーティングでは可能な限り端的かつ断定的に回答して、ミーティング後にフォローアップとしてEメールで回答のサマリと補足のコンテンツ(参照先URL等)を送ることをお勧めします。
競合他社に関連した質問
サービス提供者にとっての競合他社に関する質問です。
xx社のサービスが発行したAccess Tokenを御社のAPI Gatewayで検証してバックエンドのResource Serverを保護することはできますか?
xx社の製品はOpen ID Connectで規程されているnonceパラメータに対応していないようなのですが、貴社のSolutionは対応していますか?
このタイプの質問は、お客様が既に競合他社の製品を優先的に検討していることをほのめかすサインです。サービス提供者は、お客様から見た複数ある選択肢の中で2番目以降にいる可能性が高いことを冷静に見極めて、1番目に躍り出るにはどうすべきかを考えるべきです。質問には可能な限り端的に回答して、質問に直接関係しない発言は控えることをお勧めします。お客様との関係性にもよりますが、お客様から可能な限りプロジェクトの状況をお教え頂くようお願いすることも大切です。"お客様は神様"ではないので、サービス提供者側は、お茶を濁すようなやり取りが続く場合はQuolified Out(捨て案件)して別のお客様から案件を発掘することも考慮すべきと考えます。
xx社とは数年来のお付き合いをしており、政治的な理由で採用は決定しています。ただし、御社のSolutionには魅力を感じているので、何とか共存できる方法を模索しています。
xx社のサービスは安価で直ぐに利用できることに魅力を感じているが、技術的な成熟度に不安を感じています。御社のSolutionをより詳しくご説明頂けないでしょうか?
超スーパーテクニカルな質問
ただ単に製品やサービスの詳細を知りたいだけで、ビジネス上の意図を持たない技術的に難易度の高い質問です。
御社がGitHubに公開しているJavaScript SDKのソースコードのxx行目〜xx行目に不可解な実装があるのですが、何故このような実装をしているのかご説明頂けますか?
御社のSolutionが提供しているAuthorization APIの認可エンドポイントの最大RPSを教えて下さい。できれば御社内で検証したベンチマーク結果を教えて頂きたいです。
このタイプの質問は、商談の意思決定に関与していない方から挙がるケースがほとんどです。質問には可能な限り端的に回答して、ミーティングで回答が困難な質問は、詳細を調査して後ほど回答させて欲しいと許可をもらうことをお勧めします。その際に、”何故その質問の回答が必要なのか?”を探ることが重要です。Softwareの実装方法や性能要件等、絶対的な正解が存在しないテーマの場合、調査はするが期待した回答ができるか約束できない旨お伝えして、会話のトピックを変えながら回答のヒントを探ることが現実的と思われます。
RFCxxxxで規程されているxxxxに則って実装していると思われます。念のためSDK作成部門に確認してみます。詳細確認にあたり、この件とプロジェクトの関係を可能な範囲でお教え頂けないでしょうか?仮にこの質問に対して満足なご回答ができない場合、プロジェクトにどんな影響を及ぼしますか?
Authorization APIの認可エンドポイントの最大RPSはxxでxxに公開しています。弊社内でのベンチマーク結果は非公開になっています。性能試験は検証環境や前提条件によって結果が大きくことなるため、仮に弊社内のベンチマーク結果をお教えしても、貴社のプロジェクトには参考にならないと考えます。だいたいで構わないので、今の認可リクエスト総数とユーザ数等の前提条件をお教え頂けますか?
敵対的な質問
サービス提供者対して敵意を持った質問です。何らかの理由で、お客様から明らかに敵意や悪意を持った質問があがるケースは多々あると思います。過去にサービス提供者プロジェクトを共にしたことがありそのプロジェクトが失敗した、サービス提供者の中の特定の個人が嫌い等、理由は様々かと思われます。
不快な表記を避けるため例は割愛させて頂きます。
このタイプの質問が挙がった場合は、先ずチーム内の他のメンバー(そのミーティングに同席している最も役職が高いメンバー、例/営業部長)とアイコンタクトをして、Qualified Outを選択肢に入れることが重要です。サービス提供者とって、現在対面しているお客様だけがお客様では無いと思います。深刻な課題を抱えていて、適切なSolutionの提案を求めているお客様は他にいます。明らかに理不尽な質問には対応せずに他に行くことも選択肢の一つです。ただし、敵意の理由は何なのかを探ることができて、理由がリーズナブルで解決できるものであればQuolified Outは時期尚早かもしれませんね。
一般的な質問
競合他社にも広く遍く当てはまる質問です。
うちの会社では、SaaSはセキュリティが心配なので導入する場合はSecurity Teamの原密なチェックが必要になります。御社のSolutionはセキュリティは大丈夫ですか?
価格が高すぎますね。月額xx円程度だと思ってましたよ。。。値引きってどれくらいまでいけますか?
このタイプの質問が挙がる場合は、お客様は提案に対してポジティブな印象を持っているものの、定量的な価値を計測することができないため先に進むことを躊躇してりることが考えられます。提案書には、計測可能な定量的な価値を明記して再度提案をご説明する場を設けることをお勧めします。定量的な価値を文字に起こすことは大変かもしれませんが、物事に100％は無いので前提条件つきでも構わないと思います。仮にお客様から"このロジックは成り立たないのでは。。。"と反応があったら、どんなロジックだと妥当かを一緒に考えましょうと前向きな会話に進めると思われます。
質問無し
お客様がサービス提供者のプレゼンテーションやデモンストレーションに対して興味を持っておらず、”ここまででご質問はありますか?”と問いかけても何も返ってこないケースです。
サービス提供者: ここまででご質問はありますか?
xx部担当者xx様: (携帯電話をみながら)特にないです。
xx部長xx様: 私も特にないです。ご説明頂きありがとうございました。(独り言で)xx社とは違うみたいですねぇ
残念ながらこのケースは競合他社に99%決まっている、またはDo Nothing(プロジェクト化しない)です。すみやかにQuolified Outして他のお客様に行くことをお勧めします。
問い合わせ対応のテクニック
傾聴
一番大切なことは良く聴くことです。お客様から挙がる質問の背景と出どころを深く理解しないまま、表面的に聞いたことにすぐに回答してしまい、会話が噛み合わなくてお客様にフラストレーションを感じさせてしまうことは最もありがちな失敗かと思います。ミーティングでは、発言中のお客様の顔色や様子を注意深く観察して、表面的に見聞きした情報の背景と出どころを確認することに努めます。
事前に調査した内容から、お伺いした内容はxxのことと推測しています。正しいですか?
xxとは具体的に何を指しますか?ご面倒をお掛けして恐縮ですが、正確に理解したいのでホワイトボードを使ってご説明頂けますか?
大切なことは、相手に傾聴している、理解したいと思っていると感じさせることです。人は誰でも、自分の話をしっかり聴いていない、軽く聞き流されていると感じると疎外感を感じると思います。お客様に疎外感を感じさせてしまっては、課題の把握やSolutionの提案以前に、人として信頼されずに商談は確実に破談になります。たとえお客様の発言内容が断片的で支離滅裂だったとしても、傾聴の態度を示しながら理解に務めることが重要です。ただし、あまりしつこく確認するとお客様に”この人は専門的な知識が乏しいのかな?”と思われるので、自分の理解を示す際はテクニックが必要です。ミーティングに参加している他のメンバーにも発言を促しながら、チームとしての理解を示すとお客様の安心感も高まると思われます。
割振
問い合わせ内容の背景と出どころを確認できたら、問い合わせの内容に応じて適切な回答担当者を割り振ります。お客様とのミーティングには、サービス提供者から複数名のメンバーが出席している場合は、その場で目で合図、または会話しながら誰が担当するを明確にすると曖昧さが残らずスムーズに次のステップに進むことができると思います。技術を担当するメンバーだけに負荷が集中しないように、チームとして問い合わせに対応できるように務めます。技術を担当するメンバーも、一人で抱えずに積極的に他のメンバーの支援をあおぐことが大切です。
浄化
回答担当者の割り振りができたら、再度、問い合わせの内容に戻り詳細を掘り下げます。
Monolithic型のSoftwareアーキテクチャからMicroservice型のSoftwareアーキテクチャに脱却して、APIやResource Serverのセキュリティを担保しながら現在の低速なリリースサイクルを高速化することがプロジェクトの目的と理解しました。この課題を解決するためにこれまでに取り組まれた施策を教えて頂けないでしょうか?
MonolithicからMicroserviceにシフトすることで、従来型のやり方を変えることに反対する方も出てくるのではと懸念しています。その点についてはどのようにお考えですか?
問い合わせの背景と出どころの確認と同時に、その課題を放置した場合のビジネス上のインパクトをお客様と共有することが重要です。ビジネス上のインパクトをお客様と共有することで、お客様社内の凛儀プロセス終盤で最終意思決定者から、”このプロジェクトは今すぐやらなくても良いね”という類の発言が出てしまいプロジェクトストップになる危険性を回避できます。課題に対する過去の取組や抵抗勢力が出てきた場合の対処方法等、様々なケースを想定した質問をしながら、問い合わせを確実に管理できるレベルまで掘り下げます。
回答
可能な限り端的かつ断定的に回答します。もし、回答が複雑になる場合、初めに"はい/いいえ、xxです。"のようなAnswer Firstなスタイルで回答します。回答で最もさけるべきは質問に答えていないことです。はい/いいえで聞かれたときははい/いいえで、オープン質問であれば端的にxxです、と先に回答して後から背景や理由を付け加えます。
おわりに
お客様の置かれた状況は業種や規模によって様々で、ありとあらゆるカテゴリの質問が上がってくることは日常茶飯事かと思います。特にCustomer IdentityやZero Trustのような、日本であまり馴染みのないテーマの商談では"この人何を探しているのかなぁ?"と思う支離滅裂な質問もあるかと思います。質問の背景と出どころを理解しながら的確な回答を続けることが、信頼されるパートナーとして認められる近道かと思います。また、問い合わせの対応状況はGoogle Spread Sheetやmonday.comのようなツールを用いて、一覧化してお客様といつでも共有できるようにすることをお勧めします。プロジェクトのどのフェーズでも一覧を確認することで、戻りやミスコミュニケーションを避けることができます。