Follow-ups

Most applications aren’t rejected. They go quiet.

Nobody followed up and nobody told you anything, so it sits at “applied” for four months. LandEarly closes both ends of that silence: it writes the nudge five business days in and hands it to you, and it moves your statuses on its own from the header fields of mail you’ve already received.

Inbox reading Off until you connect itDraft · day 530300 charactersgmail.metadata
The part nobody else does

An email lands. The application moves - or pointedly doesn’t.

What arrives14:08 · headers only
FromWrenfield Recruiting <…@ashbyhq.com>
SubjectInterview availability - Staff Engineer, Payments
Delivered-Tomarcus+le7f3c1a@fastmail.com
Message body

Never fetched. Under gmail.metadata the Gmail API rejects a full-format read - this is not a rule we keep, it is a request Google refuses. Attachments and calendar contents are never requested at all.

matched · sender is a known ATS domain

LandEarly read
Subject lineSender domainMessage bodySender's nameAttachments
Deterministic rule · no model call
interview_invite0.90

two strings in.
no sentence is quoted,
because none was read.

Your trackerwithin 30 min
Staff Engineer, PaymentsWrenfield · Ashby
submittedinterview
Reply token - exact

The application was submitted from a +le alias, so the reply came back addressed to it. This identifies the application directly rather than guessing from the sender.

The board moves and a status email goes out. What it can tell you is that the stage changed - not when the call is, or how long it runs, because those live in a body nobody read.

Nothing above asked you to forward anything. The alias in the Delivered-To line is what makes attribution exact - it was added to the address when the application was submitted, so a reply identifies its own application. Without one, matching falls back to the sender’s domain inside a 90-day window, and refuses when two employers share a host.

Both halvesOff until you turn it onRead-only, header fieldsOne follow-up per applicationSeparately switchable
Half oneThe nudge

Day five, still nothing. Here’s the email - in your inbox, for you to send.

The design handoff for this page drew a follow-up addressed to a named recruiter, sent from your account, on the original thread. That is a good product and it is not this one. What LandEarly does is narrower and worth stating plainly: it notices the silence, writes a short draft from four facts it can verify, and puts it where you write from. The last step is yours, on purpose.

Follow-up · LedgerlineDrafted · waiting for you
To- no recipient is resolved
Written fromYour nameThe company nameThe role titleHow many days since you applied
Hi - I applied for the Senior Backend Engineer role at Ledgerline five business days ago and wanted to check in on where things stand. Is there any update on the timeline? Thanks, Marcus
DRAFTED BECAUSE 5 business days, no reply, no outcome
GROUNDED IN the four facts above - and nothing else
LENGTH 186 characters · a schema rejects anything outside 30300
Approve & sendCopyDismiss

“Approve & send” sends it to you. The email lands in your own inbox, from LandEarly, so you have the text where you write from. Getting it to the company is the Copy button and your own mail client - which is also why the draft has no To: line to be wrong about.

Timing you can predict, because nothing about it is adaptive.

There is no send window, no local-time logic and no holiday calendar in this path - the handoff drew all three. One job runs each morning and asks a single question of every submitted application: has it been 5 business days with no reply and no outcome?

Waits5 business daysMon–Fri, counted in UTC
Wakes09:00 UTCone run a day, for everyone
Sends toyour own inboxnever to the company
Auto-sendoff by defaultopt-in, still to you

Four rules, none of which is a setting.

Each is enforced somewhere you can check rather than promised in copy - a database constraint, a query clause, a schema bound.

Never twice

One draft per application, ever - a unique constraint on the application, not a counter someone could reset. There is no second nudge and no sequence.

Never invented

Four facts go into the prompt and it is told to use only those. There is no résumé and no posting text in this path, so a claim about your work can’t be made up because none is made at all.

Never a surprise

It stops writing the moment anything happens: the query skips applications that have left “submitted” or already have a recorded outcome. A reply that landed yesterday means no draft today.

Always yours

Editable to the last comma before you do anything with it, and the edit is what’s saved - the text you approve is the text that’s kept, not the one the model wrote.

Half twoStatuses that move themselves

What has to be true before your tracker changes.

Not sentiment analysis, and not a model quietly deciding how your search is going. A subject line and a sender’s domain go in; one of three status moves, or nothing at all, comes out. The list below is the whole vocabulary - and the interesting half of it is the rows that change nothing.

What the board does with itsubmitted → interview · offer · rejected
The subject reads as scheduling"Interview availability", "Next steps", a booking link in the subject
→ interviewThe one move most people are waiting for. It fires from submitted or interview only, so nothing already decided gets dragged backwards.
The subject reads as a decision against you"Unfortunately", "other candidates", "we regret to inform"
→ rejectedChecked before the interview pattern on purpose - a post-interview rejection usually contains the word “interview”, and matching that first would advance an application that just ended.
The subject reads as an offer"Offer", "compensation", "start date"
→ offerThe third and last automatic move. There is no fourth - every other classification maps to nothing.
A real person replies, saying nothing decisive"Thanks for the nudge, it's with the hiring manager now"
no changeFiled as an outcome so the reply is on record, and the status is left alone. There is no “in review” column to move it to, and inventing progress from a polite reply is the failure mode this rule exists to prevent.
An assessment or take-home arrives"Coding challenge", "HackerRank", "technical test"
no changeClassified, stored, and deliberately not advanced - a test is not an interview, and the board only has a column for one of them.
The ATS acknowledges receipt"We have received your application. Do not reply."
droppedNot filed at all. The scan returns before writing anything, because counting an automated receipt as a response would inflate how often you hear back.
Two employers share the senderMail from a host like jobs.smartrecruiters.com, used by both
asks youStored with no application attached and sent to your match queue. Picking the most recent would be a coin flip between two companies, and a wrong pick isn’t passive - it emails you about the wrong one.

Every automatic move writes a timeline row marked as email-sourced, so a status you didn’t set is always distinguishable from one you did. What that row cannot carry is a quote from the message - there is no stored sentence to show you, because none was ever read.

The honest version: this is right most of the time and wrong occasionally, and it is built to be wrong in the cautious direction. Roughly seven in ten real applicant-system emails are decided by a rule with no model involved; the rest go to a model that gets the same two strings, not the message. When it can’t tell which application a message belongs to it refuses rather than picking, which is why you’ll occasionally be asked a question instead of shown a move.

Where the line is

Two features that share a page and nothing else.

They’re separate in the code and separate in your settings: one is a daily job over your own applications, the other is a scan of mail you gave read access to. Neither needs the other, and turning one off leaves the other running.

Drafting a follow-up

No inbox connection
  • Waits 5 business days after you apply
  • Writes one draft, from four facts about the application
  • Delivers it to your own inbox for you to send
  • Stops if the application has moved or heard back

Moving a status

Read-only inbox grant
  • Wakes every 30 minutes and reads headers
  • Classifies from the subject and the sender's domain
  • Ties it to an application by alias, or by domain within 90 days
  • Moves the board only to interview, offer or rejected

Six things neither half will do.

Worth writing down as negatives, because a capability is easy to imply and hard to disprove - and because a design draft for this page implied most of them.

  • Email a company on your behalf. Nothing on this page addresses a recruiter. The draft goes to you and you send it.
  • Reply to anyone. Both inbox grants are read-only and there is no compose path attached to them.
  • Guess a recruiter’s address. No pattern is assembled from a name and a domain, because no recipient is resolved anywhere in this flow.
  • Nudge twice. One draft per application, enforced in the database rather than in the code that writes them.
  • Move a finished application. Automatic moves depart only from submitted, interview, offer - nothing leaves rejected or withdrawn - they follow the same transition table a drag does, and never re-fire into a status the application is already in.
  • Read the mail back to you. There is nothing stored to read - which also means no “open the original” link, because a pointer is not a link.
Reading your inbox - plainly

You’re letting software into your email. Here is the whole of it.

Four things: what gets read, what can’t be, what survives afterwards, and how to end it. Two of these cards are less flattering than the version a handoff drew - the filter runs on our side rather than the provider’s, and disconnecting doesn’t reach into your Google or Microsoft account. Both are stated here rather than in a policy PDF.

What is read

Header fields, on threads that survive a filter running on your side

Worth being exact, because the shape is unusual: under gmail.metadata Gmail disables server-side search, so it hands back recent threads and we filter here.

  • Five headers, requested by name: From, Subject, Date, Delivered-To, To.
  • A thread is kept if the sender is one of 37 applicant-system domains, or a company you applied to, or the subject reads as job mail.
  • That third test is a subject pattern, so it can catch a thread you never applied through. The rest of the pipeline then has nowhere to file it, and it is dropped.
gmail access ·
gmail.metadata
outlook access ·
Mail.Read
What is never read

The body of the message, and everything hanging off it

Not “filtered out” or “not shown to humans”. For Gmail the API refuses the request - a full-format read under this scope returns an error, not a message.

  • Message bodies on Gmail, in every case, including on threads that matched.
  • Attachments and calendar contents, on both providers - neither scope asks for them and no code path reads them.
  • Sending mail as you, and your contacts. Both grants are read-only; nothing LandEarly sends ever leaves your address.
  • The exception, stated plainly: Outlook’s Mail.Read has no headers-only equivalent, and one path does read bodies there - parsing job listings out of job-alert emails. It is off for Gmail entirely.
bodies stored, either provider ·
NONE
sender names or addresses stored ·
NONE
What is kept

4 fields - and not one of them is text from your mail

The whole evidence record for a detected outcome, in full. The table has no column for a subject, a snippet or a sender.

  • provider · threadId · messageId · fromDomain
  • The message id is a pointer, not a copy - enough to prove which message a status came from, useless for reading it back.
  • The domain is the only piece your match queue can show you, which is exactly why that screen asks which application this is rather than showing you the mail.
  • Outcome rows are append-only and included in your account export, so what is held about your inbox is a file you can download and read.
quoted sentence stored ·
NO - NONE EXISTS
row history ·
APPEND-ONLY
How it ends

One button, and the token is gone from our side before the page reloads

No email to support and no exit survey. What it does and doesn’t do are both worth knowing.

  • The stored credential is hard-deleted, not marked inactive, and scanning halts on the same click.
  • It does not call Google or Microsoft to revoke the grant - the entry stays listed in your account with them until you remove it there, and the link to do that is on the settings page.
  • Your applications, statuses and outcome rows stay exactly where they are. They simply stop moving on their own. Deleting them is the account-wide delete, not this switch.
  • Drafts keep coming. The two halves are genuinely separate - the draft cron never looks at whether an inbox is connected.
connection called stale after ·
2 HOURS
scan interval ·
30 MINUTES

Both halves start off. Neither is bundled into signup.

A new account has no inbox connected, so nothing is read and no status moves by itself. Muting an email now mutes only the email: the draft is still written and still waiting on the application - the notification toggles stopped deciding whether the work happens at all.

Inbox reading · OffAuto-send · Off

Access is granted through Google and Microsoft’s own consent screens, which means the scope names above are checkable against what they showed you - and revocable from their side as well as ours. The retention schedule, the subprocessor list and the per-field scope tables live on Trust & Safety.

Asked directly

The questions this feature deserves.

Does the follow-up actually reach the company?

Only when you send it. LandEarly writes the draft and delivers it to your own inbox - the “send” button is about approving the text, not about reaching a recruiter. A handoff for this page drew a To: line with a named recruiter on it; there is no such line, and no address is resolved anywhere in the flow.

Can I use this without connecting my inbox?

Yes, and it’s the default. Drafts need no mail access at all - the cron that writes them never checks whether an inbox is connected. Only the status-moving half needs a grant, and turning that off later leaves every status you already have.

How does it know which application an email is about?

Applications submitted for you carry a per-application alias in the address, so a reply comes back identifying itself. Without one it matches the sender’s domain against companies you applied to in the last 90 days - and refuses when two employers share a host, which is common on applicant systems, rather than guessing between them.

What if it moves a status wrongly?

Change it back from the application; the timeline keeps both the automatic move and your correction, and email-sourced moves are marked as such. What it can’t show you is the sentence it read, because none was stored - the evidence is the sender’s domain and a message id.

Will it reply to recruiters for me?

No. Both inbox grants are read-only and there is no compose path attached to either. It reads headers, files an outcome, and at most moves the board to interview, offer or rejected.

Why did my drafts stop?

Not your email settings - those govern the digest, not the draft. Either the application has left “submitted”, something already replied, or it has passed 30 days since you applied, at which point a “just following up” stops being one. All three cancel the draft by design.

Follow-ups

Stop finding out in October that it ended in July.

Start with drafted nudges, which need no mail access at all. Connect an inbox later - or never - if you want the board to keep up without you.

Gmail · Outlook · read-only · scan every 30 minutes