「通夜振る舞いは何人前にしますか」。担当者にそう聞かれた喪家は、たいてい正確な人数を答えられません。会葬者の多くは訃報を受けてから駆けつける立場で、参列するかどうかを本人もまだ決めていないからです。
料理と返礼品の発注は、その「まだ決まっていない人数」に対して先に確定させる仕事です。この記事では、葬儀社に特有のこの構造を、他業種の実例と照らしながら整理します。
会葬者数は「読めない」のではなく「最後まで動く」
会葬案内は電話・FAXで届き、弔問可否の返事も同じ経路で戻ってきます。本人は参列するつもりだったはずなのに、当日の体調不良や急な予定変更で覆ることが珍しくありません(訃報は誰の都合にも合わせてくれません)。
この構造が発注をむずかしくしている理由は3つあります。
- リードタイムの壁 — 料理・返礼品は仕入れ・準備が必要で、通夜当日の午前中には数量を確定させなければならない
- 後戻りできない意思決定 — 多めに発注すれば廃棄、少なめなら通夜の最中に追加手配が走る(追加手配は、たいてい定価より高くつきます)
- 属人化した匙加減 — 「この地域なら会葬案内○件に対して何人前」という読みは、ベテラン担当者の経験に閉じている
電話・FAXでの返答は担当者の手元にバラバラに積み上がり、直前の変更が反映されないまま発注数量が確定してしまう。発注担当は結局「今わかっている範囲」だけで数量を決めるしかないわけです。この「多めに発注して廃棄するか、足りずに追加手配するか」の二択は、毎回運任せにするしかないのでしょうか。
Before / After の試算
参考までに試算すると、会葬案内を50件出しても実際の参列は30〜45人の幅で動くことがあります。±30%ほどの振れ幅です。これは実測ではなく仮定を置いた数字ですが、発注判断の起点をどう変えられるかを整理したものが以下の表です。
| 項目 | Before | After |
|---|---|---|
| 弔問可否の反映 | 電話を受けた人のメモ頼みで、直前の変更が発注担当に届かないことがある | 変更が入った時点で、全体の集計に即座に反映される |
| 発注数の確定 | 前日夕方までの人数で「えいや」と決める | 当日朝の集計を見てから確定できる |
| 数量のズレへの対処 | 多め発注の廃棄か、通夜中の追加手配 | 直前の変動幅を見ながら発注量を調整できる |
「数え直す」を人手から外す
変わるのは受付の窓口ではありません。電話・FAXのまま受け続けても構わず、変わるのは「受けた変更をどこまで手作業で数え直すか」です。数え直しを仕組み側に寄せれば、属人化していた匙加減も担当者の頭の中から外に出せます(ベテランが休んでも、勘まで一緒に休むことはなくなるわけです)。担当者がやるのは発注直前の最終確認だけになります。
他業種では、この「数え直しをなくす」がどう効いたか
playpark に葬儀社での導入実績はまだありません。ただし「状態が変わるたびに手作業で数え直している」という構造は他業種で実装しています。以下は他業種で実測した数字です。
構造が近いのは、入社手続きの進捗管理です。担当者ごとの台帳で追っていた70項目超の進捗を一覧で可視化した入社対応の実例では、実測で対応工数が80%削減されました。個々の状態、つまり弔問可否を追い続ける発想は、ここでの進捗追跡と同じです。
数字を集計する側の遅さを解いた例もあります。データはあるのに集計処理が遅くタイムアウトしていた工数レポートを、都度反映できる形に作り直したBI集計の実例では、実測で処理時間が85%短縮されました。「数字はあるのに、必要な瞬間に出てこない」という点は、直前の弔問可否の変更を発注担当が把握できない状態とよく似ています。
どちらも葬儀の話ではありません(進捗管理と工数レポート、扱うものはだいぶ違います)。それでも共通しているのは「状態の変化を、都度反映できる形に変えた」という一点です。
発注判断の立て方から、一緒に整理しませんか
最初の一歩はシステム導入ではありません。直近の会葬案内と実際の会葬者数を並べ、案内件数に対してどのくらいの幅で人数が動いたかを確認するところからです。その幅が見えれば、発注量の決め方は仕組みにできます。
playpark の業務効率化サービス「SHITATEYA」では、いまの受付方法を変えずに集計の仕組みだけを設計できます。業種を問わない進め方は業務自動化ソリューションで紹介しています。発注量の決め方に迷いがあるなら、お問い合わせからご相談ください。



