Web AppShut Down

Kitchit

Kitchit は、自宅での食事向けにプライベートシェフを予約できるオンデマンド型マーケットプレイスでした。閉鎖は、顧客満足度が高くても、各取引が地域供給、日程調整、サービス品質、反復需要、利益率に依存する場合、事業として拡大できないことがあると示しています。

元のストーリーを見る

プロダクト概要

何だったか

Kitchit は、自宅でのプライベートダイニング体験のために、顧客とプロのシェフをつなぎました。

誰のためか

プライベートディナーや特別な食事を開く消費者プライベートイベントを探すプロのシェフ自宅でレストラン品質の食事を求めるフードテック顧客

課題 / 価値

自宅でレストラン品質のプライベート食事を提供し、シェフにはマーケットプレイス経由の集客チャネルを約束しました。

中核ワークフロー

顧客がプライベートダイニング体験を選択またはリクエストし、Kitchit がシェフの空き状況や期待値を調整し、シェフが顧客の自宅で料理しました。

中核依存

反復予約頻度、密度ある地域供給、シェフ稼働率、貢献利益、顧客獲得コスト、サポート負荷に依存していました。

プロダクト形態

オンライン予約マーケットプレイスプライベートシェフイベントの調整シェフ供給ネットワーク顧客サポートと日程調整ワークフロー

価格モデル

マーケットプレイス予約モデル。公開情報は資金調達とサービスの位置づけを報じていますが、テイクレート、平均予約額、シェフ支払い、粗利、顧客獲得コストは公開していません。

競合または代替手段

プライベートシェフのマーケットプレイスケータリング事業者レストランでの食事ミールキットオンデマンド食品配達SpoonRocket、Dinner Lab、Kitchensurfing などのフードテックスタートアップ

何が起きたか

概要

Kitchit は、顧客満足度と一定の利用が報じられていたにもかかわらず、難しいフードテック市場で十分な規模に達せず、ランウェイ終了後の 2016 年 4 月に閉鎖しました。

結果

同社は、限られたランウェイでプライベートシェフのマーケットプレイス拡大を続けるのではなく、運営を停止しました。

中核リスク

高い満足度は、高接触のローカルサービスにおけるマーケットプレイス密度、反復頻度、貢献利益、投資家が支えられる規模を証明しませんでした。

タイムライン

  • Kitchit は 2011 年、プライベートシェフのマーケットプレイスとして始まりました。
  • Forbes は閉鎖前に、プライベートシェフと食事客をつなぐサンフランシスコのスタートアップとして同社を紹介しました。
  • TechCrunch は、Kitchit が $8.1 million を調達し、100,000 を超える食事または利用者にサービスを提供したと報じました。
  • 2016 年 4 月、TechCrunch は Kitchit が 5 年後に閉鎖したと報じました。

作る前に確認すること

なぜ重要か

人、日程、品質、地域供給、サポートを調整するマーケットプレイスには、個々の顧客が体験を好きだという証拠だけでなく、密度と経済性の証明が必要です。

主な確認事項

強い顧客フィードバックを拡大可能性の証拠と扱う前に、反復頻度、供給稼働率、貢献利益、サポート負荷を検証してください。

チェックリスト

  • コホート別の反復予約を追う。
  • シェフ稼働率とキャンセル率を測る。
  • サポート時間を含めた予約ごとの貢献利益を計算する。
  • 広く展開する前に一つの市場で密度テストを行う。
  • NPS と実際の再注文行動を比較する。
  • ユーザーは重いリマインダーや割引なしに十分な頻度で繰り返すか。
  • 供給側は継続するだけの収入を得られるか。
  • 完了取引あたりのサポート時間はどれくらいか。
  • 返金、調整、獲得コスト後も貢献利益はプラスか。
  • 複数都市に広げる前に一つの密度ある市場で成立するか。

参考になる場合

  • ローカルサービスのマーケットプレイス、コンシェルジュ型プラットフォーム、AI 予約アシスタント、高接触サービスワークフローを作っている。
  • 各取引に人間の調整、供給マッチング、日程調整、品質管理が必要である。
  • 最も強い証拠が、満足度、推薦文、一回限りの利用であり、反復経済性ではない。

参考になりにくい場合

  • プロダクトが純粋なソフトウェアで、限界調整コストがほぼゼロである。
  • ユースケースが高頻度で、予算化されており、既に反復購入行動が証明されている。

開発前テスト

  • 一都市での手作業コンシェルジュパイロット
  • 有料の反復予約コホートテスト
  • シェフ稼働率と供給維持のテスト
  • 実際のサポート時間を使った貢献利益モデル

応用できる学び

  • NPS を反復頻度、粗利、獲得コストと一緒に見る。
  • 需要を広げる前に供給稼働率を検証する。
  • 人間の調整を例外ではなくプロダクトの一部としてモデル化する。
  • ユースケースが両側を活発に保つほど高頻度かを確認する。
  • 高単価でたまに使うサービスに、ベンチャー規模の前提を置きすぎない。

今作るなら

顧客が喜ぶ体験を作るだけでなく、一つの都市で反復予約、シェフ稼働率、貢献利益、サポート時間を測り、高頻度ではない高単価サービスが本当に密度を持てるかを先に確認してください。