Inside HireQwik's Score Filter for the Needs Review Queue

An AI screening dashboard score filter sounds like a small thing to ship: a dropdown, four options, done in an afternoon. We shipped ours on July 7, 2026, and it took a recruiter’s actual complaint to get there. She could see the resume-match score on every row of the Needs Review queue, but she couldn’t do anything with it except scroll past the rows that didn’t matter yet. A hundred-plus candidates sorted by score is still a hundred-plus candidates you have to look at one at a time to find the ten Strong Gos.

The complaint itself was specific, not a general “make the dashboard better” ask. She wanted to bulk-approve everyone above 90% for one JD before lunch, and the only way to find them was to sort the column and count down from the top by eye, checking her own math against the score printed on each row. That’s not a filter. That’s a manual filter a human is running in her head, on a page that already has the data needed to do it for her.

What the Needs Review tab is, before the filter matters

The Needs Review tab sits before a single AI voice interview happens. It’s the queue of candidates who’ve cleared resume matching against a job description and are waiting to be invited to a screen, or waiting on a recruiter to greenlight them manually. Every row already carries a match-score percentage. What it didn’t carry, until this shipped, was a way to act on that score in bulk, to say “show me only the ones above 90” instead of eyeballing a sorted column.

The four bands

The filter sorts the resume-match score into four bands: Strong Go (90–100%), Go (75–89%), Maybe (60–74%), and Reject (0–59%). It sits in the same toolbar row as the existing Role and Source filters, styled and positioned to match, so it doesn’t read like a bolted-on feature. Select one band, several, or none, and the toolbar’s count pill updates to show exactly how many candidates match. It also clears itself automatically the moment you switch off the Needs Review tab, so a filter set for one morning’s triage can’t quietly hide candidates on a tab where it was never meant to apply.

It’s worth being precise about what these four bands are not. If you’ve read about the four bands on the HireQwik dashboard, Strong Go, Go, On Hold, No Go, this is a different set wearing similar names. Those bands come out of a completed voice interview: communication quality, role fit, and domain basics, scored from an actual conversation. The Score/Decision filter’s four bands come out of the resume match alone, before anyone has talked to the candidate. We kept “Strong Go” as a label in both places because the intent is the same (this candidate looks ready to move), but the evidence behind the label is not. A recruiter who treats a 92% resume match the same way they’d treat a post-interview Strong Go is making a call the system never claimed to support.

Most vendor screening dashboards don’t make that distinction visible at all: a single “AI score” column, no note on whether it came from a resume pass or an actual conversation. Pinpoint’s own pitch for its AI candidate filters is built around avoiding exactly this kind of unexplained number, breaking evaluation into visible criteria instead of a black-box score. We agree with the instinct. We just think the fix has to extend to labeling which stage of the pipeline produced the number, not only what went into it.

Why this filter runs in the browser, not the database

Every other filter on the Needs Review tab, Role and Source, sends a parameter to the backend and gets back a fresh page of results. The score filter doesn’t. There’s no match_score band parameter on the API today, so filtering happens client-side, over whatever page of candidates is already loaded. That’s a real constraint, not a design flourish. On a campaign with a few hundred candidates in the queue at once, filtering the loaded page covers what a recruiter is actually looking at during a triage session. It’s the kind of tradeoff that’s honest about what shipped in a day versus what would take a backend migration, and we’d rather ship the honest version than delay for a distinction most triage sessions won’t hit.

The part that isn’t about filtering at all

The reason this shipped as more than a cosmetic dropdown is what it does to bulk actions. Before the filter existed, “select all” on the Needs Review tab meant every row currently loaded, including the ones a recruiter had scrolled past because they didn’t match what she was looking for. Filter the view down to just the Maybe band, and select-all, bulk-approve, and bulk-reject now all read from that filtered list instead of the full one. A recruiter clearing out low-scoring stragglers can select-all inside the Reject band with some confidence that “all” means what’s on her screen, not what’s hiding above the fold. That mechanism is worth its own explanation. We cover exactly how HireQwik’s bulk actions stay scoped to what’s visible in a follow-up post on the specific mistake it prevents.

The edge case: candidates with no score yet

Not every row in Needs Review has a match score. A candidate can land there through a manual add, or arrive before the resume-scoring pass has finished running against a fresh JD, and in those cases the score field is simply empty. The filter’s banding logic treats a missing score as belonging to none of the four bands. Select Strong Go, Go, Maybe, and Reject all at once, and an unscored candidate still won’t show up. That’s the correct default for a filter meant for triage, but it’s worth knowing if a candidate count looks smaller than expected: check whether the gap is candidates genuinely outside the selected bands, or candidates with no score at all sitting just outside the filter’s reach entirely. The unfiltered view, or the Role filter alone, still surfaces them.

Stacking it with Role and Source

The filter doesn’t replace Role or Source. It sits next to them, and the three combine as an “and,” not an “or.” A TA lead running six JDs through one campaign can select a single Role, then layer Strong Go and Go on top of it, and see exactly the ready-to-advance slice of just that one JD, without the other five roles’ candidates diluting the count or the view. That combination is the actual daily use case more than any single filter alone. “Show me who’s ready, for this JD, sourced from the sheet we triggered this morning” is a sentence a recruiter can say out loud, and now it’s also a sequence of three clicks instead of a mental filter she has to run herself while scrolling.

What changes for a recruiter’s actual morning

Picture a campus drive at the 2,500–3,000-candidate scale HireQwik pilots typically run, resume matching finished overnight. Without the filter, the Needs Review tab is a single long list, sorted by score if the recruiter remembers to sort it, unsorted if she doesn’t. With it, she opens the tab, selects Strong Go and Go, and the count pill tells her immediately how many candidates are worth fast-tracking to an interview invite without a second look. She switches to Maybe alone next. This is the band that actually needs her judgment, because a 65% match could be a genuinely underqualified candidate or a strong one whose resume just didn’t parse cleanly against the JD’s keyword set. Reject, she may not open at all that morning, or she opens it specifically to spot-check that nothing scored oddly low for a reason that isn’t the candidate’s fault.

That’s a different workflow than scrolling a sorted list and trusting yourself to notice where “the good ones” stop and “the maybes” start. A sorted list still asks a human to draw the line by eye, every session, on every campaign. A filter draws the line once, in the toolbar, and lets the recruiter decide which side of it she wants to look at first.

What a resume-match score filter still can’t do

It’s a pre-call signal, and it inherits every limitation a resume-match score has. A candidate can score Maybe on paper and turn out to communicate clearly, hold their own on domain basics, and land Strong Go on the actual interview. That’s exactly what relevance-aware resume scoring is built to catch fewer of, not eliminate entirely, because a resume is still a resume, not a conversation. It’s a known gap industry-wide: research on ATS matching has found the correlation between match score and interview outcome is strong but far from linear, plateauing well before it hits 100%. That’s exactly why Maybe, not Reject, is the band built to absorb that uncertainty. The filter doesn’t replace judgment on the Maybe band. It just makes sure that judgment gets spent where it’s actually needed instead of on the 90 candidates whose fit was never in question.

The other honest limit: it’s a filter over what’s currently loaded, not a saved segment. Close the tab and reopen it, and the filter is gone unless it’s still in the URL from that session. It’s built for a single triage sitting, not as a permanent view a recruiter returns to every morning without resetting it.

If your team’s version of this is still a spreadsheet sorted by a formula column, see what the filtered queue actually looks like at your hiring volume.