Sales · Find & Prepare
Describe your ideal customer. Get a verified list by morning.
Say who you sell to in a sentence. Doe searches companies and people that match, scores each against your ICP with a reason you can read, verifies the emails, and writes the list to a sheet or your CRM. No checkbox gymnastics, no scraped guesses.
Works acrossDoeHubSpot
What you get.
Describe your ideal customer in a sentence and Doe returns a built, qualified, email-verified list, not a raw export. It searches companies and people with its native tooling, scores each row against your ICP with a reason attached, runs a waterfall to confirm deliverable emails, and writes the result to a sheet or your CRM. The list rebuilds itself on a schedule and skips everyone you have already contacted.
Your best customers do not fit in a dropdown.
You know your ICP when you see it. "Mid-market logistics companies that just outgrew spreadsheets, run on NetSuite, and have a VP Ops who owns the tooling budget." Now go express that in Apollo's filters. You can't. So you approximate: industry equals "Transportation," headcount 200 to 1000, and you hope. What comes back is a list that is 40% off-target and you find out one bounced email at a time.
The other half of the job is worse. You paste names into a sheet, tab over to verify the email, tab back, mark the ones that look promising, then realize the list you built six weeks ago is already stale because three of them changed jobs and two got acquired. Building the list was supposed to be the easy part. It eats the morning, every morning.
What changes.
- 01How you describe the targetBefore · Translate your ICP into rigid checkbox filtersWith Doe · Say it in a sentence; Doe builds the search
- 02List qualityBefore · Padded to a count, ~40% off-fit, found out via bouncesWith Doe · Qualified against your ICP with a reason per row
- 03Email accuracyBefore · Verify one row at a time, after the factWith Doe · Verified on output; risky rows flagged before you send
- 04Staying currentBefore · Stale within weeks; rebuilt by handWith Doe · Rebuilt on a schedule, already-contacted rows excluded
From one sentence to a qualified, verified list
- 01Reads your ICP in plain English and turns it into a searchDoeDoe translated "mid-market logistics on NetSuite with a VP Ops budget owner" into company and people criteria, including the firmographic and persona filters you could not express in a dropdown
- 02Searches matching companies and the right people inside themDoeDoe pulled candidate accounts and the decision-makers who match the persona, scoped to your size, geo, and technology constraints
- 03Scores every row against your ICP and attaches a reasonDoeThe Judge qualified each lead with a fit score and a one-line rationale, so you see why a row made the list, not just that it did. Off-fit rows are excluded, not padded in to hit a count
- 04Runs a waterfall until each kept row has a verified emailDoeDoe ran its native verification waterfall, stopping once it had the number of verified, deliverable emails you asked for. Risky and unverifiable rows are flagged, not silently included
- 05Writes the finished list where your team already worksHubSpotDoe created or updated contacts with fit score, source, and verification status, and dropped a copy in a shared sheet. Nothing lands without context
- 06RecurringEvery Monday at 6:00 AMEach week Doe rebuilds the list against the same ICP, skips everyone already in sequence, and adds only net-new matches. The rejections you make teach it your real ICP, so the list gets sharper every run instead of going stale. New rows pushed to HubSpot + a summary in #prospecting.
Start with the right source material.
- 01Add your library and toolsAdd or select the source files Doe should use, then connect the tools this task needs. No API keys, no engineering.
- 02Describe what you need“Build me a weekly list of mid-market logistics companies on NetSuite with 200 to 1,000 employees. Find the VP of Operations or Head of Logistics, verify their work email, score each against our ICP, and drop net-new matches into #prospecting and HubSpot.”
- 03It runs on scheduleRuns every Monday. A qualified, verified, de-duplicated list is ready before your team logs in.
Before you delegate.
- 01How is this different from filtering in Apollo or ZoomInfo?Apollo and ZoomInfo give you a filter form and a database. You translate your ICP into their checkboxes and accept whatever comes back. Doe takes the ICP as you actually describe it, runs the search for you, then qualifies each result against your criteria with a written reason and verifies the email before the row reaches you. The difference is the judgment and verification layer Doe adds — qualification with a written reason, and an email verified on output — not the raw database underneath.
- 02Does Doe just scrape contacts, or are these verified?Verified on output. Doe runs a native verification waterfall and only counts a row as complete once it has a deliverable email, stopping at the number you asked for. Emails that come back risky, catch-all, or unverifiable are flagged rather than slipped into the list, because a list full of bounces is what torches your sending domain.
- 03How does Doe learn my ICP over time?Every run is a trace you can review. When you remove a row as off-fit or keep one the score ranked low, Doe records that decision and weights the next search accordingly. This is compounding precision: the list does not just stay current, it gets more accurate at your specific ICP each week. There is no model training and your data never trains anyone else's.
- 04Where does the data come from, and is it compliant?Company and contact data comes from Doe's native search and enrichment plus public web sources Doe reads the way a research analyst does. Nothing is pulled from behind a login or in violation of a platform's terms. Verification status and the source of every field travel with the row so your RevOps team can audit it.
- 05Can I run more than one ICP at a time?Yes. Each ICP is its own standing job with its own schedule and destination. A team selling two products to two personas can run both in parallel, and each one keeps its own exclusion list so the same person is never worked twice.