まずは卸売ECを小規模でスタートしたい方へ。リーズナブルなSaaS(ASP)版『EC-Rider Primo(プリモ)』誕生! 詳しくはこちら

LINE受発注で「スタンプ=了解」の誤認を防ぐ:確定の決め方と、受発注の仕組みへ移す判断基準

◆監修・編集責任者 小園 将隆 

B2B EC-COLUMN

この記事のポイント

  • スタンプが「了解」と受け取られる食い違いは、どの返信で注文を確定とするかが取引先と決まっていないことから起きる。確定は定型文で伝え、スタンプは受け取りの合図と文面で合意する。
  • LINE公式アカウントの無料範囲は保存が半年、タグが1個まで。チャットProで5年・最大30個に広がるが、同じ取引先の複数注文の状態を見分ける作業は残る。
  • LINE公式アカウントのトークでは送信取消が使えないため、変更や取消は変更後の全内容を新しい文面で出し、どちらを有効とするかを決めておく。
  • 履歴の遡り、確定・変更・欠品の状態管理、取引先ごとの締め時刻、電話・FAX・LINEの混在と転記が問題になったら、受発注の仕組みへ移す時期である。
  • 切り替えは数社で試し、飲食店の入力をLINEのまま残せるかを最初に確かめ、食い違い件数と転記時間を切り替え前と比べる。

30代後半の日本人男性が移動中のスマートフォン確認をしている場面

LINEの返信が「了解」と受け取られる食い違いは、注文が成立する時点を決めていないことから起きる

飲食店から閉店後に届いたLINEの注文に、翌朝の仕分けの合間にスタンプだけを返す。
受注側は「見ました」のつもりでも、飲食店は「受けてもらえた」と受け取ります。
その結果、納品の朝に数量や日付がずれる。
この食い違いの多くは、LINEのどの返信で注文を確定とするかを、取引先と決めていないことから起きます。
契約は申込みと承諾で成立し、書面は要りません4。
そのため、確定の返信文・締め時刻・変更の出し方を文面で合意すれば、運用ルールで防げる誤認は少なくありません。
ただし、LINE公式アカウントの無料範囲は、保存が半年、タグが1個までです1。
履歴や注文の状態を追い切れなくなったら、受発注の仕組みへ移す時期です。

食い違いが起きる典型の場面

たとえば、飲食店の担当者が閉店後にLINEで「明日、鶏もも5kg、キャベツ2ケース」と送ったとします。
受注側の担当者は翌朝の仕分けの合間にそれを開き、手が離せないのでOKのスタンプだけを返しました。
受注側にとって、そのスタンプは「見ました、在庫を確かめてから返事します」という意味です。
ところが飲食店の担当者は「受けてもらえた」と受け取り、ほかの仕入先には頼みません。
昼前になって、キャベツが1ケースしかないと連絡が入ります。
これではランチの仕込みに間に合いません。

逆向きの食い違いもあります。
受注側が「キャベツは1ケースのみですが、残りは明後日の納品でよいですか」と送り、飲食店がスタンプで返したとします。
受注側は、明後日の分納で了承されたものとして処理します。
一方、飲食店は「読んだ」としか思っていません。
このとき、どちらの担当者も手順を怠けたわけではありません。

二つの場面に共通する原因は、返信の言葉づかいの粗さではありません。
どの返信をもって注文を確定とするかが、取引先との間で決まっていないことです。
既読やスタンプが注文の確定や内容の承認を意味するという定めは、LINE公式アカウントのチャットのマニュアルでは確認できません1。
機能の側から確定の意味を読み取ることはできません。
そのため、意味は当事者どうしで決める必要があります。

契約は申込みと承諾で成り立つという原則

では、注文はいつ成立するのでしょうか。
民法は、契約は申込みに対して相手方が承諾をしたときに成立する、と定めています4。
法令に特別の定めがある場合を除けば、書面の作成などの方式は要りません4。
飲食店のLINEの注文を申込みとすれば、受注側の返信は承諾として受け取られる余地があります。
注文書や受注確認書がなくても取引が成り立つのは、この原則があるからです。

裏を返すと、書面が要らないぶん、どの言葉が承諾にあたるかの線引きは、やり取りの中身に委ねられます。
スタンプ一つや「了解です」の一言が承諾と見られるかどうかは、それまでの取引の仕方や前後のやり取りによって変わります。
ここで一律に答えられるものではありません。
個別の案件で判断が必要になったときは、法律の専門家に相談するのが確実です。

取引先と取引基本契約を結んでいる場合は、そちらを先に確認します。
たとえば契約書に「受注確認の通知をもって個別契約が成立する」といった定めがあれば、LINEの運用もその定めに合わせて組み立てます。
定めがなければ、民法の原則の上で、当事者どうしで確定の合図を決めておく意味が大きくなります。

確定の合図を文面で決める

確定の合図は、口頭の申し合わせで済ませず、LINEの文面で取引先と共有しておくと、後から確かめられます。
決めておきたいのは、確定を伝える文面の形と、それ以外の返信の意味の二つです。

たとえば次のように取り決めます。
受注側が「【受注確定】」で始まり、納品日・品目・数量を書いた文面を送った時点で、注文は確定とする。
スタンプや「見ました」「確認します」は受け取りの合図であり、確定ではない。
確定文が届くまでの間、飲食店は注文をまだ確認中のものとして扱う。

この取り決めは、受注側を守るためだけのものではありません。
飲食店の担当者にとっても、確定文が来ていなければ別の仕入先を検討する目安になります。
欠品が分かってから慌てる場面も減らせます。
取り決めの文面を各取引先のトークに一度送り、了承の返事をもらっておけば、その返事自体が合意の記録になります。
ただし、この記録も後から探し出せなければ役に立ちません。

確定の合図を決めていないと、同じスタンプが受注側と飲食店で別の意味になる(模式図)
飲食店の注文に受注側がスタンプで返し、受注側は確認中、飲食店は確定と受け取るため、数量や納品日のずれにつながる流れの図
▼ 図の内容を文字で読む
  1. 飲食店の注文
    • 数量・納品日をLINEで送る
  2. 受注側のスタンプ
    • 受注側の意図:見ました、確認中
    • 飲食店の受け取り:受けてもらえた
  3. 確定の合図が未合意
    • どの返信で注文を確定とするかが決まっていない
  4. 納品の朝のずれ
    • 数量や日付の食い違い
    • 欠品の連絡が昼前になる

LINE公式アカウントのチャットで記録・管理できる範囲と限界

保存期間は無料範囲で半年、チャットProで5年

注文の確定文を決めても、そのやり取りが残っていなければ照合できません。
たとえば、数か月後に請求額や納品数を確かめようとした場面です。
LINE公式アカウントの保存期間は、テキストメッセージ・画像・動画・ファイルのいずれも、無料範囲で半年、チャットProオプションで5年間です1。
また、チャット履歴は2024年以降のものが対象とされています1。

無料範囲で運用している場合は、半年より前の注文のやり取りは、トークを遡っても確認できない前提で考えます。
たとえば、月末締めの請求について数か月後に数量の問い合わせを受けたときです。
季節ごとの発注量を前年と比べたいときも同じです。
こうした場面に備えるには、LINEの外に別途記録を残しておく必要があります。
飲食店から写真で受け取った手書きの発注メモも、画像として同じ保存期間で扱われます。

チャットProオプションを使えば、保存期間は5年に延びます1。
ただし、やり取りが保存されていることと、それを注文として検索・集計・出力できることは別の話です。
保存期間を延ばして解決するのは「消えてしまう」問題です。
「探すのに時間がかかる」問題は残ります。
この違いは、仕組みへ移すかどうかを判断するときに効いてきます。

タグの上限と、状態管理の限界

注文の流れを追うには、やり取りが保存されているだけでは足りません。
どの注文がいまどの状態にあるかを見分ける必要があります。
LINE公式アカウントのチャットではタグを付けて目印にできます。
追加できるタグは、無料範囲で1個まで、チャットProオプションで最大30個までです1。

受注の現場で見分けたい状態は、「受付」「確認中」「確定」「欠品あり」「変更あり」と複数あります。
無料範囲のタグ1個では、「確認中」にだけ目印を付けて、残りはトークを読んで判断する、という使い方が限度になります。
チャットProでタグが増えれば、状態ごとに目印を分けられます。
それでも、同じ取引先が同じ日に朝の分と夕方の分を別々に注文してきた場合はどうでしょうか。
どちらが確定済みで、どちらが欠品連絡待ちかは、トークを読み返して確かめることになります。

マニュアルが示しているのは、タグの数の上限です。
注文1件ずつに数量や納品日と結び付いた状態を持たせる使い方までは前提にしていない、というのが編集部の見方です。
タグはやり取りの目印として使い、注文の状態は確定文の書き方で補う、という役割分担になります。

手動チャットと応答メッセージの切り替え

夜間や休業日に届く注文への返し方も、記録の残り方に関わります。
LINE公式アカウントでは、応答時間外は応答メッセージで対応できます1。
担当者が手動で返す手動チャットは、一時的なものは1時間で自動終了し、延長すれば最長7日まで続けられます1。

このしくみは、受付と確定を分けて伝えるのに使えます。
夜間の注文には、応答メッセージで「ご注文を受け付けました(確定は翌朝、【受注確定】の文面でお知らせします)」と返します。
そのうえで、担当者が在庫を確かめてから、手動で確定文を送ります。
このとき肝心なのは、応答メッセージの文面に「確定」と読める言葉を入れないことです。
自動の返信が確定と受け取られるのを防ぐためです。

一方、手動チャットは放っておけば1時間で終わります1。
在庫確認や産地への問い合わせで返事に時間がかかる注文もあります。
手動チャットの終了後に飲食店からメッセージが届いたら、どの応答が返るのかを設定画面で確かめておきます。
意図しない自動返信による誤解を防ぎやすくなります。

送信取消が使えない点

個人向けのLINEには、送ったメッセージを相手の画面からも消す送信取消があります。
標準では送信後1時間以内、LYPプレミアム会員は7日以内に使えます3。
しかし、LINE公式アカウントやBot機能のあるトークルームなどでは利用できません3。
また、自分の画面からメッセージを削除しても、消えるのは自分の側だけです3。
相手の画面には残ります。

受注側が数量を打ち間違えた確定文を送ったとします。
あるいは、飲食店が桁を間違えた注文を送ったとします。
どちらの場合も間違いは消せず、新しいメッセージで訂正を重ねることになります。
トークには誤った文面と訂正の文面が並んで残るため、どちらが有効かは読み手が判断しなければなりません。
まとめると、記録は半年または5年は残ります。
一方で、注文ごとの状態や、訂正の前後関係を整理する役割は、運用ルールで補う必要があります。

観点 無料範囲 チャットProオプション
テキスト・画像・ファイルの保存期間 半年 5年
追加できるタグの上限 1個 最大30個
同じ取引先の複数注文の状態の見分け トークの読み返しが必要 目印は増えるが読み返しは残る
夜間の注文は、受付の返信と翌朝の確定文を分けて送る(模式図)
夜間に届いた注文へ応答メッセージで受付を返し、翌朝に在庫を確かめて、担当者が手動で確定文を送る順序の図1夜間に注文が届く2受付だけを伝える3翌朝に在庫を確かめる4手動で確定文を送る

▼ 図の内容を文字で読む
  1. 夜間に注文が届く
    • 応答時間外のため応答メッセージで返す
  2. 受付だけを伝える
    • 「受け付けました」と書く
    • 「確定」と読める言葉は入れない
  3. 翌朝に在庫を確かめる
    • 担当者が数量と納品日を確認する
  4. 手動で確定文を送る
    • 【受注確定】で始まる文面を返す

スタンプ禁止・復唱返信・締め時刻の表示で防げる誤認と、防げない場面

確定は定型文だけにする

一つ目の取り決めは、注文の確定を定型の確定文だけで伝えることです。
スタンプや短い返事では確定を伝えません。
スタンプそのものを禁止する必要はなく、「スタンプは受け取りの合図であって確定ではない」と意味を限定すれば足ります。
受注側に担当者が複数いる場合は、確定文の書き出しと項目の並びを全員で揃えます。
人によって「承りました」「OKです」「手配します」と表現が違うと、飲食店はどれが確定なのかを毎回推し量ることになるからです。

確定文の形は、たとえば次のようにします。
「【受注確定】6月12日納品/鶏もも 5kg/キャベツ 2ケース/変更は前日15時まで」。
書き出しを固定しておけば、後でトークを読み返すときに、確定文だけを目で拾いやすくなります。

数量・納品日・単価を復唱する

二つ目は、飲食店が送ってきた数量・納品日・単価を、確定文の中で受注側の言葉に書き直して返すことです。
「玉ねぎ10」が10kgなのか10箱なのか。
「明日」が配送便の翌日なのか、暦の翌日なのか。
復唱すれば、受注側の解釈が文面として飲食店の目に触れます。
食い違いがあれば、納品前に気付く機会ができます。
単価まで毎回書くと文面が長くなりすぎます。
相場で変わる品目や、取引先ごとに決めた単価がある品目に絞って書くとよいでしょう。

復唱すると返信の数は増えます。
ただ、LINE公式アカウントの料金プランでは、LINEチャットの送受信は課金対象外とされています2。
これは1対1のやり取りの話で、友だちへの一斉配信などのメッセージ配信の課金とは別の扱いです。
負担になるのは通数の費用ではなく、担当者が1件ずつ書き直す手間です。

締め時刻と受付可否を自動応答で示す

三つ目は、締め時刻と、時間外に届いた注文の扱いを、飲食店が送る時点で見える形にしておくことです。
たとえば、応答時間外の応答メッセージに「本日分の受付は15時で締め切りました(このご注文は明日の受付として、朝に確定文をお送りします)」と書いておきます1。
そうすれば飲食店は、送った直後に、その注文がいつ確定するのかを知ることができます。

締め時刻を過ぎた注文を、担当者が気を利かせて当日扱いにすることもあるでしょう。
それが続くと、どこまでが例外かが曖昧になります。
例外として受けるときは、確定文にそのことを書いておくと、次回の基準がぶれません。

変更・取消は新しい文面で出す

四つ目は、変更や取消を新しい文面で出すことです。
元の注文への短い返事で済ませず、変更後の全内容を書き直します。
送信取消が使えない以上、トークには元の注文、変更の連絡、訂正が順に積み重なります。
「キャベツ1ケース減で」とだけ書かれた連絡は、元の注文を見に戻らないと最終の数量が分かりません。
「【変更確定】6月12日納品/鶏もも 5kg/キャベツ 1ケース」と全体を書き直せば、最新の文面だけで納品内容が決まります。

あわせて、元の注文と変更の連絡が食い違ったときに、どちらを有効とするかも決めておきます。
たとえば「後から送った確定文を有効とする」「変更は締め時刻までに確定文が出たものに限る」といった取り決めです。
飲食店から変更を受けた場合の扱いも決めておきます。
受注側が変更確定の文面を返すまでは、変更前の内容で手配する、という決め方です。
確認中の変更がいつの間にか反映されている、という事態を避けやすくなります。

ルールで防げない場面

四つの取り決めで減らせるのは、次のような食い違いです。
返信の意味の取り違え、数量や単位の読み違い、締め後の注文の扱いの迷い、変更前後の混同。
どれも、受注側の担当者が1件ずつ確定文を書き、飲食店がそれを読むことで成り立っています。

裏返せば、その手作業が追いつかなくなると、ルールは守られなくなります。
朝の数時間に多くの取引先から注文が集中し、確定文を書く前に仕分けが始まってしまう。
担当者が休んだ日に、誰がどの注文に確定文を出したかが、トークを読み返さないと分からない。
半年より前の請求の問い合わせに、手元の記録で答えられない。
こうした場面は、文面のルールをいくら細かくしても解消しません。

ルールがどこまで効いているかは、件数で確かめられます。
たとえば1か月分の注文を抜き出し、確定文の内容と実際の納品内容が食い違った件数を数えます。
あわせて、その原因が読み違い・変更の混同・確定文の出し忘れのどれだったかも記録します。
これらの取り決めは編集部の提案で、効果は各社の注文の量や品目によって変わります。
数えてみて、出し忘れや確認の遅れなど、手作業の量から来る食い違いが残るなら、次は仕組みへ移すかどうかを考える段階です。

取り決めで減らせる食い違いと、手作業が追いつかず残る場面(編集部の提案に基づく模式図)
確定文・復唱・締め時刻の表示・変更の出し方で減らせる食い違いと、手作業が追いつかなくなると残る場面を分けて示した図確定文・復唱・締め時刻の表示・変更の出し方で減らせる食い違いと、手作業が追いつかなくなると残る場面を分けて示した図取り決めで減らせる食い違い返信の意味の取り違え数量や単位の読み違い締め後の注文の扱いの迷い変更前後の混同手作業が追いつかず残る場面朝に注文が集中し、確定文より先に仕分けが始まる担当者が休んだ日に、誰がどの注文に確定文を出したか分からない半年より前の請求の問い合わせに答えられない効き目の確かめ方1か月分の食い違い件数と原因を数える

▼ 図の内容を文字で読む
  • 取り決めで減らせる食い違い
    • 返信の意味の取り違え
    • 数量や単位の読み違い
    • 締め後の注文の扱いの迷い
    • 変更前後の混同
  • 手作業が追いつかず残る場面
    • 朝に注文が集中し、確定文より先に仕分けが始まる
    • 担当者が休んだ日に、誰がどの注文に確定文を出したか分からない
    • 半年より前の請求の問い合わせに答えられない
  • 効き目の確かめ方
    • 1か月分の食い違い件数と原因を数える

LINEのトーク運用から受発注の仕組みへ移す判断条件

履歴をどれだけ遡る必要があるか

一つ目の条件は、注文のやり取りを何か月前まで遡る必要があるかです。
LINE公式アカウントの無料範囲で残るのは半年です1。
請求の照合や返品の確認が締めから数週間で終わり、半年を超えて遡る場面がほとんどないとします。
その場合は、運用ルールのままでも記録の面では困りません。

半年を超えて遡る必要があっても、すぐに仕組みへ移すとは限りません。
保存期間だけが問題なら、チャットProオプションで5年に延ばす選択肢があります1。
判断が分かれるのは、遡る目的が「やり取りを読むこと」なのか、「注文を一覧にして数えること」なのかです。
たとえば、前年同月の発注量を品目ごとに比べたい、取引先ごとに数量の訂正が何件あったかを出したい、という使い方です。
こうした使い方は、トークを残すだけでは満たせません。

確定・変更・欠品を状態で管理したいか

二つ目は、確定・変更・欠品を、注文1件ごとの状態として持ちたいかどうかです。
取引先が少なく、1日1回まとめて注文が届くなら、トークの最新の確定文を見れば状態は分かります。
一方、同じ取引先から1日に何度も注文や追加が届き、欠品で分納になる品目もあるとします。
その場合、状態は注文と品目の単位に分かれていきます。
トークの目印に使えるタグは無料範囲で1個までなので1、こうした状態を一覧で見渡す役には立ちにくいでしょう。

状態を持ちたい理由が、担当者の交代や休みのときの引き継ぎにある場合は、なおさら仕組みの側で状態を持たせる意味があります。
トークを最初から読み返して状況をつかむ作業は、読む人によって結論が変わるおそれがあるからです。

締め時刻が取引先ごとに違うか

三つ目は、締め時刻や納品できない日が、取引先ごとに違うかどうかです。
全取引先で締め時刻が同じなら、応答メッセージで一律に示せます。
しかし、配送ルートによって締めが違ったり、取引先ごとに定休日が違って納品できない日があったりする場合もあります。
そうなると担当者は、注文が届くたびに「この店の締めは何時だったか」を思い出して判断することになります。
判断を人の記憶に頼っている状態は、担当者が替わったときに食い違いの元になります。

受発注の仕組みの中には、締め時刻を受注側で調整できるものがあります。
たとえば、インフォマートのTANOMUの公式ページには、受注側が注文締切時間を調整したり、納品不可日を指定したりできると記載されています5。
これは同サービスのページに書かれた機能です。
ほかの製品にも同じ設定があるとは限りません。

注文経路が混在して転記が起きているか

四つ目は、LINE以外の経路の注文が混ざり、転記が起きているかどうかです。
電話で受けた注文は手書きのメモに、FAXの注文は紙のまま、LINEの注文は画面の上にある。
受注側の担当者は、それらを受注台帳や販売管理の画面へ打ち直しています。
この転記の段階で数量の打ち間違いや入力漏れが起きると、どうなるでしょうか。
LINEの確定文をいくら丁寧にしても、納品内容との食い違いは残ります。

LINEの運用ルールを整えても、転記の時間が受注作業の大きな部分を占めているとします。
その場合は、ルールを足すよりも、受注を一か所に集める仕組みを検討する段階です。
TANOMUの公式ページでは、受注側が電話・FAX・LINEの受注を一括で管理できると説明されています5。
なお、取引先数や注文件数が何件を超えたら移すべきか、という一般に当てはまる数字はありません。
まず自社の1か月の注文を経路別に数え、転記にかかっている時間を把握します。
そのうえで、ここまでの四つの条件に当てはまるかを見ていくのが現実的です。

判断条件 運用ルールで足りる状況 仕組みへ移す状況
履歴を遡る範囲 照合が半年以内で終わる、またはやり取りを読めれば足りる 注文を一覧にして数えたい・前年と比べたい
確定・変更・欠品の状態 1日1回のまとめ注文で最新の確定文を見れば分かる 同じ取引先の複数注文や分納を引き継ぎたい
締め時刻・納品不可日 全取引先で同じ 取引先ごとに違い担当者の記憶で判断している
注文の経路 LINEにほぼ集まっている 電話・FAX・LINEが混在し転記が起きている
運用ルールで足りる状況と仕組みへ移す状況の分かれ目(編集部の整理・模式図)
履歴を遡る範囲、注文の状態、締め時刻と納品できない日、注文の経路の四つの条件ごとに、運用ルールで足りる状況と仕組みへ移す状況を分けた図
▼ 図の内容を文字で読む
  • 履歴をどれだけ遡る必要があるか
    • 足りる:照合が半年以内で終わる
    • 移す:注文を一覧にして数えたい
  • 確定・変更・欠品を状態で管理したいか
    • 足りる:最新の確定文を見れば状態が分かる
    • 移す:同じ取引先の複数注文や分納を引き継ぎたい
  • 締め時刻が取引先ごとに違うか
    • 足りる:全取引先で同じ
    • 移す:担当者の記憶で判断している
  • 注文経路が混在して転記が起きているか
    • 足りる:注文がLINEにほぼ集まっている
    • 移す:電話・FAX・LINEが混在し打ち直している

LINE連携の受発注ツールを選ぶときに確認する項目

注文確定の通知と変更・取消の範囲

仕組みへ移すと決めたら、次に迷うのは、どの製品なら食い違いを仕組みで防げるかです。
機能一覧に「LINE連携」とあっても、注文の確定を誰がどの操作で行い、それが飲食店にどう伝わるかは、製品ごとに違います。
運用ルールで定型の確定文が担っていた役割を、仕組みのどこが引き継ぐのか。
それを確かめることが出発点になります。

具体的には、次のことを尋ねます。
飲食店が注文を送った時点で、飲食店に何が返るのか。
受注側が確定させたときに、確定の通知が届くのか。
確定後の変更や取消をどこまで受け付け、その記録が残るのか。
TANOMUの公式ページからは、LINEで注文できることや締切時間を調整できることは読み取れますが、注文確定の手順の記載は確認できません5。
こうした項目は、導入前に提供元へ直接確認します。

履歴の保存期間と出力

先に見たとおり、保存されていることと、数えられることは別です。
仕組みの側では、次の点を確かめます。
注文履歴が何年残るのか。
品目・取引先・期間で絞り込めるのか。
CSVなどで書き出して、販売管理や請求の作業へ渡せるのか。
TANOMUの注文履歴の扱いも公式ページでは確認できないため5、同じく問い合わせの項目になります。

履歴の出力で手作業の転記が減るかどうかは、出力したデータを次にどの画面へ入れているかで決まります。
請求書の作成や在庫の引き当てを別のシステムで行っているなら、そのシステムが読み込める形で出せるかまで尋ねておきます。
導入後に転記が残る事態を避けやすくなります。

締切後の注文の扱い

締め時刻を過ぎて届いた注文の扱いも、製品によって違います。
自動で翌日の受付に回すのか、受付自体を止めるのか、受注側の判断に委ねるのか、という違いです。
運用ルールでは例外として受けていた注文が、仕組みに移った途端に受け付けられなくなるとします。
そうなると、飲食店にとっては不便が増えたことになります。
締切後の注文をどう扱いたいかを先に自社で決め、その扱いが設定できるかを確かめます。

飲食店側の費用と入力手段

最後は、飲食店側の負担です。
受注側が仕組みを入れても、飲食店に費用や新しい操作を求めれば、使ってもらえないおそれがあります。
その場合、結局はLINEや電話の注文が残ります。
TANOMUは、発注側の得意先は無料で利用でき、LINEで受け取ったチラシからLINEで注文できると説明しています5。
これは同サービスの条件であり、市場一般の水準ではありません。
受注側の利用料金や契約条件は、提供元に確認する必要があります。

提供元に尋ねる項目をまとめると、次の五つです。

  • 注文の確定を誰がどの操作で行い、飲食店へどう通知されるか
  • 確定後の変更・取消をどこまで受け付け、記録が残るか
  • 注文履歴の保存期間と、絞り込み・書き出しの形式
  • 締切後に届いた注文の扱いを設定できるか
  • 飲食店側の費用と、LINEなど従来の手段で注文できるか
40代前半の日本人男性が小売店のバックヤードでの発注をしている場面

飲食店に負担をかけず、LINEの入力を残して切り替える進め方

少数の取引先で試す

切り替えは、全取引先で一斉に始めるより、変更や追加の連絡が多い数社から試すほうが、食い違いの原因を見つけやすくなります。
変更が多い取引先ほど、確定文や変更の扱いの不備が表に出やすいからです。
試す取引先には、何が変わり、何が変わらないのかを先に伝えます。

仕組みへ移す場合、最初に確かめたいのは、飲食店側の入力をLINEのまま残せるかどうかです。
閉店後にスマートフォンから注文している担当者にとって、注文の入口が変わるのは小さくない負担です。
入口が変わらなければ、飲食店に求めるのは、確定の通知の読み方を覚えることだけで済みます。
LINEから注文できると説明している製品であっても5、自社の取引先の注文の仕方にそのまま合うかは、試行の中で確かめます。

確定の返信文を新旧で揃える

運用ルールの段階で決めた確定文の形は、仕組みに移ってからも、できるだけ同じにしておきます。
飲食店の担当者は、これまで「【受注確定】で始まる文面が来たら確定」と覚えてきました。
仕組みから届く確定の通知も、同じ書き出しと項目の並びで受け取れるのが理想です。
通知の文面を変えられない製品もあります。
その場合は、切り替えの前に、新しい通知のどこを見れば確定と分かるのかを飲食店に伝えます。
新旧で確定の合図が違うと、切り替えの直後に、再び「どれが確定か分からない」状態を自分たちで作ってしまいます。

食い違い件数と転記時間で効果を確かめる

試行の効果は、二つの数字で見ます。
一つは、確定した内容と実際の納品内容が食い違った件数です。
運用ルールの効き目を測ったときと同じ数え方をします。
もう一つは、受注側の担当者が、注文を受注台帳や販売管理へ打ち直すのにかけている時間です。
切り替え前の1か月と試行期間とで、同じ取引先について比べます。

数字が改善しない場合は、原因を確かめて、確定文や締めの設定を直し、同じ条件でもう一度試します。
問題がなければ、対象の取引先を広げます。
試行の期間や取引先の数に決まった目安はなく、この進め方も編集部の提案です。
それでも、件数と時間という同じ物差しで比べておけば、見分けがつきます。
仕組みへの移行で自社の食い違いが減ったのか、それとも作業の場所が変わっただけなのか、という見分けです。

LINEの確定ルールで足りるか、仕組みが要るかは、取引先ごとの注文経路や締め時刻、転記の量によって答えが変わります。社内だけでは線を引きにくい判断です。

いまの注文経路と食い違いが起きている場面を一緒に整理し、運用ルールで対応できる範囲と、受発注の仕組みへ移す条件のどちらに当てはまるかを確かめられます。無料相談で要件を整理する

要点の整理

軸 基準
確定の合図 定型の確定文だけを確定とし、スタンプは受け取りの合図と文面で合意する
変更・取消 変更後の全内容を新しい文面で出し、どちらを有効とするかを決めておく
記録の範囲 無料範囲は保存半年・タグ1個まで、チャットProは5年・最大30個まで
移行の判断 履歴の遡り、状態管理、取引先ごとの締め、経路の混在の4条件で見る
ツールの確認 確定の通知、変更の範囲、履歴の出力、締切後の扱い、飲食店側の費用と入力手段
切り替え 数社で試し、食い違い件数と転記時間を切り替え前と比べる
20代前半の日本人男性がトラックの運転をしている場面

製品の説明だけでは、注文確定の手順や履歴の出し方が、自社の取引先の注文の仕方に合うかを判断しにくいためです。 提供元へ尋ねる項目の整理、試行する取引先の選び方、食い違い件数と転記時間の比べ方を相談できます。

BtoB通販システムのご相談

貴社の商習慣に合わせたご提案をいたします。

無料相談はこちら

よくある質問

スタンプだけで返してしまった注文は、成立したと見られるのか。

成立したかどうかは、それまでの取引の仕方や前後のやり取りによって判断が変わり、一律には言えません。
民法では、契約は申込みと承諾で成立し、書面などの方式は原則として要りません4。
そのため、スタンプが承諾と受け取られる余地はあります。
取引基本契約に成立時点の定めがあれば、そちらが先に確認されます。
実務では、スタンプを返したと気付いた時点で、確定文か「確認中です」という文面を改めて送り、どちらの状態なのかを文面で残しておくのが確実です。

注文の確定を知らせる返信文は、どう書けばよいか。

書き出しの語を固定し、納品日・品目・数量を受注側の言葉で書き直して並べます。
相場で変わる品目や取引先ごとの単価がある品目は、単価も添えます。
最後に変更の締め時刻を書いておくと、飲食店が次に何をすればよいかまで伝わります。
たとえば「【受注確定】6月12日納品/鶏もも 5kg/キャベツ 2ケース/変更は前日15時まで」という形です。

LINE公式アカウントのチャットProを使えば、受発注の仕組みは要らないか。

チャットProオプションでは、保存期間が5年、タグが最大30個まで広がります1。
「記録が消える」「目印が足りない」という問題は小さくなります。
一方で、次のような必要がある場合は、チャットの保存とタグだけでは対応しにくくなります。
注文を一覧にして数える、同じ取引先の複数の注文を状態別に見分ける、取引先ごとの締め時刻を設定で扱う、電話やFAXの注文と一か所にまとめる、といった必要です。
こうした場合は、仕組みを検討する段階です。
どちらに当たるかは、判断条件の4項目に自社が当てはまるかで見分けます。

飲食店側に新しいアプリを入れてもらえない場合、どう切り替えるか。

飲食店側の入力をLINEのまま残せる仕組みを選ぶのが近道です。
たとえばTANOMUは、発注側がLINEで受け取ったチラシからLINEで注文でき、発注側の利用は無料と説明しています5。
ほかの製品でも同じ条件とは限らないため、導入前に提供元へ確認します。
仕組みを入れない段階でも、取り違えを減らす余地はあります。
確定文・締め時刻・変更の出し方をLINEの運用ルールとして揃えれば、飲食店の操作は変わりません。

変更や取消の連絡が、元の注文と食い違う場合、どちらを有効とするか。

どちらを有効とするかは、あらかじめ取引先と決めておくのが基本です。
たとえば「後から送った確定文を有効とする」「変更は受注側の変更確定の文面が出るまで反映しない」といった取り決めを、文面で合意しておきます。
LINE公式アカウントのトークでは送信取消が使えず3、誤った文面と訂正が並んで残ります。
変更のたびに全内容を書き直した文面を出しておけば、最新の内容を一つの文面で確かめられます。
取り決めがないまま食い違った場合の扱いは、契約の定めや個別の事情によるため、一律には決められません。

◆監修・編集責任者

小園 将隆

株式会社フライトソリューションズ ECサービス部 マネージャー

BtoB通販のパッケージシステム「EC-Rider B2B Ⅱ」の導入支援をはじめ、製造業、卸売業をはじめとした法人向け通販サイト構築を多数手掛ける。卸売領域の専門知識をもとに、日本の商習慣に固有の課題をパッケージシステムの機能追加によって解決。BtoB流通の販路拡大を支援する。

> プロフィールの詳細を見る

  1. 1 出典:LINEヤフー株式会社「LINE公式アカウント マニュアル(チャット)」(2026年)
  2. 2 出典:LINEヤフー株式会社「LINE公式アカウント 料金プラン」(2026年)
  3. 3 出典:LINEヤフー株式会社「LINEヘルプセンター:メッセージの取り消し(送信取消)と削除」(2026年)
  4. 4 出典:法務省(民法)「民法 第522条(契約の成立と方式)」(現行法)
  5. 5 出典:株式会社インフォマート「TANOMU(タノム)公式サイト」(2026年)

◆この記事について

独自調査以外の一次情報は、省庁・公的機関を中心とした信頼性の高い情報源から引用し、出典を明記しています。
年次更新される統計については、引用元の最新版を確認したうえで掲載しています。

※この記事は上記の監修・編集責任者がAIの協力を得て制作しています。

監修確認日:

記事内容に関するお問い合わせ:お問い合わせフォーム

BtoB EC(受発注)サイト構築システム「EC-Rider B2B Ⅱ」への
各種お問い合わせ

ページTOPへ戻る
無料相談を予約 お見積
平日10:00~18:00
page
top