人材派遣の稼働管理をCRMで設計する｜オーダー・スタッフ・稼働をどう持つか

人材紹介向けに設計されたCRMを派遣事業に持ち込むと、ほぼ必ず途中で行き詰まります。理由は明確で、紹介は「決まったら終わり」、派遣は「決まってからが本番」だからです。

紹介のパイプラインは入社でクローズします。派遣は就業開始がスタート地点で、そこから稼働、更新、終了までが続きます。しかも1人のスタッフが複数の就業先を経験し、1つのオーダーに複数人がアサインされます。この構造を、紹介と同じデータモデルで表現することはできません。

派遣の稼働管理の設計とは、オーダー・スタッフ・稼働という3つの単位をどのレコードで持ち、契約期間の満了日から逆算して更新業務を回す仕組みを決める作業です。管理項目を並べる作業に見えますが、実際には継続収益が途切れないようにするための業務設計です。

この記事では、HubSpotを例に、派遣事業の稼働管理をCRM上でどう設計するかを整理します。派遣事業を手がける会社で管理の仕組みを作る立場の方、紹介と派遣を両方手がけていて管理が分断している方に向けた内容です。次の4点がわかります。

• オーダー・スタッフ・稼働という3つの単位 ── それぞれをどのオブジェクトに割り当てるかの判断基準を示します
• 稼働をどこに持つか ── 取引で持つ場合とカスタムオブジェクトで持つ場合の分岐点を説明します
• パイプラインを2本に分ける設計 ── オーダー獲得とアサインを同じボードに載せない理由です
• 契約満了から逆算する更新管理 ── 更新業務を人の記憶から仕組みへ移す設計を示します

読み終える頃には、自社の派遣業務をどの単位でレコード化するかのたたき台が作れる状態になります。ぜひ最後までご確認ください。

派遣は「続く」ビジネスであることが設計を変える

まず、紹介と派遣で管理対象がどう違うのかを整理します。

紹介と派遣で、CRMに求めるものが変わる

紹介ではクローズしたレコードは過去のものになりますが、派遣ではクローズが存在しません。就業中のレコードを日常的に見る前提で設計する必要があります。

収益は「稼働している時間」から生まれる

厚生労働省の集計によれば、令和6年度の派遣労働者数は約220万人（前年度比3.9%増）、派遣先件数は約86万件（同7.9%増）、年間売上高は9兆9,005億円（同9.4%増）でした。派遣料金（8時間換算の平均）は26,257円、派遣労働者の賃金（8時間換算の平均）は16,735円です（令和6年度労働者派遣事業報告書の集計結果（速報）、2026年3月31日発表）。

この2つの数字の差が、事業の粗利の源泉です。つまり「誰が、どこで、いくらで、何時間稼働しているか」が把握できないと、粗利が読めないということになります。決定件数だけを追う設計では、派遣事業の実態は見えません。

更新漏れが最も大きな損失になる

派遣で最も痛いのは、更新の意向確認が遅れて就業が途切れることです。スタッフは別の仕事を探し始め、派遣先は別の会社に依頼します。1件の更新漏れが、そのまま継続収益の消失になります。

更新業務を人の記憶に任せない。これが派遣のCRM設計における最大の目的です。

3つの単位を分けて持つ

派遣の管理には、3種類のレコードが必要です。

これは特定の企業の実装ではなく、派遣事業でよく出てくる構造を一般化した設計例です。

オーダー・スタッフ・稼働

• オーダー：派遣先からの依頼。「この職種を、この条件で、何名」という単位です
• スタッフ：登録している派遣スタッフ。人そのものなのでコンタクトが自然です
• 稼働（アサイン）：スタッフ1人が、あるオーダーに就業している1件。ここが派遣特有の単位です

紹介では「求職者×求人＝選考」が1件でしたが、派遣では「スタッフ×オーダー＝稼働」が1件になります。似ているようで、稼働には開始日・終了予定日・更新回数・単価という時間軸の情報が乗る点が決定的に違います。

オーダーはカスタムオブジェクトで持つのが基本

オーダーは派遣先企業に紐づき、1社が複数のオーダーを持ちます。会社のプロパティーには収まりません。カスタムオブジェクトで持つのが素直な設計です。

カスタムオブジェクトの作成には、Marketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Smart CRM・Revenue Hub のいずれかの Enterprise が必要です（カスタムオブジェクトを作成する）。求人をカスタムオブジェクトで持つ考え方はHubSpotで求人を管理する方法で詳しく扱っています。

稼働をどこに持つか

稼働は、取引で持つ方法とカスタムオブジェクトで持つ方法があります。

多くの派遣会社では、稼働を取引で持つ設計が扱いやすいです。金額（派遣料金×想定稼働時間）を持て、パイプラインで状態を管理でき、レポートも標準機能で作れます。カスタムオブジェクトが必要になるのは、稼働の件数が数万件規模になり、取引のレポートが重くなる場合です。

判断に迷ったときの起点

判断の起点は、「その単位で金額を集計したいか」です。稼働ごとの売上と粗利を見たいなら取引、オーダー単位でしか金額を見ないなら稼働はカスタムオブジェクトでも構いません。

パイプラインは2本に分ける

派遣には性質の違う2つのプロセスがあります。

オーダー獲得のパイプライン

派遣先の開拓から、オーダーを受注するまでのプロセスです。担当は営業で、扱う単位はオーダーです。ステージの例を挙げると、アプローチ、ヒアリング、条件提示、契約、オーダー受注といった流れになります。

アサインのパイプライン

受注したオーダーに、スタッフを当てるプロセスです。担当はコーディネーターで、扱う単位は稼働です。候補選定、意向確認、顔合わせ、就業決定、就業開始という流れが典型です。

この2つを1本にすると、営業が見たい「受注前のオーダー」と、コーディネーターが見たい「充足待ちの稼働」が混在します。見たい人が違うプロセスは分けるのが原則です。パイプラインは Starter 以上で追加作成できます（パイプラインを設定・カスタマイズする）。

稼働中は「ステージ」ではなく「状態」で持つ

就業開始した後の稼働は、ステージを進める対象ではありません。数か月から数年、同じ状態が続きます。

ここでステージを細かく刻もうとすると、誰も動かさないステージができます。就業開始でパイプラインはクローズし、稼働中かどうかは別のプロパティー（就業状態）で持つ設計が扱いやすくなります。稼働中の一覧は、ビューで「就業状態＝稼働中」を絞れば作れます。

更新を期限から逆算する

派遣のCRMで最も価値が出るのが、この部分です。

契約期間満了日を必ず持つ

稼働のレコードに「契約期間満了日」を日付プロパティーとして持たせる。これが全ての起点です。ここが空欄のレコードがあると、その分だけ更新漏れのリスクが残ります。

満了日は必須プロパティーにしてください。就業開始のステージへ進めるときに埋めていないと進めない、という制約をかけるのが確実です。

逆算してタスクを自動生成する

HubSpotのワークフローは、日付プロパティーを基準にした実行に対応しています（ワークフローのアクションを選択する）。満了日から逆算して、段階的にタスクを作る設計が可能です。

• 満了60日前：スタッフへ更新意向の確認タスク
• 満了45日前：派遣先へ継続の打診タスク
• 満了30日前：双方の意向を確定させるタスク
• 満了15日前：書類手配のタスク

日数は業態によって変えて構いません。重要なのは、1つの期限に1回だけ通知するのではなく、段階を分けることです。1回だけだと、その日に担当者が不在なら流れます。

更新しない場合の受け皿

更新しないと決まった稼働は、そのまま放置せず「終了予定」として扱い、終了後は稼働状態を変えます。同時に、そのスタッフを次のオーダーへ当てる導線が必要です。

終了予定のスタッフ一覧をビューで持っておくと、コーディネーターが次の就業先を先回りして探せます。ここが繋がっていないと、優秀なスタッフが離れます。

交代・追加も同じ形で扱う

1つのオーダーに複数人が入る場合や、途中で交代が発生する場合も、稼働レコードを1件ずつ作ることで表現できます。オーダー側で「必要人数」と「充足人数」を持ち、稼働レコードの件数と突き合わせれば、充足状況が自動で見えます。

登録から稼働までの歩留まりを見る

派遣事業のもう1つの生命線が、スタッフの供給です。オーダーがあっても人が当たらなければ売上になりません。

登録したスタッフの多くは稼働しません

登録はしたが一度も就業していない、あるいは1回就業したきり連絡が取れない。この層は、どの派遣会社にも一定数存在します。問題は、その規模を数字で把握できていないことです。

スタッフのコンタクトに「登録状態」を持たせ、登録済み・稼働中・待機中・連絡不能といった区分で分けると、供給力の実態が見えます。区分は多くしすぎず、4〜5個に留めるのが運用しやすい範囲です。

待機中のスタッフを可視化する

稼働が終了した直後のスタッフは、次の就業先を探しています。この期間が長引くほど、他社へ流れます。

「就業終了から30日以内で、次の稼働が決まっていないスタッフ」をビューで出せるようにしておくと、コーディネーターが優先的に当てられます。待機中の可視化は、新規登録を増やすより投資対効果が高い場面が多くあります。

登録から初回稼働までの日数を測る

登録日と初回の就業開始日の差を持てば、供給のスピードが測れます。この日数が長い職種は、オーダーが来ても当てられない領域です。

数字が取れると、採用広告をどの職種に寄せるかの判断が勘から離れます。登録数だけを追っていると、稼働に繋がらない層を増やし続けることになりかねません。

面談・スキル情報は選択式で持つ

スタッフの経験職種や保有スキルを自由記述で持つと、オーダーが来たときに検索できません。主要な職種・スキル・勤務可能エリア・勤務可能時間帯は選択肢型で持ってください。マッチングの検索性については候補者と求人のマッチングをCRMで運用するで詳しく扱っています。

法令要件は基幹システムに置く判断

派遣事業には、法令に基づく管理項目があります。ここの扱いを最初に決めておく必要があります。

CRMで持たないほうがよいもの

労働者派遣法には派遣可能期間の制限があり、事業所単位・個人単位で抵触日を管理する必要があります。また、雇用契約、社会保険、給与計算、就業条件明示書といった書類の管理も伴います。

これらは法令の改正に追随する必要があり、誤りが直接コンプライアンス上の問題になる領域です。派遣管理システム（基幹システム）が対応している場合、CRM側で二重に持つべきではありません。数字がずれたときに、どちらが正しいのかを判断できなくなります。

CRMが持つべきもの

CRMが担うのは、人と関係と経緯です。

境界の目安は、「法令や会計の正確性が問われるものは基幹側、判断と経緯はCRM側」です。この線引きを曖昧にしたまま両方に持つと、必ず運用が崩れます。

連携するなら向きを決める

両方に存在する情報（稼働の開始日・終了日など）は、片方向の同期にしてください。双方向にすると、上書きの衝突が起きたときに原因を追えません。人材業界特化のシステムとの併用については人材紹介CRMのデータ設計でも触れています。

派遣で見るべき数字

設計が正しいかどうかは、必要な数字が取れるかで判定できます。

このうち更新率と終了理由は、後から設計を変えると過去分が取れません。最初から持たせておく価値が高い項目です。終了理由は自由記述ではなく選択肢型にして、「スタッフ都合」「派遣先都合」「期間満了」などを分けて集計できるようにしてください。

人材業界のマッチング運用については候補者と求人のマッチングをCRMで運用する、分業体制の設計は人材紹介のRA/CA分業をCRMで設計する、業界全体の設計観点は人材紹介・人材派遣のHubSpot活用ガイドをあわせてご覧ください。

よくある質問

派遣の稼働管理について、ご相談の場でよくいただく質問をまとめました。

Q1. 稼働を取引で持つと、取引の件数が膨大になりませんか。

稼働人数が数百人規模であれば、取引の件数としては問題になりません。年間で数万件の稼働が発生する規模になると、レポートの応答が重くなる場面が出てきます。その場合は、終了した稼働をアーカイブ用のパイプラインへ移すか、稼働をカスタムオブジェクトへ移す検討に入ります。最初から件数を心配して複雑な設計にする必要はありません。

Q2. 紹介と派遣を両方やっています。同じCRMで管理できますか。

同じアカウントで管理できます。パイプラインを分け、オブジェクトを共通で使う設計が基本です。求職者とスタッフは同じコンタクトで持ち、「登録区分」のプロパティーで分けます。同じ人が紹介の候補者にも派遣スタッフにもなり得るため、分けたアカウントにすると履歴が繋がらなくなります。

Q3. 稼働中のスタッフの状況を、どのくらいの頻度で記録すべきですか。

すべての稼働を毎月フォローするのは現実的ではありません。開始直後（1か月以内）と、更新前の2つのタイミングを必須にする設計が実務的です。この2点を押さえるだけで、早期離職と更新漏れの大半は検知できます。フォローの記録はタスクではなくメモで残し、次回のタスクを同時に作る形にすると継続します。

Q4. 単価の改定が頻繁にあります。どう持てばよいですか。

稼働レコードに現在の単価を持ちつつ、改定の履歴は別に残す設計をおすすめします。現在値だけを上書きしていくと、「いつからいくらだったか」が失われ、過去の粗利を再計算できなくなります。改定が多い場合は、稼働に紐づく期間別の明細を持つ構造を検討する価値があります。

Q5. 既に派遣管理システムがあります。CRMを入れる意味はありますか。

派遣管理システムは「契約後の実務」に強く、「契約前の営業活動」と「スタッフとの関係づくり」には弱いのが一般的です。オーダーを取る前の商談、登録したが就業していないスタッフへのフォロー、更新の意向確認といった領域は、CRMが担うほうが自然です。役割を重ねず、境界を先に決めることが両方を活かす条件になります。

まとめ

派遣の稼働管理は、紹介の設計の延長では組めません。要点を整理します。

• 派遣は決まってからが本番。就業開始がスタート地点で、稼働・更新・終了までが管理対象になります
• オーダー・スタッフ・稼働の3単位に分ける。「スタッフ×オーダー＝稼働」が派遣特有の単位で、ここに時間軸の情報が乗ります
• オーダー獲得とアサインでパイプラインを分ける。見たい人が違うプロセスを同じボードに載せない設計です
• 稼働中はステージではなく状態で持つ。数年続く状態をステージで刻むと、誰も動かさないステージができます
• 契約満了日から逆算して段階的にタスクを作る。1回だけの通知では、その日に不在なら流れます
• 法令に関わる管理は基幹システムに置く。判断と経緯をCRMが持つ、という境界を先に決めます

最初の一歩としておすすめしたいのは、「現在稼働中のスタッフ全員の契約満了日を1枚の表に書き出す」ことです。書き出せない、あるいは調べるのに時間がかかるなら、それが今の管理の弱点です。全体の設計を描く前に、この一覧が自動で出る状態を作るだけで、更新漏れは大きく減ります。

そのうえで、稼働レコードに満了日を必須で持たせ、逆算のタスクを1本だけ作る。ここから始めるのが現実的です。

自社の派遣業務に合わせた稼働管理の設計を具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現在の管理方法をうかがったうえで、設計の方向性をご提案します。