A Hiring System For A Small Business: Full Architecture

What happens when there's no hiring system

The trigger is always the same. Something breaks, or someone quits, or a quarter goes sideways, and you say the words: we need to hire someone. From that sentence to a person starting, everything that follows is improvisation, and the improvisation costs you more than the salary.

It goes like this. You write a job description in forty minutes by pasting together two you found online. You post it in three places. Applications arrive — sixty of them, then a hundred and forty — into your personal inbox, which is now the applicant tracking system. You read the first twenty carefully and the next hundred and twenty in about four seconds each, which means you're screening on resume formatting. You interview six people, in six different conversations, asking whatever occurred to you that morning, and at the end you have six impressions and no comparison, because you didn't ask them the same things. You pick the one you liked. Liking is a real signal about very little.

Meanwhile the good candidates evaporate. Not because they weren't interested — because you took eleven days to reply and they took a job from a company that took two. Speed is the single most controllable advantage a small business has in hiring, and it's the first thing to die without a system, because responding to candidates is nobody's actual job and every day it isn't done, it becomes more embarrassing to do.

And then the part that isn't discussed. The hundred and thirty people you never replied to. They applied, they waited, they got nothing — not a rejection, silence. Every one of them now has an opinion about your company, and they tell people. Your employer brand isn't your careers page; it's what the people you didn't hire say about you. Most founders are quietly running a machine that generates detractors at scale and calling it a hiring process.

The root cause is not effort or care. It's that hiring is treated as a project each time — a thing you do, urgently, and then stop — rather than a system that exists. Founders love the comforting lie that only we can do things the right way, and hiring is where that lie is most expensive, because "the right way" here just means "whatever I remembered to ask."

The scorecard and the requisition: what has to exist before you post

Nothing gets posted until two objects exist. This is the gate, and it's the discipline that everything else depends on.

Object one: the role scorecard. It lives in Notion, in a database of roles, and it has a fixed shape. Three to five outcomes — not responsibilities, outcomes. "Manage client communication" is a responsibility and it's unscoreable. "Every active client has a status update in their hands by Friday, and no client escalates to the founder about not knowing what's happening" is an outcome, and you can tell in ninety days whether it happened. Under the outcomes: the competencies required to produce them, and for each, a written definition of what great looks like versus adequate. Writing that definition is the hard part and it's the part that pays, because it forces you to know what you're buying before you go shopping.

The scorecard also has to name what this role is allowed to decide. Enablement is engineered through three forces — empowerment, the authority to decide; education, the knowledge to act; and environment, the system that supports action. Empowerment starts at the scorecard or it never starts. A role hired without defined decision rights becomes a low-agency role, and then everyone concludes the hire lacks initiative. People don't become low-agency by nature — they become low-agency by design.

Object two: the requisition. Trigger, approval, and budget. What event created this need, who signed off, what the compensation band is, and — the question that saves the most money in this entire document — what would have to be true for this role not to exist. Half of the roles small businesses hire for are architecture problems wearing a hiring costume. Someone is drowning in transport work, so you hire a person to do the transport work, and now you have a salary permanently attached to a problem that a build would have deleted. The requisition should force that question in writing, once, before it can be approved. If the honest answer is "nothing, we genuinely need a human here," good — you've now got a much better job description than you would have written otherwise.

Only when both objects exist does the posting happen, and the posting is generated from the scorecard rather than composed separately. That's not a shortcut, it's an alignment guarantee: what you advertise and what you'll measure against come from one source, so they can't drift.

The pipeline: stages, SLAs, and where AI must not decide

Every sourcing and intake surface converges into one pipeline. Job boards, referrals, your own audience, inbound from the careers page, the person you DM'd — all of it lands as an application object in one place. In a GoHighLevel-centered build the candidate is a contact and the application is an opportunity in a Hiring pipeline, with the role as a field. That single consolidation is worth more than any clever tooling: the reason candidates get lost is almost never that a stage was designed wrong, it's that there were four inboxes and no board.

The stages: Applied → Screened → Structured Interview → Work Sample → Final → Reference → Offer → Closed. Each stage has an SLA, and the SLA is the part that has teeth. Applied to Screened: 48 hours. Any stage to any stage: 5 business days maximum. When an SLA breaches, the system does not send a gentle nudge — it posts into Slack with the candidate, the role, and the owner's name. Transparency is a leadership strategy, and a stage-aging alert with a name attached is the cheapest one available.

Screening is where AI earns its seat, and where the boundary has to be explicit. Claude or the OpenAI API reads each application against the scorecard's competencies and produces a structured output: evidence found for each competency, evidence absent, and questions this application raises. That's genuinely useful — it's the four hours of careful reading you were never going to do for candidate number ninety-seven, done identically for all of them, which is more fairness than a tired human at 11pm provides.

And here is the line. The model does not reject. It ranks, it summarizes, it surfaces — a human moves the stage. Two reasons, and only one is legal. The legal one you can look up. The operational one is that a model rejecting candidates against a scorecard you wrote will faithfully amplify every flaw in the scorecard, silently, at volume, and you'll never see the candidates it was wrong about because they're gone. Automation should handle movement, not meaning. Screening a hundred applications is movement. Deciding a person doesn't get a conversation is meaning.

The structured interview kit is a real artifact per stage, and it's the single highest-leverage document in hiring. Same questions, same order, every candidate, scored on a rubric tied to the scorecard's competencies — 1 to 4, with what each number means written down before anyone interviews. Scores get entered before the debrief, not during, because the first person to speak in a debrief sets the room and you've just converted three independent assessments into one. This is the difference between six impressions and a comparison.

The work sample is short, paid, and resembles the actual job — not a puzzle. It's the only stage that predicts anything reliably, and it's the one small businesses skip because it takes effort to design. Design it once, per role, and it's an asset forever.

Reference, offer, and the rejection you're not sending

The reference call is not a formality and it isn't a vibe check. It's a verification pass against the scorecard: for each outcome, you ask the reference for a specific instance. "Tell me about a time this person had to do X" where X is the outcome you wrote in step one. The kit exists. The notes land on the candidate record. Most reference calls are worthless because they're improvised, and improvised reference calls only detect people who are bad at picking references.

The offer stage has an owner and a clock. The gap between final interview and offer is where good candidates are lost, permanently, to companies that were merely faster. Pre-decide the band at requisition so the offer doesn't require a fresh negotiation with yourself while a candidate waits four days for an answer you could have had in advance. The close is a human conversation, always, and it's the founder for any role that matters.

Now the stage that nobody builds: rejection. Every candidate who is not moving forward gets told, within the SLA, by a real message. Not a template that reads like a template — a short, specific, human note. This is the highest-ROI automation-adjacent build in the whole system and it's the one that gets cut, because it feels like it produces nothing.

It produces your employer brand. Every rejected candidate is a person who now knows something about how your company treats people when there's nothing to gain. Some of them will apply again in two years, better. Some of them will refer someone. Some of them will become clients. All of them will tell the story of how you handled it, one way or the other. Automate the trigger, not the tone: the system fires the reminder at the SLA and names the owner; the human writes the sentence that makes it not feel like a machine. It takes ninety seconds a candidate, and the reason it doesn't happen today is not time — it's that nothing tells you to.

And the last stage: hired closes the pipeline and fires the seam. The moment an offer is accepted, the candidate record writes an employee record and triggers pre-boarding — day -7. The scorecard travels with it. That handoff is a wire, not a conversation, and it's covered by the employee onboarding system, which is a different machine with a different shape. The only thing the two share is the scorecard, and that sharing is the point: the standard you hired against becomes the standard you measure against, without anybody re-deriving it.

What done looks like, and what it takes

Done looks like this. Nothing gets posted without a scorecard and an approved requisition that answered whether the role should exist. Every candidate from every source is in one pipeline. Every stage has an SLA and breaches shout in Slack with a name on them. AI reads every application against the scorecard and decides nothing. Every interview at a given stage asks the same questions and produces a number against a rubric written in advance. References verify the outcomes rather than the impression. Every rejected candidate gets a real message inside a week. And the scorecard doesn't get archived at offer — it becomes the 30/60/90 review, so on day 90 you can say whether the hire is landing without convening anyone's opinion.

The test: can somebody other than you run a hire end to end and produce a decision you'd trust? If not, you don't have a hiring system, you have a hiring habit that lives in your head — and it will hit its ceiling at exactly the number of roles you personally have attention for. Your business will not reach its potential if you're the one powering it. It will reach its potential when you're the one shaping it.

What it takes to build. The OPERATE Report ($1,997) will tell you, among other things, how many of the roles you're planning to hire are actually build problems — this is frequently the most valuable output of the diagnostic for a company at the hiring stage, and it occasionally saves the entire cost of the engagement in one sentence. A Build Day ($5K/day) is typically enough to construct the candidate pipeline in GoHighLevel with stages, SLA automations, Slack alerts, and the intake forms feeding it, plus the Notion scorecard and interview-kit databases. The AI screening layer — an n8n or custom flow calling Claude against the scorecard, writing structured output onto the candidate record — is usually a second day or a Custom Build depending on how many intake surfaces have to be reconciled. Companies hiring continuously tend to run it inside the retainer ($5,000+/mo, three-month minimum, five build credits), because a hiring system is never finished; the scorecards change as the roles do.

Build the systems as you do the work, not instead of the work. The next role you're about to hire for is the one to build this around — write the scorecard first, run the hire through the stages by hand, feel where it drags, and then automate the drag. When you do something manually first, you feel its texture, and that texture is what separates a hiring system from a hiring form.