Planning multi-location integration

Start with a location-by-location inventory

Build one inventory for every office before selecting a new structure. Make differences visible; do not assume that the largest office has the best process. Use the same categories and questions for each site so owners can compare like with like.

Begin with systems. List the tools used for scheduling, billing administration, accounting with payroll and timekeeping; communications; document storage with purchasing; facilities; and reporting. Capture users at each location, with its cost; the access administrator, information flows, vendor terms and any integration or export constraints. Note local spreadsheets or workarounds. Distinguish tools merely available from those staff rely on every day.

Map staff roles and decision rights by location. Include site leadership, front-office administration, revenue-cycle work, human resources and purchasing; facilities and cross-location responsibilities. Record the person responsible for each recurring task, the backup and workload, plus who can approve exceptions. Job titles alone do not reveal how work gets done. An office manager may know how to resolve a billing handoff or arrange a repair even if that task is absent from the formal job description.

Review each lease, service agreement, and local operating commitment with appropriate business advisers. Record premises, term, plus renewal mechanics, permitted use, maintenance obligations, access provisions, landlord contacts, and site-specific commitments. Include vendor arrangements that vary by location. Distinguish written agreements from local practice: a recurring service may have been arranged informally and never entered into the central vendor file.

Finally, identify how each location reports performance and cash movement. Write down the report name, definition, owner, preparation cadence, and recipient for measures such as revenue, operating expense, staffing, appointment utilization, accounts receivable, and service response times. Definitions often differ even when labels match. One office may count a cost when an invoice is received while another uses the payment date. Document whether numbers are location-specific, shared, allocated, or unavailable. This baseline will make later comparisons more credible and help expose missing data before it becomes a dispute.

The goal is to share work when doing so creates consistent control, useful scale, or better visibility, while retaining local authority where speed, context, or a location-specific commitment matters. Avoid treating centralization as the default answer. For every function, ask who benefits from a common process, what decisions need local knowledge, how much work is involved, and what would happen if the shared team were unavailable.

Functions that commonly merit a shared backbone include accounting standards, payroll administration, vendor negotiation, technology administration, policy ownership, management reporting, and recruitment coordination. Shared processes can make costs easier to compare, reduce duplicate administration, and clarify access or approval questions. They still need service expectations and a named contact. A shared inbox with no owner can be less responsive than a local person with a clear remit.

Some activities should remain close to the location even when they use common rules. Site leaders often need authority over daily scheduling of staff, facilities access, local purchasing within a limit, immediate coverage adjustments, and communication with a landlord or local supplier. Local managers can apply a common policy while adapting execution to the layout and staffing pattern, plus operating constraints of their office. Define which choices are genuinely local and which require approval, so staff know the boundary without relying on informal interpretation.

Create a decision-rights matrix for each function. Identify who performs and approves the task, and who advises, and who needs an update. Specify thresholds for spending, hiring, contract changes, and exceptions. Include an urgent decision path when the approver is unavailable. Keep the matrix simple enough for staff to use without executive interpretation.

Test the proposed model against routine examples. If an office needs a replacement workstation, who selects it, who checks the standard configuration, who approves the expense, and who confirms delivery? If a payroll entry needs correction, who gathers the facts, who submits the change, and who verifies it appeared properly? If those questions produce several competing answers, the function is not yet ready to be moved. Resolve the ownership and handoffs before staff are told to follow the new process.

Set transition ownership and escalation routes

Every workstream needs one accountable transition owner with the authority to coordinate people across locations. The owner may delegate tasks, but there should be no ambiguity about who maintains the plan, records decisions, and raises blocked items. Name a sponsor who can resolve conflicts between workstreams and protect time for the people doing the work. For a small group, one person may hold more than one role, but the distinction between doing the work and resolving an impasse should remain clear.

Break the transition into milestones that produce verifiable outputs. A useful sequence is discovery complete, target process approved, vendor arrangements and access confirmed, staff training completed, pilot launched, first reconciliation reviewed, and expansion decision made. Give each milestone an owner, a target completion point, dependencies, evidence of completion, and a decision maker. Avoid milestones such as "systems ready" without a definition. Better evidence might be that named users can complete a sample workflow, the finance owner can reconcile a location report, and the local manager has a working escalation contact.

Publish contacts by issue type. Staff should know whom to contact about access, payroll, invoices, building issues, reporting errors, and schedule disruptions. Each route needs a primary contact, backup, acknowledgement expectation, and escalation contact. Update the list when roles change; a route dependent on one person is fragile.

Use a decision log for choices that affect multiple sites. Each entry should state the question, approach, decision maker, affected locations, temporary exceptions, and review point. This reduces repeated debate and gives a new manager context. Keep it accessible to process users and provide a way to flag outdated instructions. A temporary decision without a review owner can quietly become permanent.

Set a regular transition meeting to review milestone status, dependencies, workload or continuity concerns, decisions needed, and next actions. It does not replace urgent escalation. Summaries should identify decisions and owners, not reproduce the conversation.

Protect continuity and staff capacity during change

Integration work consumes time from people who already have day-to-day jobs. Estimate the work by role and location before scheduling a launch. Include time for discovery interviews, data cleanup, process design, training, testing, parallel reporting, and issue resolution. Ask local managers to identify busy periods, planned absences, and tasks that cannot be deferred. Capacity planning is not just a central project concern: if the same office manager is expected to run daily operations and lead several transitions, the plan may fail even when the timeline looks reasonable.

Provide temporary coverage where needed by reducing optional work, assigning a backup, using a short-term specialist, staggering rollout, or shifting a task centrally for a limited period. State who covers the work, for how long, what checks apply, and when it returns to the normal owner. Do not count the same hours in two workstreams.

Protect service continuity with a written fallback for each changed process. Identify what staff should do if a shared system is unavailable, a file transfer is delayed, the central contact does not respond, or a new process produces conflicting records. State who can authorize use of the prior method, how the temporary activity is recorded, and how it will be reconciled after recovery. A fallback should preserve a reliable business record and prevent duplicate processing. It should not depend on staff inventing a workaround under pressure.

Communicate what is changing, what remains stable, when it takes effect, and where questions go. Tailor the message to process users. Invite staff to identify hidden dependencies and test instructions; their feedback can reveal steps missing from a formal process map. Explain how suggestions will be assessed.

Track transition issues in one list with severity, owner, location, due point, and disposition. One site's problem may signal a broader flaw; a local exception may need a local fix. Review patterns, not just totals. Repeated access failures may indicate an incomplete user roster, while reporting corrections may reveal misaligned definitions. Close an issue when the affected owner confirms the fix works.

Track cost, workload, and operational results

Set a baseline before changes. Choose measures for cost and continuity, with a separate capacity measure. Cost may include administrative expense, vendors, transition spending, and recurring staff hours. Continuity may include unresolved requests, delayed approvals, missed reporting deadlines, and process interruptions. Capacity may include overtime, open roles and backlog, plus key tasks with a trained backup. For every measure, record its source and owner. Set a review cadence.

Separate one-time costs from recurring costs. One-time expenses may include conversion, contract review, training, temporary coverage, duplicate operation, and termination fees. Recurring costs include subscriptions, central staffing, local administration, and vendor services. Include local hours spent submitting information, correcting errors, and following up; omitting them makes the comparison incomplete.

Use a consistent allocation method for shared costs and state it plainly. Equal allocation can be simple but may not reflect use; headcount, transaction volume, square footage, or another driver may fit certain expenses better. Avoid changing the method mid-comparison without showing the effect. For management purposes, present both the total group cost and the location view, so owners can see whether a shared service creates savings overall while shifting a disproportionate burden to one office.

Review operational indicators alongside financial results. Low central cost can mislead if processing slows, managers spend more time resolving exceptions, or reporting becomes less reliable. Early expense may be appropriate if it pays for coverage or improves control. Set acceptable ranges and name who can approve corrective action. Label unreliable measures provisional and fix the data process.

Illustrative worked example

Consider a group with three offices that wants to centralize invoice processing and monthly management reporting. The amounts and volumes below are illustrative only. Office North processes 120 invoices each month, Office Central processes 80, and Office South processes 50. Each office currently spends approximately 22, 18, and 15 staff hours a month on invoice entry, follow-up, and reporting preparation. The finance lead proposes a shared team and a single reporting template, while local managers retain authority to confirm receipt of goods and flag location-specific coding.

The inventory shows that North and Central use the same accounting platform, while South sends a monthly spreadsheet for manual entry. The group confirms that all three sites can use the platform, but South needs a revised approval path because its manager is part-time. The target design assigns invoice entry and reconciliation to the shared finance coordinator, receipt confirmation to a named local backup, and exception approval to the finance lead. A documented fallback allows local logging during a platform outage, with the shared coordinator reconciling the temporary entries when service returns.

For planning, the group assumes the new shared coordinator will need 44 hours a month at a loaded labor cost of $32 per hour, or $1,408 monthly. Training and data cleanup require 36 one-time hours across locations; at an illustrative loaded rate of $28 per hour, that represents $1,008. Temporary duplicate operation is estimated at another 18 hours, or $504. The current local effort totals 55 hours monthly. If the process reduces local input to 12 total hours for receipt confirmation and exceptions, the illustrative local time released is 43 hours. Those hours are capacity released, not automatically cash savings: the owners must decide whether they reduce overtime, avoid future hiring, or are redeployed to other work.

The group's monthly cost comparison therefore includes the $1,408 shared team cost, software costs if any, and remaining local hours valued consistently. It also shows the current costs and the one-time $1,512 setup and duplicate-operation estimate separately. Before expanding, the team checks invoice turnaround and unresolved exceptions. It also tracks month-end completion, coding corrections and local hours used. If South's exception backlog rises while the other sites improve, the group adjusts the approval backup and training instead of assuming one aggregate average represents all offices. This example illustrates the arithmetic and decision process; actual results depend on verified costs, workload or service requirements.

Pilot, evaluate by location, and expand deliberately

Choose a pilot that tests meaningful variation. The largest or most ready office may not test smaller-site staffing limits or different vendor terms. Select a supportable scope and define inclusions, exclusions, observation period, and pause or rollback conditions.

Before launch, train the people who perform and approve the work, and those who support it. Provide a process map with routine and exception examples, plus the contact route and fallback steps. Ask each role to demonstrate its part. Attendance is not readiness: a local backup should carry out critical steps, and the central owner should find location information needed to resolve exceptions.

Review pilot performance separately for each location. Compare results with the baseline and with the expected range, but account for differences in volume, staffing, lease obligations, and data quality. Ask whether the process worked, whether people knew who owned each handoff, whether the fallback was needed, how much time the new model consumed, and what additional local work appeared. Include qualitative observations with the measures, because a report may show a delay without revealing that approvals are routed to an unavailable manager.

Set expansion criteria before the pilot begins. Criteria might include a minimum level of report completeness, acceptable exception backlog, stable turnaround, confirmed backups, and a manageable workload for the shared team. Assign a decision maker who can authorize expansion, require a targeted revision, or extend the pilot. Record the reasons. Avoid expanding simply because a launch date has arrived or because one location reports a positive experience. A staged rollout gives the organization a chance to adjust training and capacity, with clear decision rights before adding more sites.

After expansion, review whether expected benefits persisted. Recheck cost, local effort, reporting quality, and exception distribution. Ask whether a temporary workaround became routine, then formalize it with controls or remove it. Revise the matrix and instructions, along with current contacts when ownership changes. Staffing and volumes may change; so can vendors or premises can all require changes to the operating model.

Common mistakes and an action checklist

One common mistake is standardizing before documenting local variation. That can erase a lease obligation, a vendor dependency, or a task carried by an informal local expert. Another is transferring a task without transferring its information, authority, or time budget. Central teams then receive incomplete requests, local employees repeat work, and managers cannot tell where an item is stuck. A third mistake is measuring only total cost: the group may appear more efficient while one office absorbs extra follow-up or loses a reliable backup.

Owners also get into trouble when they launch too many changes at once, rely on a single contact, treat training as a one-time announcement, or judge the pilot using aggregate results alone. Temporary workarounds are especially risky when nobody tracks them to closure. Avoid vague ownership such as "finance handles it" or "the site will follow up." Name the role, define the handoff, state how completion is confirmed, and give staff a usable escalation route.

Use this short checklist to turn the plan into assigned work:

Complete a consistent inventory of systems and roles; agreements and vendors; reports and informal workarounds for every location.
Decide which activities are shared and which remain local; document performers and approvers; backups and thresholds, plus exception paths.
Name the sponsor and transition owners, then set milestone evidence, decision routes, contacts, and a decision log.
Estimate transition effort by role and site; arrange coverage and define a recorded fallback for each changed process.
Establish location-level cost and continuity baselines, plus a capacity baseline with clear definitions and data owners.
Run a bounded pilot, review outcomes by location, resolve issues, and document the decision to expand, revise, or pause.
Update instructions and contacts after the change, then schedule a review of cost, workload, reporting quality, and unresolved work.

Questions about your own practice? Contact Richard@DoctorsInvestorClub.com.