厚生労働省の職業紹介事業報告によれば、令和6年度の民営職業紹介事業における新規求職申込件数は約5,545万件で、前年度比42.8%増。常用求人数は約1,789万人で38.0%増でした。ところが同じ年度の常用就職件数は約92万件、伸びは4.8%にとどまっています（令和6年度職業紹介事業報告書の集計結果（速報）、令和8年3月31日発表）。求職者も求人も4割前後増えたのに、成約の件数はほとんど動いていません。
同じ資料には、常用就職1件あたりの手数料が約103万円と記載されています。1件の取りこぼしが100万円規模の機会損失になる事業で、入口の量が4割増えても出口が5%しか増えないのであれば、ボトルネックは案件の量ではなく、案件をさばくオペレーションの側にあります。
本記事では、人材紹介業の業務工程を9つに分け、HubSpotの標準機能で完結する範囲と、そこから外に出る範囲を線引きします。そのうえで、私たちが実際にデモ環境で稼働させている業務アプリ7本の画面と設計を示します。従業員数百名規模でCA（キャリアアドバイザー）とRA（リクルーティングアドバイザー）が分業している人材紹介会社、あるいは人材派遣・RPOを兼業している企業のDX推進担当者・営業企画責任者を想定した内容です。
目次
CRMを入れても手作業が残る理由は、担当者の怠慢ではありません。人材紹介業の業務には、汎用CRMの標準的なデータモデルでは表現しきれない構造が3つ含まれています。多対多の関係、帳票としての体裁、そして「やらせない」ための統制です。この3つを標準機能の外側に置いたまま運用を始めると、そこだけがExcelとWordとして現場に残ります。
一般的なBtoB営業では、1つの会社に1つの商談が紐づきます。人材紹介業はそうなりません。1つの求人に対して複数の候補者を当て、1人の候補者を複数の求人に当てます。多対多の関係が業務の中心にあるため、オブジェクト設計の段階でここを決めておかないと、後から「推薦」という単位がどこにも存在しないCRMになります。
私たちが人材業界のポータルを設計する際は、会社＝求人企業、コンタクト＝候補者と求人企業の担当者、取引＝推薦案件（選考）、カスタムオブジェクト＝求人と採用イベント、という対応から始めます。推薦を取引として持つことで、1つの求人に複数の推薦がぶら下がり、1人の候補者からも複数の推薦が伸びる構造になります。
ここで注意すべきはエディション要件です。HubSpotの公式ナレッジベースには、カスタムオブジェクトの作成はMarketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Smart CRM・Revenue HubのいずれもEnterpriseが対象と記載されています（2026年9月18日取得時点）。一方、レコード間の関係を区別する関連付けラベルはProfessional以上が対象です。求人をカスタムオブジェクトとして持つか、取引の種別プロパティーで代替するかは、この要件差で決まります。オブジェクトを増やすべきかどうかの判断基準はHubSpotカスタムオブジェクトの設計判断と作らない基準で詳しく整理しています。
次の表は、人材紹介業の9工程について、HubSpot標準機能で完結する部分と、そこから外に出やすい部分を分けたものです。注目していただきたいのは機能の有無ではなく、右側の列に並ぶ作業の性質です。いずれも「レコードを1件ずつ開いて処理する」形に馴染まないものばかりで、だからこそ一覧性の高いExcelに戻ってしまいます。
| 業務工程 | HubSpot標準で完結する部分 | 外に出やすい作業 |
|---|---|---|
| 求人企業の開拓 | 会社レコード・活動履歴・ビューでの絞り込み | 訪問先の優先順位付け、訪問ルートの作成 |
| 求人の受注 | ミーティング記録、求人オブジェクトへの登録 | 商談メモから求人条件への転記 |
| 求人の公開前チェック | タスク、ワークフローによる通知 | 承認の強制、条件別の承認ルート、監査履歴 |
| 求人票の作成 | — | A4帳票の体裁づくり、PDF化、印刷 |
| 母集団形成（説明会・展示会） | フォーム、リスト、メール配信 | 当日受付、名刺の取り込み、出欠の反映 |
| 候補者の選定 | ビュー・フィルターでの絞り込み | 多対多のスコアリング、NG条件の除外 |
| 推薦 | 取引レコード、パイプライン管理 | 二重推薦の検知とブロック |
| 選考進行・ヨミ | パイプライン、フォーキャストツール | 確度×ステージの二軸集計、想定手数料の内訳 |
| データ整備 | インポート、一括編集 | 大量更新の権限別の出し分け、更新履歴の追跡 |
右側の列がゼロになることはありません。重要なのは、この列に何が残るかを導入前に把握し、残るものを誰がどの手段で引き受けるかを決めておくことです。
CRMの定着支援で最初に確認するのは、入力率の低いプロパティーの一覧です。そこに並ぶのは、ほぼ例外なく「入力しても入力した本人には返ってこない項目」です。経営が見たい集計のためだけに存在する項目は、現場にとって報告作業でしかありません。
逆に、入力すると自分の仕事が軽くなる項目は放っておいても埋まります。求人条件を埋めればマッチする候補者が並ぶ、ステージを動かせばヨミ表が更新される、訪問を記録すれば翌日の訪問先が提案される。この因果を設計に組み込めるかどうかが、入力率を左右します。組織横断でデータが分断されたまま定着に失敗する構造については組織のサイロ化を解消するデータ設計でも扱っています。
足りない機能をどう埋めるかには3つの選択肢があります。設定で解決する、レコード画面の中にカードを足す、外部アプリを別タブで動かす。この判断を業務ごとに下せるかどうかが、投資額と運用負荷を決めます。順番は常に「設定で足りないか」から検討します。
入力を減らす目的なら、多くの場合は設定の範囲で解決します。ワークフローで他のレコードを作成・更新し、カスタムレポートで集計する。この2つで済む業務にアプリを作るのは過剰投資です。
私たちのデモ環境では、この範囲だけで次の自動化を組んでいます。ミーティングログから求人オブジェクトのレコードを作成し、会社とコンタクトのプロパティーを更新し、商談メモの内容を求人詳細プロパティーへ反映する。履歴書PDFのアップロードを起点に、候補者コンタクトの各プロパティーへ内容を振り分ける。RAが商談後にメモを書けば求人レコードが立ち上がり、CAが履歴書を置けば候補者情報が埋まる状態です。
ワークフローの設計思想そのものについてはHubSpotワークフローとは、除外条件と目標設定の実務はワークフロー活用術で解説しています。パイプラインの自動化設定のように、パイプライン設定側から組めるものも少なくありません。
レコード画面を離れずに済ませたい情報は、UI extensionsで作るカードに向いています。見るだけ、あるいは軽い操作で完結する用途です。私たちが用意しているのは2種類で、取引・会社のレコード画面に、関連する面接の予定と結果を時系列で表示するカードと、ヨミ確度別の想定手数料集計を表示するカードです。HubSpot内で完結するため、外部アプリのような月額利用料は発生しません。
ここもエディション要件を確認してから設計します。HubSpotの開発者向け変更履歴には、2024年11月14日以降、Hubの種類を問わずEnterpriseティアであればプライベートアプリのアプリカードを構築・利用できると記載されています。それ以前はSales HubとService HubのEnterpriseのみが対象でした（App Cards for Private Apps Now Available Across All Enterprise Tiers）。同じ変更履歴には、マーケットプレイス経由の公開アプリのカードはこの制限の対象外である旨も記載されています。Professional環境でカードを使いたい場合、この差が選択肢になります。
カードで何を出し、何を出さないかの整理は開発者プラットフォームの概要とプライベートアプリの構築ガイドが出発点になります。
カードの中に収まらない処理は、外部アプリとして持ちます。判断基準は画面の広さではなく、処理の性質です。次の5類型に当てはまるものは、設定やカードでは実装できません。
3番目が最も見落とされます。画面上のボタンを隠したりバリデーションを表示したりするだけの実装では、URLを直接叩けば処理が通ってしまいます。承認を必須にしたいのであれば、発行処理の直前にサーバー側で承認状態を確認する必要があります。監査に耐える統制を作るかどうかは、ここの実装方法で決まります。私たちがこれらのアプリを設計する際は、APIキーをすべてサーバー側でのみ扱い、ブラウザ側には渡さない構成を前提にしています。
RAの訪問先選定は、担当者の記憶と勘に依存しやすい業務です。求人数の多い企業、しばらく接触できていない企業、近くにある未接触の企業。この3つを頭の中で突き合わせられる人はいますが、組織として再現はできません。企業マップ＆訪問プランナーは、この判断材料を地図の上に並べます。
優先度は、募集中の求人数と最終接触からの経過日数から算出します。求人を多く抱えていて、かつ接触が途切れている企業が上位に来る設計です。画面右側には「今日回るべきTOP5」が並び、各社の求人件数と接触履歴の有無が添えられます。業界・募集職種・担当者・提案中/導入済みサービス（人材紹介、人材派遣、RPO、ダイレクトリクルーティング支援、採用ブランディングなど）での絞り込みもできるため、サービス別の深耕先も同じ画面で探せます。
訪問先を選ぶと、回る順番が自動で組み直されます。出発時刻と各社の滞在時間から到着予定を計算し、ルートの近くにある未接触企業を「ついで訪問」として提案します。確定した計画は訪問計画書のPDFとして1クリックで出力できます。地図の表示はGoogle Mapsを利用する構成にも対応していますが、その場合はGoogle側のAPIキーをお客さまからご提供いただく前提になります。
訪問先でチェックインすると、HubSpotに活動として記録され、会社レコードの最終接触日が更新されます。更新された最終接触日は翌日以降の優先度スコアの入力値になるため、回った実績がそのまま次の提案に反映されます。入力が自分の翌日の段取りに返ってくる構造で、これが定着の条件になります。
求人情報の表示には法令上の義務が伴います。厚生労働省は、職業紹介事業者や募集情報等提供事業者に対し、令和4年職業安定法の改正により求人等に関する情報の的確な表示を義務付けており、虚偽の表示または誤解を生じさせる表示をしてはならないと規定しています（厚労省リーフレット）。令和6年4月からは募集時等に明示すべき事項も追加されています。求人票の中身を担当者の注意力だけで担保するのは、この規制環境では無理があります。
承認ワークフローは、求人公開前の承認を必須の工程として挟みます。承認ルートは条件に応じて1段階と2段階が自動で切り替わり、最低賃金に抵触する可能性のある条件や、高年収案件は自動で2段階に回ります。最低賃金は毎年改定されるため、閾値の更新は運用に組み込む必要があります（地域別最低賃金の全国一覧には2026年9月18日取得時点で令和7年度分が掲載されています）。承認者はHubSpotのユーザーから割り当てるため、ユーザー権限の管理と二重管理になりません。
誰がいつ承認・却下したかは、コメント付きでHubSpotのレコードのメモに記録されます。却下から修正、再申請までのライフサイクルも同じ画面で管理するため、差し戻しの理由が口頭で消えません。担当者の異動や労働局の調査で経緯を遡るとき、履歴がCRM側に残っていることが効きます。承認待ちの案件は既定フィルターで自分の分だけを件数バッジ付きで表示でき、承認の滞留を可視化できます。運用要領の確認が必要な場合は、厚労省の職業紹介事業の業務運営要領が一次情報になります。
求人票発行アプリは、CRMの求人データからA4の求人票を生成します。雇用形態・勤務地・勤務形態・想定年収・月所定労働時間・言語要件といった項目が定型のレイアウトに流し込まれ、承認日のスタンプ付きでプレビューされ、そのままPDF保存と印刷ができます。Wordへの転記と整形の工程がなくなるため、体裁が担当者ごとにばらつきません。
この2つのアプリは連動しています。発行処理の直前にサーバー側で承認状態を確認するため、未承認や却下済みの求人票は発行そのものができません。未承認の求人を開いた場合はロック画面と承認ワークフローへの導線が表示され、修正・再申請の流れにつながります。「急ぎだから承認前に出してしまう」という運用上の抜け道を、仕組みとして閉じる設計です。
候補者選定は、レコードを1件ずつ開いて経験と希望を読む作業になりがちです。100名の母集団に対してこれをやると、それだけで半日が消えます。候補者マッチングアプリは、求人レコードから起動した時点で対象候補者を並べ、開く前に見極められる状態を作ります。
スコアは職種、年収、経験、NG条件から算出します。一覧には氏名・希望職種・経験年数・希望年収・NG条件が列として並び、どの要素でスコアが付いたかを確認できます。最低マッチ度のスライダーと最低経験年数で母集団を絞り込めるため、「まず60点以上を見る」といった運用に乗せられます。候補者起点で「合う求人を探す」場合も同じエンジンが動きます。
NG条件に該当する候補者は一覧から自動で除外され、除外件数が画面上部に表示されます。同一の候補者×求人の二重推薦はサーバー側でブロックし、すでに推薦済みの候補者にはバッジが付きます。応募が進行中の候補者も表示が分かれるため、他のコンサルタントが動かしている案件に重ねて打診する事故を防げます。冒頭で触れた「1件あたり約103万円」の単価を踏まえると、事故1件の代償は謝罪の工数だけでは終わりません。
一覧で候補者を選び「紹介する」を押すと、推薦レコード（取引）が作成され、選考パイプラインのステージ管理に乗ります。打診リストが別のスプレッドシートとして独立しないため、選定と進捗管理の間に転記が発生しません。求人レコードから開いた場合は対象求人が固定され、複数の求人を並行して見ているときの取り違えを防ぎます。
ヨミ表は、案件ごとの確度と金額を見込みとして束ねた売上予測です。人材紹介業では、選考ステージとヨミ確度という2つの軸で見る必要があるため、標準のフォーキャスト機能だけでは表の形が作れません。結果として、CSVを書き出してExcelでピボットを組む作業が毎月発生します。
選考ヨミ表アプリは、パイプラインのステージ構成をCRMから自動で取得し、ヨミ確度との二軸で集計します。新規マッチ、書類選考中、求人紹介中、面接中、オファー交渉中、内定承諾（成約）、不合格、辞退といったステージごとに、件数・想定手数料・構成比が並びます。集計ビューはステージ別・ヨミ確度別・担当者別を切り替えられ、セル単位のドリルダウンで数字の根拠になっている案件まで辿れます。ヨミ会で「この2,000万円の内訳は何か」と聞かれた場合に、その場で答えられる状態です。
集計元はCRMのレコードそのものなので、選考ステージの変更は次の集計に反映されます。Excelに書き出した時点で実態との乖離が始まる構造をなくすことが、このアプリの本来の目的です。パイプラインの通過条件はパイプラインのルール設定で縛れるため、ステージ運用の精度そのものもHubSpot側で担保できます。
ヨミ表を開かずに、担当している企業や案件の状況だけ確認したい場面があります。その用途には前述のUI拡張カードを使います。取引・会社のレコード画面に、関連する面接の予定と結果、ヨミ確度別の想定手数料集計を直接表示します。集計の全体像はアプリで、個別レコードの文脈はカードで。この役割分担にしておくと、現場が画面を行き来する回数が減ります。
母集団形成のイベントは、事前準備・当日運営・事後フォローで担当も道具も分かれがちです。招待メールはマーケティング担当、当日の受付は現場、名刺の入力は事務、フォローはCA。この分断のせいで、イベントの成果がCRMに揃って残りません。イベント管理アプリは、この3フェーズを業務フロー順のメニューとして1画面に並べます。
招待、リマインド、出席者向けのお礼、欠席者向けのフォロー、SNS告知文を、AIが一括で生成します。生成物は本文入りの下書きとしてHubSpotへまとめて登録されるため、内容を人が確認してから送信します。アプリから直接送信することはありません。文面には設定画面で定義した文体・トーンの指示が自動適用され、HubSpotのブランドボイス設定と揃えることもできます。
事前登録者はチェックインで受付し、飛び込み参加は名刺を撮影するだけでコンタクトに登録されます。重複は既存レコードに統合されるため、同じ人が別レコードとして増えません。事前の参加者取り込みはCSVインポートにも対応しています。
サマリー画面には参加登録数・出席数・出席率・名刺交換数が並びます。終了後は出欠のセグメントからリストを作成し、参加者に対して取引を一括作成できます。「説明会に来た人のうち、まだ面談していない人」を抽出して次の打ち手に回すところまでが、同じ画面の中で完結します。
ここまでの6本は、データが揃っていることを前提にしています。その前提を作るのが最後の1本です。地味な領域ですが、AIを業務に載せる段階で最も効いてくるのはここです。データが分断されたままでは、どのAI機能も精度が出ません。SSOT（信頼できる唯一の情報源）を先に作る理由はそこにあります。
Excelライク一括編集アプリは、取引やカスタムオブジェクトをシート形式で表示します。セル選択、コピー＆貼り付け、一括入力バー、キー操作に対応しているため、Excelの操作感のまま数十行を更新して保存できます。パイプライン・取引ステージ・担当者でのフィルターと、列の並び替えも同じ画面で行えます。HubSpot標準のレコードの一括編集で足りる場面も多いため、シート型UIが必要かどうかは更新頻度と1回あたりの行数で判断します。
一括更新の自由度は、統制とのトレードオフになります。このアプリではHubSpotアカウントでログインし、担当者は自分のレコードだけ、管理者は全件と表示項目の設定まで、という出し分けをサーバー側で強制します。表示項目が未設定のパイプラインでは標準の取引項目のみが表示され、項目の追加は管理者の設定後にのみ可能になります。誰がいつ何を変えたかの更新履歴も自動で記録されるため、一括更新でも変更を追跡できます。
一括編集は、溜まってしまったデータを直す手段です。そもそも入力を減らす設定は、前述のワークフロー側で組みます。ミーティングログを起点にしたレコードの作成・更新、履歴書PDFからのプロパティー振り分け、レコードの関連付けとラベル付けの自動化。この2つを組み合わせて、「直す量を減らしてから直す」順序にします。データサイロを放置したまま一括編集ツールだけ導入すると、間違ったデータを高速に量産することになります。
ここまで読んで「専用のATSを入れれば済むのではないか」と考える方もいるはずです。その判断は十分にあり得ます。選択肢を公正に並べたうえで、自社の条件に合うものを選ぶべき論点です。以下は公開情報と私たちの支援経験に基づく整理で、特定製品の優劣を述べるものではありません。
| 観点 | 専用ATS・人材紹介システム | 内製（社内開発・ノーコード） | HubSpot上に業務アプリを追加 |
|---|---|---|---|
| 立ち上がりの早さ | 速い（業界標準の機能が揃っている） | 遅い（要件定義から始まる） | 標準構成なら速い |
| 自社業務への適合 | 製品の型に業務を合わせる | 完全に合わせられる | ロジック・画面の調整で合わせる |
| データの置き場 | ATS側に分散しやすい | 設計次第 | CRMに集約される |
| マーケティング連携 | 製品により差が大きい | 都度実装 | CRMと同一基盤 |
| 継続コスト | ユーザー数課金が中心 | 人件費と保守が固定で乗る | 初期費用＋運用の持ち方で変動 |
| 撤退のしやすさ | データ移行の負荷が大きい | 属人化すると動かせない | データはCRM側に残る |
表に載らない論点が1つあります。社内に専任のエンジニアがいない組織で内製に踏み込むと、作った本人の異動で止まります。私たちが見てきた範囲では、この止まり方が最も復旧しにくい失敗です。CRM全社導入が失敗する組織要因についてはCRM全社導入で失敗する企業と成功する企業で整理しています。
できます。実際に多いのは、候補者側の実務はATS、求人企業側の開拓と収益管理はHubSpot、という分担です。この構成で論点になるのは、どちらを正とするかの決定です。両方で同じ項目を更新できる状態にすると、必ず食い違います。オブジェクト単位で「正はどちらか」を決め、片方向の同期に寄せるのが原則です。
3つあります。第一に、HubSpotのライセンス費とは別に費用が発生します。第二に、地図や生成AIなど外部APIを使う機能では、API側の利用料が実費で乗ります。第三に、運用主体を決める必要があります。私たちの環境で運用・保守まで引き受ける形と、お客さまの環境でLovableをご契約いただき自社で運用する形の2通りがあり、後者は管理権限付きでチャット操作による修正ができる代わりに、運用の責任がお客さま側に移ります。独自環境への載せ替えは個別の相談になります。
プロセスの定義です。どの選択肢を選んでも、選考ステージの意味、ヨミ確度の定義、NG条件の基準が揃っていなければ、道具は動きません。ツール選定より前にここを揃える作業が、実際には最も時間を要します。GTMエンジニアリングで扱っているのは、この上流の設計です。
見積書の総額を1つの数字として眺めていると、どこを削れるのかが分かりません。稟議に出す資料としては、費用を3つの層に分解しておくほうが通りやすくなります。金額は要件によって変わるため個別のお見積りになりますが、内訳の構造は先に把握できます。
初期費用は、アプリごとの標準導入と、そこへの加算で決まります。標準導入に含まれるのは、HubSpotとの接続設定、項目の対応づけ、初期設定、動作確認までの一式です。用語・表示項目・選択肢の差し替えといった軽微な調整は標準導入の範囲に含みます。
加算が発生するのは、内容が次のどちらかに当たる場合です。判定ロジックや画面構成の変更、項目の追加は「調整」。オブジェクトの追加、外部システムとの連携、新しい処理の追加は「拡張」で、こちらは業務整理・プロセス整備・設計の工程を含みます。区分はアプリの種別では変わらず、依頼内容の区分で決まります。複数のアプリを同時に導入する場合は、HubSpot接続・認証・初期設定の共通部分をまとめられるため、1本ずつ導入するより初期費用を抑えられます。
月額は運用の持ち方で2通りに分かれます。私たちの環境で運用し保守まで引き受ける形と、お客さまの環境で運用する形です。前者はアプリ単位の課金で、AI機能を使うアプリは利用量で変動します。後者はアプリ数によらない課金で、購入クレジット数によって変動します。どちらを選ぶかは、社内に管理を持ちたいかどうかと、アプリを何本入れるかで決まります。
いずれの場合も、HubSpotのライセンス費、AIを使う場合の利用料（実費）、お客さま側のデータ整備・移行は含みません。HubSpot本体の導入支援費用の相場観についてはHubSpotの導入支援は必須？公式オンボーディング費用の実額で公式の価格情報を整理しています。
これらのアプリはAIで組み上げているため、標準構成であればカスタマイズなしで1ヶ月以内の稼働開始が目安です。従来のスクラッチ開発で数ヶ月かかっていた領域が、この期間に収まります。ただしHubSpot本体の初期設定（プロパティー設計、ビュー設定、ドメイン設定、自動化の構築）は別の工程です。CRMそのものがまだ整っていない場合は、本体設定とアプリ導入の順序を決めてから着手します。
7本すべてを同時に入れる必要はありません。むしろ、最初の1本で現場の手応えを作れるかどうかが、その後の展開を決めます。選び方には2つの型があります。
統制系（承認ワークフロー・求人票発行）か、集計系（選考ヨミ表）から始めるのが定石です。前者は「未承認の求人票が出回らなくなった」という形で、後者は「ヨミ会前の集計がなくなった」という形で、効果が1ヶ月以内に目に見えます。マッチング系は効果が大きい反面、候補者データの整備状況に成果が左右されるため、データがまだ薄い段階では手応えが出にくくなります。
導入後に効果を説明するには、導入前の数字が必要です。求人票1件あたりの作成時間、ヨミ表集計の月次工数、二重推薦の発生件数、最終接触から90日を超えた求人企業の社数、求人受注から公開までのリードタイム。この5つは、いずれも導入前に測っておけば前後比較ができます。測っていないと、「楽になった気がする」以上の報告ができません。
まず、使われていないのが特定の人か、全員かを切り分けます。特定の人なら運用の説明で解ける場合が多く、全員なら設計側の問題です。全員が使っていない場合に確認するのは、その画面を開く理由が業務フローの中に組み込まれているかどうかです。「余裕があれば見る画面」は誰も開きません。朝の訪問先決定、推薦前の候補者選定、ヨミ会前の確認のように、既存の業務の手順に組み込まれているかを見直します。
アプリ本体は別タブで動作するため、HubSpot側のエディション要件はアプリが参照するオブジェクトによって変わります。求人などをカスタムオブジェクトとして持つ構成ではEnterpriseが必要です（公式ナレッジベース、2026年9月18日取得時点）。レコード画面内のUI拡張カードについては、プライベートアプリのアプリカードがEnterpriseティア対象であることが開発者向け変更履歴に記載されています。ご利用中のエディションでどこまで実装できるかは、ポータルを確認したうえで個別にお答えします。
できます。その場合はオブジェクト単位で「どちらを正とするか」を先に決めます。候補者はATS、求人企業と収益管理はHubSpot、という分担が一般的です。双方向で同じ項目を更新できる状態にすると必ず食い違うため、片方向の同期に寄せる設計を推奨します。
アプリはHubSpotのAPIを通じてレコードを参照・更新します。APIキーはすべてサーバー側でのみ扱い、ブラウザ側には渡しません。どのオブジェクトのどのプロパティーにアクセスするかは導入時に確定させるため、範囲を限定できます。個人情報の取扱いに関する社内規程やプライバシーポリシーとの整合は、導入前の確認事項として設計に含めます。
いま測っていない場合、導入を止めてまで計測期間を取る必要はありません。現実的なのは、導入と同時に「これまでの作業を再現した場合の所要時間」を担当者3〜5名にヒアリングして代替値にする方法です。精度は落ちますが、前提を明記すれば稟議の根拠にはなります。次の施策では導入前の計測を工程に入れてください。
運用主体を私たちの側に置く形を選べば、開発者は不要です。お客さまの環境で運用する形を選ぶ場合は、管理権限を持つ担当者が1名以上必要になります。この場合はチャット操作でアプリを修正できますが、変更内容の検証と統制は自社側の責任範囲になります。
ありません。イベント管理アプリの生成物は、本文入りの下書きとしてHubSpotに登録されるところまでで止まります。送信操作は人が行います。文面の品質を上げる方向では、ブランドボイスの設定を揃えるのが効果的です。
アプリは業界別の設定を差し替えられる構成にしているため、他業種への展開は可能です。ただし人材派遣は稼働管理と請求、SESは要員のアサイン管理が中心になるため、求人票発行や二重推薦ブロックの重みは変わります。どのアプリが自社の業務に効くかは、工程の棚卸しから判断します。
用途によっては代替できます。汎用的な帳票出力や地図表示の連携アプリは存在します。代替が難しいのは、自社の選考ステージやNG条件の定義に依存する処理と、サーバー側で止める必要がある統制です。既存アプリで足りる部分は既存アプリを使い、業務固有の判定だけを作るのが、費用としては最も軽くなります。
7本のアプリは、それぞれ別の工程の詰まりを解いています。全部入れることが目的ではなく、自社でいま最も時間を奪われている工程から1本を選ぶのが現実的です。次の一覧は、どのアプリがどの工程に効き、何を統制しているかをまとめたものです。
| アプリ | 解決する業務 | 起動場所 | 統制のポイント |
|---|---|---|---|
| 企業マップ＆訪問プランナー | 訪問先の優先順位付けとルート作成 | 会社のレコード | 訪問実績が次の優先度に反映される |
| 承認ワークフロー | 求人公開前の承認と履歴管理 | 求人のレコード | 条件別の自動ルート切替と監査履歴 |
| 求人票発行 | A4求人票の生成とPDF出力 | 求人のレコード | 承認済みのみ発行するサーバー側ゲート |
| 候補者マッチング | スコア順の候補者選定と打診 | 求人・コンタクトのレコード | NG条件の自動除外と二重推薦ブロック |
| 選考ヨミ表 | 確度×ステージの集計と予測 | 取引のレコード | 集計元がCRMなので実態とずれない |
| イベント管理 | 説明会・展示会の一貫運営 | 採用イベントのレコード | 生成した文面は下書き登録までで停止 |
| Excelライク一括編集 | 大量レコードの更新 | 別タブ（カードは起動用） | 権限による出し分けと更新履歴の記録 |
| UI拡張カード | 面接予定・ヨミ集計の表示 | 取引・会社のレコード内 | HubSpot内で完結し月額利用料なし |
冒頭の数字に戻ります。求職者も求人も4割増える市場で、成約が5%しか増えないのであれば、次に投資すべきは集客ではなくオペレーションです。人材紹介業のHubSpotは、標準機能で7割まで回ります。残りの3割を現場のExcelに残すのか、仕組みとして持つのか。その判断が、1件約103万円の単価で積み上がる差になります。
株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして、CRMの設計から定着までを支援しています。人材業界向けの業務アプリは、デモ環境で実際に動く状態をご覧いただけます。自社のどの工程から着手すべきかの整理を含めて、お問い合わせフォームからご相談ください。