GoHighLevel for Recruitment Agencies: Setup (2026)
GoHighLevel for Recruitment Agencies: Setup (2026)
By Dr Priya Jaganathan, GoHighLevel Certified Admin · HL Growth Partner, Australia · Updated 28 August 2026 · 9 min read
Setting up GoHighLevel for recruitment agencies is harder than setting it up for a plumber or a physio, and the reason is structural rather than technical. Recruitment is two-sided. You are selling to client employers and simultaneously managing a candidate market, and those two groups need entirely different pipelines, different messaging rules and different reporting. Most sub-accounts I inherit from Australian staffing firms have one pipeline with candidates and vacancies jumbled together, which makes time-to-fill impossible to measure and makes SMS blasts genuinely risky.
The build that works is deliberately boring: one sub-account, two pipelines, a hard separation between candidate contacts and client-employer contacts, and a small set of custom fields that carry the recruitment data your consultants actually type into notes today. Everything else — application forms, screening surveys, round-robin interview calendars, placement agreements with e-signature, redeployment campaigns — hangs off that foundation. This guide walks through it in the order I build it for a client, and it finishes with an honest note about where a dedicated applicant tracking system still beats HighLevel for recruitment agencies and how to sit the two side by side.
The two-sided data model: candidates versus client employers
Contacts in GoHighLevel are flat. There is no built-in notion of a candidate record versus a company record, so you have to impose one. Get this wrong and every subsequent decision — segmentation, automation entry, reporting — inherits the mess.
Option 1: tags plus a record-type custom field
The lightest approach and the one I use for agencies under about 5,000 contacts. Create a single-select custom field called Record Type with values Candidate, Client Contact and Referrer, and mirror it with tags type-candidate and type-client. The tag drives smart list filters and workflow entry conditions; the field drives clean reporting and stops a consultant accidentally ringing a hiring manager with a shift offer. Every intake point — form, survey, manual add, import — must set both. No exceptions, or you will be cleaning it up in six months.
Option 2: custom objects for vacancies
Custom objects are where this gets interesting. A vacancy is not a contact and it is not really an opportunity either — one vacancy can carry five shortlisted candidates. Modelling vacancies as a custom object with fields for role title, award classification, pay rate, location, start date and hiring manager, then associating candidate contacts to it, gives you a structure that actually reflects the work. If you are new to this, my walkthrough on GoHighLevel custom objects and data modelling covers the association setup step by step. Be realistic though: custom object reporting is still thinner than contact and opportunity reporting, so keep your headline metrics on the pipelines.
Option 3: two pipelines, which you need regardless
Whatever you choose above, you need two pipelines. Opportunities are where GoHighLevel's reporting lives, so the candidate journey and the business development journey each get their own. This is the single highest-value change I make in a recruitment sub-account.
Building the candidate pipeline
Six stages. Applied, Screened, Shortlisted, Interviewing, Placed, Guarantee period. Resist the urge to add more — I have seen an eleven-stage candidate pipeline where consultants simply stopped moving cards because it was too much admin, and a pipeline nobody updates is worse than no pipeline.
The Guarantee period stage is the one agencies forget. Most Australian placement agreements carry a replacement guarantee of somewhere between four and twelve weeks. Keeping placed candidates visible in a stage until that window closes means your check-in automation runs, your invoice milestones fire, and you spot a wobble at week three instead of hearing about it when the client asks for a refund.
| Stage | What moves it | Automation that fires | Owner |
|---|---|---|---|
| Applied | Application form submitted | Confirmation email, resume upload request if missing, tag type-candidate | Unassigned / resourcer queue |
| Screened | Screening survey completed or phone screen logged | Right-to-work and referee reminder, score written to custom field | Resourcer |
| Shortlisted | Consultant moves card manually | Internal Slack/email alert to consultant, candidate SMS advising submission | Consultant |
| Interviewing | Booking made on round-robin calendar | Confirmation, 24-hour and 2-hour reminders, no-show follow-up | Consultant |
| Placed | Placement agreement signed in Documents & Contracts | Opportunity value set to fee, onboarding sequence, invoice task | Consultant |
| Guarantee period | Start date reached | Day 1, day 7, day 30 check-in SMS to candidate and client | Account manager |
Set the opportunity value to the placement fee, not the candidate's salary. It is a small discipline that makes your pipeline value column mean something. For the mechanics of stage automation and pipeline permissions, see my guide to GoHighLevel pipelines and opportunities setup.
The client and business development pipeline
The second pipeline tracks the employer side: Enquiry, Vacancy briefed, Shortlist sent, Placement, Invoice. Cards here belong to a hiring manager contact tagged type-client, and the opportunity name follows a convention like Acme Logistics – Forklift Operator – Laverton so consultants can search it later.
Two automations earn their keep immediately. First, a stale-vacancy alert: if an opportunity sits in Vacancy briefed for more than five business days with no shortlist sent, the consultant gets a task and the manager gets a notification. Vacancies go cold quietly. Second, an Invoice stage trigger that fires the internal handover to accounts with the fee, start date and guarantee end date pulled from custom fields, so nobody re-keys it. If you also run a professional services arm, the intake logic in my post on GoHighLevel client intake for accountants maps across almost directly.
Application intake, screening surveys and document handling
Keep the application form short — name, mobile, email, role applied for, right to work in Australia, resume upload. Every extra field costs you applicants. Do the depth in a separate survey sent immediately after submission, where conditional logic can branch by role type: a survey for trades candidates asking about tickets and white cards looks nothing like one for aged care asking about NDIS worker screening and police checks.
Surveys support scoring, and this is underused. Score right-to-work status, licence currency and availability, write the total to a custom field, then have the workflow move anything above your threshold to Screened automatically and route the rest to a nurture list rather than the bin. The field and conditional logic setup is covered in GoHighLevel forms and surveys for lead capture.
Resumes and placement agreements
File upload fields on forms drop resumes onto the contact record, which is fine for volume roles. For anything where the consultant needs to compare four resumes side by side, you will still be exporting. Placement agreements, terms of business and candidate consent forms are a better fit: build them in Documents & Contracts, populate with custom values so the fee percentage, guarantee period and role details merge in, and take an e-signature. Signature completion is a workflow trigger, so the card moves and the invoice task creates itself. My guide to GoHighLevel documents, contracts and e-signatures has the template and trigger detail.
Interview scheduling and SMS compliance
Use a round-robin calendar per desk rather than per person. If three consultants cover healthcare, the healthcare calendar distributes bookings among them with availability pulled from each connected Google or Outlook calendar. Set a meeting buffer, a minimum scheduling notice of at least two hours, and a booking window that respects the time zone the candidate is actually in — a Perth candidate booking into a Sydney consultant's diary is where most double-bookings originate. The configuration specifics are in GoHighLevel calendars and round-robin booking.
SMS, ACMA and opt-out handling
Recruitment agencies send a lot of SMS, and shift offers to a candidate database are exactly the kind of bulk messaging that attracts attention. Under the Spam Act and the associated industry code administered by the Australian Communications and Media Authority, commercial electronic messages need consent, clear sender identification and a functional unsubscribe. Consent obtained when someone applied for a role two years ago is thinner than most agencies assume.
Practically: capture explicit SMS consent at application with an unticked checkbox, store the date and source in custom fields, include agency name in the message, honour STOP replies automatically and never route bulk sends through a number that also handles two-way consultant conversations. Transactional messages about a specific interview a candidate booked sit differently to a blast advertising unrelated vacancies — treat the second category as marketing. More detail in my post on GoHighLevel SMS compliance in Australia.
Conversation AI for first-pass screening, and where not to use it
Conversation AI handles the repetitive top of the candidate funnel well: confirming a candidate still wants the role, checking availability and shift preference, asking whether they hold a specific ticket, and rebooking a missed interview. Point it at a knowledge base built from your role descriptions, keep the bot scope narrow, and set it to hand off to a human the moment the conversation leaves those rails.
Where I switch it off: any conversation about pay negotiation, any decline or rejection message, anything touching a candidate's health, disability, visa or personal circumstances, and any client-employer conversation at all. Hiring managers notice a bot instantly and it reads as disrespect. There is also a fairness dimension — automated screening that filters candidates on criteria you have not examined carefully can produce discriminatory outcomes, and "the AI did it" is not a defence. Keep the human decision at Shortlisted.
Australian Privacy Act obligations for candidate data
This is general information, not legal advice, and a recruitment agency handling this volume of personal information should get its own advice. That said, the shape of the obligation is worth understanding before you build. Candidate records typically contain personal information and often sensitive information — health details, criminal history checks, sometimes racial or ethnic data collected for diversity reporting — which carries stricter handling rules under the Australian Privacy Principles published by the Office of the Australian Information Commissioner.
In build terms that means: a privacy collection notice linked from every application form, a clear purpose for each field you collect, restricted user permissions so contractors and resourcers only see the contacts they need, and a retention policy you actually run rather than a database that grows forever. Set a workflow that flags candidate records with no engagement for a defined period so someone reviews whether to archive them. Also think about where data goes — integrations, exports to spreadsheets and third-party job board syncs all extend your footprint.
Redeployment, database reactivation and reporting
Your placed-candidate database is the most valuable and most neglected asset in the account. Contracts end, and a candidate who did twelve months at a good client is worth far more than a cold applicant. Build a redeployment workflow driven by a contract end date custom field: sixty days out, a personal-sounding SMS or email from the original consultant asking about next steps. Segment past placements by skill tag so a new vacancy can trigger a targeted send to fifty relevant people rather than a blast to five thousand.
For reporting, two numbers matter more than the rest. Time-to-fill comes from the gap between the client opportunity's Vacancy briefed date and the candidate opportunity's Placed date — capture both as date custom fields via workflow so you are not relying on stage-change timestamps alone. Placement value comes straight from opportunity value in the client pipeline, split by consultant and by client. Build a dashboard with pipeline value by stage, conversion from Shortlist sent to Placement, and source attribution on candidate applications so you know whether Seek, referrals or your own funnels are producing placements. Agencies running similar deal-flow reporting will recognise the pattern from GoHighLevel setup for mortgage brokers.
Where a dedicated ATS still beats GoHighLevel
Being straight about this saves everyone time. A purpose-built ATS such as JobAdder, Bullhorn or Vincere does several things HighLevel does not: resume parsing that reads a CV and populates structured fields, Boolean search across resume text, multi-posting to Seek and Indeed from one screen, compliance document expiry tracking for tickets and licences, and timesheet-to-payroll for temp and contract desks. If you place high volumes of temporary staff, none of that is optional.
The sensible split for those agencies is ATS as the candidate system of record and GoHighLevel as the marketing, communications and business development layer — SMS, email nurture, funnels, calendars, client pipeline. Connect them by webhook or through Zapier/Make, syncing on a small number of events: new placement created, contract end date changed, candidate opt-out status. Keep the sync narrow and one-directional per field so you never have two systems arguing about which record is correct. For permanent-only agencies under about three consultants, GoHighLevel on its own is usually enough.
Common mistakes to avoid
- Running candidates and vacancies through a single pipeline, which makes time-to-fill and placement value unmeasurable and guarantees a consultant eventually sends a candidate SMS to a hiring manager.
- Blasting the entire candidate database with shift offers on consent captured years ago, with no opt-out field and no record of when or how consent was obtained.
- Leaving placed candidates in a closed-won stage with no guarantee period tracking, so replacement risk is invisible until the client complains.
- Letting Conversation AI handle rejections, pay discussions or client-employer conversations instead of stopping it at availability and logistics questions.
- Collecting police checks, health information and visa details on forms with no privacy collection notice and no user-permission restrictions on who can view them.
- Building eleven pipeline stages because they mirror an old spreadsheet, then wondering why nobody updates cards.
If you want a recruitment-ready GoHighLevel build with candidate and client pipelines running side by side, book a strategy call with the HL Growth Partner team.
Frequently asked questions
Can GoHighLevel replace an applicant tracking system entirely?
For a permanent-placement agency with a handful of consultants and moderate application volume, yes — two pipelines, forms, surveys, calendars and Documents & Contracts cover the workflow. For high-volume temp and contract desks needing resume parsing, Boolean search, job board multi-posting and timesheet-to-payroll, no. Those agencies should keep an ATS and use HighLevel as the communications and business development layer.
How do I stop candidate and client-employer records getting mixed up?
Set a Record Type custom field and a matching tag at every single intake point, including manual adds and CSV imports. Then build every smart list, workflow entry condition and bulk action on that filter. The failure mode is always an import or a hastily added contact that skipped the tag, so audit untagged contacts monthly until the habit sticks.
Is GoHighLevel for recruitment agencies compliant with Australian SMS rules?
The platform gives you the tools — consent fields, automatic STOP handling, sender identification, dedicated numbers — but compliance depends on how you configure and use them. You need documented consent with a date and source, clear agency identification in messages, a working opt-out on every marketing send, and a genuine distinction between transactional and marketing messages. Configured properly it holds up; configured lazily it does not.
What custom fields should a recruitment sub-account start with?
On candidates: record type, right-to-work status, licences and tickets held, availability, preferred locations, desired rate, source, SMS consent date and source, contract end date, and a screening score. On client contacts: company, fee percentage, guarantee period in weeks, terms of business signed date, and account manager. Add fields only when a consultant is already recording that information in notes.
How do I measure time-to-fill accurately in GoHighLevel?
Write two date custom fields via workflow — vacancy briefed date on the client opportunity and placement confirmed date on the candidate opportunity — rather than relying on stage-change timestamps, which move whenever someone drags a card back. Report the difference by client, by consultant and by role type, and exclude vacancies your agency was never realistically going to fill so the average stays honest.
