見出し画像

2打席目で放つ「Arch(アーチ)」

こんにちは、HiCustomer鈴木です。本日6月1日、巻き起こる艱難辛苦を乗り越え、ようやく新プロダクトArch(アーチ)を無事正式リリースできたこと、大変感慨深い気持ちで迎えております。

Archは僕たちの4年に渡るカスタマーサクセスの経験と失敗から生まれたプロダクトであり、自らのカテゴリを「コラボレーション・サクセス・プラットフォーム」と銘打っております。この珍妙なカタカナの背景、そしてどんなことを実現したいかを少し説明させてください。(3,700文字)

「カスタマーサクセス」の現実

カスタマーサクセスとは一体何でしょうか。
顧客を満足させること?能動的なサポート?解約を阻止すること?LTVを最大化すること?左記を目的とした製販一体の業務プロセス?仕事における喜び?従業員の行動規範?それとも経営理念?

使われる場面や人によって解釈の振れ幅が大きなキーワードですが、カスタマーサクセスという言葉の意味を2つに分けてみると、自社視点/顧客視点の違い、つまり「収益最大化の取り組み」「顧客の期待を現実化する取り組み」の間に1本線を引くことができそうです。

自分たちの顧客全てが契約前に抱いていた期待を果たせている、ないしはそうなるに違いないという思い込みで「収益最大化の取り組み」のみにリソースを投入しても、かなりの確率で狙った結果を出すことはできません。
なぜならば、既に、しかもかなり早いタイミングで顧客はあなたのプロダクトに失望しているかもしれないからです。

移動中、顧客が何気なくタクシーCMを見る。「簡単導入・大きな成果」を謳うプロダクトに興味を持ち問い合わせ、営業から提案を受け、他製品との比較検討を終える。ROI計算を添えた稟議書を出し、無事承認。
さぁいよいよだと高まった意気込み・期待は、オンボーディングの期間中に現実と向き合います。思っていたのと違う、セットアップがこんなにも大変、現場社員が全然使ってくれない、いつになったらROIが出る見通しが立つのか。ーー現場のひそひそ話が耳に入る。「ぶっちゃけエクセルでよくない?」「誰が導入決めたんだっけ?」
しばらく経ち利用が芳しくないことを察知したベンダーから支援申し出の連絡が来て気まずい。…そうだ、自分たちには早すぎたのだ。「すみません今バタバタしてまして」とその申し出を断り、そっと解約を心に決める。

書籍Onboarding Mattersによると、解約原因のうち約25%がオンボーディング体験によるものと言われています。解約までとは行かずも、使いこなせず潜在的にアップセル可能性が消失している顧客を合わせるとどの程度になるでしょうか。体験が悪いということは現行のオンボーディングプロセスが多くの場合、実は間違っている可能性を示唆しています。にもかかわらずコスト削減の圧力により、もしくは他社もやっているからと、本当は間違っているプロセスをそのまま自動化する。当初は工数が減った(ように見える)。しかし、次第に理解の甘い顧客から問い合わせの件数が増え、主要機能の利用率は高まらず、契約更新時に掛かる提案労力が増え、解約の件数を確認しヒヤリとする。こんな経験ありませんか?

「オンボーディング」の現実

オンボーディングの大筋はベンダーが顧客とプロダクト導入の目的やゴール、スケジュールを握り、コミュニケーションとコンテンツを駆使し自社の定めたオンボーディング完了条件達成まで顧客を支援する工程を指します。そして、オンボーディングにはその成功を阻む「摩擦」が随所に設置されています。

そもそも、顧客(決裁者/導入責任者/現場のエンドユーザー)は本業で忙殺されています。その隙間を縫ってオンボーディングに参加しているためモチベーションはまちまち。実は今のやり慣れた業務を変えたくないメンバーもいるかもしれません。上が勝手に導入を決めてきたプロダクトの導入を任されるケースもあるでしょう。

その状態で売り手の担当から五月雨で届くメールには数多くの添付資料、状況確認&フォローアップの連絡の数々、その上初めてのツールで分からないことだらけ。本業がさらに多忙になると面倒なオンボーディング作業は後回しになり、時間が経つにつれて熱量が下がり、なんとかセットアップを終えて一息。すると今度はなぜか現場が使ってくれない、成果が出ない。このようにズルズルと予定が遅延し、そして失敗に至ります。

オンボーディングは組織をまたぐプロジェクト

オンボーディングは期間とゴールが明確な短中期のプロジェクトです。しかも、売り手と買い手が同じゴールを追いかける両社協働のプロジェクトなのです。本来、プロジェクトを上手く進めるためには関係者間で情報の透明性を担保し、適切なピアプレッシャーを掛け合うことで物事を前に進めていきます。

しかし、SaaSのオンボーディングの場合、「売り手 - 買い手」と「決めた人 - 使う人たち」で組織が分かれているがゆえに、情報が分断し、Whyを含むコンテキストが失われ、認知コストが高まる構造的な問題を抱えています。売り手のオンボーディング担当は一人で同時並行の案件を多数持つ宿命にあるため、過度な関与を嫌い、買い手側組織内のプロジェクト管理を導入責任者に委ねることになります。当然、今回選ばれた導入責任者がプロジェクト管理のエキスパートであるというケースは稀であるため、設置された「摩擦」に絡め取られていくことになります。

そこでArchの出番

Archはインスタントな顧客専用ページを作ることができるプロダクトです。ページ内にプロジェクト管理に必要なブロックを配置し、関係者の情報伝達を滑らかにすることで、カスタマーサクセスのプロセスをロータッチ化させ、時にはハイタッチ以上の成果を引き出します。
Archの活用で売り手の負荷を軽くし、買い手のプロジェクト管理コストを引き受け、早期の成功体験創出に寄与します。CRMとの連携でカスタマーサクセス期に取得・生成したデータを他部門で再利用し顧客体験向上の施策に活用できるようにもなる予定です。

Archを通じて狙う短期的な定量成果はオンボーディング期間の短縮と成功率を上げること。スピードは正義であり売り手 - 買い手双方に経済合理性をもたらすと信じています。というか顧客には導入前の紙・エクセル含むツールと多くの代替手段が選択可能なので、1日でも早く成功体験を踏んでもらわないと離脱のリスクが逓増します。

SaaStrの創始者Jason Lemkinの書籍”From Impossible To Inevitable”にも「最初の90日で上手く使いこなせるようになってもらうと、そうならなかった場合と比べて、その後の利用頻度が3倍高くなった。」とあり、期間によって利用頻度が高まるのであれば、解約も減りエクスパンションの可能性も高くなるはず。つまり、オンボーディングの質はNRRと相関する仮説が立つので、このあたりを証明していきながら経営陣にとっても自社で使わない理由のないプロダクトに近づけていきたいと考えています。

Archのプロダクトビジョン

売り手と買い手の成果をエフォートレスに。

売り手の立場で見た「売る、売ったあと成果をあげてもらう」すら、ともすると難しいことなのですが、買い手の立場で「自分たちに合ったものを正しく買う、買ったあと期待していた成果を引き出す」って冷静に考えるとすごく難しいことだなと感じます。

本来は、作り手の製品/サービスに払った対価以上の手にした生産性をもとに、買い手が付加価値を乗せた新たな製品/サービスを提供していく連鎖により経済が成長していくと信じているのですが、どうもそうなれてないケースを散見しています。人口減社会の日本において、企業の成長と豊かな生活を維持するには生産性を高めることは必須条件なのに、その手段であるデジタル活用が上手く行かないのはなかなかに厳しい。僕たちが育てるArchを通じて売り手 - 買い手双方の成果に貢献しつつ、少しでも社会の前進に貢献できればと考えています。この国が好きなので。

無償トライアルもあるのでお気軽にお申込みください🙌


Q&A

Q. 他のプロダクトとの違いを教えて下さい。
A. プロダクトビジョンです。SaaSはビジョンに向かって成長する生き物みたいなものなので、ビジョンが異なれば狙う成果、それを担う機能は必然的に差が開いていきます。その時点のスナップショットだけでなくベクトルも踏まえ選定をおすすめします。

Q. もしかして営業フェーズでも使えますか?
A. はい、使えます。プリセールスはオンボーディングのそれと極めて似た性質を持つ「両社協働のプロジェクト」です。そして本来的にカスタマーサクセスは購買体験から始まっています。当社においても営業フェーズからArchを使っていますが、一人で持てる案件数がかなり増えます。

Q. 働くことに興味があります。
A. ありがとうございます🙇‍♂️ 直近ではプロダクトマネージャー, UXデザイナー, エンジニアを必死に探しておりご興味あればぜひこちらをご覧ください。カジュアル面談も大歓迎です。

この記事が気に入ったらサポートをしてみませんか?