建築とホテル、リアルとデジタルが交わるプロダクト開発。
こんにちは、NOT A HOTEL の井上雅意です。「世界中に自宅がある、あたらしい暮らし」をつくるスタートアップでCXO をしています。前回のnote ではNOT A HOTEL のサービス設計についてお伝えしました。
今回は建築・ホテルオペレーション・ソフトウェアというリアルとデジタルが共存するプロダクトを、どのように開発しているかご紹介します。
NOT A HOTEL を取り巻く変数
NOT A HOTEL は自宅・別荘・ホテルになる「あたらしい暮らし」をつくっています。この暮らしの体験を設計するには「暮らす人」「土地や建築」「ソフトウェア」といった要素を考慮する必要があります。それぞれに自由度を持たせるほど変数は掛け算方式で増えていき、それらの変数を許容できる柔軟性のあるサービス設計が求められます。
滞在をサポートするチャット機能
柔軟性のある体験を実現するために考慮していることを、チャット機能の開発事例を通してご紹介します。
チャット機能は滞在時の問い合わせ窓口で、お客さま向けアプリの一機能です。セントラルなカスタマーサクセスと各拠点にいるスタッフが連携しお客さまをサポートします。予約の変更・キャンセルから、ハウス設備の使い方、さらには「夜食に焼きそばが食べたくなった」など様々な暮らしのお困りごとを解決します。
このチャット機能ではお客さまからの問い合わせがあった際、一次対応をカスタマーサクセススタッフ＋AI チャットボットが行います。そして必要に応じて、お客さまが滞在されている拠点のホテル・サービススタッフと連携して二次以降対応を行います。
現地にスタッフがいるのであれば、一次対応から滞在先の現地スタッフが行った方がいいのでは？というご意見もあると思います。この方法を選んだ理由は、二つの柔軟性を持たせるためです。
ひとつはお客さまの滞在体験をより柔軟にするためです。NOT A HOTEL のサービス運営は豪華で至れり尽くせりの滞在体験というよりも、気の向くままに滞在でき困った時にはすぐ解決してもらえる、ちょうどいい距離感を目指しています。そのため従来の電話やフロントでのコミュニケーションよりも、スマートフォンやタブレットでシーンを選ばず非同期で問い合わせられる体験の方が適していると考えました。
もうひとつは高品質なサービスを、スピード感を持って展開するための柔軟性です。NOT A HOTEL は3年間で全国に拠点を30箇所まで増やすことを目指しています。その度に現地でスタッフを増員し、僕たちが求める水準のサービスを提供していくことは採用もオペレーションも費用も難易度が高いです。そこで一次対応をカスタマーサクセスに集約した仕組みにすることで、いつくかのボトルネックが解消されスピード感と品質を保って展開できると考えました。
柔軟な体験を持続的に提供するためには、さまざまな変数を考慮したプロダクト設計が必要です。ここからはチャット開発の例を通して、NOT A HOTEL を取り巻く3つの変数をご紹介します。
変数1: 建物の構造
NOT A HOTEL は風土に合わせてコンセプトやデザイン、使う材質、建築の構造などを企画しています。そうしたオリジナリティの高い建築を実現しつつも「どのNOT A HOTEL でも自宅のように（＝同じ操作性で）過ごせる」という暮らしやすさにこだわっています。
そのためすべてのNOT A HOTELはIoT化されており、スマートホームコントローラーと呼ばれるタブレット端末で電気・室温・音楽など（サウナの温度までも！）を操作することが可能です。
その上でハウス設備ごとの特性として、お客さまから「〇〇はどこに収納されているか？」「〇〇の使い方がわからない」といった問い合わせがチャットに寄せられると想定します。もし全ての建築が同じ構造であれば返答は1パターンのため、AI チャットボットでの自動対応などで充分となります。
しかしNOT A HOTEL のように建築の構造が異なる場合、お客さまが滞在している建築の情報を考慮しなければ問い合わせに答えることができません。この場合はAI チャットボットでの自動応答以外に、カスタマーサクセスによる個別対応や、拠点ごとにガイドを作成するなど検討案が増えます。
このように建築に変数が存在すると、カスタマーサクセスのオペレーションや開発するプロダクトにも影響が及びます。そういったケースが多く存在し、都度最適解を導くことが求められます。
変数2: ホテルオペレーション
ホテルオペレーションとは、NOT A HOTEL 滞在期間中のサービス提供を指します。このホテルオペレーションは現場のサービス運営方針によって、在り方が大きく変わります。
一例としてNOT A HOTEL では、チェックイン・チェックアウトを無人で実施します。対応可能な時間帯になると、お客さまのスマートフォンアプリに鍵をお送りします。
この時に考えられる一番シンプルな仕組みは、チェックインとチェックアウトの時間をトリガーにしてオペレーションを組むことです。チェックインは15:00以降、チェックアウトは10:00までと決めてしまえば、例外が発生しないため必要なプロダクトもシンプルになります。
しかしお客さまにとっての最適な体験は「清掃がすでに終わっていればチェックイン時間を早められる」「次の予約がなければチェックアウトを延長できる」といった柔軟なサービスのはずです。
サービスとして実現したいことを決めたら「どうしたらプロダクトはチェックイン可能時間を把握できるか？」といった仕組みに落とし込むための検討項目が加わります。具体的には下記のようなことを調査し、清掃完了をトリガーにした柔軟なチェックイン・チェックアウトのパターンを自動化することができます。
具体的な検討項目の例：
スタッフは清掃プロセスをどの時間帯にどのように行っているのか
清掃の完了をプロダクトが把握するには何をトリガーにするのが適切か
スタッフが清掃の完了報告（＝チェックイン可能の判断）をするなら、清掃プロセスのどこに組み込めば抜け漏れなく実施できるか
ここまでパターンを想定したとしても「チェックイン可能時間より早く到着してしまったが、今から荷物を預かってもらえるか？」「渋滞発生で到着が遅れるため、夕食の時間を変更したい」といった急遽のリクエストもあるかもしれません。こういったパターン化が難しい問い合わせ内容は、カスタマーサクセスやサービススタッフがチャット対応する方針としています。
このようなオペレーションありきのプロダクト開発では、開発者と現場のサービススタッフが、目線を合わせる必要があります。どちらも「お客さまにいい体験を提供する」というゴールは同じなのですが、サービス提供とプロダクト開発という異なる視点を持っています。
両者でサービス運営をどのように行うか、実現するためのプロダクトはどうあるべきかを落とし込んでいます。
変数3: お客さまが滞在に求めること
NOT A HOTEL はその時のニーズに合わせて、自由な使い方ができます。たとえば一度に一泊〜数泊の短期間でご利用される方がいれば、数週間や数ヶ月に及ぶ長期のご利用をされる方もいらっしゃいます。
この時の変数は短期・長期の利用で、それぞれお客さまが求めるサービスが異なるという点です。
例えば旅行など特別な日に短期間でお越しいただく場合は、食事やアクティビティなど事前に計画をしたいことが多いと思います。この際は項目をメニュー化することが可能なため、AI チャットボットから自動で選択肢を提案し予約や変更・キャンセルできる方がお客さまにとって利便性が高いです。
一方で日常の暮らしに近い長期滞在をされる際は、AIチャットボットで事前に食事の有無などを逐一決めることはストレスになってしまうでしょう。その代わり、より細かなご要望や相談など、自動対応が難しい問い合わせ内容が増えると想定されます。カスタマーサクセスにはコンシェルジュに近い、中長期的な関係構築が求められます。
そのため問い合わせ内容が滞在期間や用途で異なることを想定し、チャットルームは滞在ごとにつくる設計にしました。
柔軟さと制約の基準
建築・オペレーション・ユーザー体験などそれぞれに自由度を持たせるほど、考慮すべき変数は掛け算方式で増えていきます。すべてを一律で仕組み化してしまえばサービス設計やオペレーションは楽になりますが、それでは満足して使われるサービスにはなりません。
「柔軟さと制約の基準をどこに持たせるか」がプロダクト開発の難しさであり、挑戦しがいのある領域でもあります。NOT A HOTEL では一定の制約条件はありつつも「お客さまの暮らし」をより良い体験にするサービス設計に取り組んでいます。
例えば拠点ごとのサービススタッフ人員数など、人的リソースにはどうしても制約が発生します。「予約時の人数設定や食事有無の選択」など定型化できることは、お客さま自身が対応できるように仕組み化しています。
一方で「夜食に焼きそばが欲しくなったからつくってほしい」など自由度が高く定型化できないものは人がサービス提供します。さらにそのなかでも遠隔対応が可能な内容はカスタマーサクセスが横断的に対応し、現地に人がいないとできないことはスタッフが対応するなどの線引きをしています。
このような判断基準が他にもあり、都度サービス運営とプロダクト開発で共に整理しています。
変数を許容するため余白を持たせる
NOT A HOTEL には建築家・サービス・プロダクト開発、子会社を含めればシェフ・ソムリエ・ホテルスタッフまで、異なる専門性を持つメンバーが集まっています。扱う領域が広いためどれだけ経験を積んできた人にも、未知の領域があります。
そのため、どんなに想定してサービスやプロダクトを組み立てても「運営が始まったら全然違った！」ということもあると思っています。だからこそ不確定要素が大きいことは「オペレーションでカバーして、パターンが見えてきたらプロダクトに落とし込む」というのも重要な考え方です。
まだまだ「わからない」こともありますが、2022年秋の引き渡し・サービス提供開始に向けてオペレーションもプロダクトも大詰めの段階となってきました。提供開始後にどのような学びとアップデートがあったか、ということも後にふりかえりを共有したいと思います。
- - - - -
NOT A HOTEL ではプロダクトマネージャーやソフトウェアエンジニアといったプロダクト開発メンバーをはじめ、コーポレート、カスタマーサクセス、セールスなど多岐にわたる職種を募集しています。ご興味のある方はぜひお気軽にご連絡ください。
この記事が気に入ったらサポートをしてみませんか？