Tracking applications reliably

A clean pipeline of submitted, reviewing, interviewing, offered, rejected does not describe reality. Most applications receive an automated acknowledgement and then nothing, ever.

Include "no response" as a real terminal state with a defined threshold, rather than leaving applications indefinitely "in progress". A tracker showing forty active applications when thirty-five are dead is not tracking anything useful.

Set the threshold per employer where you have history rather than as a single global number. Fourteen days of silence from a company that usually replies in a week means something; the same silence from one that takes six weeks means nothing, and one threshold gets both wrong.

• Submitted, acknowledged, in process, interviewing, closed
• No response after a defined window — a state, not a gap
• Withdrawn by the candidate
• Confirmed versus inferred, marked on every transition

Candidates apply through many channels, and only some go through your platform. A tracker covering a third of someone’s applications is a partial record they will stop maintaining.

Capture from confirmation emails, from a browser extension, or from a forwarding address. Anything that does not require them to enter the same information twice — because they will not.

Email is the highest-coverage source by a distance. Almost every application produces a confirmation and almost every outcome arrives there, so a system reading a scoped label reconstructs most of a search without the candidate doing anything at all.

Responses arrive without reference numbers, from unfamiliar addresses, occasionally from agencies representing an employer. Matching them to the right application is genuinely difficult.

Use sender domain, thread references, role title and timing together, and leave the ambiguous ones unmatched rather than guessing. Attaching a reply to the wrong application corrupts two records, which is worse than one gap.

Do not let unmatched items accumulate silently. A short review queue that the candidate clears in a minute keeps the record accurate; a growing pile of unattached messages is how a tracker quietly stops reflecting reality while still looking complete.

When applications use tailored CVs, the version sent matters. A candidate preparing for an interview needs the exact document the interviewer is reading.

Store it with the record, permanently, and surface it on the application page. This is the single most appreciated feature in a tracker and among the easiest to build.

Store the file rather than the recipe for rebuilding it. Regenerating from a template and a profile three months later produces a different document, and the one thing the candidate needs is the one the interviewer is holding.

A completed search leaves a dataset the candidate will want again in two years: which companies responded, who they spoke to, what was said, which version of their CV was working. That is worth more than the tracking was during the search.

Make export trivial and complete. A candidate who can take their whole history with them in one action is a candidate who trusted the system with it in the first place, and the export is also the honest answer to what happens when they stop using the product.

Pair it with equally trivial deletion. A job search ends, the data stays sensitive, and a product that makes removal as easy as export is one people are willing to give the access to at the start.

• One-action export of everything, documents included
• One-action deletion, genuinely removing retained content
• A record that stays readable outside your product
• Retention that ends when the search does, unless they say otherwise

Automatic capture and classification will get things wrong — a duplicate, a misread status, a reply attached to the wrong role. A system the user cannot fix becomes a system they stop trusting.

Make every field editable and every inferred status overridable in one action. Their corrections are also your best signal about where the classification is failing.

Mark what was inferred so a correction sticks. A status the candidate fixed should not be silently overwritten the next time the classifier runs, and the only thing preventing that is knowing which values a person put there.