SAGIO Radar¶
Radar turns merchant acquisition into a ranked list instead of a cold-calling habit. It sweeps public sources for New Zealand food merchants, merges them into one record per business, reads their websites to find out what they already run, and scores how likely each one is to switch to SAGIO this week.
The output is not "1,000 leads". It is an ordered queue, and every position in it can be argued with — open any row to see the exact signals and evidence that produced its score.
This page contains merchant contact data
Phone numbers and email addresses collected from public sources are business contact details, not personal profiles, but they are still not something to publish openly. This page must stay behind the HQ login.
Loading the Radar dataset…
| # | Fit | Merchant | Kind | Where | Contact | Existing stack |
|---|
Market venues
Auckland Night Markets publishes no vendor directory, so there is nothing to scrape — but it does publish where dozens of prospects stand on a known night. One organiser relationship reaches a whole venue at once.
| Night | Market | Location | City | Organiser |
|---|
How to read the score¶
A merchant's score is the sum of weighted signals. Positive weights mark a merchant who can switch easily; the single negative weight marks one who cannot.
| Weight | Signal | Why it predicts a fast yes |
|---|---|---|
| +3 | Mobile or pop-up merchant | No fixed terminal contract to unwind |
| +3 | Owner directly reachable | The decision-maker answers the phone |
| +3 | No sophisticated POS detected | Nothing expensive to rip out |
| +3 | Paying marketplace commission | Already losing 30% and knows it |
| +2 | Active Instagram | Owner-operated and reachable off-channel |
| +2 | Recurring market attendance | Referral surface: they meet other vendors weekly |
| +2 | Already uses QR | Customers are trained; the behaviour exists |
| +1 | Runs on Shopify | An integration path already exists |
| +1 | Simple self-managed website | No agency between us and the owner |
| −3 | Multi-location chain | Central procurement, long sales cycle |
Tier A is 11 points or more, B is 7, C is 3. The maximum currently reachable score is 20.
Two signals deliberately score zero¶
The original rubric wanted "accepts card" and "recently opened". Neither is observable from any wired source, so both appear in every breakdown with zero points and the reason attached, rather than being quietly dropped:
- Accepts card — only 28 of 4,865 Auckland OpenStreetMap records carry any
payment:*tag. - Recently opened — only 18 carry
start_date.
They stay visible because a scoring rubric that hides its blind spots produces a number that looks better informed than it is. Wiring a source that supplies either one is a real upgrade to Radar's accuracy.
Sources¶
| Source | What it gives | Scale | Terms |
|---|---|---|---|
| OpenStreetMap via Overpass | The base universe: names, addresses, cuisine, phone, website | ~4,900 Auckland food businesses | ODbL — attribution required |
| Street Food Network | Confirmed mobile operators | 13 vendors | robots.txt permits crawling |
| Auckland Night Markets | Recurring venues and the organiser contact | 10 venues | Curated by hand; no vendor list exists |
Merchant data on this page is derived from OpenStreetMap and is © OpenStreetMap contributors, available under the Open Database Licence.
Sources considered and not wired¶
- Auckland Council food register (
eatsafe) — the largest available universe of registered food premises, but the site answers plain HTTP requests with406 Not Acceptable, includingrobots.txt. Reaching it needs browser automation, and it carries no contact details. Worth doing; not free. - A national MPI register — does not exist in the form the plan assumed. Food-business registration in New Zealand is administered per territorial authority, so "the NZ register" is really a dozen council registers.
- Instagram and TikTok discovery — the highest-signal enrichment layer and the one with the least defensible scraping story. Not wired.
Running it¶
bun scripts/radar/run.ts # Auckland, enrich 300 websites
bun scripts/radar/run.ts --no-enrich # sources only, fast
bun scripts/radar/run.ts --area Wellington # any region in config.REGIONS
bun scripts/radar/run.ts --enrich-limit 1000 --publish-limit 2000
bun test scripts/radar/ # 30 unit tests
The run writes docs/radar/data/merchants.json, which is what this page reads.
Sweeping is polite by design: every request identifies SAGIO with a contact
address, hosts are rate-limited to one request per 1.2s, and responses are
cached on disk for a week, so a re-run costs a merchant's server nothing.
What Radar does not do yet¶
- No claim-link generation. The strongest wedge in the acquisition plan — pre-generating a merchant page and leading with "I made this for your business" — is not built. Radar produces the ranked queue that would feed it.
- No outreach state. Radar does not know who has been contacted. Every run reproduces the full ranking from scratch.
- No transaction-volume estimate. Nothing in the wired sources supports one, and a guessed number would quietly reorder the queue.