The sort order is a decision, not a default

Given a list of businesses with a rating and a review count, the obvious move is to sort by review count and work down. For B2B that is exactly backwards, and the failure is legible the moment you look at the top of the list.

Sorted by reviews, our list opened with a home-security company carrying 5,870 reviews and a furniture retailer with 2,193. Neither is a prospect: one installs alarms, the other resells sofas. Meanwhile a genuine contract electronics manufacturer — exactly the business the machine is built for — sat far down the page with eleven reviews.

The reason is structural, not incidental. Review count measures how many members of the public have transacted with a business and been prompted to say so. A business that serves thousands of consumers accumulates thousands of reviews. A contract manufacturer with nine industrial clients on annual agreements accumulates almost none, and would not want any: its customers are not the reviewing public. So in a B2B dataset, review count is a fairly direct measure of how consumer-facing a business is, which is very close to an inverse measure of how good a prospect it is. Sorting by it does not merely fail to help, it actively promotes the wrong rows to the top of the list — the exact rows a person working down the list will contact first.

What we sort by instead is target geography, then contact completeness: a row with an email outranks a row with a phone number and a website, which outranks a row with only a phone number. That ordering encodes the only two things the dataset actually knows about whether a lead can be worked — whether you can reach them, and whether they are in the market being sold into. It makes no claim about business quality, because nothing in a Maps row supports one.

The same restraint applies to the rating column. A 4.8 average across six reviews and a 4.8 across six hundred are not the same measurement, and neither tells you whether a shop solders connectors by hand all day. The rating is carried through into the output because it costs nothing and is occasionally a useful sanity check on a business that might not exist any more. It is not a ranking input.

Deduplication happens on place_id before any of this, and that ordering matters too: dedup before filtering, not after. Two query sets that overlap will return the same business under different search terms, and if the filter runs first you will make the same keep-or-drop decision twice and occasionally reach different answers, because the two rows can carry different category strings for one business. Dedup first, decide once.

Finally, the honest limits. This dataset says nothing about company size, headcount, revenue or whether a business is still trading — Maps rows outlive the businesses they describe. It cannot tell a ten-person shop from a two-hundred-person plant, which for a machine priced at $1,899 is the single most useful thing to know and the thing you will have to find out on the call. A scraped list of this kind is a starting set of doors to knock on. Treating it as a qualified pipeline is how people end up with a thousand contacts and no conversations.