飲食店のエクセル管理から移る｜台帳を同時に開けない問題から手を付ける

宴会と貸切の問い合わせを表計算ソフトの台帳で管理している飲食店は、いまでも多数あります。列を足せばどんな項目でも扱えて、色を付ければ状況が分かり、追加の費用もかかりません。宴会の受付という、店ごとにやり方が違う業務にはよく合っています。

それでも、ある時点から回らなくなります。回らなくなる原因は、ほぼ決まっています。台帳を同時に開けないことです。ここから、最新版が分からない、店の外から見られない、返したかどうかが残らないという問題が連鎖します。

この記事では、飲食店の宴会と貸切の受付を表計算の台帳から移すときに、どこから手を付けるかを順番に並べます。表計算そのものを否定する話ではありません。移す部分と、移さずに残す部分を分ける話です。

表計算の台帳で足りている店は、そのままでよい

移す必要がない条件

先に、移さなくてよい場合を書きます。次の三つが当てはまるなら、いまの台帳を変える理由はほとんどありません。

一つ目は、台帳を触る人が一人だけの場合です。店長が全部の宴会を受けて、店長だけが台帳を開く。この形なら、同時に開けない問題は起きません。二つ目は、宴会の件数が月に数件で、記憶で追える場合です。三つ目は、台帳を開くのが店のパソコン一台だけで、外から見る必要がない場合です。

この三つが揃っているなら、表計算は十分に強い道具です。むしろ、店ごとの独自の項目を自由に足せる点で、既製の仕組みより使い勝手が良いことがあります。

回らなくなる分かれ目

回らなくなるのは、この三つのどれかが崩れたときです。宴会の担当が二人になった、月の件数が増えた、店の外から確認したい場面が出てきた。

現場では、担当が二人になった時点で急に苦しくなると言われています。件数の増加より、人が増えることのほうが効きます。ファイルを同時に開けないという一点が、そのまま二人の作業を直列にしてしまうからです。

表計算の台帳で、実際に何が詰まるのか

同時に開けない

いちばん大きいのがこれです。共有のフォルダに置いた表計算ファイルは、誰かが開いている間、他の人は読み取り専用でしか開けません。

宴会の受付では、これが致命的に効きます。電話で問い合わせを受けている最中に、台帳が開けない。開けても読み取り専用なので、そのままでは書き込めない。仕方なく紙にメモして、後で打ち込む。その打ち込みが忘れられます。

読み取り専用で開いてしまった状態に気づかず、そのまま書き込んで別名で保存してしまう事故も起きます。この瞬間に、台帳が二つになります。

店の外から見られない

三つ目が、確認できる場所が限られることです。店のパソコンに入っているファイルは、店にいないと開けません。

宴会の相談は、営業時間外にも届きます。休みの日に幹事から電話が来て、空いているかを聞かれても、答えられません。「明日、店から折り返します」と返している間に、他の店で決まります。

共有のクラウドに置けば外からも開けますが、今度は表計算のファイルをスマートフォンで開くことになります。列が横に長い台帳を小さな画面で見るのは、実際にはほとんど無理です。

返信の状況が残らない

四つ目が、受付の記録としての限界です。表計算の台帳は、予約の一覧を管理する道具であって、やり取りの記録を残す道具ではありません。

誰がいつ返信したかは、メールの送信済みフォルダを見ないと分かりません。返したかどうかが件ごとに残らないと、二重返信と返し忘れは必ず起きます。備考の列に「〇月〇日返信済」と手で書いている店もありますが、書き忘れが一件でも出れば、その列は信用できなくなります。

添付ファイルが台帳の外に置かれる

五つ目が、名簿や見積書の置き場所です。表計算の台帳に、ファイルそのものは入りません。だから別のフォルダに保存して、台帳の備考欄にファイル名を書くことになります。

この対応関係は、人の手で維持されます。ファイル名を書き忘れれば、後から探せません。宴会の名簿は締切前に何度も送り直されるので、どれが最新かも分からなくなります。

台帳を作った人しか、使い方が分からない

六つ目が、属人化です。宴会の台帳は、たいてい店長かベテランの社員が自分の使いやすいように作っています。シートが複数に分かれ、片方のシートの値をもう片方が参照し、条件によって色が変わる設定が入っている。

作った本人には自然な作りでも、他の人には読めません。列の意味を聞かなければ書き込めず、間違ったセルに入力すれば数式が壊れます。壊れたことに気づかないまま、集計だけが狂っていることもあります。

この状態は、移行の理由としては軽く見られがちです。しかし作った人が休んだ日に受付が止まるという意味では、同時に開けない問題と同じ重さがあります。

予約管理の仕組みと、宴会の台帳は別物

グルメサイトの予約台帳では、宴会が収まらない

多くの飲食店は、グルメサイトが提供する予約の管理画面を既に使っています。にもかかわらず宴会の台帳を表計算で別に持っているのは、そこに収まらないからです。

通常の席の予約は、日時と人数と名前が決まれば成立します。宴会は違います。コースの選択、飲み放題の有無と時間、席の形、持ち込みの可否、支払いの方法、請求の宛名、仮押さえの期限、人数の確定期限、名簿の受け取り。決めることが十以上あり、しかも問い合わせから確定まで何日もかかります。

この「確定するまでの過程」を持てる場所が無いので、表計算の台帳が生まれます。順番としては自然な流れで、店の判断が間違っていたわけではありません。

確定したあとは、いまの仕組みに戻す

だから移行を考えるときも、全部を一つにまとめようとしないほうがうまくいきます。確定するまでの過程を扱う場所と、確定した予約を席に割り当てる場所は、別でよい。

確定した宴会を、いま使っている予約の管理画面に登録する。この一手間は残りますが、一日に何度も発生する作業ではありません。むしろ、確定した時点で登録するという区切りができるので、抜けが減ります。

移行の範囲を「問い合わせから確定まで」に限定すると、決めることが一気に減ります。席の割り当ても、当日の運営も、これまでどおりで構いません。

移すと決めたとき、最初にやること

全部を移そうとしない

移行が止まる最大の原因は、範囲を広げすぎることです。過去の宴会の記録も、常連の一覧も、メニューの原価表も、まとめて移そうとすると、作業量に押しつぶされます。

移すのは、これから受ける問い合わせだけです。過去の記録は表計算のまま、参照専用として残します。読むだけなら同時に開けない問題は起きませんし、読み取り専用で構いません。

この線を引くと、移行の作業がほぼゼロになります。新しい問い合わせを新しい場所で受け始めるだけです。過去の記録を移す作業は、必要になったときに、必要な件だけ手で写せば足ります。実際には、ほとんど必要になりません。

移す前に、いまの台帳の列を数える

次にやるのが、現在の台帳の列を数えることです。宴会の台帳は、年々列が増えます。使われなくなった列も、消す判断がされないまま残ります。

数えたうえで、それぞれの列について「いま誰が何のために見ているか」を書き出します。答えられない列は、移す対象から外します。

多くの店で、実際に使われている列は15前後に収まります。三十列ある台帳でも、半分は過去の名残です。移す前に削れば、新しい仕組みの設計が軽くなります。

色分けと数式は、移せないものとして扱う

表計算の台帳には、たいてい色分けの規則があります。確定は緑、仮押さえは黄色、断りはグレー。担当者の頭の中にだけある規則も混ざっています。

色は、そのままの形では移りません。ここで「同じ色分けを再現したい」と考えると、移行が止まります。色が表していたものは、たいてい状況です。状況を選択肢として持てる形にすれば、色は要りません。むしろ、選択肢で持ったほうが数えられます。

数式も同じです。人数から金額を計算する数式、期限までの日数を出す数式。移す先で同じことができるかを先に確認し、できないなら手で計算する運用に戻すか、その項目自体をやめるかを決めます。数式の再現に時間をかけるのは、たいてい割に合いません。

移す順番

第一段階は、問い合わせの受け口だけ

最初に移すのは、問い合わせが届く場所です。台帳ではなく、入り口から手を付けます。

理由は二つあります。届いた時点で件として残る形にしないと、台帳への転記という作業が消えないこと。そしてもう一つ、入り口を変えるのは店の中の作業を変えないので、抵抗が小さいことです。

この段階では、台帳は表計算のまま残します。届いた問い合わせを見て、これまでどおり台帳に書き込む。二重管理になりますが、期間を区切れば耐えられます。

第二段階は、状況と担当を件に持たせる

次に、届いた件に状況を持たせます。未対応、返信済み、仮押さえ、確定、断り、流れた。この六つで足ります。担当も件に付けます。

ここまで来ると、台帳の役割が減ります。台帳が持っていた「いま何がどうなっているか」の情報が、件の側に移るからです。台帳に残るのは、確定した予約の日付と席の割り当てだけになります。

この段階で二重管理をやめられる店と、やめられない店に分かれます。予約の管理に別の仕組みを使っている店なら、確定した分だけをそちらに渡す形にできます。表計算の台帳しか無い店は、もう少し併用が続きます。

第三段階は、名簿とファイルを同じ場所に寄せる

最後に、名簿や見積書の置き場所を件の中に移します。ここまでの二段階が済んでいれば、この移行は自然に進みます。届いた件の中にファイルの欄があれば、そこに入るからです。

宴会の名簿には、氏名、所属、アレルギーや食事制限の申告が並びます。置き場所を変えるときは、見られる人の範囲も一緒に決めます。個人情報の保護に関する法律は、事業者に対して次のように定めています。

個人情報取扱事業者は、その取り扱う個人データの漏えい、滅失又は毀損の防止その他の個人データの安全管理のために必要かつ適切な措置を講じなければならない。出典: 個人情報保護委員会

必要かつ適切な措置が具体的に何を指すかは、事業の規模や取り扱う中身によって変わります。断定はできませんし、判断に迷う場面では所管の窓口や専門家に確かめてください。移行は、見られる人を絞り直すよい機会です。表計算のファイルは、開けた人が全部見られる形になっているからです。

移行の前に決めておく細かい点

誰が管理する人になるか

新しい仕組みを入れるとき、最初に決めるのが管理する人です。設定を変えられる人、アカウントを追加できる人、通知の宛先を決める人。

飲食店では、この役をオーナーが持つか店長が持つかで揉めることがあります。決め方の目安は、辞める可能性の低いほうです。店長の個人のアカウントで契約して、その店長が異動や退職をすると、引き継ぎに手間がかかります。

あわせて、契約に使うメールアドレスも個人のものにしないほうがよい。店の代表アドレスを使えば、担当が変わっても引き継げます。

通知の宛先を、いま開いているものに合わせる

移行の直後に必ず起きるのが、見落としです。受信箱で受けていたころは、他のメールと並んで目に入っていました。専用の場所に届くようになると、見に行かないと見えません。

対処は単純で、届いたことを知らせる先を、いま一日に何度も開いているものに合わせることです。メールを一日中見ている店ならメール、公式アカウントの管理画面を開きっぱなしにしている店ならそちら。習慣を変えずに済む場所に通知を出します。

そのうえで、開かないと閉じられない状態にしておきます。返していない件が一覧の上に残り続ける形なら、見落としは翌日に持ち越されません。通知だけを飛ばして、残っているかどうかがどこにも出ない形が、いちばん抜けます。

誰が何を見られるかを、移行のときに引き直す

表計算のファイルは、開けた人が全部見られます。共有のフォルダに置いてあれば、アルバイトも過去の宴会の名簿を開けます。この状態は、移行のときにしか直せません。

飲食店で線を引くなら、三本で足ります。宴会の相談を最後まで扱う人、当日の運営に関わる人、求人の応募を扱う人。二本目の層に必要なのは当日の分だけで、過去の宴会も先の相談も見る必要がありません。

移行のあとに絞ろうとすると、いったん全員が見られる形で運用が始まってしまい、後から狭めるのは反発が出ます。最初から絞っておくほうが、説明が要りません。

移行のときにつまずく場面

二重管理の期間が終わらない

いちばん多い失敗が、これです。新しい場所で受け始めたのに、台帳への転記もやめられない。両方をやり続けるうちに、負担が増えたという理由で元に戻ります。

止め方は、期限を決めることです。二重管理は1か月まで、と先に決めます。期限が来たら、台帳への転記をやめます。不安なら、確定した予約の日付だけを台帳に残す形にすれば、席の割り当てはこれまでどおり見られます。

期限を決めずに始めると、二重管理は永遠に続きます。そして、どちらが正しいのか分からない期間も同じだけ続きます。

台帳を見ていた人が、新しい場所を見ない

二つ目が、人の問題です。宴会の台帳は、店長以外も見ています。ホールの責任者が来週の予約を確認し、厨房が人数を見ます。

その人たちは、問い合わせの管理には関心がありません。必要なのは、確定した予約の日付と人数と席だけです。新しい場所に全部が入っていても、見に行く理由がありません。

対処は、その人たちに渡す形を別に用意することです。確定した予約だけを一覧で出して、印刷するかタブレットに表示する。全員を新しい画面に移そうとすると、抵抗が大きくなります。必要な人だけが新しい画面を使い、それ以外の人には結果だけを渡す形が、現実的です。

移す先の入力項目を、いまの台帳の写しにしてしまう

三つ目が、設計の問題です。移行のときに、いまの台帳の列をそのまま項目として並べてしまう店があります。慣れた形のほうが移りやすく見えるからです。

しかしそれをやると、台帳が抱えていた問題も一緒に移ります。使われていない列、担当者しか意味の分からない略号、他の列と重複している項目。移した先でも同じものが並び、しかも表計算のように後から気軽に消せません。

移行は、項目を削る数少ない機会です。列を数えて、いま誰が何のために見ているかを答えられないものは落とす。この作業を移行の前にやっておくと、移した先の画面が短くなり、入力の手間も減ります。落とした項目が本当に必要だったなら、運用のなかで必ず声が上がります。そのときに足せば済みます。

移した直後に、繁忙期が来る

四つ目が、時期の問題です。十二月の直前に移行を始めると、まず失敗します。新しい形に慣れていない状態で件数が跳ね上がり、確実に回る古い形に戻ります。

移行は、比較的落ち着いている時期に始めます。飲食店の宴会でいえば、繁忙期の3か月前には始めて、二重管理の期間を落ち着いた月の中で終わらせます。

繁忙期の直前に「今のままでは回らない」と気づくことが多いので、この判断は難しい。しかしその年は乗り切って、終わった直後に移行する。この順番のほうが、結果的に早く定着します。

表計算に戻したくなる場面が必ず来る

五つ目が、心理的な問題です。移した先では、表計算でできていた自由な操作ができません。列を勝手に足す、セルにメモを書く、並べ替えて眺める。この自由さは、慣れているほど手放しがたい。

現実的な対処は、書き出せる形にしておくことです。件の一覧を表計算の形で書き出せるなら、集計や分析はこれまでどおりできます。日々の受付は新しい場所で回し、月末の集計は書き出した表でやる。この使い分けなら、両方の良さが残ります。

移行の途中で、台帳をどう扱うか

表計算のファイルは、消さずに凍結する

移行が終わったあと、古い台帳をどうするかで迷う店があります。消すのは不安で、置いておくと誰かが開いて書き込みます。

現実的なのは、凍結することです。ファイル名の先頭に、いつまでの記録かを付けて、書き込みをしない場所へ移します。共有のフォルダに置いたままだと、慣れている人が反射的に開いて書き込みます。書き込まれた瞬間に、また二つの台帳が並行します。

凍結した台帳は、しばらく残しておきます。前の年の同じ時期の宴会を調べたい場面は、必ず来ます。ただし、参照するだけで書き込まないという扱いを徹底します。名簿が入ったままなら、置き場所と見られる人も、そのときにあわせて決めておきます。

移行の直前に、駆け込みの相談が来る

宴会の受付は、移行の予定に合わせて止まってくれません。切り替えの前日に大きな相談が入ることもあります。

このときに迷わないよう、線を先に引いておきます。切り替えの日より前に届いた相談は最後まで台帳で扱い、その日以降に届いた分だけ新しい場所で受ける。日付で切るのがいちばん揉めません。

件で切ろうとすると、途中の相談をどちらで扱うかの判断が毎回発生します。日付で切れば、迷う余地がありません。台帳側で進んでいる件は、そのまま台帳で終わらせます。宴会は問い合わせから開催まで数か月あるので、この扱いはしばらく続きます。

移行の作業を、誰か一人の仕事にしない

移行を店長ひとりの作業にすると、忙しくなった時点で止まります。しかも止まったことが他の人には見えないので、二重管理が長引きます。

作業を分けます。項目を決めるのは店長、実際に届いた相談を新しい場所で扱うのは受付を担当する全員。決めるところと使うところを分けておくと、店長が休んだ日も進みます。

分けておくと、店長が繁忙で手を止めても、使う側の慣れは進みます。進み具合を測る指標も、一つだけ決めておきます。新しい場所で受けた件の割合が、全体の何割になったか。これが十割に近づいた月に、二重管理を終えます。

割合が伸びない月があったら、原因を人に求めないことです。たいていは、新しい場所で扱いにくい相談の型が残っています。電話で来る相談か、常連からの相談か。どちらかが取り残されていることが多い。

移行後の最初の一か月で見ること

転記が本当に消えたかを確かめる

移行の効果は、機能が増えたことではなく、作業が減ったことに出ます。最初の一か月で確かめるのは、転記の作業が消えたかどうかです。

届いた問い合わせを台帳に書き写す作業、返信の内容を備考欄に書く作業、名簿のファイル名を控える作業。この三つが残っているなら、移行が中途半端です。どこかで新しい場所と古い台帳が両方使われています。

残っている作業を書き出して、なぜ残っているのかを一つずつ潰します。多くの場合、原因は「誰かがそこを見る習慣がある」ことです。その人に渡す形を別に作れば、転記は要らなくなります。

電話で受けた分が入っているかを見る

移行して一か月経ったときに、記録の件数を数えてみます。フォームから届いた分だけが記録されていて、電話で受けた分が入っていないなら、片方だけの移行になっています。

電話は無くなりません。特に直前の人数変更は電話が早い。対処は、電話のあとに確認の一通を送る運用にすることです。「先ほどお電話でお伺いした内容の確認です」という短い一通を送れば、その時点で件として残ります。相手にとっても、口頭で聞いた条件が文字で残るので助かります。

通話の終わりに連絡先を聞く一言を、電話の受け答えの型として決めておきます。聞くタイミングを決めていないと、忙しい日には抜けます。

表計算に戻っていないかを見る

最後に確かめるのが、こっそり表計算が復活していないかです。新しい場所で扱いにくい項目があると、誰かが自分用の表を作ります。その表が育つと、また同じ問題が始まります。

見つけたら、責めずに理由を聞きます。たいてい、新しい場所で持てない項目があるか、一覧の見せ方が合っていないかのどちらかです。理由が分かれば、設定で解決できることが多い。放置すると、二つの台帳が並行して動く元の状態に戻ります。

移す先を選ぶときの比較の軸

送る側に何を求めるか

第一の軸は、問い合わせをする側の手間です。宴会の幹事は複数の店に同時に問い合わせているので、送信の手前に登録の壁があると、そこで数が減ります。

無料で使える定番の道具と、送信されたあとの扱いがどう違うのかは、Googleフォームとの比較で、回答が表に溜まったあとに何が起きるかという観点から整理されています。表計算の台帳から移るとき、回答が別の表に溜まる形に移すだけだと、同じ問題が形を変えて残ります。

届いたあとに、状況と担当を持てるか

第二の軸は、件に状況と担当が付くかどうかです。表計算の台帳から移る目的の大半は、ここにあります。同時に開ける、最新版が一つ、誰が返したか残る。この三つが揃わないなら、移す意味が薄い。

すでにサイトにフォームを置いている店であれば、Contact Form 7との比較に、送信の通知だけが飛ぶ状態と、送信後の管理まで持つ状態の違いがまとめられています。どこまでが標準で備わっているかは、できることで確かめられます。送信されたあとの道具がそろっているかどうかは、フォームを作る画面を見ても分かりません。

会社の環境との関係

第三の軸は、いま使っている環境との関係です。すでに事務作業を特定のグループウェアで回している場合と、店の受付だけを独立させたい場合とで、選ぶものが変わります。前者なら既存の環境の中で完結させたほうが、アカウントの管理が一つで済みます。後者なら受付だけを切り出したほうが、見られる人を絞りやすい。仕様は変わるので、比べるときは各サービスの公開資料でその時点の内容を確かめてください。

比べるときは、入力する画面ではなく、届いた一覧の画面を長く見たほうが判断がしやすい。表計算の台帳を使ってきた店ほど、入力のしやすさに目が行きます。しかし移行の目的は入力ではなく、入力したあとに何ができるかの側にあります。

飲食店以外の受付でも、同じ構造が繰り返し出てきます。表計算の台帳で始めて、担当が二人になった時点で回らなくなる。どの場面でどう詰まるのかは、問い合わせの受付に、受け取ってから返すまでの流れとして整理されています。宴会のように日付と定員と締切を扱う受付は、イベントの申し込みの形に近く、期限と枠をどう管理するかという観点でまとめられています。

移行を、どこで判断するか

移すかどうかを決めるとき、機能の一覧を見比べても答えは出ません。判断の材料になるのは、いまの台帳で起きている事故の中身です。

数えるのは三つです。読み取り専用で開いてしまって書き込めなかった回数、どれが最新か分からずに開き直した回数、そして二重返信か返し忘れが起きた件数。この三つを一か月だけ記録してみます。

一か月でどれもゼロなら、いまの台帳で足りています。移す必要はありません。どれかが複数回起きているなら、それは仕組みの問題であって、注意で減らせるものではありません。

判断のときに、費用だけで決めないことも大事です。表計算の台帳には追加の費用がかからないので、月々の支払いが発生する形と比べると、どうしても不利に見えます。比べるなら、こちら側にも金額を置きます。二重予約が一件起きたときの損失、返信が遅れて失注した宴会の売上、台帳の作り直しにかかった時間。宴会は一件あたりの金額が大きいので、年に一件の事故を防げるだけで釣り合うことがあります。料金には、どの範囲までが基本に含まれるのかが書かれているので、比べるときの材料になります。

そして、移すと決めたら順番を守ります。入り口、状況と担当、ファイルの置き場所。この順です。台帳の置き換えから始めると、日々の受付が止まったまま作業だけが増えます。入り口から始めれば、初日から効果が出ます。届いた問い合わせが件として残る、それだけで転記の作業が一つ消えるからです。

Q1. 宴会の台帳を表計算で管理していますが、変えたほうがよいですか？

触る人が一人だけで、件数が記憶で追える程度で、店の外から見る必要がないなら、変える理由はほとんどありません。回らなくなるのはこの三つのどれかが崩れたときです。特に担当が二人になった時点で急に苦しくなります。件数の増加より人が増えることのほうが効き、ファイルを同時に開けないという一点が、二人の作業を直列にしてしまうからです。

Q2. 過去の宴会の記録も、全部移す必要がありますか？

移す必要はありません。移すのはこれから受ける問い合わせだけで、過去の記録は表計算のまま参照専用で残します。読むだけなら同時に開けない問題は起きません。この線を引くと移行の作業がほぼゼロになり、新しい問い合わせを新しい場所で受け始めるだけになります。過去の件は必要になったときだけ手で写せば足り、実際にはほとんど必要になりません。

Q3. 台帳の色分けや数式は、移した先でも再現できますか？

同じ形での再現は考えないほうが進みます。色が表していたのはたいてい状況なので、確定や仮押さえといった選択肢として持たせれば色は要らなくなり、しかも数えられるようになります。数式は、移す先で同じことができるかを先に確認し、できないなら手で計算するか項目自体をやめるかを決めます。再現に時間をかけるのは割に合いません。

Q4. 移行の作業は、いつ始めるとよいですか？

繁忙期の3か月前です。十二月の直前に始めると、慣れていない状態で件数が跳ね上がり、確実に回る古い形に戻ります。落ち着いている時期に始めて、二重管理の期間をその中で終わらせます。二重管理は1か月までと期限を先に決めておかないと、負担が増えたという理由で元に戻ります。繁忙期の直前に限界に気づくことが多いので、その年は乗り切って直後に移すほうが定着します。

Q5. ホールや厨房のスタッフも、新しい画面を見る必要がありますか？

必要ありません。その人たちが見たいのは確定した予約の日付と人数と席だけで、問い合わせの管理には関心がありません。全員を新しい画面に移そうとすると抵抗が大きくなります。確定分だけを一覧で出して印刷するかタブレットに表示し、必要な人だけが新しい画面を使う形が現実的です。あわせて、当日の運営に関わる人には過去の宴会の名簿まで見せない形にしておきます。