A second location is usually opened on the strength of the first. What rarely survives the move is the thing that made the first one work: the owner was standing in it. Every question the front desk couldn't answer got walked twenty feet and answered correctly, and nobody thought of that as a system, because it never failed while the owner was in the building.
Consistency is what a second location breaks first
With one office, "how we do it" lives in one person and a few binders. A dental practice that adds a second office in Wolfforth discovers the problem within a month: the Lubbock front desk quotes the crown at the updated price because the office manager sat in the meeting where it changed, while Wolfforth quotes last year's number because the email announcing it went to a distribution list that predates the second office. Neither desk is careless. They are reading different copies of the practice.
The same split shows up in an HVAC company that opens a branch down the corridor to chase commercial work. The branch inherits the shop's paperwork on a thumb drive, and from that day forward the two price books age separately. Six months later the branch is still quoting a diagnostic fee the main shop retired in the spring, and the first anyone hears of it is a commercial customer with buildings in both towns asking why the same company charges two prices for the same visit.
One set of documents, with a location column
The structure that prevents this is not complicated, but it has to be deliberate. There is one knowledge base — price book, warranty terms, financing sheet, employee handbook, service-area map, the scripts the desk answers from — and every entry in it carries a tag saying which locations it applies to. The default tag is all of them. When a question arrives, whether from a staff member or from the phone system, it arrives stamped with a location, and the retrieval step only considers documents that apply there.
That one tag is the difference between a shared brain and a shared rumor. The crown price changes once, in one document, and both desks are reading the new number the same afternoon.
Overrides, not copies
The tempting shortcut is to copy the documents and let each office edit its own set. That is how you end up with two handbooks that agree on nothing by Christmas. The better structure is an override: the shared document is the base, and each location keeps a deliberately short document stating only what is different there. The Wolfforth office is closed Saturdays. The branch adds a trip fee past a certain mileage. The second office's X-ray machine is a different model with a different consent form. When a question touches something an override covers, the override wins for that location; everything the override is silent on falls through to the shared version. When a company-wide policy changes, it changes once.
The discipline this enforces is worth as much as the technology. An override file that grows past a page is a sign the location is drifting into being a different business, and that is a conversation for the owner, not for the software.
A caller to the Wolfforth office should hear the Wolfforth hours
Each published number is its own front door. Because the system knows which number was dialed, it knows which location's hours, address, staff, and calendar apply before anyone picks up. A caller who rings the second office at 5:40 gets that office's closing time in the after-hours message, a text offering that office's next open slot, and directions to that building rather than the main one. Holiday closures are set per location, because the office that shares a parking lot with the clinic closes when the clinic does.
Stated that way it sounds too obvious to mention. It is also routinely wrong in practice, because the greeting was recorded once, years ago, at the first location, and every line the company has added since plays the same recording with the same hours.
Five numbers, three columns
Locations can only be compared on numbers that are collected identically, so the weekly report holds every location to the same five: calls received, calls answered live, median minutes to first response on the calls that were not, appointments booked, and booked work completed. One row per number, one column per location, side by side.
The definitions matter more than the dashboard. If the first office counts an appointment as booked when it goes on the calendar and the second counts it when the patient confirms, the comparison is fiction with a chart on it. Part of the setup is writing down, once, what each of the five numbers means, and then refusing to let either location count differently. Done that way, the report starts asking useful questions on its own: why one office answers nine calls in ten live and the other six in ten with the same staffing, or why the branch books fewer estimates from the same call volume. The report does not answer those questions. It makes them impossible not to see.
What this does not solve
A shared knowledge base makes the second location consistent. It does not make it good. If the branch is understaffed, its answers will now be correct and its hold times will still be long, and the report will show you that in column two. It also cannot referee genuinely different markets: if commercial work in one town needs different terms than residential work in another, the overrides will faithfully record the difference, but deciding whether the difference should exist is an owner's judgment. And the whole arrangement inherits the health of its sources — if nobody owns the price book, both locations will now be wrong in perfect unison.
Where to start
Take one document both locations answer questions from — the price book is the usual candidate — and ask each front desk the same ten questions in the same week. The questions they answer differently are the first month's scope, and finding them costs nothing but two phone calls.