1. Home
  2. Store locator for stores, branches and collection points
📅 Free webinar · 14 October, 11-11.30am BSTWill AI recommend your stores? Three moments that decide a saleSave your seat

Build a store locator that takes shoppers to the right branch

A store locator shows shoppers the stores, branches or collection points nearest to them, and takes them to the right one.

Miss the three checks and you lose the order

Shoppers check three things before they set off: is it near me, is it open, and can I collect there. A page that cannot answer those three questions loses the trip, and the order with it. A store locator answers them on the spot: it puts the nearest physical locations in front of the shopper and takes them to the right one.

Talk to our team
An enterprise-grade and ready-to-use Store Locator to convert customers from search to stores

The four moments of a shopper's search

Four moments, and none of them should ask the shopper to work.

  1. The map can open where they are.

    The Woosmap Geolocation API uses IP-based location to open the map around the shopper at the right zoom level, with the closest points already in view. From there, they search with what they know.

  2. Search accepts what they know.

    Autocomplete covers cities, towns, places, postcodes and addresses worldwide, and it also matches the names of your own stores.

  3. Opening hours decide the trip.

    Hours are displayed live, the list can be filtered on the points that are open, and results are sorted by distance.

  4. Directions start on your site.

    With the Distance API, the shopper works out the route to the point they chose without leaving your site, on foot, by car or by bike.

Click and collect changes what "nearest" means. A collection point is not always a full store, and the one that matters is the one holding the order: the same locator lists collection points alongside stores and branches, with the opening hours that decide whether the shopper goes today or tomorrow.

Search that matches your estate, not a generic map

Two branches are rarely interchangeable: one serves a catchment area, another holds the stock, a third opens on a Sunday. The search has to know that before the shopper does.

Catchment areas.

A catchment area can be attached to each point of sale, so traffic goes to the store that should serve it.

Along a route.

Points of interest can be searched and displayed by proximity to a route, for the customer who collects on the way home.

Your own attributes.

Filters are built on your own store data, the services available in store for example, with the categories you choose, the display format you choose, and an "open now" option.

Dense estates stay readable: all points of sale are broadcast at every zoom level, on web and on mobile, without making the shopper click to break a cluster open, and clustering stays available where it helps.

The full capability inventory of the API behind this page lives on the Stores API product page.

Three ways to build a store locator, one decision to make

The question is not whether it is possible, it is how much of the rendering you want to own.

Store Locator Widget.

A ready-made locator that takes very little coding to configure. The fastest route to a working page.

Map JS API.

You build the locator brick by brick and control the rendering, at the cost of writing the front end yourself.

Stores API, called directly.

Everything is driven server side, which suits an existing front end or a native app.

The developer documentation covers request formats, authentication and configuration for each integration path.

Whichever path you take, the base map, the colours and the point of interest icons are customisable to your brand identity, and the widget is natively responsive on mobile web. The locator can also run without a map at all, as a list of stores with their address, contact details, status, logo and photos, which is useful in a checkout step or an embedded view where a map has no room.

The full decision matrix, including the point where each path stops paying off, is laid out in the store locator API guide on the Woosmap blog.

Read the developer guide

Keeping the store data current

A locator is only as good as the data behind it, and that data changes every week: a new opening, a temporary closure, a phone number nobody updated.

Bulk updates by API.

A REST API updates points of sale in bulk, which is what an overnight sync from your own systems needs.

Editing in the Console.

A store can be edited directly in the Woosmap Console by the users who have access to it.

Presence management connectors.

The data can also be synchronised from a presence management connector: Localistico, Partoo and Yext.

Some Woosmap customers hold up to 80,000 establishments in that repository, without maintaining one database per country.

The same repository serves every market you trade in. Display units and time format are settings rather than forks, and the Store Locator Widget ships its interface in fifteen languages. Build on the Map JS API instead and the interface is yours to localise. The units setting earns its keep here more than anywhere: a distance in miles reads naturally to a shopper driving to an out of town store, and one in kilometres reads naturally to the same brand's customers in Dublin or Lille, without forking the front end or the data.

Start free, and see what it costs before you commit

Start on the free tier.

Woosmap publishes three plans, Free, Pro and Enterprise. The Free tier lets you evaluate without commitment, while Pro and Enterprise are paid plans. See the pricing page for current details.

Watch what you consume.

API usage is visible project by project in the Woosmap Console, overall and per API.

Try it, then build on it.

Woosmap publishes a hosted demo of a store locator and the complete starter project behind it, built with the Map JS API.

Try the official demoSee pricing

Try a working store locator before you build one

The official Woosmap sample below loads on its own as you reach it. Search a town, choose a result, then open a store to read its address, its opening hours and its distance. It runs on a sample dataset of coffee shops, not on your own estate.

Questions we are asked

The widget exposes usage events to your application: a store selected, a click on a phone number, a distance computed, a click through to the site. These usage events are anonymised. The widget documentation explains how to listen to them.

Yes. The terms depend on your setup, and they are agreed with Woosmap directly: contact us and we will tell you what applies to your case.

Woosmap publishes a Store Locator cartridge for Salesforce Commerce Cloud, compatible with the Storefront Reference Architecture and configurable from the Business Manager.

The locator is there to help a shopper find the right store. If you also need a page of its own for each store or each area, Store Pages publishes those pages from the same store data.

Your next step

If you are scoping the project, tell us how many stores and collection points you run, in which countries, and on which front end. With those three, we can point you at the integration path that fits your team and your platform. If you are the one who will integrate it, start with the developer guide and the starter project: they are the fastest way to a locator running on your own data.

Talk to our teamRead the developer guide