Open a fresh extraction of plumbers and a strange pattern appears: rows with a phone, a rating, plenty of reviews, and no street address. New users file bug reports about it. The rows are correct, and understanding why changes how several whole categories should be worked.
What a service-area business is
Google Maps distinguishes two kinds of business. A storefront serves customers at its premises: shops, clinics, restaurants. A service-area business (SAB) serves customers at their premises: plumbers, electricians, cleaners, mobile locksmiths, landscapers, movers. Google lets SABs hide their street address and display a coverage area instead, because the address is often the owner’s home and publishing it serves nobody.
The result in your export: a legitimate, active, often thriving business whose address column is blank or shows only a town name.
The categories where this dominates
This is not an edge case. In the trades, SAB configuration is the majority arrangement:
- Mostly SABs: plumbers, electricians, locksmiths, cleaners, movers, landscaping, pest control, mobile mechanics, towing.
- Mixed: HVAC (offices plus service fleets), roofers, painters, photographers.
- Mostly storefront: everything customers walk into, from salons to restaurants to clinics.
A trades export where 40-60% of rows lack full addresses is a normal, healthy extraction. An extractor that “fixed” this by dropping those rows would be discarding the majority of the category.
What it breaks, and what still works
Broken: address-based anything. Mail campaigns, door visits, address-deduplication, “businesses on this street” analyses all lose the SAB half of the category. If a workflow assumes a street address, trades categories will quietly starve it.
Still works: everything that actually matters for outreach.
- Phone is unaffected, and in SAB categories the listed number is usually the owner’s mobile, which makes these rows more directly contactable than storefront rows, not less. Phone-first workflows were built for exactly this population.
- Coordinates still exist (Google anchors the listing somewhere in its service area), so radius and territory work keyed on latitude/longitude survives, with the caveat that the pin marks the area, not a door.
- Ratings, review counts, category, hours are all unaffected, so review-band segmentation proceeds normally.
The prospecting angle hiding in the flag
An SAB row tells you something a storefront row does not: this business’s entire customer acquisition runs through its listing, its reviews and its phone. There is no walk-in traffic, no shopfront visibility, no passing trade. Which means:
- Their Maps presence is their storefront. Under-reviewed SABs are losing jobs to better-reviewed rivals in a way a physical shop with foot traffic is not, making them the strongest fit for review-gap pitches in the whole dataset.
- Missed calls are lost jobs, entirely. A storefront misses a call and the customer may still walk in; an SAB misses a call and the customer dials the next result. Every missed-call-recovery, answering, and WhatsApp-autoreply service sells best into SAB categories, and the industry guides for trades lean on exactly this.
Working an SAB-heavy export
- Do not filter on missing addresses. Add an
is_sabstyle flag (address blank or town-only) instead, and treat it as segmentation, not damage. - Route SAB rows phone-first, storefront rows by their category norms.
- Use coordinates for territories, never parsed street addresses, in mixed categories.
- De-duplicate on place ID as always; SABs make address-based deduping worse than useless.
- Expect home-adjacent hours: SAB owners answer early and late, and the best call windows sit outside storefront norms.
Half of local business does not have a front door. The export represents them faithfully; workflows just have to stop assuming everyone does.