There is a quiet tax buried in most municipal alert systems, and it is paid by whoever in city hall is least able to refuse the job. Someone has to keep the geography current.
It starts reasonably. The city defines a handful of areas it thinks in — the north service area, the downtown district, the two commission wards — and gives each one a short code. Then someone assigns addresses to them. Then a subdivision goes up, and someone assigns those addresses. Then forty people move, and nobody assigns anything, because nobody was told. Eighteen months later the clerk sending a boil-water notice is looking at a list that was accurate in the spring of the year it was built, and has to decide whether to trust it or send city-wide and apologize.
That is not a software failure exactly. It is a modeling choice: the system treats geography as a list to be maintained rather than as a shape on a map. Every consequence follows from that.
The shape is the thing the city already has
Here is what makes the hand-maintained list strange: the city is not missing the geography. It has the geography. It is in the GIS export, the parcel register, the zoning map, the comprehensive plan. Cities are, institutionally, extremely good at knowing where things are. What they lack is a way to hand that knowledge to the alert system without retyping it as a list of addresses.
So Bloomz for Cities now takes the shape directly. An admin opens the city group, goes to the neighborhood map, and either draws each neighborhood boundary on the map or imports the GeoJSON or KML the city’s GIS already produces. That is the whole setup step, and it happens once.
From there the placement runs the other direction. Instead of a person assigning residents to areas, the map places residents inside areas — automatically, from data the city already collects:
- the home address a resident gave when they signed up
- the household import, if the city loaded its parcel or utility register
- a find-my-neighborhood check a resident runs on their own phone
- a resident tapping their neighborhood on a map
Add a subdivision and its residents land in it as they sign up. Redraw a boundary after an annexation and everyone geocoded inside the new line moves with it. Nobody files a ticket asking for the list to be updated, because there is no list.
Automatic, but not stubborn
The failure mode of automatic placement is obvious to anyone who has fought with an address-matching system: the software is confidently wrong about one household and there is no way to overrule it.
So the rule is explicit. An admin can move anyone, and once an admin has placed someone, the map will not move them again. Automation handles the thousands of ordinary cases; the clerk who knows that the house on the corner is served by the other district handles that house, once, permanently.
The same principle covers the residents the map cannot place at all. They do not vanish into a silent gap — they collect in a Needs Placement list with the reason attached: no address on file, an address the geocoder could not resolve, or an address that falls outside every boundary you have drawn. That third reason is quietly the most useful one in the set, because a cluster of “outside every boundary” results usually means a boundary is wrong, not that the residents are.
What happens at send time
None of this matters unless it makes the actual send simpler, and the design decision here was to add nothing new to learn.
A city alert targets a neighborhood by choosing that neighborhood as a recipient, in the same picker used to choose any other group. There is no separate zone step, no second targeting concept sitting beside the group picker doing almost the same job. Choose the neighborhoods the notice affects, choose the channels, send. The post then carries an Affected-area chip, so a resident who receives it can see what it covers rather than guessing whether it applies to them.
One rule is worth stating plainly because it cuts against the grain of precise targeting. A resident using the app without an account has not necessarily told you where they live. For a neighborhood-targeted alert, those residents are included anyway. Precision is a convenience; an unreceived flood warning is not a convenience problem. When the two conflict, delivery wins.
The location that never leaves the phone
A find-my-neighborhood check sounds like the part where a city starts collecting location traces, so it is worth being specific about what it does.
The app downloads the city’s neighborhood boundaries, which are public shapes, and does the point-in-polygon check on the device. What it sends back is the neighborhood the resident landed in — an id, nothing else. Coordinates are not transmitted, and the server rejects the request outright if they appear in it. The city learns that someone is in the North Mill Creek neighborhood, which is exactly what it needs to send them the right notice, and learns nothing about where they were standing when they checked.
That is not a policy commitment that depends on someone remembering it. It is what the endpoint accepts.
The practical version
If you run a small city and you are evaluating this, the useful question is not which product has geographic targeting — nearly all of them claim it. The question is who maintains the geography after launch, and what happens to the residents the system cannot match.
If the answer is “a staff member keeps a list current” and “they are dropped from the send,” you have bought a job, not a capability.
Smart Alerts for cities sends across app, email, SMS, and voice from one compose screen, with per-channel delivery proof on every send. For more on why the address, not the resident, is the right unit for city software, see Why a City Platform Should Work From the Household.