Is Anyone Still There? 773 Employment Checks on 717 People Before Send

We ran 773 employment checks before send. 768 came back current, 3 found someone who had left, 2 came back unverified, and a check cost under one BlitzAPI record on average. A contact lookup often proves only that a person once held a role. It says nothing about today.

This happened to us on 26 September 2026. A data-infrastructure client spotted six people in our sequences who had already left their companies. And every one had passed our lookups. A later check turned up two more we had written to. Eight people. The client caught six of them before we did.

Since then the check has run 773 times on 717 people, counted by name plus account spelling, in 50 batches in October 2026. One check is one row in a batch file. Count by LinkedIn profile URL instead and the same rows hold 701 people, because 16 people at one client account sat under two spellings of the account name. The title uses 717. The tables below use the profile count, 701, which is the stricter one.

Six people had left and our lookups passed them

A lookup hands back what a database holds. If the person changed jobs after that record was last refreshed, you still get a clean title and a company name. That's what data decay looks like on a single row: it reads fine and the person has moved. To see it on your own data, open the profiles of a handful of contacts you've already emailed.

The first full check ran on the client's roster on 26 September. Seventy-three rows came back as 63 current, 8 left, 1 with no record and 1 not found at the company. Eight of 73 is 11.0%. That fits six plus two. But the file can't split the eight between the client's find and the later check, so that split rests on the rule text as written, and eight is the only count the file supports.

That same day, two guessed email addresses, run through an email-to-person lookup, resolved to the wrong person. The employment check no longer uses that kind of lookup.

The rule that came out of it is short. Nobody gets outreach until a check shows they still work at the company. And the check runs when a person is found, before drafting, before the first email, and again before a later email in the same thread.

Four outcomes, and a fixed order of lookups

The check is a procedure, and the order is part of it. BlitzAPI person enrichment goes first. Anyone it can't settle goes to Clay Enrich Person, then to a Clay search on name plus company domain, and last to a person who opens the profile. And you shouldn't let anyone pick a source by feel for one contact and a different source for the next.

Every check ends in one of four results, and only the first clears a person for outreach.

And every run writes a dated record and logs what it spent.

Which source can answer the question

Before the check went into the procedure, I tested three sources on people whose status was already known: departures the client had confirmed, and colleagues still on staff. The sources are BlitzAPI, Clay and MoltSets.

Small samples, every one, and each is a snapshot. But the denominators differ (15, 12 and 11), so the case sets weren't identical. If you're choosing a source, treat these as a reason to test it on your own people, not as a ranking.

BlitzAPI's end dates run coarse. It showed January 2026 for two people who left in mid-2026. A clue, not proof of when someone left, so if you rely on an end date, check it against the profile.

MoltSets got 5 of 11, and several of its misses showed a person still at a company they'd left. Its own newsletter says it shipped a weekly data refresh on 16 October. I haven't re-run employment on it since, so that result is dated. In the pre-send check, MoltSets is not an employment source. We keep it for graded email.

And a roster isn't a check either. On 28 September, 378 people pulled from rosters with a current-employee filter went through the check (the filter comes from our handoff notes, not re-derived from the raw files). 370 came back current. Six had left. Two came back unverified. If a list arrives labelled "current employees", you still don't know until someone checks.

85 of 91 stale addresses still carried Grade A

MoltSets attaches a letter grade to each business email it returns (we saw A, B, C and F across the two runs).

The test used the same 821 LinkedIn profiles at 10 US B2B companies, with one lookup per person, run twice: 28 September and 22 October, 24 days apart. Any address at a different company's domain counted as stale. On 28 September that was 91 addresses, and 85 of those 91 (93.4%) still carried Grade A, the same grade as nearly every address returned that day (438 of 447). The grade did not flag a wrong address. On 22 October it was 40 addresses, and 29 (72.5%) were Grade A.

Then I pulled full profiles for 24 of these people, 12 of whom had a September address at another company. All 12 profiles still showed them at their own company, so the address was the stale part.

The count of stale addresses fell between runs, which is a better number. But it's still 40 addresses, 29 of them graded A. And this is one source, business email only, with 621 of the 821 profiles in the US, so read it as a test of one source and not of the market.

What 773 checks found

Shares are rounded. And the 72 repeats are 773 checks minus 701 people by profile (56 if you count by name plus account spelling), and no one was checked three times.

That 99.35% describes these lists. They were runs with the check in the loop from the start, which means you can't use the figure to estimate how many leavers a check would find on a list that had never seen one. Three lists are on the table, and I count left only. The 26 September roster came back 11.0% left (8 of 73), the 28 September roster pull 1.6% (6 of 378), and these runs 0.39% (3 of 773). Unverified is separate: 2 of 378 and 2 of 773, and on the first roster 2 of 73 had no usable result (1 no record, 1 not found at the company). Different lists on different dates. And none of it is a before and after.

The three who had left carried source end dates from November 2023 to August 2026. But those dates are coarse, so I don't read when each person left from them.

None of the 72 people checked twice changed status between their two checks. I can't read a shelf life from that, but it does say a second look inside that gap found nothing new.

Three current rows carried a role-changed flag: same company, different job. Under the rule, each is sendable only once the copy points to the role that was checked.

What a check costs

For BlitzAPI, a lookup that finds a person returns one record, and a lookup that finds no one is free. That's from Blitz's own pricing docs, fetched 27 October 2026. The 773 checks made 773 lookups, one each. And in 47 of the 50 batches the balance drop was no larger than the lookups, so I read those as clean, and 713 lookups drew 630 records, or 0.884 a lookup. But the other three batches (60 lookups) shared the key with other jobs, so their balance drops of 506, 851 and 1,224 records say nothing about this question. For those, the 53 rows Blitz settled stand in.

That gives 683 records across 773 checks, 0.88 a check, with 690 as the high bound. Add up the raw balance drops instead and you get 3,211 records, or 4.15 a check. That reading is wrong because the shared key adds other jobs' records. As a cross-check, the 28 September run used 336 records on 378 people, 0.89 a check.

For Clay, Enrich Person costs half a credit for each profile sent to it, and only the people BlitzAPI didn't settle go there. That's 106 profiles, so 53.0 credits, or 0.069 a check. The rule reproduces the logged balance drop in 43 of the 50 batches. But the raw logged drop across all 50 is 58.7 credits, so call it 0.07 to 0.08 a check. The 28 September run gives 28.5 credits, which is 57 profiles at half a credit. And two people were referred to a manual profile check, whose time wasn't logged.

Dollars next. Start is $99 a month for 200,000 records as of October 2026, which implies $0.000495 a record at the cap, so 683 records is about $0.34. That's 0.34% of a Start month. But it's the price at the cap, not our bill. And the Start plan looks very interesting to us and is under consideration. Clay stays in credits. The credits here sit on an older plan, so read the figure as ours, not a current Clay price. If you're pricing a check yourself, settle the counting rule first: a found person is one record, and a miss is free. The wider spend of a waterfall is in enrichment waterfall costs.

One gap remains. Within the 47 clean batches, 630 records were drawn against 614 rows Blitz settled. My guess is that a lookup returning a person who didn't match the account still counts. But I haven't confirmed how Blitz bills that case, and the 16 records are the size of the doubt.

What a send waits for in Trellis

We run the check on our side. Trellis doesn't run it. What Trellis does is keep the result and hold a send until the result is on file.

As of 23 October the code holds a send in two cases. It holds a send when there is no result on file, when the result is out of date, or when it says Could not confirm (the Unverified outcome above), and shows "Employment check needed". It also holds a send when the result says Left, Not at the company or Role changed, and shows "Employment not current". The newest result wins. An old "left" never turns into fine on its own, and only a newer check changes it.

Trellis stores five results: Still there, Left, Not at the company, Role changed and Could not confirm, each with an optional link to the source. Staff on the agency side see a button that reads "Record check". And if you're on a client seat, you see "Your operator records this check." The AI in Trellis can't send, approve or dial.

One limit. This describes what the code does. Sending is a separate setting that is off in some workspaces, so read this section as the hold, not a live send.

What to ask of any sending process, ours included

Three questions to put to an agency or a tool. Or to your own team.

When was each person last checked, and where's the record?

Ask per person, not per program. If you can get a dated record for each one, you can count checks and re-checks the way they're counted here. And if the answer is "we verify our lists", ask to see one row.

What happens to someone the check can't confirm?

In these logs it was 2 people in 773. Nothing sends until someone opens the profile. That was our own gap until 26 September 2026, when a client found six departed people in sequences our lookups had passed.

Which fact is the report counting?

A verified mailbox and a current job are different facts. In the September run, 85 of 91 addresses at another company's domain still carried the top grade. And when you read "verified" in a report, ask whether it means the mailbox or the person, because you'll act on it as if it meant the person.

Run it on your own list

Every number above comes from one firm's lists, and yours will differ, which is the reason to run the check on your own.