Managing hiring across a single location is a scheduling problem. Managing hiring across 20 locations simultaneously is a coordination problem of a different character entirely. The failure modes are different, the tooling requirements are different, and the breakdown points are not where most recruiting teams expect them to be when they first start scaling across sites.
This article covers what we have learned from working with recruiting teams that manage multi-site pipelines, specifically in logistics distribution and regional retail operations. If you are running 2 to 4 locations, most of what follows may be slightly ahead of where you are. If you are managing 10 or more locations with a single central recruiting function, the problems described here will be familiar.
The coordination problems that actually get teams stuck
The most obvious problem in multi-location hiring is visibility: you do not know the current state of each site's pipeline without pulling data from multiple sources or asking site managers directly. But in practice, visibility alone is rarely what causes the pipeline to break down. It is a symptom of three underlying coordination failures that happen at the operations layer.
The first is interviewer calendar fragmentation across locations. When interviews are being scheduled at 20 different sites, each site's hiring manager or ops supervisor has their own calendar, their own available windows, and their own communication pattern with the recruiting team. A central recruiter coordinating interview scheduling across all 20 sites is effectively maintaining 20 separate scheduling relationships, each with its own cadence of slot requests, updates, and last-minute changes. The cognitive overhead alone is significant, but the practical failure mode is that high-urgency locations get the recruiter's attention while medium-urgency locations go quiet, and the pipeline at those quieter sites stalls not because of applicant volume but because scheduled interview slots never get confirmed.
The second coordination failure is candidate routing errors. When a candidate applies and their location preference is not precisely matched to the available role at the nearest site, they end up in the wrong pipeline. This sounds like a minor data hygiene problem, but at 20 locations it creates a recurring pattern of interviews scheduled at the wrong site, candidates who do not show because they cannot get to the location they were booked for, and site managers asking why their requisition is not getting filled while candidates in the system are marked as scheduled but actually routed elsewhere. We have seen this pattern repeatedly and it is always invisible until someone digs into the records.
The third failure is status update lag from site managers. Central recruiting depends on site managers confirming whether candidates who interviewed were offered a position. In a single-location operation, this feedback loop can be informal. At 20 locations, each site manager has their own reporting rhythm, and the recruiting team is often working with stale status data across a significant portion of the pipeline. Candidates who have been offered a position but not marked as hired remain in active scheduling queues. Candidates who withdrew after the interview are still being tracked as pipeline inventory. The pipeline numbers look healthier than they actually are until the offers-per-application rate starts dropping.
What a multi-location pipeline structure actually needs
The structural requirement for managing pipelines across 20 sites is straightforward to describe and harder to implement: each location needs to be a distinct pipeline unit with its own applicant queue, its own interview calendar pool, and its own status tracking, but all of it needs to be visible to the central recruiting function as a consolidated view.
Most ATS systems handle the data storage for this reasonably well, particularly Greenhouse and Lever with their multi-office configurations. Where they fall short is the outreach and scheduling layer. An ATS tells you who applied and what stage they are in. It does not run outreach calls or confirm interview slots. When those activities are being managed manually across 20 locations, the ATS data is always behind what is actually happening in phone and email communications between candidates and local contacts.
The outreach and scheduling automation layer solves the lag problem by making the confirmation loop visible and timestamped. When a candidate is contacted for a screen, the call timestamp and outcome are recorded. When they are routed to an interview slot, the booking confirmation is recorded. When the interview date passes without a status update from the site, the system flags the open item. This creates an auditable activity trail across all 20 pipelines without requiring the recruiting team to manually chase status updates from every site manager.
Location-specific calendars and routing rules
For the scheduling layer to work correctly across multiple locations, each site needs its own configured calendar pool and its own routing logic. This is more setup work than a single-location deployment, but it is a one-time configuration cost rather than an ongoing operational burden.
The routing logic has to handle three cases: candidates who applied specifically to one location, candidates who indicated willingness to work at multiple locations, and candidates who are geographically near the boundary between two sites. The first case is simple. The second case requires a priority order for which site to book first, typically based on urgency or open role count. The third case requires a defined rule, usually radius-based (book to the nearest site within a specified distance threshold), rather than leaving it to manual recruiter judgment. Without an explicit rule for boundary cases, those candidates accumulate in an unassigned state that nobody is actively managing.
Timezone management is relevant for operations that span multiple timezone zones. Interview confirmation messages sent at 6 AM Eastern reach candidates in Pacific time in the middle of the night, and response rates are poor. This sounds obvious but it is a configuration step that gets missed in multi-site setups that start in one timezone and expand later. Every candidate communication in the automation layer should resolve to the candidate's local timezone, not the central office timezone.
What the recruiting team's weekly view should show
In a functioning 20-location operation, the recruiting team should be able to answer these questions without pulling manual reports: which sites have the most urgent open requisitions, which sites have candidates in the pipeline that have not moved in more than 5 days, which candidates are scheduled for interviews in the next 48 hours across all sites, and which interview slots from the previous week are still missing a hire or decline outcome from the site manager.
Those four questions define the minimum viable multi-location pipeline view. Everything else, like sourcing channel analysis or time-to-fill trend data, is valuable but secondary to the operational questions that determine whether the current week's hiring will hit its targets.
The failure mode we see most often in multi-site operations that are not working is that the recruiting team has visibility into aggregate numbers (total open roles, total applications, total scheduled interviews) but not into the per-site pipeline age and status. Aggregate numbers look fine until a specific site is suddenly four weeks behind on filling shifts because its local pipeline has been stalled at the interview stage for ten days and nobody noticed.
Where central coordination ends and local autonomy begins
We are not arguing that every element of multi-site recruiting should be centrally managed and automated. There are decisions that site managers make better than a central recruiting function. Whether a candidate's answers in a first screen translate to the specific physical requirements of their particular facility is one. Whether a candidate who seemed borderline on the phone is worth giving a chance given current staffing pressure at that location is another.
The automation layer handles the logistics: outreach, screening against objective criteria, interview slot booking, and status tracking. The site manager makes the hiring decision after the interview. The central recruiting team manages the aggregate pipeline and ensures every site has the throughput it needs to make those decisions at pace. The breakdown happens when logistics tasks creep back into the central recruiting function through manual coordination work, which is what happens in multi-site operations without automation. The recruiting team ends up doing calendar work at 20 locations when their time should be on sourcing strategy and site manager relationship management.
The coordination architecture for 20 sites is not dramatically more complex than for 5 sites, provided the routing rules and calendar configurations are set up correctly from the start. The mistakes that make 20-site coordination hard are usually made in the first three to five site configurations and then compounded as more sites are added on top of an already inconsistent foundation. Starting with explicit routing rules and per-location calendar pools, even when it feels like overbuilding for current volume, pays off when the team adds the 15th and 16th site later.