Which candidates are waiting on your team: joining Greenhouse and Gmail

It is Tuesday morning and the head of talent is standing at a recruiter's desk with a question that sounds simple. A hiring manager escalated last night: a senior backend candidate they liked has gone quiet, and the manager thinks nobody replied to her. The recruiter opens Greenhouse and pulls up the candidate. Stage: Technical Interview. Last activity: eleven days ago. There is a scorecard from the interview, submitted. There is no rejection, no offer, no scheduled next step. The pipeline view shows her sitting in a column with fourteen other names.

So the recruiter opens Gmail and searches the candidate's name. There is a thread. The candidate wrote on the Thursday after her interview asking about timing and mentioning a competing process. Nobody answered it. The last message in the thread is hers.

Now the head of talent asks the real question: how many others are like that? Not how many are stalled in a stage. How many wrote to us and are still waiting. Neither person can answer it, and both of them have the evidence on screen.

What Greenhouse shows on its own

Greenhouse is a good applicant tracking system and it is genuinely strong at pipeline state. It knows every candidate, every job, every stage, the date they entered that stage, who owns them, which interviews are scheduled, which scorecards are in and which are missing, and what the offer status is. Its reporting is real reporting: pipeline per job, time in stage, stage conversion, source quality, interviewer load, EEOC breakdowns. If you want to know that eleven candidates have been in Technical Interview for more than ten days, Greenhouse tells you that cleanly and you can build the report yourself.

Greenhouse also logs email. If your recruiters send candidate mail from inside Greenhouse, or through the Gmail integration that syncs candidate correspondence to the profile, the thread appears on the activity feed. That is a real feature and it works.

Here is precisely where it stops. Greenhouse knows a message exists. It does not know what the message said, and it does not evaluate whether the last one obliges you to reply. Activity on a profile is activity: an email that says "great news, we are moving you forward" and an email that says "I have another offer with a Friday deadline, can you tell me where I stand" are the same row in the feed. Its report filters run on the fields it stores: stage, date, owner, status. There is no field called "the candidate asked us something and we have not answered." That is not an oversight in the product. It is not the kind of thing the schema is made of.

What Gmail shows on its own

Gmail has the sentences. Every word the candidate wrote is there, searchable, with exact timestamps and a thread structure that shows who spoke last. A recruiter who searches a name gets the whole conversation in a few seconds, including the tone of it, including the part where the candidate mentioned a competing offer, including the fact that the last message came from her and nothing followed.

Gmail search is capable. You can scope to a label, restrict to a date range, filter to messages you have not replied to within a mailbox, and Priority Inbox and nudges will surface some of it. For one candidate, Gmail answers the question completely.

Here is where it stops. Gmail does not know who is a candidate. It does not know which requisition anyone applied to, what stage they are in, whether they were already rejected last week, whether the silence is a problem or the correct outcome. An unanswered thread from a candidate who withdrew is not a failure. An unanswered thread from someone in final stage with a competing offer is an emergency. Gmail cannot tell those apart because the difference lives in a different system entirely. And a recruiting inbox is not just candidates: it is vendors, scheduling bots, agency outreach, internal threads. Sorting the mailbox by "last message not from us" gives you a pile that is mostly noise.

Why the gap exists

Look at the shape of the two halves.

The answer to "which candidates are waiting on us" needs one column from each side. The waiting part is a sentence a human wrote in a hurry on a Thursday night. The candidate part is a record with a stage and an owner.

This is why it is not a missing report. Greenhouse could add every filter in the world and still not surface it, because the evidence that someone is waiting was never a field it stores. Gmail could add every rule in the world and still not surface it, because the evidence that this person matters was never in the mailbox. The question falls in the space between two systems that are each complete on their own terms.

It is worth being precise about the neighbours here too, because people reach for them first. Zapier and Make will absolutely move this forward: new candidate, send mail, update stage, post to Slack. That is what they are for and they do it well. But they are trigger based. They fire when something happens and act on that one thing. "Which candidates are currently waiting on us" is a question about accumulated state across two systems, and there is no event to hang it on. The situation you are asking about is precisely the one where nothing happened.

BI tools have a different boundary. Looker's conversational layer and Power BI Copilot answer questions in natural language, well, over what they are connected to: warehouses, modelled tables, defined metrics. If your Greenhouse data lands in the warehouse, they will chart stage duration beautifully. But the sentence in the mailbox is not in the warehouse and is not a modelled dimension. It is outside what those tools can see at all, not something they are bad at.

What the join actually requires

Two things, and only one of them is mechanical.

The key is email address. Greenhouse has the candidate's address on the profile. Gmail has it in the From line. Match them and you have a candidate-to-thread mapping, with the usual mess: candidates who apply from a personal address and reply from work, aliases, plus-addressing, threads where a coordinator is the only recruiter-side participant. Name matching helps as a fallback. This part is fiddly but it is deterministic.

The second part is not. Somebody has to read the last inbound message and decide whether it obliges a reply. "Thanks, looking forward to it" closes a thread. "Can you let me know by Thursday, I have another offer" opens one. "Sounds good, I will send those over" means the candidate owes you something, not the reverse. A rule that says "last message not from us equals waiting" produces a queue full of pleasantries, and a queue full of pleasantries gets ignored by week two. The judgement is the product. That is the part matching cannot do.

How you would answer it with Skopx

Skopx connects to Greenhouse and Gmail among nearly 1,000 tools, and the question goes in as a question:

Which active candidates sent us an email we never replied to, and how long have they been waiting? Show stage, job, recruiter, what they asked, and days since.

What happens: it pulls active candidates from Greenhouse with stage, requisition and owner, finds their threads in Gmail by address, checks who spoke last, and reads the final inbound message to judge whether it actually needs a response. The answer comes back with citations, so you can click through to the Greenhouse profile and the Gmail thread and see the sentence yourself rather than trusting a number.

Once you have asked it once, you can turn it into a standing console. In Skopx that is another sentence in chat: describe the view you want and an internal app gets built from it. A useful version for this looks like one table sorted by days waiting, with columns for candidate, job, stage, recruiter, the asked question in the candidate's own words, and the age of the silence. Filters for requisition and recruiter, so a hiring manager sees only theirs. Row-level scoping so recruiters see their own pipeline. And on each row, one button that a person clicks: draft a reply in the recruiter's Gmail, with a confirmation before it sends.

The console stores nothing of its own. It reads Greenhouse and Gmail live every time it loads, and the only write is that button, pressed deliberately by a human who read the row.

Honest limits

It reads and it acts on a click. It is not a system of record and it will not become one. There are no forms, no notes saved into the console, no records created. Greenhouse stays the source of truth for pipeline and Gmail stays the source of truth for correspondence.

It does not run on a schedule, does not send alerts, and does not chase anyone automatically. Nothing happens overnight. Somebody opens the console and looks, or nobody does.

There is no public link. It lives behind your workspace and respects permissions from the underlying tools.

The join is only as good as the addresses. A candidate replying from an address Greenhouse has never seen will be missed unless name matching catches it, and it sometimes will not. The judgement on whether a message needs a reply is a model reading text, which means it will occasionally be wrong in both directions. That is why every row cites the actual thread: the console tells you where to look, and you decide.

And it does not solve slow hiring. It shows you the specific people currently waiting on a human being, which is a smaller and more useful thing than a funnel chart.

Team is $16 per seat per month with 2.3 million AI tokens included. Solo is $5. SOC 2 controls are in place.