← Portfolio

Demo 04 · For dealer locators & fleet operations

Locator that's a tool, not a phonebook.

A working locator for 500+ USPS facilities across all 50 states. Search by name, filter by facility type, narrow by ZIP prefix, or click a state chip to zoom in. Clicking a pin highlights the list. Clicking the list flies the map. One state object. Bidirectional binding.

If you operate

A dealer network · multi-location retail · fleet · service-area or dispatch dashboard

Your current locator is "type your zip, see a list." Customers want to filter by service type, EV-certification, hours, capacity, language, certification, and right now those questions get routed to your call center because the locator can't answer them.

The problem we solve

A map should be a tool, not a phonebook with pins. When the filters, the pins, the selection, and the detail panel all bind to a single state object, the locator becomes the answer to "which one is right for me?" For the customer and for the rep who needs to deep-link a colleague to "Texas service centers with EV certification."

What we'd build for you

  1. Inventory the dimensions your users actually filter on: service tier, hours, certifications, capacity, EV/heavy-duty, language, current availability. Pull from the dispatch system you already have.
  2. Wire each filter to one shared state object. The map reads the same source as the list; both update in lockstep.
  3. Persist filter state in the URL so reps can deep-link to a filtered view ("/locator?state=tx&service=ev&open=now"). Marketing can do the same for campaigns.
  4. Roll out customer-facing first; if the same data feeds your ops dashboard, the second deploy is mostly a different stylesheet.

Stakes

Without it: "find me a location that does X" calls flow to your call center. Reps build their own private spreadsheets. Customers route around the locator to Google.

With it: the locator answers the hard questions. The call center handles only the irreducible ones. Reps share filtered links instead of phone numbers.

Map a locator overhaul →

How it's built

  • Dataset: 500+ curated USPS facilities (state capitals plus the largest cities per state), served as a static JSON file from /data/usps.json. Same shape as a real client's facility table.
  • State container: a plain JS object with five fields: query, zipPrefix, activeTypes, activeStates, selectedId. A single render() reads it and updates the map, list, count, chips, and overlay together.
  • State-zoom: toggling a state chip calls map.fitBounds() on the bounding box of all facilities in the active states. Fewer states selected, tighter zoom.
  • Map sync: the filtered set's GeoJSON is hot-swapped on the source via map.getSource('usps').setData(...). MapLibre diffs internally.
  • Selection sync: a single selected-id drives both the list highlight (CSS class) and the map (data-driven circle-radius + circle-color expression).
  • Map → panel: clicking a pin sets state.selectedId and calls render(). Clicking a list item sets the same field plus map.flyTo(). The state object is the bidirectional join.