The problem this solves
Store databases are good at one half of this question and weak at the other. Asking which shops run a given commerce platform is a technology lookup, and plenty of indexes answer it. Asking which of those shops actually sell camping gear, prescription eyewear or restaurant supplies is a question about merchandising, and the category labels in a directory are usually inherited from whatever the shop typed into a form years ago. Filtering on both at once in one index tends to return a list that is right about the platform and vague about the product.
The usual workaround is to pull a wide platform list and sort it by hand. That works at fifty rows and stops working at five hundred, and the judgement calls get made quickly and inconsistently near the end. Worse, the reasoning disappears: a row survives or it does not, and nobody can reconstruct why a week later when a rep asks whether the list was built properly.
What makes this workable is checking each candidate against the store itself and keeping the answer. A shop either shows the platform in its storefront or it does not, and it either sells the category or it sells something adjacent. Both are visible on the page. When the finding travels with the row, a near-miss stays inspectable and the definition can be tightened on the next run rather than re-argued.
How the mission runs
- State the two conditions in plain sentences. The prompt carries the criteria as sentences a person would write: the storefront runs on <platform>, and the shop sells <category>. The Prospecting Agent turns each into a condition it will test candidate by candidate, so both are first-class filters rather than one hard filter and one hopeful keyword.
- Generate candidates from the open web. Candidates come from searching the web for shops that plausibly fit, which is what lets the mission reach stores no directory has categorised properly. The generation step is deliberately broad, because it is cheaper to test a candidate and reject it than to miss a shop a directory filed under the wrong label.
- Check every candidate against both conditions. Each candidate is read against the two conditions in turn and gets a verdict plus the finding behind it. A shop whose storefront shows the platform and whose catalogue shows the category is a match. One that satisfies only the second is held as a near-miss with the failing condition named, which is the part that tells you whether your criteria are too tight.
- Add firmographics to the survivors. Matches are enriched with the company facts that make a list usable: headcount band, country and the registered company name behind the brand. This runs only on rows that already passed both conditions, so the enrichment spend follows the qualification rather than leading it.
- Save the list and export the evidence with it. The matches are written to list <name> with the domain, the firmographics and the per-condition findings as columns, then exported to Google Drive as a CSV. The evidence columns are the point: anyone can open the file and see why a shop is on it.
The prompt
This is the exact objective the agent receives. Swap the obvious placeholders for your own domain, segment or channel and run it as-is from the console, Slack, or the API.
What comes back
A refreshable list of 25 checked stores with domain, company name, headcount band and country, plus one evidence column per condition carrying the finding and the page it came from. The same file lands in Google Drive as a CSV, and the near-misses stay on the run so the criteria can be tuned before the next pass.
Make it yours
- Swap the platform condition for a payment provider, a subscription app or a loyalty tool to find shops that already run a system yours integrates with.
- Add a third condition about scale, such as shipping internationally or listing more than a hundred products, when the small end of the market is not worth a rep touching.
- Point the same two conditions at a second country and run them as separate lists, so regional differences in the platform mix stay visible instead of averaging out.
- Follow the list with a contact pass to add the head of e-commerce with a verified email, turning a qualified account list into a sendable one.
Frequently asked questions
Why check the storefront instead of filtering a store directory?
A directory can only return what it has already collected and labelled. Checking the storefront answers both halves of the question at the moment you ask it, which matters most for the shops a directory has filed under a vague category or has never seen.
What happens to the candidates that fail one condition?
They come back as near-misses with the condition they failed and the finding behind it. That is usually the most informative part of a first run: if every candidate fails the platform check, the platform name probably needs to be stated differently.
How long does a run like this take?
Discovery searches for several minutes rather than seconds, because each candidate is read and tested rather than matched against a stored field. A run returns what it has found so far and can be collected again as it continues, so nothing is lost if you stop watching.
Can the list be kept up to date?
Yes. The list is persistent, so the same criteria can be run again on a schedule and only the new matches added. Shops migrate between platforms more often than most teams expect, which is exactly why a stored answer goes stale.