サービス提供者様の今回のシステム開発への想い
2017年、Amazon Goがメディアで取り上げられていた頃、レンタルドレスというビジネスモデルについて知る機会がありました。競合店を調査の上、実店舗を無人化することで、十分な収益性を確保しつつ、素晴らしいユーザー体験を提供できると考え、準備を始めました。レンタルというビジネスは、通常の小売と比べ、注文ステータスの管理を詳細にする必要があります。時間軸を意識した在庫管理も必要になり、小売と比べるとシステムやオペレーションの難易度が高い事業です。そこで、当初から実店舗は無人化していましたが、将来的な自動化を見据えつつも、LINEの手動対応とスプレッドシートの手動管理で、運営をスタートさせました。無人化は機能し、副業かつ人を雇わずにも事業は回ったことに加え、ユーザーからのフィードバックも一貫して素晴らしいものでした。2021年に入り、コロナの影響は残っていたものの、2022年以降を見据え、無人化の要件を検討し始めました。LINEのアカウントをボット化し店員の役割を担わせることで、注文ステータスの変更を自動で処理できるようにし、創業当初に思い描いていたビジネスがようやく実現しました。
LINEとの連携
ユーザー体験・開発工数が優れているLINEを採用
ユーザー主導で注文のステータスを適切に管理してもらうためには、ステータスの変更が容易なことと、適切なタイミングで促すことが必要だと考えました。
都度メールを送りWebサイトにログインして管理してもらうことや、アプリを開発して最初にインストールしてもらうことも選択肢としてはあります。ただ、既にほぼ全てのユーザーがインストールして慣れ親しんでいるLINEのユーザー体験に沿って設計することは、ユーザー体験・開発工数いずれの面からも、他の手段より優れていると思い、LINEのMessaging APIとLIFFを利用することにしました。
DBへの手入力がゼロに。手動メッセージの配信数も減少傾向
2021年2月のリリースまでは手動対応アカウントのみで運用し、リリース以降は原則ボット対応、例外対応として手動対応アカウントを残すという運用をしています。
例えば、2020年2月1日からの30日間で、計1,438のメッセージ（あいさつを除く）を手動で送っていましたが、ほぼ同じ売上の2022年1月1日からの30日間では、計193の手動メッセージしか送っておらず、売上当たりの手動メッセージの配信数は今も減少傾向にあります。また、後者の期間においては、Messaging API経由で計3,698のメッセージを送ることで、より大きな効果として、DBへの手入力がゼロになりました。
蓄積されたデータは店舗の運営改善やコンテンツ化して発信
DBには顧客情報や注文情報、メッセージ情報の全てが、LINEのユーザーIDと紐づいて格納されています。
予約情報に基づいて鍵を発行しLINEで送るだけでなく、レンタル開始日や返却期限日の前日に案内を送ったり、ドレスのIDの登録や返却完了の連絡が行われていない場合にリマインドのLINEを送ったりしています。Messaging APIを使うと、LINEの公式アカウントページからはメッセージが見えなくなるので、メッセージ情報も保存し、確認ができるようにしています。
蓄積されたデータは、店舗の運営改善に役立てたり、コンテンツ化して外部に発信したりしています。
