シェアキッチン・間借り店舗・短期出店スペースの運営事業者向け

シェアキッチン・短期出店スペースの利用審査・売上報告・退店確認を管理するWebシステム

Webシステムのカスタマイズ制作

シェアキッチン・短期出店スペースの申請から営業後の確認までを管理するWebシステムの構成例です。
出店者と利用日を基準に、審査、契約条件、設備・保管場所の割当、売上報告、退店確認、利用料を確認できます。

日替わり・週替わりで出店者が変わり、使用設備や冷蔵庫の割当、清掃写真、鍵の受け渡しなどを利用ごとに確認している施設では、予約日時とは別に管理する情報が増えることがあります。このページでは、担当者向けの未処理事項と確認期限、出店者がスマートフォンから提出する報告を同じ利用記録に関連付ける画面例をご紹介します。

既存の予約サービスを継続する構成と、予約機能を含めて開発する構成の両方をご紹介します。シェアキッチン、間借り店舗、チャレンジショップ、短期物販・ポップアップスペースなど、運営方法に合わせて対象を選べます。

シェアキッチンの片付けを出店者と管理担当者が確認する人形風のミニチュアイラスト

このような施設運営に向いています

  • 日替わり・週替わりで出店者が変わり、複数施設・区画を数名の担当者で管理している。
  • 出店内容、使用設備、提出書類を確認してから利用を認めている。
  • 出店者ごとに固定利用料・売上歩合・最低保証・報告期限が異なる。
  • LINEやメールに、鍵返却、清掃写真、備品破損の報告が分かれている。
  • 営業後の売上報告を催促し、月末に契約ごとの利用料を計算し直している。
  • 次の出店者が来る前に、再清掃・忘れ物・設備点検への対応を共有したい。

導入する範囲は、施設の数だけでなく、出店者の入替頻度、審査・報告件数、契約方式、確認にかかる時間から検討します。固定の少人数へ貸し、確認業務も少ない場合は、既存サービスと簡単なフォームで足りることもあります。

ご紹介する7つの利用場面

  1. 本日の利用と、次の受入までに確認すること

    誰が何を確認し、次の利用者を受け入れる準備を進めるか判断します。

  2. 食品・物販の内容に応じて利用申請を審査する

    提出された出店内容を、どの条件で受け入れるか確認します。

  3. 契約条件と、利用区画・設備・保管場所を確認する

    予約の確定状況と、必要な区画・設備が確保されているか確認します。

  4. 出店者がスマートフォンから売上を報告する

    どの利用日の売上を、どの資料と契約条件に基づいて報告するか確認します。

  5. 清掃写真・片付け・鍵返却を退店時に報告する

    清掃・返却の何が完了し、何を運営者へ伝える必要があるか確認します。

  6. 利用前後の記録を確認し、再清掃や追加対応を依頼する

    次の利用に向けて、再清掃・設備確認・返却のどれが必要か判断します。

  7. 契約別に利用料を計算し、確認済み明細を集計する

    請求に使える明細と、売上や追加料金の確認を待つ明細を区別します。

予約の前後で、確認が増える場面

パターン1:予約日は決まったが、何を販売するか、必要な資料が分からない

利用内容と資料の確認を申請へ関連付け、追加確認が必要な項目を出店者へ案内します。

パターン2:キッチンは空いているが、冷蔵庫の保管場所が前の利用者の荷物で埋まっている

設備や棚に利用期間を設定し、区画の予約とは別に保管の重複を確認します。

パターン3:売上報告の催促先を、LINEの履歴から探している

利用日別に未提出・提出済み・修正依頼中を表示し、報告が必要な出店者を確認します。

パターン4:写真は届いたが、片付けが終わったのか、誰が確認したのか分からない

出店者の報告と運営者の確認を分け、再清掃依頼と次の受入までの確認期限を残します。

パターン5:固定料と歩合の契約が混在し、月末の転記と計算に時間がかかる

契約の適用期間、歩合対象売上、最低保証の単位を使い、確認済みの明細を集計します。

パターン6:利用後に傷が見つかったが、開始時からあったものか分からない

開始時・終了時の記録と確認結果を参照し、原因や追加費用を担当者が確認します。

予約管理は、2つのカスタマイズ例から検討できます

予約から一式で作る場合も、現在の予約受付を継続する場合も、出店者・利用日・契約条件を基準に、審査・売上・退店確認をつなげられます。

例A:既存の予約サービスを継続

予約受付と確定は既存サービスで行い、新しいWebシステムでは利用申請、提出書類、設備割当、売上報告、退店確認などを扱います。

  • 予約番号と施設・利用日・出店者を関連付ける
  • 予約変更・取消の結果を、確認した時点とともに表示
  • API・CSV等の連携方法と更新頻度を確認
  • 取得失敗時は未確認と表示し、担当者が結果を確認

例B:予約機能を含めて開発

利用申請、仮押さえ、区画・設備の空き、規約同意、支払条件、予約確定、変更・取消を同じシステムで扱います。

  • 利用審査と予約確定を別の状態で管理
  • 確定時に設備・保管期間・前後時間の競合を再確認
  • 同時申込、期限切れ、変更・取消の処理を設計
  • 決済やスマートロックは必要な範囲で外部サービスと連携

どちらも制作例として掲載しています。導入時には、予約を確定するシステム、更新する担当者、変更・取消の反映方法を決めます。同じ予約を双方で別々に確定する運用は避けます。

食品と物販で、申請・当日確認の項目を変えます

シェアキッチン・間借り店舗製造・販売内容、使用設備、冷蔵・冷凍保管、清掃分担、施設が求める書類と担当者の確認結果。
短期物販・ポップアップスペース商材、持込什器、電源、看板、搬入経路、毎日の撤去、期間中の荷物保管。
共通する記録出店者、契約、利用日、申請審査、料金条件、報告、退店確認、対応履歴。

画面構成イメージ

7つの画面は架空データを使った独立した操作例です。実際の認証・データ保存・通知・予約確定・請求は行いません。画面を移動・再読込すると操作前の状態に戻ります。

シーン1

本日の利用と、次の受入までに確認すること

書類不足、清掃の確認待ち、鍵の未返却、前日分の売上未提出を予約表とは別に確認している場合は、利用日と施設・区画を基準にまとめられます。この画面では、現在の状態、対応する担当者、確認期限を一覧にします。

  • 施設・区画別に、搬入から片付けまでの利用時間と運営者の点検枠を表示
  • 売上報告と退店確認を別々の状態で表示
  • 次の受入に影響する清掃・返却・設備停止を優先して確認
  • 売上未提出の利用日を抽出し、対象者と案内内容を確認
  • 複数施設の管理を、施設別・担当者別に絞り込み

モックでは、昼のキッチン利用後に再清掃が必要で、18時から次の利用が予定されている場面を示します。売上報告は翌日締切のため、現場の確認を先に進めます。

画面イメージ:本日の利用と、次の受入までに確認すること

この画面で判断すること
誰が何を確認し、次の利用者を受け入れる準備を進めるか判断します。

システム画面のイメージはPC、タブレット、スマホ横向きでご覧ください。

この画面例を別画面で開く

シーン2

食品・物販の内容に応じて利用申請を審査する

シェアキッチンで製造・販売する場合と、短期スペースで衣類や雑貨を販売する場合では、確認する内容が異なります。申請目的に応じて、販売品目、使用設備、持込什器、保管、施設が求める書類、搬入・撤去の条件を表示します。

  • 食品では製造・販売内容、使用設備、施設側の確認結果を記録
  • 物販では商材、什器、電源、看板、搬入経路と撤去条件を確認
  • 資料の提出済みと、担当者の内容確認済みを区分
  • 追加質問、回答、許可条件、否認理由を申請に関連付け
  • 繰り返し利用は承認済み資料を参照し、変更部分を再確認

施設が利用を承認した記録と、食品営業等の行政手続きは別です。必要な確認項目は営業形態や施設の運用に合わせて設定し、システムだけで許可の要否や営業可否を判断しません。

画面イメージ:食品・物販の内容に応じて利用申請を審査する

この画面で判断すること
提出された出店内容を、どの条件で受け入れるか確認します。

システム画面のイメージはPC、タブレット、スマホ横向きでご覧ください。

この画面例を別画面で開く

シーン3

契約条件と、利用区画・設備・保管場所を確認する

同じキッチンが空いていても、希望するオーブンや冷蔵棚を別の出店者が使用している場合があります。区画の利用日だけでなく、設備、保管場所、搬入・片付け、運営者の点検時間を関連付けます。曜日固定契約でも各日の利用記録を作成します。

  • 既存予約サービスの結果を照合する例と、このシステムで予約を確定する例を掲載
  • 利用申請・出店契約・各日の利用番号を関連付け
  • 冷蔵・冷凍棚や備品の割当を、利用日をまたぐ保管期間も含めて確認
  • 仮押さえ、条件同意、支払条件、設備の空きを別々に確認
  • 特定日だけの休止、申請内容の変更、取消を履歴に残す

モック内の切替はカスタマイズ例の比較です。実際の運用では予約を確定するシステムと、双方で更新する項目を決めます。外部結果が取得できない場合は未確認と表示します。

画面イメージ:契約条件と、利用区画・設備・保管場所を確認する

この画面で判断すること
予約の確定状況と、必要な区画・設備が確保されているか確認します。

システム画面のイメージはPC、タブレット、スマホ横向きでご覧ください。

この画面例を別画面で開く

シーン4

出店者がスマートフォンから売上を報告する

「売上の何%を場所代とする」契約では、売上報告が届かなければ利用料を確定できません。出店者が利用日を選び、売上・返品・補足を入力し、必要に応じてレジ締め資料を添付する構成にします。運営者は未提出だけを確認して催促できます。

  • 売上ゼロ、未提出、報告不要を異なる状態で管理
  • 歩合対象売上の税込・税抜、値引き・返品・手数料の扱いを契約に合わせて設定
  • 売上と資料の照合、提出日時、確認者を記録
  • 固定料+歩合と、最低保証付き歩合の計算根拠を表示
  • 提出後の訂正は理由と版を残し、確認済みデータを無断で上書きしない

金額入力だけで売上の正確性を保証するものではありません。必要な施設ではレジ資料・POS出力と照合します。売上が未提出でも、清掃や鍵返却の報告は先に受け付けます。

画面イメージ:出店者がスマートフォンから売上を報告する

この画面で判断すること
どの利用日の売上を、どの資料と契約条件に基づいて報告するか確認します。

システム画面のイメージはPC、タブレット、スマホ横向きでご覧ください。

この画面例を別画面で開く

シーン5

清掃写真・片付け・鍵返却を退店時に報告する

営業終了後、出店者がスマートフォンから、コンロ、シンク、作業台など施設が指定した箇所の写真と確認項目を提出します。ゴミ、持込什器、冷蔵棚、鍵、忘れ物、備品の破損も、同じ利用番号から報告できる構成です。

  • 施設・用途ごとのチェック項目と写真の必要箇所を表示
  • 利用者が担当する清掃と、運営側が担当する点検を区分
  • 未完了や確認できない項目も、理由付きで報告
  • 鍵の受け渡し方法と返却結果を記録
  • 通信失敗時は未提出のまま表示し、入力内容を確認して再送

写真を提出しただけで退店確認済みにはしません。モックでは送信失敗時の表示と、売上未提出のまま退店報告を先に提出する操作を試せます。

画面イメージ:清掃写真・片付け・鍵返却を退店時に報告する

この画面で判断すること
清掃・返却の何が完了し、何を運営者へ伝える必要があるか確認します。

システム画面のイメージはPC、タブレット、スマホ横向きでご覧ください。

この画面例を別画面で開く

シーン6

利用前後の記録を確認し、再清掃や追加対応を依頼する

清掃が不足していた、備品が戻っていない、開始時からあった傷なのか分からない。こうした確認をLINEの写真だけで行うと、対象の場所や利用日を探し直すことになります。開始時の記録と退店報告を並べ、依頼内容・担当者・期限・再報告を残します。

  • 開始時と終了時の写真・メモを、利用日と箇所で照合
  • 再清掃依頼、再報告、担当者確認を別々に記録
  • 次の利用開始までに必要な確認と担当者を表示
  • 修理・点検が必要な設備は使用停止として管理
  • 追加費用は原因・契約・根拠資料を確認し、現場確認と別に確定

撮影日時と提出日時は区別します。写真に写っていない状態をAIで合格にしたり、破損の申告だけで賠償額を確定したりする構成にはしません。

画面イメージ:利用前後の記録を確認し、再清掃や追加対応を依頼する

この画面で判断すること
次の利用に向けて、再清掃・設備確認・返却のどれが必要か判断します。

システム画面のイメージはPC、タブレット、スマホ横向きでご覧ください。

この画面例を別画面で開く

シーン7

契約別に利用料を計算し、確認済み明細を集計する

固定料金、売上歩合、最低保証、延長料金などが契約ごとに異なる場合、月末に売上報告を集めて計算し直す作業が発生します。確認済みの売上と、その利用日に適用した契約条件から明細を作り、既存の請求・会計システムへ渡せるようにします。

  • 固定料、歩合、最低保証、承認済みの追加料金を内訳で表示
  • 未提出・修正依頼中は計算保留とし、ゼロ円に置き換えない
  • 日・期間・月など契約で定めた単位で最低保証を計算
  • 税・端数処理、締日、訂正・取消、出力対象を確認
  • グラフから金額の内訳を確認し、明細CSVや帳票へつなげる

モックの棒グラフは施設利用料の内訳で、出店者の売上や施設の利益ではありません。CSV出力を行っても、請求済み・入金済みへ自動で変更しません。

画面イメージ:契約別に利用料を計算し、確認済み明細を集計する

この画面で判断すること
請求に使える明細と、売上や追加料金の確認を待つ明細を区別します。

システム画面のイメージはPC、タブレット、スマホ横向きでご覧ください。

この画面例を別画面で開く

売上報告と退店確認を個別に確認できます

管理対象状態の例と意味
利用審査提出待ち/確認中/追加確認/承認/否認。書類を提出しただけで承認済みにはしません。
利用予約申請/仮押さえ/確定/取消。審査の承認と、区画の確保は別です。
売上報告未提出/提出済み/修正依頼/確認済み/報告不要。金額ゼロの報告と未提出を区別します。
退店確認未報告/報告済み/是正依頼/確認済み。写真の提出後に運営者の確認を行います。
利用料未計算/確認待ち/確定/請求済み。CSV出力や資料の閲覧だけで請求済みにはしません。

歩合利用料は、契約方式を区別して計算します

説明用に、歩合対象売上80,000円、歩合率10%、固定料または最低保証5,000円とした例です。税計算前の金額を示しています。

固定料+歩合5,000円+8,000円=13,000円
最低保証付き歩合5,000円と8,000円の高い方=8,000円

歩合対象売上の税込・税抜、返品、値引き、決済手数料、端数、最低保証を計算する日・期間・月の単位を決めます。契約の変更は適用日と履歴を残し、過去の利用料に新しい条件を自動適用しません。

出店者と担当者で、必要な情報だけを表示します

出店者

自社の申請、契約条件、利用日、売上・退店報告と、運営者からの確認依頼。

施設・現場担当者

担当施設の当日予定、設備・鍵、清掃・返却、次の受入に必要な確認事項。

審査・料金担当者

担当する申請資料、審査、契約・売上、利用料の確認・確定と操作履歴。

提出書類と鍵の情報は、閲覧する担当者・期間を限定します。利用停止・契約終了時のアクセス停止、保存期間、削除方法も対象にします。

記録と、人による判断を区別します。

施設の利用承認は、行政上の許可取得や衛生上の安全を保証するものではありません。写真は現場確認の資料として扱い、備品の破損も原因・契約条件を確認して追加対応を決めます。通信・外部連携の結果が不明なら、完了と表示せず確認を残します。

報告の回収から始める構成も、予約から一式で扱う構成も選べます

最初に作る範囲の候補

  • 出店者・施設・利用日の一覧
  • 売上報告と未提出の確認
  • 箇所別の清掃写真・鍵返却
  • 運営者の確認・再提出依頼
  • 契約条件に合わせた利用料明細

必要に応じて追加する範囲

  • 利用申請・資料・審査履歴
  • 区画・設備・保管場所の割当
  • 仮押さえ・予約確定・変更・取消
  • POS・会計・決済・鍵サービスとの連携
  • 施設別集計、帳票、確認期限の通知

既存予約を継続する場合は、どの方法で利用情報を受け取るかを最初に確認します。

ご相談時に確認したい内容

  • 施設数・区画数・月間利用件数と、食品・物販等の用途
  • 現在の利用申請書、審査で確認する資料、利用規約
  • 固定料・歩合・最低保証、報告期限、締日と請求方法
  • 冷蔵庫・設備・備品・鍵の割当と返却方法
  • 清掃写真の必要箇所、点検担当、再清掃の依頼方法
  • 既存予約サービスの名称と、予約機能も開発するかどうか
  • 出店者・現場・審査・料金担当の閲覧範囲と写真の保存期間

利用申請書やExcel、現在のLINE・メールでの案内があれば参考にできます。まだ機能が決まっていなくても、負担になっている確認作業から画面と対象範囲を検討します。

共通する機能は、予約受付・日程調整管理システム、申請・承認ワークフローシステム、顧客・会員向けマイページシステムの例もご覧いただけます。

シェアキッチン・短期出店スペースの管理システムについてよくある質問

この業務で確認しておきたい点と、個別開発の進め方・費用・保守についてまとめています。

Q.既存の予約サービスやLINEを使い続けられますか?

使い続ける構成と、予約機能も含めて開発する構成の両方を検討できます。既存予約を継続する場合は予約番号と利用申請を関連付け、申請審査・売上・退店確認など必要な業務を追加します。LINE等への通知や自動取込は、サービスの仕様・利用条件・費用を確認して対象を決めます。

Q.予約機能も一緒に作る場合、どこまで管理できますか?

仮押さえ、利用条件への同意、支払条件の確認、区画・設備の確保、確定、変更・取消までを対象にできます。予約を確定するシステムを一つに決め、同時申込の競合や期限切れの処理を設計します。外部決済やスマートロックは接続先ごとに連携範囲を確認します。

Q.固定料金だけの施設や、売上報告が不要な契約でも使えますか?

使えます。固定料金だけでも、利用申請、設備割当、鍵返却、清掃写真の確認を対象にできます。売上を確認する契約は報告を求め、不要な契約は「報告不要」と表示して未提出と区別します。

Q.固定料と歩合の合算、最低保証付き歩合の両方に対応できますか?

契約条件に合わせて計算できます。固定料と歩合を足す方式と、最低保証額と歩合額の高い方を採用する方式は別です。歩合対象売上、税・返品・値引き・決済手数料、端数、日・期間・月などの計算単位を確認して実装します。

Q.曜日固定や複数日にわたる出店も管理できますか?

出店契約と各日の利用記録を分ける構成にできます。基本資料や料金条件を参照しながら、日ごとの売上・退店・鍵返却を記録します。特定日だけの休止、日をまたぐ保管、最終日の一括撤去なども施設の運用に合わせます。

Q.食品と物販で申請フォームを変えられますか?

変えられます。食品では製造・販売内容や使用設備、施設が求める資料を、物販では商材・什器・電源・看板・搬入撤去を確認するなど、用途に応じた項目を表示します。必要のない食品関連の質問を物販出店者へ一律に求めません。

Q.売上がゼロの日や、後日返品があった場合はどうしますか?

売上ゼロは0円の報告として受け付けます。未提出は金額が未確認の状態です。後日返品は元の利用日、返金額、訂正理由を関連付け、締め前後でどう再計算・調整するかを決めます。確定済みの明細を履歴なしで書き換えません。

Q.売上を集計できていなくても退店報告できますか?

できます。売上報告と退店確認は別の状態で管理し、清掃・鍵返却の報告を先に提出できます。売上の未提出だけを理由に実際の退店を止めたり、退店済みの記録を残せなくしたりしない構成です。

Q.清掃写真が不足している場合や再清掃にも対応できますか?

確認する箇所と不足内容を指定し、再提出や再清掃を依頼する構成にできます。提出された写真・メモ、依頼内容、期限、担当者の確認を履歴に残します。提出済みと清掃確認済みは別に扱います。

Q.利用審査や、食品営業の許可を自動で判断しますか?

システムは、行政上の許可・届出の要否、営業可否、食品の安全性を判断・保証しません。施設内の利用審査に必要な申請内容、提出資料、担当者の確認結果を記録する構成です。許認可や衛生上の判断は、事業者が管轄窓口や専門家へ確認して行います。

Q.出店者に他社の売上や提出書類が見えませんか?

出店者には自社の申請・利用・報告だけを表示する設計にします。現場担当者は担当施設の当日情報、料金担当者は売上・契約明細など、業務上必要な範囲を設定します。書類や鍵情報には個別の閲覧条件と保存期間を設けます。

Q.スマートロックやPOS、会計ソフトとも連携できますか?

連携先のAPI・出力形式・契約条件を確認して検討します。予約変更と鍵の有効時間、POSの売上定義、会計への出力項目など、接続するだけでは決まらない業務条件も確認します。結果が取得できない場合は未確認として担当者へ伝える構成にします。

Q.仕様が未定でも、画面例にない業務や一部分だけの開発を相談できますか?

はい。掲載画面は一例です。受付や進捗確認など、必要な部分から開発できます。現在の管理方法とお困りごとを伺い、画面構成をご提案します。初回相談と概略の構成案のご提案は無料です。Excelや帳票があれば参考にしますが、資料がなくてもご相談いただけます。

Q.既存システムとの併用やデータ移行、公開後の機能追加はできますか?

可能です。基幹システム、CRM、Excel、共有フォルダを残し、不足する機能を追加できます。正式なデータの保存先と更新担当・時点を決め、自動連携はAPIや出力機能を確認します。移行は項目の対応、重複・欠損、添付ファイルの状態を調べてお見積もりし、対象を限定する場合があります。公開後の機能追加にも対応できます。

Q.個人情報や社外秘情報を扱う場合、何を確認しますか?

認証、閲覧・更新権限、操作履歴、通信の暗号化、バックアップ、保存期間・削除方法、退職・契約終了時の利用停止を確認します。扱う情報、利用者、社外公開の有無、社内規程、サーバー環境に応じ、必要な対策と運用担当を設計時に決めます。

Q.画面例の全機能が表示価格に含まれますか?複数シーンの費用は合計ですか?

表示価格は「対象範囲例」を中心とした目安で、画面内の全ボタン・集計・通知・外部連携を含む価格ではありません。画面、項目、利用者、権限、通知、履歴などの対象範囲を見積書に記載します。複数シーンは共用機能と追加設計を確認し、初期開発費・月額保守費を算定するため、単純な合計にはなりません。

Q.表示価格は税込ですか?サーバーや外部サービスの費用も含みますか?

表示価格はすべて税別です。サーバー費用、外部API、ファイル保存、メール配信などの利用料は一律に含めていません。必要な費用を初期開発費・月額保守費と分け、正式なお見積もりで消費税を含む合計額をご案内します。

Q.月額保守には何が含まれますか?

不具合の調査・修正、軽微な表示調整、利用環境・外部仕様の変更に伴う確認、運用相談などが対象例です。監視、バックアップ、セキュリティ更新、対応時間は構築先と重要度によって異なり、見積書・保守契約に範囲を明記します。画面や機能の追加は個別にお見積もりします。

Q.月額保守は必須ですか?未契約でもスポット対応できますか?

必須ではありません。未契約でも調査・修正・機能追加を依頼ごとにお見積もりできます。ただし、優先対応、定期確認、対応時間の確保は月額契約と異なり、即時対応を保証するものではありません。扱う情報と業務への影響に応じて選べます。

Q.現在の自社サーバーや会社ドメインを使えますか?

原則として、現在の会社ドメインまたはサブドメインのサーバー内に構築します。PHP・データベース、容量、SSL、バックアップ、外部通信の制限などはこちらで事前確認するため、専門的な仕様を調べてから相談する必要はありません。安定運用が難しい環境では、必要条件と代替案をご案内します。

シェアキッチン・短期出店スペースの利用審査・売上報告・退店確認について相談したい方へ

「売上報告の催促と利用料の計算をまとめたい」「清掃写真や鍵返却を利用日ごとに確認したい」「予約サービスを残して出店者審査を追加したい」といった段階でもご相談いただけます。現在の利用申請、契約条件、予約・報告の方法を伺い、必要な画面と開発範囲をご提案します。

お問い合わせ

相談前に何を伝えればよいか迷っている方へ 専門用語や資料の準備は不要です。相談時にお聞きする内容を先に確認できます。
相談前に伝える内容を見る

業務・機能別に見るWebシステム開発例

受付、予約、顧客・案件管理、申請・承認など、必要な業務や機能に近いWebシステムの開発例をご紹介します。

TOPへ