One Assistant, Many Locations: Answers per Branch

When a business opens its second location, one thing changes for the assistant on the website – and it changes everything downstream: almost every answer now carries a condition. Opening hours, availability, contact people, directions and free appointment slots stop applying to “the company” and start applying to a branch. The German business register shows how common this is: for the 2024 reference year it records 3,844,055 (Destatis) local units against 3,543,865 (Destatis) legal units. This article describes how an assistant settles the location before it answers, which fields are maintained per branch, which values have to come from your own systems at the moment of the question, and how a handover reaches the right team.

Enlarge graphic

Labels in the illustration

• “Are you open tomorrow?”
• “I am in Augsburg.”
• Which location do you mean?
• Augsburg, Ingolstadt or Fürth?
• “Augsburg.”
• Augsburg: Mon–Sat 9 am–7 pm.
• Closed on 8 August.
• 1
• Location settled
• Page context, picker or one question
• Before answering
• 2
• Field per branch
• Hours, holidays, team, directions
• Knowledge base
• 3
• Value from system
• Stock, slots, waiting time
• Tool control
• Without a location
• One answer that fits at most one of the branches.
• The question costs a sentence, the wrong answer a journey.
• 3,844,055
• Local units 2024
• 3,543,865
• Legal units

One question, three branches

Why the second location gives every answer a condition

The business register separates two levels that tend to blur in everyday use. The legal unit is the entity – the limited company, the sole trader, the association. The local unit is the geographically separate part of it: the branch, the workshop, the practice in the next town. For the 2024 reference year the register counts 3,844,055 (Destatis) local units and 3,543,865 (Destatis) legal units across economic sections B to N and P to S. The gap of roughly 300,000 is the surplus of local units over legal units: a company with five branches contributes four of them and still counts as one legal unit. How many companies run more than one location is not shown by these two tables – that it is no fringe case is shown by the surplus all the same. For every one of those companies, a single set of opening hours on the website is not enough.

The gap is widest in retail. There, 659,860 (Destatis) local units stand against 557,277 (Destatis) legal units: a good hundred thousand more points of sale than there are entities behind them. For an assistant this is not an abstraction. It means the question “do you have that in stock?” cannot be answered without a location – and that an answer given anyway will, with some likelihood, be about the wrong shop. The same holds for practices with two sites, for workshops with a branch in the next town, and for studios that share a brand but offer different classes.

Settling the location comes before the answer

Settling the location is not an extra step at the end but the first move in the conversation – as soon as the question depends on the place. In practice there are three routes, and they do not exclude one another. The page context carries furthest: whoever is on the Augsburg branch page has already chosen the location; the assistant picks it up from the page address and names it in its first sentence so the assumption stays visible. The second route is a picker: a short list of locations that can be chosen with one tap. The third is a clarifying question in one sentence, when the first two yield nothing.

• Page context: the branch, region or landing page supplies the location identifier; the assistant confirms it visibly instead of setting it silently.
• Picker in the chat: a list with town and district, sorted by proximity to the page context, not alphabetically across a hundred entries.
• One clarifying sentence: “Which location do you mean? We have three in the region.” – asked before any time or stock figure is named.
• Switching mid-conversation: if someone names a different town later, the location is reset and the earlier answer is not quietly carried forward.
• No location needed: questions about the right of return, shipping options or payment methods are as a rule the same across branches and need no clarification.

The craft lies in restraint. A clarifying question that arrives with every second message feels like a form. The rule can be stated bluntly: ask only where the answer would differ by location. Whether a question falls into that class is not decided by the language model in the moment of the conversation but by the knowledge base – every field carries the flag for whether it is location-bound. How such a knowledge base has to be built so answers stay traceable rather than freely composed is described in the article on hallucinations and the knowledge base.

Which fields are maintained per branch

A location record is quickly listed and still rarely maintained in full. Six groups cover the bulk of the questions that actually arrive in multi-site businesses – and they are remarkably similar for a retailer, a practice and a workshop.

The effort for these six groups is modest once and small on repeat – provided the fields are structured rather than written as a paragraph. A paragraph cannot be evaluated: the assistant can quote from it, but it cannot check whether 24 December appears in it. Which content belongs in a knowledge base, and in what form, is a topic of its own; for multi-site businesses only one column is added, namely the location identifier on every single field.

Holidays and hours: one business, many calendars

Opening hours are not purely an organisational matter, they are regulated – and the rules do not stop at the state border but in part at the municipal boundary. The federal frame is set by the German Shop Closing Act:

The federal states have made their own rules to differing degrees. Bavaria passed its own shop closing act in 2025, and it shows how fine-grained responsibility becomes: the municipality decides on the exceptions. Under Article 6(1), municipalities may release “at most four Sundays and public holidays per year for the opening of sales outlets” by statutory order (Bavarian Shop Closing Act, translation; the German wording is the binding one). Under Article 7(1) they may additionally release “at most eight working days per year for the opening of sales outlets from 8 p.m. until midnight at the latest” (Bavarian Shop Closing Act, translation). The opening under Article 6 is limited to five consecutive hours between 10 a.m. and 6 p.m. For a chain with branches in several municipalities the result is plain: two neighbouring towns, two different calendars.

Values that only exist at the moment of asking

Part of the answers cannot be maintained at all, because they change by the hour. Stock, free appointment slots, waiting time at the counter, capacity in the workshop: these values arise at the moment of the question and belong at an interface, not in a knowledge base. The assistant fetches them with the location identifier and returns the result together with the location name. How an assistant controls tools and systems is in principle independent of the number of branches; running several locations simply adds one mandatory parameter – and that is exactly what tends to be forgotten when a single-site setup is extended.

• Stock per branch instead of a total across all warehouses – “in stock” without a place is worthless for the journey there.
• Free appointment slots per location and per resource, not per company.
• Collection and reservation status tied to the branch where the goods actually sit.
• Waiting time or utilisation only where it is measured – otherwise better left out than estimated.
• Prices and promotions where they differ regionally; otherwise marked explicitly as identical across branches.
• A defined behaviour when the interface does not respond: say that the value cannot be retrieved right now instead of inventing a figure.

The last point is where trust is either built or lost. An assistant that answers “yes, it is there” while the inventory system is down costs more, after a wasted journey, than no assistant at all. The clean form is unspectacular: name the outage, offer the fallback route, take the enquiry. How stock, appointments and prices are bound to your own systems through tool control in the Custom package, without the assistant sliding between two locations, depends above all on a clean key per branch.

The handover reaches the branch team

When the assistant cannot go further, the location also decides where the conversation goes. Handing over to a central address is the most common silent failure in multi-site setups: the enquiry arrives, but at the wrong team, and is passed on from there – a day later and without the conversation history. What works instead is a mailbox or queue per location, plus a fallback route for the case where the place stayed unknown. When a handover to a human is due at all is independent of the number of branches; the destination of that handover, however, depends on it directly.

The last row is the reason why settling the location pays off even when the assistant cannot answer the question at all. It does not answer – but it puts the question to the right person, with the wording of the enquiry and the name of the location in the subject line. That is already a good part of the benefit, and it comes without any additional interface.

When the location stays unclear

There remains the case where the place is unclear: someone arrives from a search engine on a general page, names no town and still wants an opening time. Two answers are defensible here, a third is not. The clarifying question is defensible. So is an answer that states the frame and discloses the binding: “Most of our sites open at 9 a.m. on weekdays; for your town I can tell you exactly, as soon as I know which one it is.” What is not defensible is head office hours handed out as branch hours.

Upkeep: who enters a changed opening time

Location data ages faster than the rest of the knowledge base, because it hangs on local decisions: a shortened Saturday, a stocktake, a move to the side street. That is why every branch needs a named person who maintains its fields, and a date on which that upkeep is due. The upkeep process for the knowledge base applies unchanged here, but gains a second axis: not only “who maintains which topic”, but “who maintains which topic in which place”.

• Every branch has a named person for its fields – deputy included, otherwise upkeep stops during holidays.
• Deviating days are recorded with a date as soon as they are decided, and expire on their own after that date.
• The holiday calendar of the town is checked once a year, preferably in autumn for the year ahead.
• Sunday trading dates come from the municipal order and are stored with their source, rather than entered from memory.
• New branches are created before opening, with the opening date as the start of validity.
• Closed branches stay in the record with an end date and a pointer to the nearest location, instead of being deleted.

The effort is justified by demand. In a representative survey commissioned by the digital association Bitkom, 61 per cent (Bitkom 2023) of the online shoppers surveyed said they would like more retailers in their region to have an online offering. For a share of those people the assistant on the website is the first contact with the shop around the corner – and the first question is rarely strategic; it is whether the doors are still open today.

Acceptance: test cases that check the location

A multi-site assistant fails acceptance in different places than a single-site one. The test cases before go-live therefore get a block of their own that checks nothing but the location binding. It is short and, in our experience, still finds something.

• Ask the same question from three branch pages – do three different, each fitting answers come back?
• Switch the location mid-conversation – does the next answer move with it, or does it stay with the old place?
• Ask without page context – does the clarifying question come, or is head office quietly served instead?
• Query a dated exception day that affects one single branch.
• Switch off the inventory interface and check whether the assistant names the outage.
• Trigger a handover and check which mailbox it arrives in.
• Rename a location and check whether the earlier label is still recognised.

The first three cases uncover the bulk of the errors, in our experience. The fourth is the one that becomes most expensive later, because it concentrates on a single day in the year and then affects every enquiry that day. Shops face one more layer: the product data has to carry the location question as well, or a clean branch record alone helps little – the article on product data for the shop assistant describes which attributes and variants are needed for that.

What becomes measurable after rollout

After go-live the benefit can be read off three figures that need no extra tooling: the share of conversations in which a location was recognised or chosen, the share of handovers that arrived in the right mailbox, and the list of questions for which the assistant found nothing for a given place. The third figure is the most useful, because it names the next upkeep step instead of leaving it to guesswork. For providers with fixed dates the same mechanism applies with different vocabulary – the article on the assistant for course providers shows this for course venues and start dates.

That leaves the question of scale. A location model maintained on its own usually carries up to a double-digit number of branches; beyond that it pays to connect it to the system that holds the master data anyway, so opening hours and services are not maintained in two places. Such connections are part of integration. And where a multi-site business has particularities – sales territories, franchise boundaries, differing ranges – that belongs in custom functions rather than in a compromise inside the standard model.

Frequent questions