見出し画像

Softwareのデモは失敗して当たり前!

先日とあるお客様向けにSoftwareのデモを実施して見事に失敗?しました。

これで何回目でしょうか。。。どこに原因があったのか振り返りたいと思います。


お客様様とは2回目のミーティングで、1回目のミーティングでプロジェクトの背景と課題、ある程度の要件はヒアリングできていました。

その内容に沿ってデモのシナリオを準備して臨みました。

Google Slide1枚でデモのシナリオを記載していざGhromeで表示しているSoftwareのPortal画面を見せるや否や、"Portal画面にLoginするところから見せて下さい"とリクエスト頂きました。

Loginするところから見せるシナリオは想定していなかったので練習していませんでした。この時点でパニック、思考停止です。


SaaS全盛の昨今、ありとあらゆるジャンルのSoftwareが毎日どこかで誰かに開発されて世に送り出されています。

どんなSoftwareのデモにも共通している目的はお客様の課題を解決できることを証明することだと思っています。

1回目のミーティングで頂いていた質問の内容から、"お客様はxx業者だからこんな課題があるんだろうな"と、ある程度は課題を想定できたので、その想定のもとにデモのシナリオを作成しました。

声出しの事前リハーサルは2回ほどやりました。トークとアクションも頭の中に完璧に叩き込んで準備万端です。


唯一の心配事は、デモのプラットフォームに慣れていないことでした。

初めて使うものだったので、どこにどんなバグが潜んでいるのか完全には洗い出せていませんでした。事前に検証はしていましたが。。。

ここにお客様が期待していることと、自分が理解していることのギャップがあったようです。

潜在的なバグが無いSoftwareは世の中に存在しないので、これはどうしようも無いことかもしれませんが。


事前に準備したシナリオ通りの進行を妨げられる質問の雨あられで、その場で受けた質問に、その場でアクションを準備して見せるという内容のセッションでした。時間約1.5時間。

私の頭の中は、クラッシュ(動かないアクション)を見せないようにしようと必死で、触ったことの無いボタンを触らないで質問に答えるには?でグルグルでした。


今回得た教訓です。上の3つはこれまでも意識していたので、今回も問題無くできていたと感じています。

・お客様の課題に沿ったデモシナリオを事前に準備する

・課題に直接関係のあるアクションだけを見せる、機能を全部見せない

・お客様に質問を投げかけてデモが意味を成しているか確認する

・お客様の期待レベルを正確に把握する

・前提条件をつけてその場をコントロールする


人の欲求に際限は無いので、"あれも見たい、これも見たい、全部見たい"といった期待を抱くかもしれません。

お客様も人ですので、課題を解決してくれるSoftwareかどうかを見極めるためにも、"Loginするところから見せて下さい、次はTenantを作成してみて下さい、このButtonを押したらどうなりますか?"と貪欲になるかと思います。

Upfront Contract(=前提条件)をつけてその場をコントロールする - これが大切です。

デモ実施前に目的とシナリオと深さに関して合意しておいて、Upfront Contractと逸脱するテーマは別の場で協議するべきですね。

いいなと思ったら応援しよう!