出勤リクエスト募集のやり方｜「いつなら行けますか」を集めてシフトを組み、予約に変える手順

「9月の出勤リクエスト募集中」と書いたあと、その希望はどこにありますか

シフトを先に決めて告知するのではなく、お客様に希望日時を聞いてからシフトを組む。この運用を始める人が増えています。

9月の出勤リクエストを募集中♡
DMにてご相談承ります。
相談例）〇月〇日の何時からいけますか？ など

理屈としては正しい方向です。来てくれる人がいる日に出勤するほうが、勘で決めた日に出勤するより埋まります。

ただ、この運用は募集した瞬間がスタートで、そこから先に3つの作業が発生します。

バラバラのDMで届く希望を、日付順に突き合わせる
希望が集中した日・1人しかいない日をどう扱うか決める
リクエストしてくれた本人に「その日、出ます」と返す

そして多くの場合、詰まるのは3番目です。「9月のシフト出ました」と全体に告知して終わってしまい、リクエストに答えてくれた人が予約に変わらない。それでは、聞いた意味がありません。

この記事では、出勤リクエスト募集を「意見集め」ではなく予約導線として設計する手順を、募集文の型から確定連絡の文面まで順番に解説します。

なお、お客様から個別に「◯日に来てほしい」と言われた1件を受ける場合は、リクエスト出勤の受け方と告知術で解説しています。この記事はこちらから募集をかけて複数の希望を集め、シフトそのものを組む運用が対象です。

出勤リクエスト募集とは？　通常のシフト告知と何が逆なのか

出勤リクエスト募集とは、シフトを確定させる前にお客様の希望日時を集め、その希望をもとに出勤日を決める運用のことです。

通常の流れと比べると、順番がまるごと逆になります。

	通常のシフト告知	出勤リクエスト募集
最初に決まるもの	出勤日	お客様の希望日
お客様の役割	決まった枠から選ぶ	決める前の材料を出す
空振りのリスク	出勤したのに埋まらない	希望が集まらない／集まりすぎる
予約が入るタイミング	告知したあと	確定連絡を返したあと
必要な準備	なし	希望を記録して突き合わせる仕組み

いちばん大事な違いは最後の2行です。通常の告知は「出しておけば入る」ですが、リクエスト募集は集めた希望を自分で処理しない限り、1件も予約になりません。募集は入口であって、結果ではありません。

この運用が向いている人・向いていない人

正直に書きます。リクエスト募集は、答えてくれる人が一定数いる場合にだけ機能します。

向いている人

本指名のお客様が5人以上いて、うち数人とは直接連絡が取れる
出勤日をある程度自由に決められる（店舗の枠が固定されていない）
週2〜4日など、出勤できる日数に制限があって選ばないといけない

向いていない人

本指名がまだ少ない。答える人がいないので、募集しても反応がなく気まずいだけになります。この段階では出勤日の決め方｜予約データから自分が稼げる曜日を見つけるのように過去の予約データから決めるほうが確実です
店舗のシフト枠が先に決まっていて、自分では選べない
毎日フル出勤していて、選ぶ余地がない

3番目の「出勤できる日数に制限がある」は、実はこの運用の効果がいちばん出るケースです。週1〜2日しか出られない人は1日の取りこぼしが致命的なので、週1〜2日しか出られない人の枠設計とあわせて読むと、どの日を選ぶかの判断がしやすくなります。

募集の型は3つある。回答数が多い型ほど、来店には繋がらない

「出勤リクエスト募集」と一口に言っても、聞き方によって集まるものが変わります。ここを意識せずに書くと、返事はたくさん来たのに誰も来ないという結果になります。

型	聞き方	集まるもの	回答のしやすさ	来店に繋がる度合い
A. 調査型	「9月いつがいいですか？」	意見・願望	高い	低い
B. 候補提示型	「9/3・9/7・9/10のどれがいいですか？」	選択	中	中
C. 確約型	「9/7に出たら来られますか？　来られるなら枠を押さえます」	仮予約	低い	高い

冒頭に挙げた実例（「〇月〇日の何時からいけますか？」）はA型です。自由に日付を書いてもらう形なので答えやすく、返事の数は集まります。

ただ、A型で返ってくる「9日あたりがいいです」は、予定ではなく希望です。答えた本人も予約したつもりがないので、その日に出勤しても来ないことがあります。

一方でC型は、答えた時点でほぼ予約です。回答数は減りますが、答えた人はほぼ来ます。

ここで判断を間違えやすいのは、回答数を成果として数えてしまうことです。 「20人が答えてくれた」は気持ちのいい数字ですが、そのうち来店したのが3人なら、A型で20件集めるよりC型で5件集めたほうが売上は大きくなります。

実際には「A型で広く聞いて、C型で個別に詰める」の2段構え

とはいえ、いきなりC型だけで募集すると、まだ日程が固まっていないお客様が答えられません。おすすめは2段階に分けることです。

第1段階（A型・公開）: 「9月の出勤リクエスト募集中です。◯日◯時ごろ、といった形でご希望をいただけたら嬉しいです。9/25まで受け付けます」

第2段階（C型・個別）: 希望をくれた人に個別で「9/7、いただいたご希望で出勤決めました。19時ごろでご都合いかがですか？」

第1段階で母数を集め、第2段階で予約に変換します。第2段階を飛ばすと、この運用はまるごと空振りします。 詳しくは後述します。

募集の期間は、店へのシフト提出期限から逆算して決める

募集文に締切が書かれていないのを、よく見かけます。これは運用として続きません。

締切がないと、こうなります。

シフトを店に提出したあとに希望が届く → 応えられない → 「聞いておいて無視された」という体験になる
いつまでも決まらないので、自分も動けない
お客様も「まだ先の話か」と思って後回しにする（そのまま忘れる）

締切は、店へのシフト提出日から逆算して決めます。

逆算のスケジュール（翌月分を募集する場合）

タイミング	やること
提出の10日前ごろ	募集開始（公開告知＋本指名さんへ個別）
提出の5日前ごろ	一度だけリマインド（「◯日まで受け付けています」）
提出の3日前	募集締切
締切〜提出まで	希望を突き合わせて出勤日を決める
提出日	店にシフト提出
提出の翌日	リクエストをくれた人へ個別に確定連絡
その翌日以降	公開告知

店へのシフト提出が月の20〜25日ごろの場合、募集開始は10〜15日ごろ、締切は17〜22日ごろになります。提出期限そのものの考え方は月初シフト提出のベストなタイミングにまとめています。

締切から提出までに3日の余白を必ず取ってください。ここが1日しかないと、希望を突き合わせる時間が取れず、結局「なんとなく」で決めることになります。それでは募集した意味がなくなります。

募集の告知は、単独の投稿で出す

やりがちな失敗が、今月の出勤予定と同じ投稿の中でリクエストを募集することです。

【NG例】
本日18:00〜24:00 🈳最短19:30〜
明日はお休みです🙏
そして9月の出勤リクエストも募集中です♡

読む側は最初の2行を「今日の枠の告知」として処理するので、3行目は流れます。目的が違う情報を1つの投稿に混ぜると、後ろにあるほうが必ず読まれません。 これは指名料の値上げ告知でも同じ構造の失敗が起きます（指名料の値上げ・ランクアップをお客様に伝える方法）。

募集は単独の投稿で、締切を明記して出してください。

聞く順番は「本指名 → 予約が入っている人 → たまに来る人 → 公開」

公開投稿だけで募集すると、答えるのはいつも見てくれている一部の人だけになります。しかも、本当に来てほしい本指名のお客様が投稿を見逃していると、その人の希望が入らないままシフトが決まってしまいます。

聞く順番は4層に分けます。

第1層：本指名のお客様（締切の10日前）
個別に送ります。「9月のシフトを組むところなので、もしご都合のいい日があれば先に教えてください」。先に聞かれること自体が特別扱いなので、返信率がいちばん高い層です。

第2層：すでに予約が入っている人（同時期）
来店時に口頭で聞くのがいちばん早いです。「来月もこのくらいの時間帯がいいですか？」

第3層：たまに来てくれる人（締切の7日前）
しばらく来ていない人にも声をかけます。リクエスト募集はしばらく来ていないお客様の掘り起こしの口実としても使えます。「久しぶりに」ではなく「9月のシフトを組むので」のほうが、相手に負担がありません。

第4層：公開告知（締切の7日前〜）
最後に公開で出します。ここまでに濃いお客様の希望は集まっているので、公開はあくまで補足です。

順番を逆にして公開を先に出すと、本指名のお客様が「全員向けのお知らせとして」リクエストを知ることになります。この構造は値上げ告知と同じで、濃いお客様ほど先に個別で伝えるのが原則です。

そのまま使える募集文

公開告知用

9月の出勤リクエストを募集しています🌙

「〇月〇日の何時ごろに行きたい」という形で、
DMからご希望をいただけたら嬉しいです。

いただいたご希望を見ながら9月のシフトを組みます。
9/17（木）まで受け付けています。

※必ずご希望に沿えるとは限りませんが、
　いただいたぶんは全部見て決めます🙇‍♀️

「必ず沿えるとは限らない」の一文は必ず入れてください。これがないと、希望に応えられなかったときに約束を破ったことになります。

本指名さん向け（個別）

〇〇さん、こんばんは🌙

9月のシフトを組むところなのですが、
もしご都合のいい日や時間帯があれば
先に教えていただけたら嬉しいです。

〇〇さんが来られる日をなるべく入れたいので、
先に伺わせてください🙇‍♀️
（9/17ごろまでに決めます）

集まった希望は、3列のリストに落とす

ここからが本題です。DMで届いた希望を、DMのまま置いておくと必ず落ちます。

理由は単純で、届く順番と日付の順番が一致しないからです。9/3の希望、9/20の希望、9/7の希望……とバラバラに届くものを、頭の中で日付順に並べることはできません。10件を超えたあたりで確実に破綻します。

必要なのは3列だけです。

希望日	誰から	希望時間帯
9/3（木）	Aさん（本指名）	20時ごろ
9/3（木）	Bさん（本指名）	夜なら何時でも
9/7（月）	Cさん（はじめまして）	14〜16時
9/12（土）	Dさん（本指名）	21時以降
9/20（日）	Aさん（本指名）	昼

このリストを希望日で並べ替えられる形にしておくのが条件です。そうすると、次の判断が一目でできるようになります。

どの日に希望が集中しているか
希望が1人だけの日はどこか
同じ人が複数日に希望を出しているか（Aさんのように）

2列目の「誰から」を省略しないでください。後述する確定連絡は、この列がないと送れません。 そして確定連絡こそが、この運用の成否を決めます。

なお、お客様がLINE・DM・店の伝言など複数の経路から連絡してくる場合、同じ人が別人として2行に入ってしまうことがあります。その対策は「この人、誰だっけ」をなくす顧客管理にまとめています。

集まった希望から出勤日を決める4つの判断

リストができたら、次は出勤日を決めます。判断は4パターンに分かれます。

1. 希望が集中した日 → 出勤確定。ただし枠数の上限を先に確認する

いちばん希望が多い日は迷わず出勤日にします。ただし、ここで**「希望が5件あるから5人入る」と考えないでください**。

1日に受けられる枠数には物理的な上限があります。出勤時間・コース時間・移動や準備を差し引くと、実際に受けられるのは思ったより少ない数です（1日に予約を何枠まで受けるか）。

上限を超える希望が集中した場合、この時点で第2希望に振ります。確定連絡の前なら、まだ「その日は先約が入りそうなので、9/12はいかがですか？」と提案できます。予約が全部入ってから調整しようとすると、断る形になってしまいます。

2. 希望が1人だけの日 → 「誰の1人か」で決める

ここは機械的には決められません。判断軸はその1人が本指名かどうかです。

本指名が1人 → 出る価値があります。1枠は確実に埋まり、出勤を告知すればほかの枠も埋まる可能性があります
はじめましての方が1人 → その1枠が飛んだらゼロになります。ほかに理由がなければ見送りが無難です

「1人でも来てくれるなら」と全部拾っていくと、出勤日数だけが増えて1日あたりの密度が下がります。

3. 希望が0だった日 → 「需要がない日」とは限らない

これが誤読しやすいところです。リクエストに答えてくれるのは、お客様全体のごく一部です。 答えなかった人の大半は、投稿を見ていないか、日程がまだ分からないだけです。

希望が0の日を「需要がない日」と判定して出勤日から外すと、リクエストを見ていない常連さんの来店機会をこちらから消してしまいます。

判断材料は、リクエストではなく過去の実績を使ってください。曜日別の稼働率は出勤日の決め方｜予約データから自分が稼げる曜日を見つけるの方法で出せます。リクエストは「足す材料」であって「引く材料」ではありません。

4. 希望が全体的に少なかった → 募集の失敗と決めつけない

反応が薄いことはあります。原因は3つに分かれます。

原因	見分け方	次にやること
聞く相手が足りない	本指名が5人未満	募集をやめて実績データで決める
聞き方が難しかった	既読はついたが返信がない	A型（自由記述）→ B型（候補から選ぶ）に変える
締切が遠すぎた	締切直前に集中して届いた	募集期間を短くする（10日→5日）

やってはいけないのは、「誰もご希望ないみたいですね…」と公開で書くことです。 読んだ人に罪悪感が発生し、次回はもっと答えにくくなります。反応が薄かった月は、静かに通常の告知に戻してください。

この運用の成否を決めるのは、確定連絡ひとつ

ここがこの記事でいちばん重要な部分です。

シフトが決まったあと、多くの人がこうします。

【これでは予約になりません】
9月のシフト出ました✨
9/3・9/7・9/12・9/20 に出勤します🌙
ご予約お待ちしています！

リクエストをくれた人も、この投稿を見れば「自分の希望が通った」と分かります。でも分かるだけです。予約するにはもう一度アクションが必要で、そのひと手間で多くが流れます。

正しくは、リクエストをくれた本人に、その人の希望と紐づけて個別に返します。

【確定連絡の型】
〇〇さん、こんばんは🌙

9月のシフトが決まりました。
〇〇さんにいただいた 9/3 のご希望、
そのまま出勤日に入れられました✨

20時ごろとのことでしたので、
そのあたりでお取りしておきましょうか？

この文には3つの要素が入っています。

相手の希望を引用する（「9/3のご希望」）── リクエストが読まれていた証拠になります
希望が通ったことを伝える（「入れられました」）── 自分の一言でシフトが動いたという体験になります
その場で時間を確認する（「お取りしておきましょうか？」）── ここで初めてリクエストが予約に変わります

3番目を「ご予約お待ちしています」で終わらせないでください。それは相手にもう一度考えさせる文です。時間まで踏み込むと、返事が「はい」だけで済みます。

なお、この連絡はシフトを公開する前に送ります。公開が先だと、リクエストをくれた人が「全員向けのお知らせ」として自分の希望の結果を知ることになり、個別に聞いた意味が薄れます。

希望に応えられなかった人へのフォローが、次回の回答率を作る

全員の希望に応えることはできません。応えられなかった人にこそ、連絡が必要です。

〇〇さん、こんばんは🌙

9月のシフト、9/10のご希望をいただいていたのですが、
今回はその日に出られないことになってしまいました🙇‍♀️

近い日だと 9/12（土）に出勤します。
21時以降でしたらお取りできますが、いかがでしょうか？

せっかくご希望いただいたのにごめんなさい🥺
次回のリクエストもぜひ聞かせてください。

ここでも代替日を必ず添えます。「今回はごめんなさい」だけで終えると、その人の来店機会が1か月まるごと消えます。

そして無視は避けてください。リクエスト募集は毎月繰り返す運用です。 答えたのに何の返事もなかった人は、翌月まず答えてくれません。回答率は、前回のフォローの結果として決まります。

リクエスト運用が続かない人が詰まる3か所

詰まり1：希望を記録していないので、確定連絡が送れない

いちばん多いパターンです。DMの中に希望が散らばったまま1〜2週間が経ち、シフトが決まった時点で「誰が何日を希望していたか」を遡れなくなります。

そうなると、送れるのは全体告知だけになります。確定連絡が送れない＝リクエスト募集をやった意味がゼロになるということです。

対策は3列リストを作ることだけです。DMが届いたその場で1行足す、が最短です。

詰まり2：「まだ確定していない希望」を予定として扱ってしまう

カレンダーアプリで管理しようとすると、ここで混乱が起きます。まだ確定していない希望と、確定した予約が同じ見た目で並ぶからです。

9/3に「Aさん希望」と書き込んだあと、実際にAさんの予約が確定してもう1件書き込むと、1つの枠に2件あるように見えます。逆に、希望のまま消えた予定を消し忘れると、空いているはずの枠が埋まって見えます。

仮の希望と確定した予約は、見た目で区別できないと必ず事故ります。

詰まり3：全部の希望に応えようとして、出勤日数が膨らむ

希望が9日ぶん集まったとき、9日全部に出ようとしてしまうケースです。1日あたりの予約が1〜2件しかない日が並び、稼働時間あたりの効率は落ちます。

出勤できる日数の上限を、募集をかける前に決めておいてください。 「9月は最大10日」と先に決めておけば、集まった希望から上位10日を選ぶだけの作業になります。上限を決めずに集めると、断る理由が自分の中にないまま判断することになります。

希望の管理方法を比較する

軸は2つです。日付順に並べ替えられるかと、仮の希望と確定した予約を区別できるか。

管理方法	日付順に並ぶ	誰の希望か残る	仮と確定を区別	実際のところ
DMのまま	✕	○	✕	届いた順にしか並ばない。10件で破綻する
紙の手帳	○	△	△	日付順にはなるが、1日に複数の希望を書くと欄が足りない。書き直しが多い
カレンダーアプリ	○	○	✕	希望と確定予約が同じ見た目で並ぶ。詰まり2が起きる
スプレッドシート	○	○	○	できる。ただし毎月シートを作り直す手間がある
P-Book	○	○	○	仮の枠と確定した枠を分けて置ける。お客様の情報と紐づく

紙の手帳が根強いのは、DMを見ながらすぐ書けるからです。悪い方法ではありません。ただ、リクエスト募集は「1日に複数人の希望が並ぶ」前提の運用なので、日付ごとの欄がすぐ足りなくなります。

カレンダーアプリの✕は見落とされがちなポイントです。予定を置くには便利ですが、「まだ確定していないもの」を置く場所として設計されていません。手帳・メモアプリからの移行で失われるものは紙の手帳・メモ帳アプリからの予約管理の移し方にまとめています。

効果は「回答数」ではなく、予約が入るタイミングで測る

リクエスト募集をやったかどうかで比べるべき数字は、回答が何件来たかではありません。見るのは次の3つです。

指標	見方	良くなっているサイン
リクエスト→来店の変換率	希望をくれた人のうち、実際に来た人の割合	5割を超えていれば十分。低い場合は募集の型をA型→B型へ
予約が入るタイミング	出勤日の何日前に埋まったか	募集した月のほうが早く埋まる
月初の埋まり具合	月の1〜10日の予約本数	月初から予約が入っていれば効いている

2番目のリードタイムが、この運用のいちばん分かりやすい効果です。リクエストに答えた人はその日を予定に入れているので、通常の告知より早く予約が入ります。早く埋まるほど、残った枠を売る時間の余裕が生まれます。

逆に、変換率が2〜3割で止まる場合は、A型の募集で「意見」だけを集めている可能性が高いです。次の月はB型（候補を3つ提示して選んでもらう）に変えてみてください。

よくある質問（FAQ）

Q. リクエスト募集は毎月やるべきですか？

毎月やるのが基本です。ただし、反応が薄い月が2回続いたら一度やめてください。「募集しているのに誰も答えない」状態が公開の場に残り続けるのは、印象として良くありません。本指名が増えてから再開すれば大丈夫です。

Q. 締切を過ぎてから希望が来たらどうすればいいですか？

正直に「もうシフトを出してしまったので、今回は入れられませんでした」と伝えたうえで、確定済みの出勤日から近い日を提案します。断るだけで終わらせないのがポイントです。次回に向けて「次は◯日ごろに募集します」と添えておくと、翌月は締切前に届きます。

Q. 同じ人が5日ぶんリクエストしてきました。全部叶えるべき？

全部叶える必要はありません。むしろ、5日希望を出す人は「そのうちどれか1日に行きたい」ことが多いです。「いちばん行きやすいのはどの日ですか？」と1日に絞って聞き直してください。 5日全部を出勤日に入れると、その人が来るのは1日だけで、残り4日は希望が1人もいない日になります。

Q. 希望通りに出勤したのに、その人が来ませんでした

A型（自由記述）の募集ではよく起こります。答えた本人に予約したつもりがないためで、悪意ではありません。防ぐには確定連絡の段階で時間まで決めてしまうことです。「20時ごろでお取りしておきますね」まで進めば、予約として扱われます。それでも当日に流れる場合は、ドタキャンを減らす前日連絡の考え方が使えます。

Q. 店にシフトを出したあとで変更したくなったら？

リクエスト運用では、これを避けるのが前提です。確定連絡を送ったあとに出勤日を変えると、「自分の希望で決まった日」が消えることになり、通常の予定変更よりダメージが大きくなります。 どうしても変わる場合は、公開告知より先にリクエストをくれた本人へ個別に連絡してください（「やっぱり別の日に」と言われたときの姫予約変更対応）。

Q. 出勤先の店舗が決まっていない場合も、この方法で聞けますか？

聞く内容が変わります。日時ではなく「どの店舗に来られるか」を聞く運用は「どの店に出るか」を直前に決めるキャストの告知術にまとめています。日時と店舗を同時に聞くと、お客様が答えにくくなるので、片方ずつ聞くのがおすすめです。

まとめ｜募集は入口、確定連絡が出口

出勤リクエスト募集は、「お客様の希望を聞くやさしい運用」に見えて、実際には集めた希望を処理する仕組みがないと1件も予約にならない運用です。

手順を整理します。

募集の型を決める — A型（自由記述）で母数を集め、C型（確約型）で個別に詰める2段構え
締切を店へのシフト提出日から逆算する — 提出の3日前に締切、突き合わせに3日の余白を取る
聞く順番は本指名 → 予約が入っている人 → たまに来る人 → 公開 — 公開は最後
希望を3列（希望日／誰から／時間帯）で記録する — 日付順に並べ替えられる形で
出勤日を決める — 集中日は枠数の上限を確認、1人だけの日は本指名かで判断、希望0の日は実績データで判断
確定連絡を個別に送る — 相手の希望を引用し、時間まで確認する。公開告知より先に
応えられなかった人にも代替日を添えて連絡する — 次回の回答率はここで決まる

いちばん取りこぼしやすいのは、6番です。シフトが決まった安心感で全体告知だけして終わると、聞いた時間がまるごと無駄になります。リクエストを予約に変えるのは、告知ではなく1通の個別連絡です。

そして6番を実行するには、誰がどの日を希望したかが残っていることが絶対条件になります。この記録さえあれば、あとは文面を当てはめるだけの作業です。

希望と予約を、同じ画面で管理する

出勤リクエスト募集でいちばん手間がかかるのは、まだ確定していない希望と、確定した予約が混ざることです。カレンダーアプリでは両者が同じ見た目で並んでしまい、どれが仮でどれが確定か分からなくなります。

P-Book は、シフトの時間軸に予約をブロックとして配置するタイムラインで予約を管理します。

希望の段階と確定した予約を分けて置ける — 仮のまま置いた枠が確定枠と混ざらないので、埋まり具合を見誤りません
空き時間と重複が一目でわかる — 希望が集中した日に何枠まで受けられるかが、計算しなくても形で見えます
予約とお客様の情報が紐づく — 「9/3を希望したのは誰か」が残るので、確定連絡をそのまま送れます
お店への連絡文を自動生成 — 決まったシフトの提出連絡もそのまま作れます

姫予約そのものの仕組みは姫予約とは？仕組み・メリット・始め方で、管理方法全体の比較は姫予約の管理方法まとめで解説しています。

月額1,980円（税込）。無料で1ヶ月試せます。カード登録不要です。 トライアル終了後の自動課金もありません。

👉 P-Book を無料で試す

P-Book は姫予約の管理をタイムラインで視覚的に行える予約管理アプリです。1ヶ月無料・カード不要で試せます。