Configure

Locations

Run one brand across many branches — a gym franchise, a clinic group, a restaurant chain. Each location gets its own knowledge, phone number, hours, and greeting, while your AI personas stay shared: update the persona once and every branch answers the new way.

How it fits together

• The persona is the brand's voice. One AI character answers for every location — its prompt, tone, and tools live in one place.
• The location is the local layer. Address, timezone, opening hours, a local phone greeting, a front-desk transfer number, free-text notes for the AI (“free parking behind the building”) — plus its own knowledge and phone numbers.
• Knowledge has two layers. Untagged knowledge is brand-shared and visible to every location. Knowledge assigned to a location answers only for that location — one branch's prices never leak into another branch's chat.
• Every conversation is tagged. Calls, texts, and web chats record which location they belong to, so the Inbox page filters per branch.

Add locations

Three ways, all interchangeable — they share one write path, so you can mix them:

1. Dashboard — open Organization → Locations and click Add location. Fill in the name, your own reference id (external ref), and address. Country and timezone are dropdowns — pick your country by name and your timezone by city (grouped by region), so there is no need to memorize a 2-letter code or the exact IANA string.
2. CSV import — click Import CSV and paste or upload a spreadsheet export. The dialog shows a worked example with a Download example CSV button you can fill in. The header row needs at least external_ref and name; optional columns cover the address, timezone, phone_greeting, handoff_phone_number, and context_notes. In a file, country is the 2-letter code (e.g. US) and timezone an IANA name (e.g. America/Chicago). Rows are matched on external_ref, so re-importing the same file safely updates instead of duplicating.
3. API — your own software syncs locations with /api/v1/locations: create-or-update one ("upsert": true) or bulk-sync up to 500 per call with per-row results. See the API reference.

Your main location

One location is your main location — it represents the brand itself. Its street address is what appears in the footer of your outbound email campaigns, because commercial email has to carry a real physical postal address (CAN-SPAM). So this is more than a routing preference: an email campaign won't launch until the address is filled in.

With a single location, it's automatically the main one — just make sure its street address and city are set. Once you have more than one, a Main location picker appears at the top of the Locations tab so you can choose which address represents the brand. Owners and admins can change it.

Give a location its phone number

Map a number the usual way (see Phone numbers) and assign it to the location. An incoming call or text routes by the dialed number: the location is resolved first, then the answering persona. The location's phone greeting (when set) wins over the persona's, and when a caller asks for a human, the call transfers to the location's front-desk number — the Downtown caller rings the Downtown desk.

Pin a website to a location

If each branch has its own site (or its own page), add one line to that site's embed snippet so its web chats belong to the right location:

window.ChatWidgetConfig = {
  apiKey: "cw_live_…",
  apiUrl: "https://chat.quincer.com/api",
  location: "your-location-ref"   // the location's external ref
};

The AI then answers with that location's hours, address, and local knowledge. A typo in the ref never breaks chat — the widget just answers brand-level until it's fixed.

One brand site with location pages? Skip the per-page snippets: give each location URL patterns (in its edit dialog), like /locations/downtown/* or a whole subdomain such as downtown.example.com. Web chats on matching pages belong to that location automatically — the most specific pattern wins, an explicit embed ref still overrides, and unmatched pages answer brand-level as usual. If two locations claim the same pattern, saving warns you.

Give a location its own knowledge

Open a location from the Locations list to manage its own knowledge — upload files, paste items, or import pages that only apply to that branch (class schedules, staff, local offers). Conversations at that location use its knowledge plus everything brand-shared; conversations anywhere else never see it.

The same goes for stock: Import inventory on a location's knowledge toolbar imports that branch's own catalog (a dealership lot, a store's stock list) — shoppers at that location see and ask about its items plus any brand-shared inventory, never another branch's, and each branch's re-import only updates its own stock. See Import inventory (CSV catalog) for the CSV format and column mapping.

If the branch has its own website, set it on the location and click Import website — its pages become that location's knowledge automatically. Pages your brand-wide knowledge already covers are skipped and reported as covered by brand knowledge, so a franchise of templated microsites doesn't import hundreds of copies of the same brand boilerplate. Update a policy once, brand-wide, and every location answers with the new version.

Route leads and bookings to the branch

• Lead notifications — give a location its own notification emails and leads captured in its conversations go to the franchisee's inbox instead of the brand-wide list (which remains the fallback).
• Bookings — set a location's own Calendly link and “book a tour” at that branch lands on its calendar (falling back to the persona's link, then the brand's).
• Contact email — set the location's public email and the AI can share it (“email us at…”) alongside hours and address.

When the AI offers meeting times

Times offered when booking used to be fixed at 9am–5pm, Monday to Friday, with no way to change them. They now follow your own data, in this order — the first one that answers wins:

1. The person — their own timezone and working hours, when they are in your people directory and those are set (set them per person via timezone and working_hours).
2. That person’s location — the branch they belong to.
3. The conversation’s location, or your default location if the conversation isn’t tied to one.
4. 9am–5pm, Monday to Friday, in the resolved timezone — the same floor as before, now only a fallback.

A location whose booking hours include Saturday is bookable on Saturday.

Hours are always read in their own clock. Whoever supplies the hours supplies the timezone with them: a location’s 9am–5pm means 9am–5pm at that location, and a person’s means 9am–5pm where they are. So a rep in Berlin who has a timezone but no working hours of their own is offered their location’s hours in the location’s clock — give them their own working hours if they keep Berlin office hours.

Because of that, booking hours and a timezone go together: setting hours on a location or a person that has no timezone is rejected, rather than saved as a window nothing can enforce.

Setting booking hours today means the API. There is no field for them on the Locations screen yet, no CSV column for them, and none for a person’s working_hours on the Directory screen — see API & webhooks for booking_hours on a location and People directory for the per-person fields. The one exception is a person’s timezone, which is a CSV column. Values written by API are returned on the next GET, so a nightly sync can check its own work. On-screen editing is coming.

When a location’s hours won’t turn a request down. A location’s booking hours describe the people who work there. If someone’s own timezone says they are somewhere else, those hours are still used to pick good times — but they will not refuse a request, because they aren’t a statement about that person’s day. Give that person their own working_hours and those do refuse, in their own clock.

If you configure nothing, nothing changes. With no booking hours anywhere, the agent behaves exactly as it did before this feature existed: it suggests times inside 9am–5pm on weekdays, but it will still accept a specific time a visitor asks for outside that — a Saturday, or 6pm — because a default nobody set is not a rule. Only hours you actually configure will turn a request down.

Visitors in other timezones. The AI also tries to keep suggested times civil for the visitor. When your hours and theirs don’t overlap at all — Los Angeles and Sydney, for instance — it now offers your real openings and says plainly that they fall outside normal hours where the visitor is, instead of telling them nothing is available. Previously that case returned no times at all, which read as a full calendar.

What the AI knows per location

• Its name and address, and the local time at the location (from the timezone).
• Its opening hours, when set (via API: a JSON map like {"mon":[["06:00","22:00"]]}).
• Its booking hours — when staff here take meetings, which is not the same as when the doors are open. A gym open 6am–10pm doesn’t mean its sales manager takes calls at 9pm, so these are deliberately separate. Set bookingHours (same JSON shape as hours) to control the times the AI offers. Leaving it unset does not fall back to your opening hours — opening hours describe the building, not the calendar, and treating them as a booking rule would start refusing appointments that used to succeed. If you want your opening hours to govern booking, copy them into bookingHours explicitly.
• Its contact email, when set.
• Your free-text context notes.
• Location-assigned knowledge plus everything brand-shared — and an explicit instruction to never quote another location's details.

Suspend a location

Suspending a location (the Suspend button, or status: "suspended" via API) stops it everywhere, immediately: calls to its numbers are rejected, inbound texts get no reply, and its web chats are refused. Nothing falls back to a brand-level answer — a paused franchisee's customers are never answered as if the branch were open. Activate it again and everything resumes; all history is kept.

Let a franchisee manage only their locations

Invite the branch manager to your team as usual (see Team & roles), then open Organization → People and click the location chip on their row to pick which locations they manage. The control only appears once your brand has more than one location.

• Nothing checked = full access — every existing team member keeps exactly the access they have today.
• Checked locations narrow, never expand. A scoped member can only edit their locations (hours, notes, greeting, suspend) and add knowledge tagged to those locations — uploading a class schedule for their own branch works, touching another branch is refused with “You manage other locations”.
• Brand-wide things are untouched. Scoping doesn't change what a member can read, and an admin's brand-level knowledge edits work as before — it's a filter on location-specific writes, not a new role.

Typical franchise setup: invite each franchisee as an admin, scope them to their branch, and they can self-serve local promos and schedule changes without being able to touch anyone else's.

Per-location reporting

The Inbox page gains a location filter once you have locations, and each thread shows a location chip. Calls record their location too, so per-branch attribution is available from day one.

• Locations leaderboard — with more than one active location, the Analytics page shows a Locations card: conversations, engaged conversations, and leads per branch over the selected period, busiest first.
• Per-location Insights — the Conversation Insights map gains a location dropdown, so you can see what visitors ask one branch for and what its agent has to decline.
• Monthly report — the emailed performance report includes a “Busiest locations this month” table (top 10 by conversations) for multi-location brands.

Tips

• Keep shared things shared. Training methods, brand policies, membership tiers → untagged (brand) knowledge. Only local facts — staff, hours quirks, parking, branch promos — belong on the location.
• Use your ids as external refs. Every surface (CSV, API, phone mapping, the embed) addresses locations by external_ref, so syncing from your own system stays idempotent.
• One persona is usually right. Reserve the per-location persona override for a branch that genuinely needs a different character, not a different greeting — greetings have their own override.