AI screening you control

AI screening columns that read like recruiter questions.

The leverage point in AI screening is not the model — it’s the column you write. ShortlistTable gives you a column system where every screen is a plain-English question with a typed output: yes/no, enum, number, date. You write the rubric; the AI does the read; every cell carries its source sentence.

No prompt engineering · Reusable templates · Typed outputs
shortlisttable.app / tables / custom-columns-demo6 columns
CandidateKafka in prodTeam size ledOn-call ≥ 12moStack maturity
Alice Chen
Ledger · 7y
Yes6YesMatureCall first
Marco Silva
CloudCo · 12y
Review?YesMatureReview fit
Nina Patel
Indie · 4y
NoSoloNoEarlyHold
Citation · Alice Chen · “Led platform team of 6 engineers building event-driven services” · resume p.1Source-backed
Plain English
Column definitions
6 types
yes/no, enum, number, date, list, text
Templates
Reuse per role family
5–10
Recommended columns per role
Why most columns are bad

Most screening criteria are written for the wrong reader.

Recruiters often inherit a list of must-haves from the intake meeting that reads like meeting notes: “strong CS background, good communicator, fast learner.” Those are not screening criteria — they are vibes. They produce inconsistent verdicts across candidates and across reviewers.

A good screening column has four properties: it is answerable from the resume alone, it is one-dimensional, it carries evidence, and it produces a yes / no / needs-review verdict. Those four constraints turn an opinion into a screen.

“Strong CS background”

Not a column. Vibes.

Cannot be answered consistently from the resume. Should be broken into specific competencies: degree-or-equivalent, stack experience, system-design scope.

“5+ years of experience”

Almost never a true must-have.

Replace with seniority indicators that actually matter: team size led, scope of system owned, named on-call ownership, depth of stack experience.

“Cultural fit”

Belongs in the interview, not the screen.

Not screenable from a resume; belongs in the interview rubric. Trying to screen for it produces bias and inconsistency without adding signal.

Column system

What you get when you write a screening column.

01 · Feature

Plain-English questions

“Has the candidate run Kafka in production for ≥ 12 months?” — write it once, the engine reads every resume against it. No system prompt to tune.

Has the candidate built a payments system?
On-call ownership ≥ 12 months?
B2B SaaS background?
02 · Feature

Typed outputs

Yes/no, enum (call first / review / hold), number (years), date (last role start), list (skills). Downstream filtering, sorting, and exports respect the type.

yes/noenumnumberdatelisttext
03 · Feature

Required evidence

Every column produces a verdict and a source sentence. If the resume is silent, the cell is marked needs-review instead of being guessed.

Resume p.1 · ExperienceLed platform team of 6 engineers building event-driven services.
04 · Feature

Column templates

Save a column from one role, apply it to the next. Most agency users build up a library of 30–40 reusable templates over time.

Senior backend packB2B AE packHealthcare RN packFounder pack
05 · Feature

Confidence threshold per column

Each column has its own threshold. The columns that need a recruiter eye land in the review queue; the obvious ones don’t.

0.75
default confidence threshold
06 · Feature

Recruiter override per cell

Disagree with a verdict on a column? Override it. The audit log shows the AI value and your override side-by-side.

AI: review · 0.62
Override: yes (note)
How it compares

Custom columns vs the alternatives.

PropertyBlack-box AIATS resume fieldsSpreadsheetShortlistTable
Define columns yourselfLimited templatesSchema-boundYes — manualPlain English
Typed outputsScore onlyATS-definedManualyes/no, enum, number, date
Reusable templatesVendor templatesTied to ATS schemaCopy-pasteSave once, apply anywhere
Confidence threshold per columnNoNoNoYes
Recruiter override per cellLimitedLimitedYesYes — audit trail
Supported Partial / manual Not supported
FAQ

Common questions on custom columns.

How many columns should I have per role?+

5–10 works best: 3–5 must-haves, 2–4 nice-to-haves, and one or two contextual columns (current title, years in role) for sorting. More than 12 and the sheet stops being a recruiter tool and starts being a database project.

Do I have to know prompt engineering?+

No. Columns are written as plain-English questions, not prompts. “Has the candidate built a payments system?” is a complete column — there is no system prompt to tune.

Can I save a column template for re-use?+

Yes — templates are first-class. Save a column from one role and apply it to another with one click. Most agency users build up a library of 30–40 templates over time.

What output types are supported?+

Yes/no, enum (custom values you define), number, date, list (e.g. skills), and free text. Downstream filters and exports respect the column type.

Can columns reference each other?+

Not directly — each column reads the source documents independently. If you need a derived column (e.g. “qualifies for shortlist if all must-haves are yes”), set a confidence threshold and a hold queue instead.

How do I handle role-family variations?+

Templates can be cloned and edited. A common pattern is one base template per role family (e.g. “senior backend”) and per-role overrides for the specific must-haves of that search.

Write better columns

Stop screening on vibes. Start screening on questions.

Write your first five columns, drop 25 resumes, get a sheet. No credit card.