Key takeaways
- We put a careers page on our site, and the first real decision was making sure applicants never land in the sales pipeline.
- Three guards do it: their own pipeline, no dollar value on their record, and none of the tags that start sales automations.
- Without those guards, your pipeline value inflates and your research automation starts researching a job seeker's imaginary business.
- Consent wording has to say what they actually agreed to. An applicant did not opt in to marketing.
- The trap that nearly got us: a script on the site rewrites every form it finds, and it would have quietly dropped the resume.
We started recruiting cold call setters and closers, which meant a careers page, which meant an application form, which meant applications landing somewhere.
The lazy version takes about twenty minutes. Point the careers form at the same intake you already use for website leads. It creates a contact, it works, you move on.
It also quietly wrecks your CRM, and it takes weeks to notice.
What actually goes wrong
A lead and a candidate are both people who filled in a form, so the temptation to treat them the same is strong. Everything downstream disagrees.
Your pipeline report counts open opportunities and adds up their value. Drop applicants in there and your pipeline is suddenly worth more than it is, made of people who want a job from you. You will make decisions off that number.
Your follow up sequences start. Someone who applied to work with you gets an email about our website packages. Nobody gets hurt by that, but it tells them nobody is paying attention.
And in our case something more specific. We run an automation that researches new leads before a sales call, digging into their business, their reviews, their site. Point that at an applicant and it goes hunting for the company of someone who is applying for a job. It finds nothing, or worse, finds a business with a similar name and writes a whole briefing about strangers.
Three guards
So the careers form has its own intake, and it enforces three separations on purpose.
Its own pipeline. Applicants get an Applicants pipeline, never the sales one. Separate board, separate stages. A hiring manager moving cards is not touching sales reporting.
No dollar value. Their opportunity carries no monetary value at all. A candidate is not a deal. A number there would show up as pipeline value on any report that forgot to exclude this pipeline, and reports forget.
None of the sales tags. Specifically, applicants never get the tag that queues a lead for research. That tag is a work queue, and putting a candidate in it is how the research automation ends up writing a sales dossier about a job seeker.
There is a fourth guard that is easy to miss. Our internal briefing and our client roster both search every open opportunity with no pipeline filter, because that is the simple way to write that query. Both had to be changed to subtract the applicants pipeline explicitly. The lesson is that separating the data is only half the job. Anything that reads broadly has to be taught about the new thing too, or it happily counts it.
Consent is not one size
The consent checkbox on a lead form and the one on a job application are not the same agreement, and treating them as the same is sloppy in a way that could actually matter.
A lead agreed to hear from you about your services. An applicant agreed to be contacted about their application. So the careers form has its own wording, and the exact wording shown is stored on their record along with the timestamp.
That stored copy is the point. If anyone ever asks what someone agreed to, the answer is not the current version of your form. It is what was actually on screen the day they clicked.
The trap that nearly got us
This one is specific to how our site is built, and it is the kind of thing that would have been maddening to debug.
A script on our site walks every form on every page and rewrites them. Anything with a certain class gets converted into our stepped lead form and posted to the lead intake as plain data.
Had we reused those class names on the careers form, three things would have happened silently. The resume would have been dropped, because a file cannot travel that way. The candidate would have been filed as a website lead. And nothing would have errored, so it would have looked like it worked.
The careers form uses its own class names for exactly that reason. It also has to send files rather than plain data, because a resume is a file, so it takes a different shape of submission entirely. Files go to storage and only their link is kept, which means the whole application is readable straight from the contact record with nothing to download.
One real limit worth stating: the upload path rejected files over about 25 megabytes in this flow, which is smaller than a typical phone video. So the video question asks for a link first and treats upload as the fallback. Better to know the ceiling than to let a candidate watch a progress bar fail.
What this means if you are hiring in the Bay Area
Most businesses we work with as a GHL consultant Bay Area partner get here eventually. You have a CRM, you start hiring, and the CRM is right there with a form builder.
Use it. Just draw the line first:
- Give applicants their own pipeline before the first application arrives, not after.
- Never put a value on a candidate's record. It will end up in a revenue number.
- Check which tags start automations and keep every one of them off the hiring path.
- Write separate consent wording and store what you showed them.
- Go find anything that counts everything. Dashboards and reports that search with no filter are where the contamination shows up.
Someone applying for a job and someone buying from you are two different relationships. Your systems should never have to guess which one they are looking at.
If you want a CRM where those lines are drawn properly, that is the work we do. Have a look at optechsol.llc.