オンデマンドサービスアプリの作り方：清掃＆修理ガイド

オンデマンドサービスアプリとは

オンデマンドサービスアプリは、現実世界の作業（家庭の清掃、家電修理、便利屋作業、継続的なメンテナンス）を予約して実行するためのプロダクトです。「オンデマンド」は必ずしも「今すぐ」を意味しません。多くは、顧客が素早く依頼でき、明確な価格や見積もりを見て、やり取りなしに確定した時間枠を確保できることを指します。

双方向のプロダクト（顧客アプリだけではない）

成功しているオンデマンドサービスアプリの多くは二面性を持ちます：

• 顧客（Customers） はサービスを閲覧し、時間を選び、支払い、作業を追跡します。
• 提供者（Service providers） は仕事を受け、スケジュールを管理し、作業を完了し、報酬を受け取ります。

少人数の提供者チームで始めても、提供者向けのツール（軽量なアプリやWebポータル）と、運営を管理するための管理パネルは必要になります。

期待値を整える：まずMVP、次に拡張

すべての機能を最初から入れたくなりますが、サブスクリプション、クーポン、ルート最適化、複数のサービスカテゴリなどは後回しにしましょう。清掃アプリ開発や修理サービスアプリでは、モバイルアプリMVPを必須機能に絞ってリリースし、ユーザーの実際の行動を学んでから、効果のある箇所だけに機能を追加するのが早くなります。

主要な構成要素

清掃や修理のための予約・スケジューリングアプリを作る場合、コアは通常次の通りです：

• 予約（Booking）： サービス選択、住所、時間枠、作業詳細
• 決済（Payments）： カード決済、返金、チップ、請求書
• ディスパッチ／マッチング： 提供者を手動または自動で割り当て
• レビュー： 完了後の評価とフィードバック
• 管理パネル： 注文、提供者、価格、カスタマーサポートの管理

これらは「依頼 → 確認 → 完了 → 支払い → レビュー」という基本ループを作り、時間をかけて改善できます。

ニッチを決めて需要を検証する

成功するアプリは「誰にでも何でも」ではなく、小さく明確な約束から始まります。標準化しやすく品質を安定して提供できる狭いニッチを選びましょう。

繰り返し可能な狭いサービスから始める

良い出発点は標準的な家庭清掃（1〜3ベッドルームのパッケージ）や小型家電の修理（洗濯機、食洗機、電子レンジ）などです。これらは含まれる内容を定義しやすく、所要時間と明確な価格設定ができます。

サービスを例外なしで一文で説明できますか？もしできなければ、さらに絞ってください。

サービスエリアと可用性を定義する

機能を作る前にどこで運営するかを決めてください：

• 都市＋ゾーン（例：「ダウンタウン、北部、西部」）で移動費を変える
• 提供者ハブからの移動半径
• 稼働時間と締切（例：当日予約は11時まで）

これにより、「プロバイダーが見つかりません」という初期の離脱を減らせます。

顧客セグメントとペインポイントを特定する

1〜2の主要セグメントを選び、彼らが何を重視するかに合わせて設計します：

• 忙しい家族： 予測可能なスケジュール、信頼できる提供者、再予約のしやすさ
• 賃貸・若年層： すばやい予約、透明な価格、入りやすさ
• 大家・物件管理者： 複数ユニットのスケジュール管理、請求書、リピート作業

ターゲット層の10〜15人にインタビューしてください。最後に誰かを雇ったときの不満点、支払額、変えたい点に焦点を当てます。

競合：不満点を見つけて改善する

3〜5の直接競合（アプリやローカルサービス）をリストアップし、Google、App Store、Yelp、Redditのレビューを集めてください。"不満" → "どう対応するか"という簡単な表を作ると良いでしょう。一般的なテーマは、遅刻、不明瞭な価格、弱いサポート、一貫性のない品質です。

最後に、ランディングページ＋広告や手動コンシェルジュ（WhatsApp予約）などの軽量テストで実際に支払ってもらえるか検証してください。

ビジネスモデル：マーケットプレイス vs マネージドサービス

ビジネスモデルは顧客に何を約束するか、裏側で何を管理する必要があるかを左右します。清掃や修理では、一般的にマーケットプレイス（独立提供者）とマネージドサービス（自社運営または厳密に管理された契約者）の二択が多いです。

マーケットプレイス：独立提供者

顧客と審査済みのプロをつなぎ、提供者は自分の事業者として可用性を設定して仕事を完了します（アプリでは自社ブランドを前面に出すことも可能）。

通常、各仕事のテイクレート（例：10〜25%）や予約手数料で収益化します。スケールしやすい反面、オンボーディングと実施の監督が弱いと品質がばらつきます。

マネージドサービス：自社のチーム（または厳密に管理された契約者）

サービスを自社で提供する形です。基準を決め、作業者を訓練し、再作業やカスタマーサポートを直接扱います。収益は仕事の全額ですが、労働、消耗品、運用コストが発生します。

定期清掃では結果の安定性を出しやすい一方で、スケジューリング、カバレッジ、急な差し替えなど運用負荷は増します。

価格設定：固定、時間制、見積もりベース

• 固定パッケージ：（例：「2ベッドルームの徹底清掃」）は迅速なチェックアウトと期待値の統一に向きます。
• 時間制： 柔軟な作業に向くが、超過を顧客が心配するため最小時間や時間追跡を明確にする。
• 見積もりベース： 修理に適している（部品や時間が不明瞭な場合）。写真＋症状を集めて範囲を示すか、点検後に確定する。

提供者のオンボーディングと信頼

オンボーディングは簡易コンプライアンスワークフローのように設計します：身元・書類収集、必要な身辺調査、保険確認、サービス基準・コミュニケーション・安全に関する短いトレーニングなど。

手数料、キャンセル、支払い（概要）

テイクレート、顧客向けの予約手数料、提供者手数料（任意）を定義します。キャンセルルールは明確に（例：X時間以内は無料、それ以降は手数料）にしてください。支払いはタイミング（即時 vs 週次）と、返金やチャージバックに備えた保留金を決めてキャッシュフローを安定させます。

必要なユーザーロールとプロダクト

オンデマンドサービスアプリは「一つのアプリ」ではありません。信頼できる予約とサポートのために、通常は顧客体験、提供者体験、管理ワークスペースの3つが必要です。各ロールは目的と画面が異なります。

1) 顧客アプリ（購入者）

顧客アプリは「何を予約できる？いつ？いくら？」の3つを簡単に答えられるようにします。

最低限、顧客はサービスの閲覧（例：徹底清掃、蛇口修理）、事前価格または見積もりの確認、時間枠の選択、アプリ内決済ができるべきです。予約後は注文追跡（「確定」「到着中」「作業中」などのステータス）、サポート連絡、提供者の評価・レビューが必要です。

2) 提供者アプリ（作業者）

提供者はスピードと明確さを必要とします。コアフローは：仕事を受ける → 受諾/辞退 → 住所へ移動 → ステータス更新 → 作業完了 → 支払い受領。

良い提供者体験には、アプリ内チャットや通話（プライバシー保護付き）、作業詳細（範囲、写真、メモ）、報酬・手数料・振込予定の確認画面が含まれます。

3) 管理パネル（運営者）

管理パネルはビジネスをコントロールする場所です。以下を管理できるべきです：

• サービスカタログと追加オプション
• 提供者のオンボーディング、書類、可用性
• 価格ルール、サービスエリア、プロモーション
• 注文監視、紛争、返金、手動調整
• カスタマーサポートツール（ノート、タイムライン、メッセージ履歴）

提供者側をまずWebポータルにできますか？

多くの場合、はい。MVPのコスト削減に有効です。小規模な提供者プールなら、レスポンシブなWebポータルで仕事受諾、ステータス更新、支払い確認をカバーできます。

その後、ボリュームや即時性が増したら、プッシュ通知やナビ、オフライン対応が価値を生むので提供者向けのネイティブアプリに移行できます。

清掃・修理のMVP範囲

MVPの目的は一つ：最小限の複雑さで実際に有料の予約をエンドツーエンドで完了させること。顧客がサービスを依頼し、提供者が受けて完了し、何か問題が起きたら介入できる——これがMVPの仕事です。

MVPのゴール（完了の定義）

実践的なMVPゴールは：50〜200件の有料注文を予測可能に完了することです。その規模で顧客が何を買うか、提供者が何を確実に提供できるか、運用の壊れやすい箇所が見えてきます。

顧客側の必須機能（MVP）

顧客側は予約に自信を持てることに集中します：

• サインアップ / ログイン（メールまたは電話）
• サービス選択（例：「1ベッドルーム清掃」や「シンク修理」）と明確な価格ルール
• 住所と基本メモ（入り口指示、駐車、修理用の写真）
• スケジューリング（日時/時間帯の選択）
• 決済（カードやウォレット）と領収書
• 注文履歴（ステータスとサポート連絡）

提供者側の必須機能（MVP）

提供者は現場に来て報酬を得るためのシンプルなツールが必要です：

• 可用性（稼働時間の切り替え、任意の休業日設定）
• ジョブの受諾/辞退（理由を選べる）
• ステータス更新：現場へ移動 → 作業開始 → 作業完了
• 基本的なジョブ詳細：住所、時間、メモ、顧客連絡（可能なら番号はマスク）

管理側の必須機能（MVP）

初期運用の“安全網”として管理パネルは：

• ジョブ管理：閲覧、割当/再割当、キャンセル、再スケジュール
• 提供者管理：オンボーディングステータス、書類、パフォーマンスノート
• 手動調整：返金/割引、支払い修正、監査用ノート

後回しにするべき“便利機能”

次の予約を完了する助けにならないものは後回しにします：

• 会員制度、紹介、複雑なプロモーションエンジン
• ダイナミックプライシングや複雑なアドオン群
• 高度なマッチング、評価に基づくルーティング、複数停止ルート最適化
• アプリ内チャット（必要なら最初はSMS/メールで代替）

良いMVPは裏側が少し手動でも、顧客にはストレスなく提供者には明確に見えることが重要です。

コアのユーザーフローとシンプルなUX

オンデマンドサービスアプリは機能の多さで勝つのではなく、予約が明快で速く、安全に感じられることで勝ちます。まずはエンドツーエンドのユーザーフローを設計し、問題が起きたときにアプリがどう振る舞うかを決めてください（必ず問題は起きます）。

予約フロー（ステップバイステップ）

メインパスは線形で予測可能に保ちます：

サービス → 詳細 → 時間 → 支払い → 確認。

各ステップで「正確なスケジューリングに最低限必要な情報は何か？」を問い続けてください。清掃なら寝室/バスルーム数や備品有無、修理なら機器種別・症状・写真などです。

実用的なフロー例：

• サービスを選ぶ（清掃、配管、電気など）
• 詳細を追加（住所、メモ、写真、入室方法）
• 時間を選ぶ（空き枠、所要時間見積、到着予定）
• 支払う（カード/ウォレット、プロモコード、チップ）
• 確認（要約、提供者の到着ルール、再スケジュール/キャンセルポリシー）

明確なパッケージとアドオン（価格は単純に）

ユーザーは総額が予測できないと躊躇します。構造化されたサービスパッケージとアドオンを用意してください。

例：

• 清掃："スタンダード清掃" と "ディープクリーン"、アドオンに "オーブン内部"、"冷蔵庫内部"、"資材持参" など
• 修理："診断訪問" とアドオンに "時間外訪問"、"2名対応"、"一般的な部品見積" など

価格ロジックは可視化し、何が含まれるか、何が時間を延ばすか、何が承認を要するかを示してください。

画面上で信頼を作る

信頼はUXの一部です。プロフィールタブに隠すのではなく、フローの中で見せてください：

• 提供者プロフィール（写真、経験、話せる言語、サービスエリア）
• バッジ（身元確認済み、書類確認済み、高評価）
• レビュー（仕事の種類と日付が分かる実在感のあるもの）
• 明確な価格表示 とポリシー（キャンセル期間、"資材込み"の定義）

必要な主要画面と“嫌なパス”の設計

多くのMVPは良いパスではなく、エッジケースで失敗します。次の状態や画面を用意してください：

• 空の状態（空きがない、エリアに提供者がいない）には代替アクションを提示
• エラー（支払失敗、枠がなくなった）には回復手順を明示
• 再スケジュール（ユーザー／提供者発の変更）には確認とリマインド
• キャンセルと返金 は透明に結果とタイムラインを示す

これらができていれば、先進機能がなくても「頼れるアプリ」と感じてもらえます。

技術選択：アプリ、バックエンド、連携

技術選択は予算とどれだけ早くローンチする必要があるかで決めると楽です。清掃や修理では顧客は信頼できる予約、更新、決済を重視するため、派手なアニメーションよりもスケーラブルでシンプルなスタックを選んでください。

iOS/Androidはネイティブかクロスプラットフォームか

最高のパフォーマンスとプラットフォーム固有の磨きを求めるならネイティブ（iOSはSwift、AndroidはKotlin）が最良ですが、二つのアプリを維持するコストが掛かります。

多くのMVPではクロスプラットフォーム（FlutterやReact Native）が実用的です：コードベースが1つで反復が早くコストが低め。ただしデバイス固有の調整が必要になることがあります。

ルール：最初のリリースが「予約・支払い・追跡・レビュー」ならクロスプラットフォームで十分なことが多いです。

バックエンドの必須事項（サーバで扱うこと）

シンプルでも堅牢なバックエンドは必要です。最低限以下を想定してください：

• アカウントと役割： 顧客、提供者、管理者
• ジョブ／予約： 依頼、受諾／割当、開始、完了、キャンセル
• 提供者の可用性： 稼働時間、休暇、サービスエリア
• 価格ロジック： 基本料金、アドオン、最低料金、税金
• 決済： 認可、キャプチャ、返金、支払い、手数料

高速で作るならFirebaseやSupabase、より複雑なワークフローやレポートが必要ならカスタムAPI（Node.js/Django/Rails）を選びます。

スピードと制御のバランスを取るなら、Koder.ai のようなプラットフォームはMVPに実用的です：顧客アプリ、提供者ポータル、管理パネルをチャット駆動で設計し、プランニング→反復ができ、準備が整えばソースコードをエクスポートできます。

再利用すべき定番の連携（自前で作らない）

一般的な部品は既存サービスを使ってリスクを下げ、早く出せます：

• 地図とジオコーディング： Google Maps や Mapbox
• プッシュ通知： Firebase Cloud Messaging / Apple Push
• メール/SMS： SendGrid + Twilio（または地域のSMSプロバイダ）
• 決済： Stripe（多くの場合簡単）、地域ゲートウェイが必要ならそちらを選択

これらを活用すると開発の不確実性が減ります。

最初に設計しておくべきデータモデルの基本

コーディング前にコアのテーブル/コレクションをスケッチしておくと良いです：

• Users（プロフィール、連絡先、役割）
• Providers（スキル、書類、評価、サービス半径）
• Services（カテゴリ、所要時間、価格ルール）
• Bookings（時間枠、住所、ステータス、割当提供者）
• Payments（金額、返金、支払いステータス）
• Reviews（星評価、コメント、予約に紐づく）

予約ステータスや決済照合まわりを早めに正しく設計しておくと、後で大きな移行を避けられます。

スケジューリング、ディスパッチ、提供者マッチング

スケジューリングがうまくいくかどうかでアプリの印象が決まります。清掃と修理ではカレンダー自体が難しいわけではなく、交通、工具、スキル、遅延といった現実の制約をシステムに落とし込むことが難しいのです。

失敗予約を防ぐスケジューリングルールを定義する

最初にシステムが守るべきことを決めてください：

• リードタイム： 顧客が最短でいつ予約できるか（例：今から2時間後、または翌日から）
• 時間枠 vs 正確な時刻： 清掃は固定枠（9–12、12–15）が合い、修理は到着ウィンドウ（10–12）が向く
• ジョブ所要時間： サービスタイプごとのデフォルトと、アドオンでの延長許容
• ジョブ間のバッファ： 駐車や引き継ぎ、遅延を見越した余裕（15–30分）

これらを最初に組み込まないと、顧客が実現不可能なスケジュールを予約してしまいサポート対応が増えます。

ディスパッチ：最初は手動、データが揃ったら自動化

実務上の2つの運用モード：

手動割当（運営者/管理者が提供者を選ぶ）はMVPに最適です。VIP対応や特殊案件、新規提供者、専用機器が必要な仕事を安全に処理できます。

自動マッチングは提供者が十分に揃い、パターンが見えてきたら有効になります。簡単なスコアリングで実装できます：まず適格な提供者でフィルタし、距離、可用性、評価、受諾率などでソートします。

現実の制約を扱う（過度に複雑にしない）

キャンセルや手戻りを避けるため、マッチングでは次を考慮してください：

• 移動時間： 半径だけでなく前の仕事からの到着見積を使う
• スキルと資格： 例：ガス機器、カビ処理、ディープクリーニングなど
• 機材や部品： バキュームやスチーマーを持つ提供者、修理で部品持参が必要かどうか

最初はルールベースで透明にし、信頼性を優先してください。

再スケジュールとキャンセルの明確なフロー

両者をサポートする明確な流れを作ってください：

• 再スケジュール： 次の空き候補を提示し、何が変わるか（時間、提供者、価格）を確認する
• キャンセル： 手数料の有無、締切（例：24時間前まで無料）、返金予定を明示する

スケジュール変更はすべて確認メッセージを送って提供者のタイムラインを即更新し、二重予約を防ぎます。

決済、返金、提供者への振込

決済は信頼を築くか、サポートチケットを生み続けるかを分ける重要な部分です。決済を予約システムの一部として扱い、各予約に明確な決済ステートを持たせ、各ステートに応じた次の操作を定義してください。

リスクに合わせた決済フローの選定

一般的に選べるフローは3つ：

• 先に課金（Charge upfront）： 予約時に支払い。固定価格に最適。
• 認可して後でキャプチャ（Authorize and capture later）： 予約時に仮押さえ、作業後に確定。合計が変わる可能性がある場合に有効。
• 作業後支払い（Pay after service）： 完了後に徴収。摩擦は少ないがノーショーや回収リスクが高い。

選んだ方式に関わらず、予約ごとに payment_status（例：unpaid, authorized, paid, failed, refunded, partially_refunded）とタイムスタンプを保存して監査可能にしてください。

返金・部分返金・キャンセルのロジック（実装指針）

"全額返金"を前提にハードコードしないでください。以下のようなシナリオを表現できる設計にします：

• 提供者未割当でのキャンセル → 決済の取り消し／自動返金
• 割当後のキャンセル → オプションでキャンセル料を徴収し、残額を返金
• サービス紛争 → 一部返金で対応し、作業済み分は保持する

返金は refund_amount, reason_code, initiated_by, provider_impact といった属性で予約に紐づくレコードとして扱い、サポートと会計で突合できるようにします。

提供者の支払い：予測可能でトレース可能に

提供者が気にするのは「いつ払われるか」と「算出方法」です。

• デフォルトは週次振込、オプションで即時振込を提供
• 振込閾値（例：$X未満は振込しない）
• 各提供者向けに振込履歴（振込日、含まれる予約、手数料、支払額の内訳）を表示
• 予約の支払いと提供者への振込は別で管理（予約は支払済みでも振込は保留）

領収書と請求書

支払い確定後と返金時に領収書を送信し、サービス、アドオン、手数料、割引の内訳が分かる請求書を生成して invoice_id と invoice_status を予約に紐づけておくと会計が楽になります。

コミュニケーション、更新、レビュー

明確でタイムリーな連絡は単発の予約をリピートに変える鍵です。清掃や修理では主に「誰がいつ来るかの確実性」と「何が行われたかの証拠」を求められます。アプリはこれらを少数の機能で提供できます。

アプリ内チャットと番号マスキング

顧客と提供者が入室方法、駐車、材料についてやり取りできるようアプリ内チャットを追加してください。

緊急時（"到着しました"、"止水しました"）には番号マスキングを提供して、双方の実際の番号を隠しつつ通話を可能にし、プラットフォーム外でのやり取りや取引を防ぎ、仕事に関する記録を残せます。

不安を減らすプッシュ通知

プッシュ通知は顧客が自然に抱く疑問に答える内容にします：

• 予約確定（日時と提供者名）
• 提供者の移動中／到着間近
• 作業開始・完了
• 時間変更、キャンセル、再割当（理由付き）

通知は短く一貫性を持たせ、必ず該当の画面（予約詳細）へ遷移できるようにしてください。ホームだけに飛ばすのは避けます。

修理で有効な写真アップロードと作業証拠

写真は修理ワークフローで特に有用です：

• 事前写真： 顧客が予約時に問題箇所をアップロードすると提供者が適切な工具を持参しやすくなる
• 作業中/完了写真： 提供者が作業証拠としてアップロードすることで紛争を減らす

これにより紛争が減り、フォローアップが迅速になり、再訪時に状況を把握しやすくなります。

レビュー、評価、モデレーション

完了直後に促すシンプルなレビューで信用が育ちます。星評価と「時間通り」「品質」「清潔感」など1〜2項目の短いプロンプトを組み合わせると良いでしょう。

管理側でのモデレーションツール（通報、削除、公開返信、紛争対応）も初めから用意してください。レビューは実際に完了した予約に紐づけることでスパムを防ぎ、マーケットプレイスの信頼性を保てます。

セキュリティ、プライバシー、信頼機能

清掃や修理のアプリでは、安全性と信頼がなければ顧客は見知らぬ人を家に入れません。事故が起きてから追加するのではなく、初期からこれらの基盤を組み込みましょう。

最低限これだけは実装すること

各ロール（顧客、提供者、管理者）に対する強力な認証を導入します。安全なパスワードルール、管理者には任意で2要素認証（2FA）、ログインのレート制限を使ってください。

RBACは必須です：顧客は自分の予約のみ、提供者は割当られた仕事のみ、管理者は必要な範囲にのみアクセス。管理操作の監査ログは初日から導入し、誰が価格を変えたか、誰が返金したか、誰がユーザーデータにアクセスしたかを追跡できるようにします。

ユーザーデータ保護（提供者の可視性制限）

通信は常に暗号化（HTTPS/TLS）し、提供者に必要な情報だけを見せるようにします。例えば、提供者が仕事を受ける前は「近隣」や概算エリアだけ表示し、予約確定後に正確な住所を公開する等の工夫です。

データ最小化の原則を守り、サービスに不要な個人情報（生年月日など）は収集しないでください。

運用上の安全とインシデント対応

提供者の検証ワークフローを作ります：身元確認、電話/メール検証、必要なら身辺調査や免許・保険のアップロードを行い、"Verified" ステータスを明示して顧客に分かりやすく表示します。

顧客と提供者双方がインシデント（安全問題、損害、ノーショー）を報告できる機能を用意し、重大な報告は優先の管理者キューにルーティングして証拠添付とタイムスタンプを残します。

保持、バックアップ、閲覧権限

シンプルなアクセスマトリクス（役割 → 見られるデータ）を定義して文書化してください。

古いチャットの自動削除ルール（例：Xか月後に削除）や暗号化されたバックアップと復元手順のテストを行い、バックアップへのアクセスは限られた管理者に限定してアクセスログを残します。

テスト、ローンチ、指標、成長計画

素晴らしいMVPでも実運用で壊れたら失敗します。低速ネットワークや提供者がピンを見逃す状況、返金処理などを想定して、テストとローンチをプロダクトの一部として扱ってください。

実用的なテストチェックリスト（MVP）

マーケティングに投資する前に基礎が退屈なくらい安定していることを確認します：

• 予約フロー： 予約作成→再スケジュール→全当事者が同じ時間と住所を見る
• 決済： カード認可/キャプチャが動作、失敗時の復帰、領収書送付、決済ステータス更新
• キャンセル＋返金： ユーザーが締切前/後にキャンセル、提供者のキャンセル、部分/全額返金の動作
• エッジケース： 二重予約、提供者のノーショー、ユーザーの住所変更、タイムゾーン問題、最後の枠の扱い
• 低速/不安定ネットワーク： スロットル環境での動作確認。アプリが無限に回り続けず安全に再試行する（重複課金をしない）
• 通知： プッシュ/SMS/メールが適時届く、ディープリンクが正しい画面を開く、通知の見逃しがジョブをブロックしない

管理パネルがあるなら、手動でのジョブ作成、提供者割当の上書き、返金、紛争ノートのテストも行ってください。

フルローンチ前にパイロットを実行する

1エリア（近隣や小さな都市）と小規模な提供者グループでパイロットを開始してください。目的はスケールではなく学習です：

• 実際のディスパッチ時間の検証（割当までの時間）
• 運用上のギャップ発見（変更時に誰が顧客に電話するか等）
• サービス所要時間、価格ルール、キャンセルポリシーの調整

パイロットは対象時間やサービスを限定し、シンプルに保ちます。そうすることでクリーンなデータと少ないサポート負担で学べます。

追跡すべき指標（週次）

少数の指標を週次で追跡します：

• コンバージョン率： 訪問 → 価格閲覧 → 予約 → 支払い
• リピート率： 30/60日以内の再予約率
• キャンセル率： 理由別に分ける
• 割当までの時間： 予約から提供者受諾まで（手動介入率も）

初期に軽量なイベントトラッキングを入れておくと、あとから分析を作り直す負担が減ります。

ローンチ後の成長ロードマップ（段階的に）

コアフローが安定したら、順序立てて改善していきます：

1. 自動化： より賢いマッチングルール、自動再割当、管理作業の削減
2. サブスクリプション： 定期清掃やメンテナンスプランで安定収益化
3. 紹介施策： 両者にクレジットを付与（不正対策を組み込む）
4. 複数都市展開： ユニットエコノミクスと運用が再現可能になってから

ビルド見積りやパイロット計画の支援が必要なら、/pricing を確認するか /contact で連絡してください。