Why did I get 300 applications in a day?

You posted a remote role on Monday afternoon. By Tuesday morning the ATS says 300 applicants, and by Wednesday it is closer to 700. Most of the résumés look fine at a glance, which is the problem: you cannot read 700 of them, and you suspect you should not have to. There are three ordinary explanations for a pile like this, and the export tells them apart.

The three causes

1. A job board picked up the posting

Indeed, LinkedIn, ZipRecruiter and the aggregators syndicate postings from most ATSs automatically, and one-click apply makes applying nearly free for a candidate. When a board starts showing your posting, applications arrive in a wave that tracks that board's traffic. The people are real. The wave just means your posting is now visible to everyone, which for a remote role with no location filter is a very large everyone.

2. Auto-apply tools

There are browser extensions and paid services that submit applications on a candidate's behalf: the candidate sets a title and a location, the tool fills in every matching posting it can find, sometimes hundreds a day. The person exists and would probably take the job, but they have not read your posting and may not remember applying. These are not fraud. They are low-intent applicants whose contact details are entirely real, and the only tell is that the application fits the role loosely and arrived in a cluster.

3. A ring

One operator applying as many people: for proxy-interview schemes, for identity-borrowing arrangements where the person who interviews is not the person who will work, or simply to get as many offers as possible and pick one. Each application needs its own identity, so the operator generates names, addresses and phone numbers, and that is where it shows. Generated identities have shapes real ones do not, and the export carries them.

What each looks like in the export

Export the posting's applicants to CSV (per-ATS guides) with name, email, phone and applied date, and look at four things.

• Timing. Sort by applied date. A board wave rises over hours and follows a daily rhythm. An auto-apply tool shows up as several applications a minute apart with similar profiles. A ring often shows up as a burst in one or two hours, frequently at an odd time for your time zone.
• Duplicate phones and mailboxes. The same phone number on several applications under different names is the single clearest sign of a ring; it is the thing that was too much trouble to vary. The same goes for one Gmail inbox hiding behind dots and plus tags. The shared phone number guide has the spreadsheet steps.
• Phone numbers from VOIP wholesalers. Real applicants give a mobile number. Generated identities give numbers bought by API from Bandwidth, Onvoy, Telnyx and the like, because that is the only way to get one per identity in seconds. The free number lookup checks one number; an upload checks all of them.
• Email shapes. Addresses with five, six or seven digits in them, handles with no trace of the applicant's name, throwaway domains. The email red flags guide goes through each.

Boilerplate résumés and identical screener answers are also real signals, and you will notice them when you do read the pile. ApplySift does not check them: the export does not carry the files, and it says so on the signals page.

How ApplySift handles a burst

If the file has an applied-date column, ApplySift counts applications per hour and looks for hours that held at least twenty applications and at least ten times the posting's median hourly count. It needs at least three distinct hours in the file to have a median at all. Rows in such an hour get the reason burst:N/hour in the scored file.

A burst never flags a row by itself, because a board syndicating your posting produces exactly the same shape. It adds one point only to a row that already has another reason. So a real person who applied during the rush stays Clear, while a row with a wholesaler number (three points) that arrived in the same rush goes to four, and a second signal of any size takes it to Likely fraud. The reason string is written on every row in the hour, flagged or not, so you can filter the scored file to the hour and look at it as a group.

Triage without reading every résumé

1. Find the clusters first. Shared phones and mailboxes collapse a pile fast: a cluster of eight applications is one applicant. Read the strongest résumé in each cluster, if any, and skip the rest.
2. Sort the remainder by tier. Likely fraud at the bottom; it is where a wholesaler number met a second signal. Glance at a sample to satisfy yourself the signals are right for your pool, then leave the rest.
3. Read the Review tier with the résumé open. One strong signal or a couple of weak ones. A fresh Outlook address with a mobile-carrier phone and a résumé that fits is usually a real person. A clean address with a wholesaler phone and a résumé that fits every posting equally is usually not.
4. Treat Clear as a normal pile. Clear means the cheap tells are absent, not that the person is real or right for the role. This is where the auto-apply applicants live, and the ordinary screening questions (do they match the posting, can they do a live call) sort them.
5. Change the posting if it keeps happening. A knockout screener question that needs a real answer, a location requirement where one is honest, and a short cover question all raise the cost of applying slightly, which is enough to drop auto-apply volume while costing a real candidate a minute.

What not to do

Do not reject a whole hour. A board wave and a ring can share one; the real applicants in it deserve the same look as everyone else. Do not reject on a single weak signal, and do not contact an applicant to ask whether their number is VOIP; it is a lookup, not a conversation. ApplySift never rejects anyone and never contacts anyone. It tells you where to look first, and the reasons are written in words next to every row so you can disagree.