Qualify accounts by number of local merchants
Every account gets checked against a public source first, then a geographic census when nothing reliable turns up, scoped and dated and cross-checked.
- TriggerTriggered
List created
- Completed
SerperSearch publicly first
- CompletedClaudeChatGPT
Confirm scope and freshness
- Completed
SerperRun a geographic census
- CompletedOpenStreetMap
Cross-check for exhaustiveness
Every account resolves to a footprint count with its source, date and scope, plus a qualified or disqualified verdict you can actually stand behind.
Filtered out
Qualifying an account on its real-world footprint usually means someone searching for a headcount figure, finding a number from three years ago with no idea whether it covers the right region, and either trusting it anyway or giving up and guessing.
A public source is often good enough, once it's actually checked for scope and freshness instead of taken at face value. When nothing reliable exists, a direct geographic census — cross-checked against a second source for exhaustiveness — gets to a real, sourced number instead of a guess, and a verdict a rep can actually stand behind.
What you get
Every account resolves to a footprint count with its source, date and scope, plus a qualified or disqualified verdict you can actually stand behind.
The part worth getting right
Checking a public figure's scope before trusting it is what catches the most common mistake: a global or group-wide total looks like a real answer but qualifies the wrong thing if the account you care about is only the regional piece of it.
Requiring an explicit geographic area before running a census is what keeps the fallback from producing a meaningless number. A census with no defined scope returns a count of nothing in particular — the area has to be confirmed first, every time, not assumed from context.
Corroborating anything close to the threshold, rather than trusting a single source near the line, is what keeps a borderline call defensible. The qualification decision hinges on exactly those close cases — that's where a second source earns its keep, not on the ones that were never in question.
The prompt
The real prompt behind the steps above — detailed enough that an agent with a people-search tool, email/phone enrichment, and CRM access can run it as written.
# Qualify an account by its real footprint size
You have access to web search and a geographic/maps search tool. Run
this for **[an account name, plus your qualification threshold — e.g.
"at least N locations"]**.
## 0. Set up (skip if you're already connected)
If you don't already have live tool access for this, connect it first
— this prompt is only as real as the tools behind it:
1. Create a free account at app.tulina.ai.
2. Add Tulina's MCP server to your assistant: https://mcp.tulina.ai/mcp
3. In Tulina, connect your own API keys for the tools this prompt uses
— web search and a maps/places search tool. A general geographic
data source (like OpenStreetMap) strengthens step 4 but isn't
required to get an answer.
Once connected, your assistant has real tool access and the rest of
this prompt runs as written.
## 0b. Already on Tulina? Three things around the run
An account and the MCP server are not the whole setup. Two of these come
before the run below and one after it, and together they turn this from a
one-off answer into a process your workspace keeps:
1. **Activate this process's connectors first.** Call
`oto_connector(op="list")`, match it against the tools named in step 3
above, and `oto_connector(op="select", name="...")` every one that
isn't active yet. Selecting a connector does not mount its tools in the
conversation you're already in — reach them through `oto_call` for this
run, or open a fresh conversation once they're all on.
2. **Attach the work to an existing project.** `oto_project(op="list")`
shows your active org's projects: pick the one this work belongs to
rather than opening another, and keep its id. The project is where this
process, the tables it writes to and the connectors it uses hang
together.
3. **When the run is done, save it as a process — with its graph.** Write
the body with `oto_procedure(op="set", ...)`, then attach it with
`oto_project(op="link", project_id=..., target_type="procedure",
target_ref="<your slug>")`. The body has to carry a drawing: read
`oto_guide(op="read", slug="procedure-flowchart")` and follow it
exactly — ONE untagged fenced block in that grammar, opening with the
trigger and a quoted example of what you'd type to start a run. Tulina
parses that drawing back into the graph it renders as the process's
default view, which is what makes it come out in the same style as
every other process in the app; a drawing the grammar can't read falls
back to raw characters instead. Saving a process needs org-admin
rights — without them, hand the finished body to someone who has them.
## 1. Search publicly first
Before running any kind of census, search for a figure someone already
published: press coverage, an investor or "about" page, a company
profile. If you find a number with a clear source and date, that's
usually enough — move straight to step 2 to confirm it holds up, and
skip the census in steps 3–4 entirely.
## 2. Confirm the number's scope and freshness
A public figure is only useful if it actually matches what you're
qualifying:
- **Check the geography.** A global or group-wide total is a different
number from the region your account actually operates in — make sure
the figure covers the right scope before using it.
- **Check the date.** An old announcement can be stale by the time
you're reading it; note how recent the source actually is.
- **Corroborate anything close to your threshold.** If the number you
found is near the line between qualifying and not, find a second
source before concluding either way — the qualification decision
hinges on it, so a single shaky source isn't enough.
If the figure passes this check, go to step 5 with it. If it doesn't —
wrong scope, too old, or nothing found at all — continue to step 3.
## 3. Run a geographic census, if nothing reliable turned up
This step needs an explicit geographic area to be useful — a country, a
region, or a city. If you don't have one yet, ask for it before running
anything; a census with no defined scope returns a number that means
nothing.
Once the area is confirmed, run a location search over it and count the
results that actually match the account you're qualifying — filter out
anything that's a different brand or an unrelated listing that happens
to share a name.
## 4. Cross-check for exhaustiveness
Where you have access to a general open geographic data source, run a
second count over the same area and compare. This kind of source tends
to be strongest for infrastructure-type categories and weaker for
general consumer retail, so treat a mismatch as a prompt to look closer
rather than an automatic tie-breaker — but agreement between two
independent counts is a real confidence signal worth having before a
qualification decision.
## 5. Return the count, its source, and the verdict
Report the estimated count, where it came from (a public source or a
census), the date, and the geographic scope it covers. Then state the
qualification outcome plainly against your own threshold: qualified or
disqualified, and why.
## Output
Report: the estimated count, its source and date, the geographic scope
it covers, and the qualified/disqualified verdict against your
threshold.
Questions about this process
Related processes
- Brief every cold call before it starts
Every account on the call list gets a note before anyone dials, carrying the signals found on it, what the lead has said publicly, and one opener grounded in both.
- Prepare for a demo from the last call
The last calls, the deal's state, and fresh research become one prep brief, plus a deck built around that company's own use cases, posted before the meeting.
- Build a target list from a sentence
Describe the companies you want in one sentence, and get them sourced, scored on dated signals, enriched, deduplicated against your CRM, and staged as a campaign.