How to Set Up HubSpot for a Staffing or Recruiting Agency
A staffing firm does not sell a product and it does not run a project. It takes a requisition, submits people against it, places one or more of them, and then bills the hours they work for as long as the assignment lasts. HubSpot's standard four objects can hold the sale and nothing after it, which is why most firms run the sale in a CRM, the requisition in an ATS, the hours in a spreadsheet, and the relationship between the three in somebody's memory. This walkthrough shows the four custom objects RevOps HQ installs for staffing and recruiting firms, the cardinality decision at the centre of the model, and the fill-rate, margin and redeployment reporting that only becomes possible once the model holds.
Key takeaways
- Four custom objects sit alongside HubSpot’s standard four: job order, placement, timesheet and time entry. Between them they carry the requisition, the person working, the approval period and the hours.
- One job order fills as many placements. A requisition with four seats is one requisition and four people, and modelling it as a deal per seat inflates pipeline while modelling it as one deal loses three of the four outcomes.
- A timesheet holds many time entries, which is what allows an approval to sit on the period while each day’s hours stay individually attributable.
- A candidate and a client contact are the same object, separated by properties and associations rather than by tables. That is what lets one contact record resolve a person’s full history: every submission, placement, timesheet and time entry.
- Job order status is moved by automation rather than by dragging: a signed agreement advances the requisition, so the board reflects what happened rather than who remembered to update it.
- Bill rate and pay rate sit on the job order, which is what makes gross margin a reportable property rather than a calculation somebody performs in a spreadsheet after the fact.
- Redeployment status is recorded against the placement that ended, so the question of what happens to a contractor at the end of an assignment has an answer that can be counted.
- The reporting the model produces is the reporting the owner actually asks for: fill rate by client, submissions per fill by recruiter, gross margin by client, redeployment rate by month, time to fill by client tier.
The Object Model Decides What Can Be Reported
HubSpot ships four objects. Contacts are individual people, companies are organisations, deals are transaction opportunities, and tickets are service issues arising from them. In the CRM each object is a table: every row is a record, every column an attribute of that record.
Those four describe a business that sells something and supports it afterwards. They do not describe a staffing firm, because the two things a staffing firm actually runs — the requisition and the hours worked against it — have no table. Custom objects supply them, and the choice of which objects to create, and how they relate, determines what can be asked of the system later.
One Job Order, Many Placements
The cardinality between job order and placement is the decision that distinguishes this model from a CRM with extra fields on it. A requisition for four contractors is one requisition. It produces up to four placements, and it may produce none if it is withdrawn.
Modelling that as a deal per seat inflates pipeline: four opportunities appear where one requisition exists, and the forecast counts a client’s single decision four times. Modelling it as one deal loses the other direction, because three of the four people placed have no record of their own to carry a start date, a status or a margin. A job order that fills as many placements represents both the requisition and each person working under it, and neither figure has to be reconstructed.
The same reasoning applies one level down. A placement accrues many timesheets, and a timesheet is itemised by many time entries. Approval belongs to the period, because that is what a client signs off, while attribution belongs to the day, because that is what is billed and paid. Collapsing the two loses one of them.
A Candidate and a Client Contact Are the Same Object
Both are people, so both are contacts. What separates them is the properties they carry and the associations they hold: a candidate has a candidate status, a redeployment preference, years of experience and a skill set, and is associated to job orders through submission and to placements through assignment. A client contact is associated to a company and to deals.
Keeping them in one object is what produces the record most firms cannot assemble today. Opening a contractor shows every job order they were submitted against, every placement they held, every timesheet raised against those placements, and the status of each. Their history with the firm becomes a record of their work history, available in the conversation with the next client rather than reconstructed for it.
Status Moved by Automation, Not by Memory
A job order passes through received, qualified with client, sourcing, submitted, interviewing, filled, and closed not filled. A placement passes through offer accepted, starting, working, completed, ended early, and converted to permanent. Both can be dragged along a board by hand, and in most portals both are.
The alternative is to let the event move the record. A signed agreement advances the job order from interviewing to filled; an assignment reaching its end date raises the redeployment task; a submission that has aged past its threshold produces a chase. The board then reflects what happened rather than who remembered to update it, which is the difference between a status field that can be reported on and one that cannot.
- Qualification gate on a new job order, so an unqualified requisition does not consume sourcing time
- Submission ageing, which chases the client rather than waiting on them
- Start-date and first-week follow-up, which is where placements are most often lost
- Assignment ending, raising the redeployment conversation before the assignment closes rather than after
- Timesheet approval chasing, so unapproved hours do not age into an invoicing problem
Margin Is a Property, Not a Spreadsheet
Bill rate and pay rate sit on the job order, and gross margin is derived from them on the placement. That is a small decision with a disproportionate effect: it makes margin a value the CRM holds rather than a figure produced by exporting two systems and reconciling them.
Once margin is a property, it can be grouped by anything else the model holds. Gross margin by client, by placement status, by client tier, by recruiter. A placement that ended early and a placement that completed can be compared on margin rather than only on count, which is the comparison that tells a firm what its attrition actually costs.
The Reporting the Model Produces
Each report below is a consequence of the object model rather than of the reporting tool. None of them can be built without the objects underneath, and all of them are available immediately once the objects exist.
- Fill rate by client, and submissions per fill by recruiter
- Hiring volume on a rolling twelve months, broken down by client tier
- Job orders open over time, which is where seasonality in the business becomes visible
- Openings by job order status, and job order status as a distribution
- Gross margin by placement status, and placement status by redeployment status
- Candidate status by current client, which shows where a firm’s available bench actually sits
- Timesheet status and hours awaiting approval, as an operational rather than a financial view
- Time to fill by client tier, and assignment completion by client tier
The redeployment pair is worth dwelling on. Placement status broken down by redeployment status shows how many completed and ended-early assignments have had no redeployment conversation at all. That figure is usually higher than a firm expects, and it is invisible in any model where the end of an assignment is not a record.
What Installation Involves
The objects, properties, associations, workflows and dashboards described here are pre-built and installed into a portal directly rather than specified from scratch at implementation rates. That covers the structure common to staffing and recruiting firms, which is roughly ninety percent of the build.
What remains is specific: whether the firm runs contract, permanent or both, what its client tiers are called, which stages its job orders actually pass through, and how timesheets arrive from whatever workforce management or ATS tooling is already in place. That part is configuration against the business and is where the engagement should spend its time.
Frequently asked questions
Which HubSpot objects should a staffing agency use?
Eight. HubSpot’s standard contacts, companies, deals and tickets, plus four custom objects: job order for the requisition, placement for the person working, timesheet for the approval period, and time entry for the hours. The requisition and the hours are what the firm runs on, and neither has a table in the standard model.
Should a job order be a deal or a custom object?
A custom object. A deal represents one transaction opportunity, and a requisition for four seats produces up to four placements or none at all. A deal per seat inflates pipeline by counting a client’s single decision several times; one deal for the whole requisition leaves the people placed under it with no record of their own to carry a start date, a status or a margin.
Can HubSpot replace our ATS?
For many firms it can hold the requisition, the submission, the placement and the hours, which is most of what an ATS is used for day to day. Where a firm wants full applicant tracking, an application object is added alongside the others. The decision worth making deliberately is which system a recruiter opens to answer a question, rather than accepting whatever a connector does by default.
How do timesheets get into HubSpot?
Time entries sync from the workforce management or ATS tooling already in place, and roll up to the timesheet that holds the approval status. Keeping the entry and the sheet as separate objects is what allows approval to sit on the period while each day’s hours remain individually attributable for billing and pay.
How is gross margin tracked?
Bill rate and pay rate are properties on the job order, and gross margin is derived on the placement. Holding it as a property rather than calculating it after the fact is what makes it groupable by client, tier, recruiter or placement status.
Do we have to build this from scratch?
No. The objects, properties, associations, workflows and dashboards are pre-built and installed into your portal directly, which covers around ninety percent of the build. What remains is configuration to your stages, client tiers and timesheet source, which is where the engagement should spend its time.
Talk through the Staffing & Recruiting build
Book a timeOpens HubSpot in a new tab. The in-page calendar needs the cookies you declined.
Setting up HubSpot for your staffing or recruiting firm?
RevOps HQ is a certified HubSpot Solutions Partner. We install the job order, placement and timesheet object model in your portal, connect it to your ATS and workforce management tooling, and build the fill rate, margin and redeployment reporting your operators ask for.