ロケットナウの損失補償とは？対象条件・申請・精算日を店舗向けに解説

ロケットナウで注文キャンセルや再注文が起きても、すべてが店舗への損失補償対象になるとは限りません。店舗の帰責事由、調理開始状況、再販可能性、申請時期などで扱いが変わります。本記事では公式ポリシーを基に、証拠保存から申請、精算確認までを実務順に整理します。

損失補償の対象になる考え方

公式ポリシーでは、店舗の帰責事由によらない理由で顧客への返金または再注文処理が行われ、ロケットナウから店舗へキャンセル・再注文の精算を行う場合が示されています。

ただし内部基準による例外があり、個別注文の補償を第三者が保証することはできません。管理画面の判定と公式連絡を確認します。

対象外になり得るケース

公式案内では、調理開始前、再販可能、再調理が不要な完成品などは対象から除外される旨があります。店舗都合の欠品、誤商品、品質不良なども帰責判断へ影響する可能性があります。

「キャンセルされたから補償」と一律に処理せず、キャンセル時点、商品の状態、再販可否、原因、連絡履歴を注文単位で残します。

キャンセル発生時の初動

注文番号、受付時刻、調理開始時刻、完成時刻、配達員受け渡し時刻、キャンセル表示時刻を記録します。商品状態や梱包済みであることが分かる写真も必要に応じて保存します。

現場担当者が口頭で記憶するだけでは、後日の確認で情報が欠けます。店舗の共有表へ当日中に記録し、個人情報は必要以上に保存しません。

申請と追加確認への対応

公式のお知らせでは申請方法が改善され、追加確認が必要な場合は担当者から連絡され、結果案内に時間がかかる場合があると説明されています。最新のポータル画面に従って申請します。

申請日、対象注文、理由、添付資料、受付状態を一覧にします。連絡へ回答できず審査が止まらないよう、店舗メールと担当者を決めます。

精算スケジュールの確認

公式ポリシーには週次・月次の一般精算と、損失補償の受付日別スケジュールが示されています。精算支給日が休日の場合は翌営業日となる案内もあります。

売上精算と損失補償は同じタイミングとは限りません。申請日ではなく承認日や対象期間を確認し、ポータルの損失補償管理と銀行着金を照合します。

補償額と会計処理

公式案内では、店舗帰責でないキャンセル・再注文の精算を正常に精算される金額を基準として扱う説明があります。ただしVAT対象外等の記載もあるため、会計区分は資料と専門家へ確認します。

注文売上、キャンセル、補償を同じ売上としてまとめると差額原因が分かりません。注文番号でひも付け、売上・控除・補償を分けて保存します。

損失を減らす店舗運用

補償申請だけでなく、欠品、商品不足、包装不良、調理遅延、受け渡しミスを分類します。店舗起因のキャンセルを減らす方が、申請工数と低評価を抑えられます。

週次でキャンセル件数、補償申請件数、承認件数、対象外理由、損失額を確認し、再発の多い工程を改善します。

注文発生から証拠保存までの流れ

注文を受けた時点で注文番号と受付時刻を確認し、調理開始・完成・受け渡しを店舗の注文票へ記録します。キャンセル表示が出たら理由と時刻を追加し、完成品がある場合は商品状態が分かる写真を必要な範囲で残します。

写真には顧客の住所や電話番号を不要に写さず、保存先と保管期間を店舗ルールで決めます。申請のために必要な情報と、保持すべきでない個人情報を分けることが大切です。

対象外判定から学ぶ

対象外になった場合は、単に納得できないで終えず、理由を調理開始前、再販可能、店舗帰責、資料不足、期限、その他に分類します。同じ理由が続くなら、受付・調理開始の記録方法や欠品管理を直します。

公式判定に不明点があれば注文番号と根拠をそろえて問い合わせます。ただし第三者サイトの説明を根拠に補償を要求せず、自店舗の契約と公式ポリシーを基準にします。

多店舗での管理方法

本部は店舗別に申請件数、承認件数、対象外件数、補償額、未処理日数を一覧化します。件数が多い店舗は配達事情だけでなく、欠品、誤商品、調理遅延、受け渡し確認を現場で点検します。

店舗から本部へ申請を任せる場合、当日の状況が失われないよう24時間以内の報告様式を決めます。本部は精算確認まで担当し、店舗へ結果と再発防止策を返します。

月次監査の方法

月末にキャンセル一覧、損失補償管理、精算履歴、銀行着金を照合します。申請中、承認、対象外、精算済みを分け、未処理を翌月へ持ち越す場合は担当者と確認日を設定します。

補償額だけでなく、廃棄原価、再調理、人件費、低評価も損失として見ます。補償申請で一部回収できても、同じ事故が続けば店舗利益と顧客体験は改善しません。

補償確認の起点は注文記録

補償の対象可否を考える前に、注文番号、受付、調理開始、完成、受け渡し、キャンセルの各時刻をそろえます。表示理由、商品状態、再販可能性、店舗と配達員の連絡履歴も確認します。記憶だけで申請すると、必要な条件を後から証明できません。

記録は注文発生時から行い、問題が起きた注文だけ急いで作らない運用にします。注文票や店内端末で時刻を残し、完成品写真が必要な場合も顧客住所や電話番号を不要に写さないよう、保存範囲と保管期限を決めます。

申請前に原因を切り分ける

キャンセル理由を、顧客都合、配達事情、店舗都合、システム表示、原因未確定に分けます。店舗都合はさらに欠品、受付遅れ、調理遅延、誤商品、受け渡し不備へ分けます。原因が違えば、補償確認と再発防止の担当も変わります。

調理済み、配達員到着済みといった一条件だけで対象と断定しません。公式ポリシー、申請画面、契約条件を確認し、事実と店舗の推測を分けて入力します。不明点は注文番号と確認済み事項をそろえて公式窓口へ照会します。

承認から入金まで追跡する

申請日、受付状態、追加確認、承認または対象外の結果、承認額、精算予定を記録します。承認通知があっても、その時点で銀行へ着金したとは限りません。損失補償管理、精算履歴、銀行明細を同じ店舗・期間で照合します。

週次精算と月次精算では確認する日付が異なる場合があります。受付日や銀行営業日の条件を公式案内で確認し、通常売上と補償額を分けます。差額が残る場合は、合計だけでなく注文番号単位で問い合わせます。

対象外になったときの改善

対象外理由を、申請期限、資料不足、調理前、再販可能、店舗帰責、条件外、その他へ分類します。対象外を申請担当者の失敗だけにせず、注文時刻を記録できない、欠品更新が遅いなど店舗工程の問題も確認します。

同じ理由が月に複数回続くなら、受付担当、調理担当、受渡担当のどこで情報が抜けるかを点検します。補償額を増やすことより、キャンセルそのものと廃棄を減らすことを優先してください。

多店舗の補償管理

店舗ごとに注文数、キャンセル数、申請数、承認数、対象外数、補償額、未処理日数を並べます。注文規模が違う店舗は件数だけでなく注文当たり比率で比較し、異常値がある店舗の欠品、調理時間、梱包、受渡しを現地確認します。

本部申請の場合は、店舗が当日中に注文番号、時刻、理由、商品状態を報告できる様式を用意します。本部は申請結果と精算確認を店舗へ返し、改善担当と期限を決めます。未処理案件を翌月へ放置しない締め日も必要です。

損失全体を数値化する

補償の承認額だけでなく、廃棄原価、再調理、追加人件費、返金対応、低評価、再注文低下を分けて記録します。補償で商品代の一部が戻っても、同じトラブルが続けば店舗利益と顧客体験は改善していません。

月次ではキャンセル率、店舗起因率、申請率、承認率、平均処理日数、再発率を確認します。数字が悪化した一工程だけを直し、翌月に同じ定義で比較します。補償制度を利益源として扱わず、事故後の限定的な回収手段として管理します。

ケース別の損失補償対応

調理完了後にキャンセルされた

注文番号、調理開始・完成時刻、商品状態、キャンセル理由を保存し、最新の申請画面で対象可否を確認します。調理済みという事実だけで補償を断定せず、公式の個別判定を待ちます。

対象外と表示された

表示理由と申請資料を確認し、調理開始前、再販可能、店舗帰責、期限、資料不足に分類します。不明点が残る場合は注文番号と確認済み事項をそろえて公式サポートへ照会します。

補償承認後も入金が見つからない

承認日、精算区分、支給予定、精算履歴の損失補償欄を確認します。通常売上と同日に入るとは限らないため、対象期間と銀行営業日をそろえて照合します。

キャンセルが同じ店舗で多い

配達事情だけでなく、欠品、調理遅延、誤商品、包装、受け渡し確認を監査します。補償件数を減らすより先に、顧客トラブル自体を減らす工程改善を決めます。

店舗・配達員が使える確認チェックリスト

実務監査シート

次の10項目は、確認済みかどうかだけでなく、根拠資料と完了基準まで残すための監査項目です。担当者名と確認日を付け、条件変更時に再確認してください。

1. 注文番号を保存した

確認資料：注文番号と受付、調理開始、完成、受け渡し、キャンセル時刻を保存する。画面や資料の取得日を残し、口頭確認だけで完了にしません。

見落としやすい点：問題発生後に記憶で時系列を作り、事実関係が曖昧になる。数値が合っていても、対象店舗・期間・契約主体が違えば比較は成立しません。

完了基準：注文ごとの時系列を画面・注文票など確認可能な記録で示せる。未確認事項が残る場合は推測で埋めず、担当者と確認期限を決めます。

2. 受付・調理・完成時刻を記録した

確認資料：キャンセル理由を顧客、配達、店舗、システム、未確定へ分類する。画面や資料の取得日を残し、口頭確認だけで完了にしません。

見落としやすい点：表示文だけで原因を断定し、誤った窓口や改善へ進む。数値が合っていても、対象店舗・期間・契約主体が違えば比較は成立しません。

完了基準：事実と推測が分かれ、補償確認と再発防止の担当が決まっている。未確認事項が残る場合は推測で埋めず、担当者と確認期限を決めます。

3. キャンセル理由を確認した

確認資料：完成品の状態と再販可能性を必要な範囲で記録する。画面や資料の取得日を残し、口頭確認だけで完了にしません。

見落としやすい点：顧客の住所や電話番号まで不要に撮影・長期保存する。数値が合っていても、対象店舗・期間・契約主体が違えば比較は成立しません。

完了基準：申請に必要な証拠だけを安全な保存先へ期限付きで保管している。未確認事項が残る場合は推測で埋めず、担当者と確認期限を決めます。

4. 商品の状態を記録した

確認資料：公式ポリシー、申請画面、契約条件の確認日を記録する。画面や資料の取得日を残し、口頭確認だけで完了にしません。

見落としやすい点：第三者の記事や過去の体験談だけで対象可否を断定する。数値が合っていても、対象店舗・期間・契約主体が違えば比較は成立しません。

完了基準：最新の一次情報と個別判定を基準に申請内容を説明できる。未確認事項が残る場合は推測で埋めず、担当者と確認期限を決めます。

5. 店舗起因か確認した

確認資料：申請日、追加確認、承認・対象外、金額、精算予定を管理する。画面や資料の取得日を残し、口頭確認だけで完了にしません。

見落としやすい点：申請した時点で処理完了とし、追加確認や入金を追わない。数値が合っていても、対象店舗・期間・契約主体が違えば比較は成立しません。

完了基準：未処理日数と次回確認日が分かり、担当不在でも追跡できる。未確認事項が残る場合は推測で埋めず、担当者と確認期限を決めます。

6. 申請日を記録した

確認資料：損失補償管理、精算履歴、銀行着金を同じ期間で照合する。画面や資料の取得日を残し、口頭確認だけで完了にしません。

見落としやすい点：承認額を通常売上に混ぜ、未着金を見落とす。数値が合っていても、対象店舗・期間・契約主体が違えば比較は成立しません。

完了基準：注文番号単位で承認から着金まで一連の証跡がつながっている。未確認事項が残る場合は推測で埋めず、担当者と確認期限を決めます。

7. 追加確認へ回答した

確認資料：対象外理由を期限、資料、調理前、再販、店舗帰責等へ分類する。画面や資料の取得日を残し、口頭確認だけで完了にしません。

見落としやすい点：対象外を制度の問題だけにし、店舗工程の欠陥を直さない。数値が合っていても、対象店舗・期間・契約主体が違えば比較は成立しません。

完了基準：同じ対象外理由の再発を受付・調理・受渡工程の修正で減らせる。未確認事項が残る場合は推測で埋めず、担当者と確認期限を決めます。

8. 承認結果を保存した

確認資料：店舗別に申請率、承認率、処理日数、補償額を注文数比で比較する。画面や資料の取得日を残し、口頭確認だけで完了にしません。

見落としやすい点：件数だけで規模の大きい店舗を問題店と判断する。数値が合っていても、対象店舗・期間・契約主体が違えば比較は成立しません。

完了基準：比率と実数を併記し、異常店舗を現場確認へつなげられる。未確認事項が残る場合は推測で埋めず、担当者と確認期限を決めます。

9. 精算明細と着金を照合した

確認資料：廃棄原価、再調理、人件費、返金対応、低評価も損失へ記録する。画面や資料の取得日を残し、口頭確認だけで完了にしません。

見落としやすい点：補償額だけを回収成果とし、事故全体の損失を見ない。数値が合っていても、対象店舗・期間・契約主体が違えば比較は成立しません。

完了基準：補償後にも残る損失と顧客影響を含めて改善優先度を決められる。未確認事項が残る場合は推測で埋めず、担当者と確認期限を決めます。

10. 再発防止策を決めた

確認資料：月末に申請中、承認、対象外、精算済みを締める。画面や資料の取得日を残し、口頭確認だけで完了にしません。

見落としやすい点：未処理案件を担当者の受信箱へ残したまま翌月へ進む。数値が合っていても、対象店舗・期間・契約主体が違えば比較は成立しません。

完了基準：持越案件の担当、問い合わせ番号、次回期限が月次表に記載されている。未確認事項が残る場合は推測で埋めず、担当者と確認期限を決めます。

公式情報の更新を追う方法

損失補償管理では、公開日の新しさだけでなく、現在のアプリ・管理画面・契約書と説明が一致するかを確認します。特に「補償対象、申請期限、必要資料、判定手順、週次・月次の精算条件」は更新の影響を受けやすい項目です。公式ページを一度読んで終わりにせず、実行日、月次締め、問い合わせ前の三つの時点で確認してください。

根拠として保存するのは「注文時系列、申請画面、判定結果、精算履歴、銀行明細、再発防止記録」です。スクリーンショットには取得日と対象店舗・期間を付け、URLだけでなく該当箇所が分かる形にします。公式情報と画面表示が異なるときは、どちらかを都合よく採用せず、公式サポートへ対象条件を示して確認します。第三者記事は論点整理には使えますが、最終判断は一次情報と個別契約を優先します。

更新を見つけたら、変更前の条件、変更後の条件、対象範囲、店舗または本人への影響、対応期限を一行ずつ記録します。過去記事の数字を現在も有効と見なさず、未確認は「要確認」と表示します。この記事も2026年9月28日時点の確認内容であり、将来の条件を保証するものではありません。

90日で運用を定着させる

最初の30日は現状把握です。注文時系列、申請画面、判定結果、精算履歴、銀行明細、再発防止記録を集め、担当者ごとに取得方法と保存先を統一します。この期間は成果を急いで断定せず、対象条件、通常時の基準値、例外日を整理します。数値が取れない項目は無理に推定せず、次月から取得できる手順を先に作ります。

31日目から60日目は、一つの課題へ一つの変更を行います。キャンセル率、申請率、承認率、平均処理日数、未着金件数、同一原因の再発率を同じ期間・定義で比較し、変更前後の差を確認します。複数の変更を同時に行った場合は因果を断定せず、結果を参考値として扱います。担当者は「実施した」ではなく、根拠資料、結果、次の判断まで記録します。

61日目から90日目は標準化です。店舗責任者、本部運用担当、経理担当、問い合わせ担当の役割を明文化し、確認頻度、異常値の基準、問い合わせ手順、月次締めを定めます。好結果だけでなく失敗条件も手順書へ残し、担当交代後も同じ方法で判断できる状態を完成とします。90日後は施策継続そのものではなく、利益・安全・顧客体験に基づき継続、縮小、停止を選びます。

KPIを混同しないための定義

主な確認指標は「キャンセル率、申請率、承認率、平均処理日数、未着金件数、同一原因の再発率」です。これらは同じ意味ではありません。表示や案件提示は機会、クリックや受諾は反応、注文・配達完了は成果、売上・報酬は総額、利益・手残りは費用控除後の結果です。上流指標が増えても、最終的な利益や安全が悪化していれば成功とは判断できません。

各KPIには対象期間、店舗または契約主体、集計単位、税込・税別、確定・速報を付けます。割合には必ず分子と分母を残し、前月比には両月の実数を併記します。小さな母数で率だけが大きく動いた場合は断定を避け、追加期間を見ます。

週次は異常の発見、月次は採算と精算、90日単位は継続判断に使います。担当は店舗責任者、本部運用担当、経理担当、問い合わせ担当です。問い合わせ件数と解決件数、申請と承認、売上と入金、報酬と手残りなどを混ぜず、読者や社内の第三者が同じ結論へ到達できる記録を残してください。

月次会議で結論を出す手順

会議前には、注文時系列、申請画面、判定結果、精算履歴、銀行明細、再発防止記録を対象期間と対象主体をそろえて配布します。資料を当日に初めて開くのではなく、担当者が差異と未確認事項へ印を付け、公式確認が必要な点は事前に問い合わせます。会議資料には良かった数字だけでなく、未処理、対象外、受付停止、事故など判断に不利な事実も残します。

会議では最初に前月の決定事項が実行されたかを確認し、次にキャンセル率、申請率、承認率、平均処理日数、未着金件数、同一原因の再発率を見ます。数値の変化に対して、施策が原因と言えるか、外部条件の影響か、データ不足で判断保留かを分けます。「上がった」「下がった」だけで終えず、対象件数、比較期間、変更内容を読み上げられる状態にします。

最終結論は、継続、拡大、修正、縮小、停止、判断保留の六つから選びます。各結論へ根拠、実行担当、期限、次回判定指標を付けます。店舗責任者、本部運用担当、経理担当、問い合わせ担当の間で責任範囲を分け、公式確認待ちの項目は暫定対応と確定後の対応を別にします。これにより、損失補償管理を慣習ではなく記録に基づいて改善できます。

よくある質問

まとめ

損失補償は、店舗の責任ではない理由で返金・再注文が行われた場合などに、条件を満たせば店舗へ精算される仕組みです。注文番号、調理状況、キャンセル理由を記録し、ポータルの損失補償管理から対象と結果を確認します。

画面、料金、対象条件は変更される可能性があります。この記事は2026年9月28日に公式情報を確認して作成しています。実行時は必ずアプリ、管理画面、契約書、公式サポートの最新案内を優先してください。

参考にした公式情報

関連するロケットナウ記事