Autto.in
Autto.in は、Hyderabad の doorstep car service で、car owners が home maintenance visits の mechanics を book できる service でした。
元のストーリーを見るプロダクト概要
何だったか
Autto.in は car owners が general car maintenance の doorstep mechanic visits を book できるようにしました。
誰のためか
課題 / 価値
costly or inconvenient garage visits の代わりに、自宅で convenient car service を受けられること。
中核ワークフロー
car owner が service request を book し、Autto.in が mechanic visit を coordinate し、mechanic が customer doorstep で maintenance を行う workflow でした。
中核依存
reliable local mechanic supply、repeat service demand、profitable customer acquisition。
プロダクト形態
価格モデル
revenue は paid car services から来ました。founder は about $15,000 self-funded investment に対し about $5,000 revenue を報告しています。
競合または代替手段
何が起きたか
概要
Autto.in は 2017 年に Hyderabad で作られた on-demand doorstep car service でした。
結果
project は about $5,000 revenue を generated しましたが、roughly $15,000 self-funded investment に対して about $10,000 lost しました。
中核リスク
offline service demand が capacity と margin proof より先に scale しました。
終了理由
founder は high burn、long customer retention cycle、quick growth pressure、heavy workload で mechanics が leaving したことを挙げました。
需要シグナル
source によると customers は service を好みましたが、retention cycle は長く、acquisition campaigns は burn を賄える repeat revenue を十分に作れませんでした。
集客上の問題
Autto.in は service camps で customers を attract できましたが、それらの campaigns は expensive で、mechanic supply が吸収できる以上の operational demand を作りました。
タイムライン
- GeniusMechanic として started しました
- feedback 後に Autto.in へ renamed しました
- early booking workflows に Tilda、Bubble、Chatra を使いました
- leaflets と apartment service camps を tested しました
- high burn、slow retention、mechanic workload pressure の後に shut down しました
作る前に確認すること
なぜ重要か
local-service app は customer interest を示しても、repeat bookings、supply capacity、margin が一緒に機能しなければ失敗します。
主な確認事項
customer acquisition を scale する前に、one small local loop 内で repeat service demand、mechanic capacity、contribution margin を証明してください。
チェックリスト
- same local segment から repeat paid bookings を示せるか。
- providers は attrition なしに peak demand を handle できるか。
- investor-style growth pressure なしに service は profitable でいられるか。
- fulfillment quality が落ち始めたら acquisition を pause できるか。
- 同じ customer はどれくらいの頻度で service を再利用するか。
- 各 provider は churn なしに何件 handle できるか。
- acquisition、provider pay、support、travel time 後の margin はいくらか。
- retention を証明する間、manual operation できるほど小さい geography はどこか。
参考になる場合
- offline service を app に変えている。
- product が contractors、operators、local service providers に依存している。
- repeat usage を証明する前に acquisition に spend する計画である。
参考になりにくい場合
- offline fulfillment step がない product である。
- target geography で reliable supply capacity と repeat paid usage がすでにある。
開発前テスト
- more acquisition channels の前に one neighborhood service loop を manually run する。
- 少なくとも one service cycle で repeat bookings と provider workload を測る。
- conservative acquisition and labor costs で contribution margin を計算する。
応用できる学び
- acquisition を加速する前に retention を validate する。
- customer demand と同じくらい supply workload を track する。
- expansion 前に completed service ごとの contribution margin を計算する。
- repeat behavior が見えるまで one small geography を十分長く使う。
今作るなら
fixed mechanic team を持つ one neighborhood loop を run し、repeat bookings と margin per service を track してください。capacity と retention が安定してから acquisition を追加してください。