Qualify accounts by number of local merchants
Multi-location businesses qualified on a real location count: a published figure checked for scope and date, then a map count confirmed by a second source.
- Starts
- List created
- Steps
- 4
- Checks and gates
- 0
- A person decides
- Never, runs alone
Trigger · Event
List created
A newly built list of accounts opens the run, so qualification finishes before a rep opens any of them.
Claude runs the rest autonomously
- 1
AI finds a published footprint figure.
SerperSerper
A published figure with its source comes first where one exists, from press coverage, an investor page or a company profile.
- 2
AI confirms the figure's scope and date.
The figure is kept only if it covers the right geography and is recent, with a second source for anything close to your threshold.
- 3
AI counts the matching locations.
SerperSerper
Once an explicit area is confirmed, you get a count of the location listings that actually match the account.
- 4
AI verifies it with a second count.
OpenStreetMapOpenStreetMap
Where available, a second geographic source counts the same area independently, so the number is confirmed before it decides the call.
Result · Every account resolves to a footprint count with its source, date and scope, plus a qualified or disqualified verdict you can actually stand behind.
Qualifying an account on its real-world footprint usually means someone searching for a 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 is actually checked for scope and freshness. When nothing reliable exists, a direct count of the account's locations, cross-checked against a second source, gets to a sourced number and a qualified or disqualified verdict a rep can 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.
How AI counts an account's locations
The run starts from a list of accounts and your qualification threshold, something like "at least N locations". For each account, the agent looks for a figure someone already published before counting anything: press coverage, an investor or about page, a company profile, found through Serper. A number with a clear source and date is usually enough, and the census is skipped.
When no reliable figure turns up, the agent counts. That needs an explicit geographic area, a country, a region or a city, and if none has been given it asks before running anything. Over that area it runs a location search and counts only the results that match the account, filtering out other brands and unrelated listings that happen to share a name.
Where an open geographic data source like OpenStreetMap is available, a second count runs over the same area. That kind of source tends to be strongest for infrastructure-type categories and weaker for general consumer retail, so a mismatch is a prompt to look closer rather than an automatic tie-breaker. Agreement between two independent counts is a real confidence signal to have before a qualification decision.
Checking a location count before it qualifies anyone
A published figure is kept only if it matches what you are qualifying.
- Geography. A global or group-wide total is a different number from the region your account operates in. It looks like a real answer and qualifies the wrong thing.
- Date. An old announcement can be stale by the time it is read, so how recent the source is gets noted.
- Closeness to the threshold. A number near the line between qualifying and not gets a second source before the verdict goes either way. The decision hinges on exactly those close cases, which is where a second source earns its place.
A figure that fails any of these sends the account to the census instead.
Requiring an explicit area is what keeps that fallback from producing a meaningless number. A census with no defined scope returns a count of nothing in particular, so the area is confirmed on every run, never assumed from context.
What each account comes back with
Every account resolves to the estimated count, where it came from (a published source or a census), the date, and the geographic scope it covers, followed by the verdict: qualified or disqualified against your threshold, and why. The source and scope travel with the number, which is what lets a rep defend the call on a borderline account.
The prompt
The real prompt behind the steps above, detailed enough that an agent with the same tools can run it as written. The Run buttons copy the full version, which also carries the steps for connecting those tools.
# 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"]**.
## 1. Find a published footprint figure
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 figure's scope and date
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. Count the matching locations, 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. Verify it with a second count
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.
Why run it with Tulina
A prompt helps one person. A process moves a team.
Pasted into a chat, the prompt above works once, for whoever pasted it. In Tulina, "Qualify accounts by number of local merchants" becomes a process the team shares, that keeps its history, runs on its own, and stays inside the same security perimeter as the tools it calls.
The whole team works on the same one
PersonalTeamOrganisation
A process lives where it belongs: yours, your team's or the whole organisation's. Whoever runs it can improve it, and everyone starts from the best version instead of explaining the job again.
Every edit is a version
v1v2v3
Each change is a new version with the previous one kept, so a bad edit is undone by restoring an earlier one. Every run records the version it followed, and what a run teaches goes back into the process.
It runs without you
schedulewebhookon demand
A hosted agent runs the process on Tulina's own infrastructure, on a schedule or when an event arrives, and keeps going when you close the chat. Nothing to host. Every run is tracked to its outcome.
Inside the same security perimeter
vaultrolesrun log
Credentials stay in the vault, never in the prompt. Roles decide who may run what, every call is logged, and a step a person has to approve waits for that person.
Questions about qualifying accounts by location count
Also on Serper
Other processes that run mainly on Serper. The tools they share with this one are lit.
Find doctors and clinics
A census of every doctor and clinic in a French city, from map listings cross-checked against the practitioner registry and facility directory, with gaps named.
- Shares
- Serper
Specialty and city named6 steps →
Find local points of sale
Every target city is searched three different ways for shops that fit your positioning, each one ranked on fit and reviews before the first email goes out.
- Shares
- Serper
Target city list created5 steps →
Outreach based on government data
Every candidate's website is verified before a credit is spent, tiered by signal strength, then written one grounded opener that is checked for repetition.
- Shares
- Serper
New target list7 steps →
