The Search-Tracking Standard, and the Minimum Record That Passes

Running an active search means you are applying across many companies at once, and the thing that quietly sinks you is not rejection. It is losing track: a follow-up you meant to send, a portal you never checked, a role you forgot you applied to. This guide gives you a pass/fail standard for your tracker, so that at any moment you can name the next action for every live application and spot the ones going stale, and so two people grading the same tracker reach the same verdict.

Most top-ranking pages hand you a template with fifteen to twenty columns and leave you to guess which ones matter. That is the wrong deliverable. What you need is the few fields that must exist and must be current, the upkeep cadence that keeps them current, and a rule for grading a stale row. Here is the standard.

What is the minimum record that passes?

The minimum record is eight fields: Company, Role, Job URL, Source, Date Applied, Status, Next Action, and Next Action Date. One source states this set directly as the documented minimum, adding Resume Version only if you tailor each application. That is the pass bar. A tracker with fewer than five fields cannot drive a next action, and a tracker with more than twelve stops getting updated.

There is a defensible reduction below eight. A five-field version holds up: company and role, the date applied, the stage, the next action with a date, and where the lead came from. Five fields is enough to always know what to do next. The eight-field set is simply the five-field core with Job URL, Source split out, and Status named explicitly so you can filter.

Everything else is an optional add-on. These recur across templates and are genuinely useful to some searchers, but none of them is load-bearing: salary or compensation, location or work mode, contact name and email, resume version, deadline, interview dates, priority, notes, and a link to a snapshot of the job description. Add an optional column only if you will actually use it, because every extra column is friction.

The core move of this standard is that two of your eight fields do the real work. Next Action and Next Action Date are what turn a log into a system. A list of companies you applied to is a graveyard. A list of companies with a dated next action against each one is a search.

Why the eight fields, and not fifteen

The answer is retention, not neatness. Trackers do not fail because people lack discipline. They fail because the sheet crosses a friction threshold and stops getting updated. The minimum-field standard is literally a retention device: fewer fields means faster rows, and faster rows mean you keep logging.

The numbers converge. Multiple practitioner pages put the cap around 9 to 12 columns, with ten as the sweet spot. Past twelve columns, update friction goes up and update frequency goes down. The failure is symmetrical: a tracker can be too thin (company plus date, useless by week three because it cannot drive a next action) or too bloated (27 columns nobody fills in). Both get abandoned, most within two weeks.

The mechanism is per-row time. The documented tolerance is under 30 seconds per application. At volume, if a row takes two to three minutes to log, you skip it after a session and the data goes stale within a week. Multiply that cost across fifty or a hundred applications and a wide tracker is not a feature. It is a slow leak.

So the eight fields are not a minimalist aesthetic. They are the largest field set that still clears the 30-second bar for most people while retaining enough to drive a next action. Add Resume Version if you tailor, add Priority if you will sort by it, and stop. If you find yourself building a 20-column workspace, check whether that is progress or procrastination with a nice interface.

What "stale" means, as a gradeable test

A row is stale when it has no dated next action, or its next-action date is overdue. That is the whole test. It is deliberately not "the date applied looks old," because an entry can be logged today and already be dead if nothing is scheduled against it.

This matters because "looks stale" is a judgment two reviewers will disagree on, and this is a standard. "Has a blank Next Action Date" is a filter, and two reviewers running the same filter get the same answer. A dated next action matters more than a tidy sheet, because undated intentions do not get done.

A list of companies you applied to is a graveyard; a list with a dated next action against each row is a search.

The grading rule, stated so it can be adopted as policy:

• Pass: every live row has a Status reflecting the last verified signal, a Next Action, and a Next Action Date that is today or in the future.
• Fail, fixable: a live row has no Next Action Date, or a date that is overdue. Fix by scheduling the next action or closing the row.
• Fail, structural: the tracker takes more than 30 seconds per row to update, or has drifted past twelve columns. Fix by cutting fields.

Run this grade weekly. The output is a count of failing rows. A passing tracker has zero fails, or each fail flagged for action or closure before you close the laptop.

The follow-up and close cadence, by source

The dominant follow-up window is 7 to 10 business days after a portal apply, or 5 to 7 after a cold email, with two touches maximum. The dominant close threshold is 3 to 4 weeks of silence. These are not arbitrary; they track the data on when replies actually arrive.

The window is calibrated to the median, which is why 7 to 10 days works. Across benchmarks, the typical first reply lands around day 6 to 7, and roughly 70% of cold-outreach replies arrive within 7 days. Following up at 7 to 10 days catches the hiring team right after the batch has been read but before silence hardens into a no. It is a data artifact, not etiquette.

Note how the 7-to-10-day follow-up window sits just past the roughly 6-to-7-day median, about one to one-and-a-half times it. That spacing is the point. You are not nagging on day one; you are arriving right after the review window closes.

The close threshold is an opportunity-cost calculation, not a rejection. Treat 4 weeks of silence as a mental no, not because you were turned down but because waiting on a cold role costs you applications you have not sent. Median time-to-fill for nonexecutive roles runs 39 to 44 calendar days, so the role is often still open when you close it in your tracker. You are closing it to protect your own throughput. Close earlier on a red flag: the posting disappears or is marked filled, the posting is reposted with new wording, the company announces a freeze or layoffs, or you get a formal rejection.

Refolk removes a slice of this friction upstream: it writes your resume from your own history, tailors it to each posting, drafts the cover letter, and scores how well you actually fit. That means the logging step at volume starts from a tailored application, not a blank one, so each row you add to the tracker already carries a resume version worth recording.

Build and maintain the tracker

This is the procedure. Setup is about 20 minutes with a Google Sheet or Excel file; the rest is upkeep measured in seconds per row.

Two implementation notes. First, on step four: some sources collapse Status and Next Action into a single "status plus next step" field. I keep them separate because Status is the last verified state (what is true) and Next Action is what you will do (what is next), and conflating them hides blank next actions behind a reassuring "Applied." Second, the daily sweep is trivially automated. Add conditional formatting for overdue actions and filter by Next Action Date on or before today. That one filter is your entire daily upkeep ritual.

How this goes wrong

The failure modes below are where trackers die quietly. Each has a tell and a check you can run, because a standard is only useful if it names its own false positives.

• Dead status, no next action. The row says "Applied" and looks maintained but has nothing scheduled. This is the headline false positive for a "live" entry. Check: filter for blank Next Action Date.
• Over-building as procrastination. A 20-column workspace feels productive but is busywork, and the tell is a beautiful tracker with very few applications in it. Check: per-row time over 30 seconds, or logging two to three minutes per row and then forgetting to log after a session.
• Following up too soon. A day-one or day-two bump reads as impatient. The false positive here is treating an automated "we received your application" reply as a real response; it does not restart the clock.
• Mutating the date fields. Overwriting Date Applied when you follow up destroys the signal of how long a role has been silent. Check: dates should never change after first entry. If you want to record the first reply, add a separate response-date column.
• Never closing cold rows. Keeping three-month-silent entries "live" inflates your pipeline and hides how little is actually moving. The false positive is a posting still visible online; a role more likely got unposted than closed, and nothing is settled until an offer is signed. Check against the 3-to-4-week rule.
• Status drift without evidence. Marking a row "In review" on a hunch. Check: change status only on an email, a portal change, or a scheduling message.
• Tracking instead of applying. The deepest failure: updating the sheet becomes a substitute for sending applications and talking to people. The guidance to update daily is real, but if your best-maintained asset is the tracker rather than the pipeline, the tracker has crossed from useful into abandoned busywork with a nice interface.

What you are actually waiting on

The tracker exists because a thin, finite human layer stands between your application and a reply, and knowing its size tells you why the cadence matters. In Refolk's index of professional profiles there are 13,872 US profiles titled "Recruiter" with recruiting skills, against 4,946 US "Career Coach" profiles. That recruiter count is the review layer every applicant is waiting on, and it is why batch-read timing and the 7-to-10-day window are worth getting right: you are queuing behind a bounded number of humans, so arriving right after the batch is read is a real advantage.

The safety net is also unevenly distributed by geography, which changes how much weight your tracker carries.

In Refolk's index the US has 13.8 times the recruiters and 6.6 times the career coaches of the UK. The standard travels, but the human safety net does not: a UK job seeker leans harder on a self-managed tracker because there are fewer advisors and fewer recruiters working the other side. The thinner the human layer, the more your disciplined upkeep is doing the work that a coach or a responsive recruiter might otherwise do.

If you want to put a face on that layer rather than wait blind, you can search the people who move these processes. Refolk runs a plain-language search over its index of professional profiles.

Verify before you call the tracker done

Run this checklist whenever you sit down to grade your own tracker. It is the pass/fail standard in checkable form. A tracker passes only if every item is true.

Keeping the standard current

This standard is evergreen because it is built on mechanisms, not current values. The follow-up window is pegged to the median first-response time, so if you ever see evidence that replies in your field arrive faster or slower, re-anchor the window to roughly one to one-and-a-half times your observed median and adjust. The close threshold is pegged to opportunity cost against time-to-fill, so if roles in your field fill faster than the 39-to-44-day benchmark, you can close colder rows sooner without losing much.

The one thing I would flag as not independently established: the idea that Date Applied and a first-response date form a twin-metric whose gap tells you something precise. The underlying facts are documented (date applied triggers follow-up timing, and median response windows exist), but the specific "the gap is a named signal" framing is mine, not a cited external rule. Treat it as a useful habit, not law. The safe, verifiable version is simpler: never mutate Date Applied, because the moment it moves you lose the ability to filter rows by how long they have been silent, and that filter is what the 3-to-4-week close rule runs on.

Re-grade weekly. The tracker is working when it can answer one question at any moment: what is the next action for every live application, and which rows have gone stale. If it cannot answer that in one sort and one filter, it has failed the standard, regardless of how good it looks.