Move the work
Inbound arrives faster than anyone can read it — and most of it is not a candidate.
A careers page that works produces a pile. Every tracker turns that pile into records, which means the cost of a good careers page is a database nobody trusts six months later.
The decision this page is built around
An application is not a candidate until a person says it is.
Applications from your careers page land in the inbox and go no further. They are not in your candidate list, not in search results, not in the pipeline, and not counted in anything. They are waiting.
Resolving one creates the candidate record and attaches them to the role in a single action. Discarding one creates nothing at all — no candidate, no duplicate, no ghost to merge away later. That asymmetry is the whole design: the easy action is the one that leaves your database clean.
- Applicant 1Senior Data EngineerMid-size product firmnotice · 30 daysResolvematched an existing record
- Applicant 2Senior Data EngineerServicesnotice · 90 daysWaiting
- Applicant 3Plant Maintenance Lead—notice · ImmediateDiscardno relevant experience
- Applicant 4Plant Maintenance LeadManufacturingnotice · 60 daysResolvenew record created
- Applicant 5Senior Data Engineer—notice · —Discardblank submission
- You triage the row, not the record —
What they typed is on the row before you open anything — notice period, current company, current location — so most decisions are made from the list.
- Resolve is one action —
The candidate is created and placed on the role together, at the entry state, rather than created here and attached somewhere else.
- Discard leaves nothing behind —
The application is marked and kept for your own audit. Your candidate database never hears about it.
- Resolved against who you already have —
Somebody applying for their third role with you is the same person, not the third copy of them — and the inbox says so when it matched, so you know whether you just created someone or found them.
Where the rest of the inbound goes
Email intake is a different door, on purpose.
Candidates forwarded or parsed out of email do not queue here — they are created directly as records, because a CV a recruiter forwarded has already been through a human. Two paths, two levels of trust, and we would rather say that plainly than pretend there is one universal inbox.
If you want forwarded mail held for triage the same way, it is worth saying so on the call; it is a known gap rather than a design position we are attached to.
Plain answers
What people ask once they see the inbox.
›Does everything inbound arrive in one queue?
No. Careers-page applications arrive here. Email-captured candidates are created directly as records. That is a real difference and it is the question we would ask first in your position.
›What happens to an application I discard?
It is marked discarded and retained for your audit. Nothing is written to your candidate database, so a discarded application cannot come back as a duplicate.
›Can two recruiters resolve the same application?
Resolving is a one-way step and the row leaves the unresolved list, so the second person sees it has already been handled.
›Do we get the resume in the inbox?
Not on the row today — you get what the applicant typed. Resume handling on the public form is an open item and we will show you exactly where it stands rather than demo around it.
›Is this a shared mailbox with a nicer skin?
No. There are no messages here. Every row is a structured application with typed fields, and every outcome is recorded as a decision rather than implied by something being archived.
Book a demo
Point your careers page at the demo.
Send twenty real applications through it, including the three you would bin. The interesting part is what your database looks like afterwards.