Numa changes the economics of the hybrid BDC model by handling after-hours calls, overflow contacts, and outbound campaigns through an AI-driven system that books appointments, captures customer intent, and logs every interaction back to the individual rooftop's DMS — without requiring human staffing for that centralized layer. This frees decentralized rooftop BDC teams to focus exclusively on complex, relationship-dependent calls where local knowledge matters. The practical result is a hybrid model that is more affordable and operationally cleaner than anything built on legacy phone systems and scripts.

Centralized vs Decentralized BDC: What Dealer Groups Are Choosing

Every dealer group above six or seven rooftops faces the same structural question eventually: do we run BDC from the center, or do we let each store own it? The financial pressure to centralize is real — one team handling inbound calls across 12 rooftops is cheaper per contact than 12 teams doing it independently. But the operational argument for decentralization is also real: a BDC agent who knows the local market, the store's service advisors by name, and the Fixed Ops workflow handles calls differently than someone in a central office working from a script.

Neither model is categorically better. The right answer depends on group size, geographic footprint, brand mix, and — increasingly — what call types you're asking the BDC to handle. The groups getting the most out of their BDC investment in 2026 aren't choosing between centralized and decentralized. They're running a hybrid, where the structure follows the call type rather than the store.

This guide covers the tradeoffs of each model, the specific conditions that favor centralization or decentralization, and how the hybrid structure works in practice.

The three BDC structure options

Before evaluating the tradeoffs, it helps to be precise about what each model actually means:

Centralized BDC. One team, typically located at a corporate facility or operating remotely, handles inbound and outbound calls for all rooftops in the group. The team has defined scripts, shared scheduling access across all DMS platforms, and reports to a central BDC director rather than to individual store GMs. Call types typically include sales appointment setting, Fixed Ops appointment booking, inbound inquiry handling, and outbound follow-up campaigns.

Decentralized BDC. Each rooftop operates its own BDC, typically staffed by two to five agents and managed by the store's BDC manager (who often reports to the GM or Fixed Ops Director). The team handles calls for that store only, knows the local staff and workflow, and is directly accountable to store-level metrics. Staffing decisions are made at the rooftop, not at the group level.

Hybrid BDC. A combination model where certain call types — typically higher-volume, more transactional calls — route to a centralized team, while complex or relationship-dependent calls route to store-level staff. The hybrid can be segmented by call type, by time of day (centralized handles overflow or after-hours), or by function (centralized handles sales, decentralized handles Fixed Ops).

Most dealer groups don't start with a deliberate choice between these models — they inherit one based on how they grew. A group built through acquisition often has a patchwork of decentralized BDC operations, each running differently. A group built ground-up from a single platform often centralizes early. Understanding where your current model came from tells you a lot about the friction points you're dealing with.

When centralized BDC works (and when it doesn't)

Centralization delivers real advantages in specific conditions:

It works when call type is consistent and scriptable. Sales appointment setting, service appointment booking, and recall outreach are well-defined call types with predictable conversation flows. A centralized team can execute these at high volume with consistent quality, and the cost per contact is typically 30–40% lower than decentralized. A multi-rooftop Chrysler Dodge Jeep Ram group in the Midwest centralized its appointment booking BDC across eight rooftops and reduced cost per booked appointment from roughly $28 to $17 within the first six months.

It works when the group has standardized its DMS and scheduling platform. If every store runs the same system, a centralized BDC agent can work across rooftops without relearning the workflow. If stores are on different platforms, centralization creates operational complexity that often cancels out the cost savings.

It doesn't work well for complex Fixed Ops calls. A customer calling about an RO that has had three delays, parts that are on national backorder, and an advisor they've had a frustrating interaction with is not a call a centralized BDC agent with a script can handle well. These calls require store-specific knowledge, relationship context, and the authority to make decisions. Routing them to a central team typically results in escalations back to the store, which wastes time and frustrates the customer twice.

It doesn't work when brand identity is a competitive differentiator. Some stores — particularly single-point luxury franchises and high-volume dealers in markets with strong local brand loyalty — find that centralized BDC erodes the "we know you" relationship quality that drives customer retention. If your retention rate is a competitive advantage tied to local knowledge and relationship continuity, centralizing the first contact point is a risk worth thinking through carefully.

When decentralized BDC works (and when it doesn't)

Decentralization preserves what centralization gives up: local context, accountability to the rooftop, and the ability to handle complex calls with store-specific knowledge.

It works when stores are sufficiently differentiated. A group with a domestic volume store, a luxury franchise, and an independent service center in the same metro has three fundamentally different customer profiles and call types. A single centralized BDC serving all three will default to the lowest common denominator in how it handles calls. Decentralized lets each store calibrate to its customer base.

It works when Fixed Ops is a primary revenue driver. Fixed Ops calls are different from sales calls in tone, complexity, and relationship sensitivity. Customers calling about their vehicle's repair status or a multi-thousand-dollar service estimate are in a different emotional register than customers inquiring about a test drive. A Fixed Ops Director who has direct management authority over the BDC agents handling those calls can calibrate quality standards, escalation paths, and advisor integration more effectively than a central BDC director managing from a distance.

It doesn't scale well. The fundamental problem with decentralized BDC is that it requires building and maintaining a functional team at every rooftop. For a five-store group, that's manageable. For a 20-store group, maintaining quality and consistency across 20 separate BDC operations is a full-time management problem. Turnover at one store creates a cascade of coverage gaps that a central team can absorb without notice.

It creates inconsistent customer experience at the group level. Customers who visit multiple stores in the same group often notice inconsistencies in how they're handled — different scripts, different follow-up timing, different processes for booking service appointments. For groups investing in a unified brand experience, decentralized BDC works against that goal.

The hybrid model — and why most groups are moving toward it

The hybrid model resolves the core tension by assigning call types to the appropriate structure rather than assigning all calls to a single structure.

The practical hybrid that's emerging in well-run dealer groups in 2026 looks like this:

Centralized handles:

• After-hours inbound (all call types)

• High-volume outbound campaigns (recall outreach, declined service follow-up, lapsed customer reactivation)

• Overflow during peak hours when rooftop BDC is at capacity

• First-contact sales appointment setting

Decentralized (rooftop) handles:

• Complex inbound Fixed Ops calls — RO status inquiries, escalations, multi-visit history calls

• Advisor-specific follow-up where the customer has an established relationship

• Same-day scheduling changes requiring real-time coordination with the Fixed Ops team

This structure means a customer calling at 7 PM to book a routine service appointment reaches a centralized system that can confirm availability and book the RO. A customer calling at 10 AM to discuss why their transmission repair is three days late reaches a store-level team member who has the authority and the context to handle the conversation.

For the Fixed Ops operator view perspective, the hybrid model works best when the store-level Fixed Ops Director has visibility into what the centralized system is booking and handling, so there are no handoff surprises when the RO hits the service drive.

What size and configuration tips the decision

Group size is the most reliable predictor of which model a group will adopt:

Under 5 rooftops: Decentralized almost always makes more sense. The overhead of centralization is too high for the volume, and the local relationship advantages of decentralized BDC are most pronounced at smaller scale.

5–12 rooftops: This is where the hybrid starts to make economic sense. Groups in this range often centralize after-hours and outbound while maintaining rooftop-level Fixed Ops BDC coverage during the day. The multi-store Fixed Ops KPI framework is particularly relevant here, because the hybrid model requires clear KPI ownership to avoid accountability gaps between the central and rooftop teams.

12+ rooftops: Centralization for high-volume, scriptable call types is almost always economically justified. The question isn't whether to centralize some functions — it's how to preserve rooftop accountability for the complex calls that can't be handled from the center.

Geographic concentration matters independently of size. A group with 15 stores in one metro has different centralization economics than a group with 15 stores spread across five states. Co-located groups can build physical BDC infrastructure; distributed groups are building virtual teams with more complex management challenges.

How Numa solves this

The structural decision between centralized and decentralized BDC is made harder by the fact that most groups are trying to solve it with the same tools they used five years ago — phone systems, scripts, and scheduling software that wasn't designed for group-level management.

Numa's platform changes the calculus on the hybrid model specifically. When after-hours calls, overflow contacts, and outbound campaigns are handled by an AI-driven system that books appointments, captures customer intent, and logs every interaction back to the individual rooftop's DMS, the "centralized team" for those call types doesn't require human staffing at all. That frees the decentralized rooftop BDC to focus on the complex, relationship-dependent calls where local knowledge actually matters — rather than spending half their shift on transactional appointment bookings that could be handled systematically.

The practical result: the hybrid model becomes more affordable and more operationally clean, because the "centralized" layer for high-volume contacts is handled by the system rather than by a separate team that needs to be hired, trained, and managed.

Frequently Asked Questions

What's the average BDC structure for a 10-store group?

Most 10-store groups operate some version of a hybrid model, even if they don't call it that. They typically have rooftop-level BDC staff handling complex calls and advisor follow-up, with a shared or outsourced solution handling after-hours volume and outbound campaigns. Pure centralization at 10 stores is uncommon unless the group built the infrastructure intentionally and has standardized its DMS platform across all rooftops. Pure decentralization is increasingly hard to staff and manage at that scale.

Does centralizing BDC hurt CSI?

It can, if the centralized team handles call types that require local context or relationship knowledge. CSI impacts tend to appear in the "advisor communication" and "ease of reaching the dealership" questions when customers feel they're dealing with a call center rather than their service department. The risk is highest in Fixed Ops, where customers often have an established relationship with a specific advisor. Hybrid models that keep Fixed Ops calls at the rooftop level while centralizing transactional volume typically show no CSI degradation from the structural change.

What's the cost difference between centralized and decentralized?

Fully centralized BDC typically costs 30–40% less per contact than decentralized, primarily through staff efficiency and shared overhead. However, the comparison needs to account for the quality degradation cost on complex calls and the CSI impact if the centralized team handles call types that perform better with local knowledge. A hybrid model often lands at 15–25% cost reduction versus fully decentralized, with better quality outcomes on the call types that matter most for retention and CSI.

Can AI handle BDC call volume?

AI handles the transactional call types well — appointment booking, general inquiries, service status updates, and after-hours contacts. These represent roughly 40–60% of total inbound BDC volume at most dealerships. The calls that require relationship context, emotional intelligence, or store-specific decision authority still route to humans. For dealer groups evaluating how AI fits into the BDC structure, the practical framing is: AI as the centralized layer for transactional volume, human BDC staff focused on complex and relationship-dependent calls.

How do groups handle the transition from decentralized to hybrid or centralized?

The transitions that work best start with one call type rather than a full structural shift. Groups that begin by centralizing after-hours contacts — which is typically low-stakes volume that the rooftop BDC would otherwise miss entirely — have a clean proof point before they decide whether to centralize additional functions. Transitions that fail usually try to move all call types at once, which creates a disruptive handoff period and a difficult staffing conversation at every rooftop simultaneously.