For franchises and multi-location operators

One brand, one customer, many stores

Running more than one location turns every small software decision into a structural one. The second store gets its own booking tool, its own reviews to chase, its own loyalty cards, and its own customer list. Two years later there is no such thing as a customer of the brand, only customers of buildings.

The choice usually on offer makes it worse. Either a corporate system individual stores cannot influence, which local operators quietly work around, or a pile of per-store point tools with no shared customer, no shared reporting, and no shared rewards balance.

This page is about the third option: one platform where the brand sets the defaults, each store runs its own day, and the customer is one person no matter which door they use.

Book a Free Demo
Marketing attribution dashboard mockup: a closed-loop flow from clicks to leads to bookings to repeat customers, a bookings-by-channel bar chart, and a booking-rate tile. Illustrative data.
Closed-loop reporting from clicks through to bookings and repeat customers, with a channel breakdown. Illustrative data.

Locations anywhere, one brand

One owner can hold many locations, and each one carries its own hours, its own menu, its own staff, and its own phone number. A store in a different neighbourhood, a different city, or a different country with different trading hours and a slightly different offer is a normal case here, not a workaround.

Nothing about the platform is geographic. It is delivered over WhatsApp, SMS, voice, and the web, and the receptionist holds the conversation in the language each customer opens with, so a group whose stores serve different customer bases does not need a different system per site. See the multilingual receptionist.

Configuration works the way an operator actually needs it to. Brand-level defaults sit at the top, each location inherits them, and a store overrides only what is genuinely different. Opening the next site is not a rebuild. It inherits the brand and you change the address, the hours, and whatever is local to it.

  • Many locations under one owner, each with its own hours, menu, staff, and phone number
  • No geographic limit: the platform runs on the channels your customers already use
  • Per-location configuration with brand-level defaults
  • A new store inherits the brand and overrides only what differs
  • Every capability on this site is available per location, controlled centrally

One customer, whichever store they walk into

This is the thing per-store point tools cannot do, and it is the difference between a group of shops and a brand. Customers are unified across locations. A rewards balance is one balance: earn at one store, redeem at another, with no transfers, no per-store cards, and no explaining to a customer why their points do not work here.

The same is true of history. A customer who orders at one location and books at another is one person with one record, so the visit history, the preferences, and the lifetime value describe the relationship with the brand rather than with a building. See the unified customer record and the points ledger.

  • One customer record across every location
  • One rewards balance, earned at any store and redeemed at any store
  • History, preferences, and lifetime value follow the customer, not the site
  • The receptionist recognises a customer at any location

Data isolation enforced at the database layer

An operations buyer asks this question early, and it deserves a direct answer rather than a reassurance. Isolation between businesses is enforced at the database layer, not by application filtering.

The distinction is the whole point. Application filtering means every query has to remember to scope itself, and safety depends on no developer ever forgetting. Enforcement at the database layer means the data is not reachable in the first place. If you are the person who has to sign off on this, that is the sentence you were looking for.

  • Isolation enforced at the database layer, not by application filtering
  • Not dependent on every query remembering to scope itself
  • The customer list, history, and contacts remain yours and exportable
  • Ad audience exports are hashed, so raw customer information never leaves the platform

Every capability, per location, controlled centrally

The usual franchise choice is bleak. Either a corporate app that individual stores cannot influence, or a pile of per-store point tools with no shared customer and no shared reporting. One removes local control, the other removes the brand.

Here every capability on this site runs per location and is controlled centrally. The phone answering, the booking, the ordering and POS connection, the reviews, the retention automations, and the social content all exist at each store, with the brand setting the defaults.

Your own app, and reporting that survives scrutiny

The brand gets its own customer app, installed to the home screen from a link with nothing to submit to an app store, carrying the menu, conversational ordering, the rewards wallet, and a scannable customer code. A group of four stores gets what a national chain built a development team for. See the branded customer app.

On the reporting side, last-touch attribution inside a defined window traces a click through to a lead, a booking, and a repeat customer. Revenue value is frozen when the booking or order is created, so numbers cannot drift after the fact, and retention revenue is counted separately from marketing revenue so a win-back is never credited to an ad. See marketing and attribution.

  • A branded customer app across the group, with one rewards wallet
  • Last-touch attribution inside a defined window
  • Revenue frozen at creation, so reporting cannot drift
  • Retention revenue and marketing revenue counted separately

How it fits the rest of the platform

Multi-location operators lean hardest on one rewards balance across every store, one customer record across the group, a branded app for the brand rather than per site, and attribution that holds up under review. Each location still runs its own front desk, with its own phone line answered, its own calendar, and its own register connected.

Questions owners ask

Can a customer earn points at one location and spend them at another?

Yes. It is one balance and one customer across every location you run. No transfers and no per-store cards.

How is data kept separate between businesses?

Isolation is enforced at the database layer rather than by application filtering, so separation does not depend on every query remembering to scope itself.

Can each store keep its own hours, menu, and phone number?

Yes. Each location has its own hours, menu, staff, and phone number, with brand-level defaults it inherits and overrides only where it differs. Stores in different cities or different countries are a normal case, not a workaround.

Does opening a new location mean setting everything up again?

No. A new store inherits the brand defaults and you change only what is local to it.

Do we get one app for the brand or one per store?

One app for the brand, carrying ordering, the rewards wallet, and a scannable customer code. It installs from a link, so there is no app store submission.

Who owns the customer data?

You do. The customer list, history, and contacts are exportable, and audience exports built for advertising are hashed so raw customer information never leaves the platform.

See it working on a business like yours.

Book a free fifteen minute demo. We will show you where customers are slipping away today and what closing that gap looks like for your shop.

Book a Free Demo