The split solves one problem and creates another

Most stores split the BDC for good reasons. Sales BDC people are good at appointment setting, objection handling, and keeping a lead warm for 60 days. Service BDC people are good at scheduling capacity, recalls, declined-service follow-up, and knowing that a 7:30 drop-off and an 8:00 waiter are not the same thing. Those are different skills and different rhythms.

Then the customer calls and ruins your org chart.

"Hi — I've got a lease that's up in two months and my car's making a noise. Can somebody help me?"

That call touches both departments. In a lot of stores it ends in a transfer, a voicemail, and nobody calling back. The customer isn't in anybody's queue because they're in both.

The fix isn't to un-split the BDC. It's to write down four things: who owns each queue, what response looks like in each one, who covers overflow, and what a handoff actually requires. Vague on any of the four and you get dead ends.

Start with queue ownership, not job titles

BDC queue ownership means one named person owns the outcome of every item in a queue — not "the sales BDC handles that," but "Marcus owns inbound internet leads 8a–4p Monday through Friday."

Make a list of every queue in the store. A typical dealership BDC structure has more than people think:

  • Inbound sales phone
  • Inbound service phone
  • Internet/third-party leads
  • Chat and text
  • Service scheduling requests from the website
  • Declined-service and recommended-service follow-up
  • Missed-call callbacks (both departments)
  • Equity mining / lease maturity outreach
  • Post-RO survey fallout and reschedules
  • After-hours voicemail

For each one, write three fields: owner, backup, and hours covered. If a queue has no name next to it, that's where your dead ends live. Most stores find two or three orphan queues on the first pass — missed-call callbacks and service web requests are the usual suspects.

One rule that prevents most arguments: the queue is owned by the department that can finish the job, not the one that answered the phone. A service advisor can't sell a lease pull-ahead. A sales BDC rep can't promise a loaner on Thursday.

Response standards, written per queue

"Respond fast" is not a standard. A standard has a clock, a channel, and a definition of what counts.

Here's a workable set. Adjust the numbers to your staffing, but write something down:

QueueFirst responseCounts as a responseEscalates after
Inbound sales callAnswered within 3 ringsLive human2 unanswered rings → overflow
Internet lead10 minutes, business hoursCall attempt + text + email30 minutes
Service web schedule20 minutesConfirmed appointment or call attempt1 hour
Missed call15 minutesCall back + text45 minutes
Declined serviceWithin 5 days of ROCall attempt + voicemail + text10 days
After-hours voicemailBy 9:15a next business dayCall attempt10:00a

The column that matters most is "counts as a response." Without it, reps mark leads worked after leaving one voicemail. Say it plainly in the standard: a voicemail with no text is not a response.

Also define the content of first contact, not just the timing. For a service BDC rep picking up a sales-flavored call:

"I can get you on the schedule for that noise right now — and it sounds like your lease is close to the end, so let me also get Dana from sales on the line before you hang up. Give me 30 seconds."

That sentence does two jobs: it serves the request the customer called about, and it prevents the second need from evaporating.

Overflow coverage: decide who picks up before the phone rings

BDC overflow coverage is where the split usually fails, because most stores treat it as a favor instead of a duty. Monday morning at 8:05 the service queue has eleven calls stacked and the sales BDC is quiet. Does sales pick up? "Sometimes, if they feel like it" is the answer in a lot of stores.

Make it a rule with a trigger:

  • Trigger: 3+ calls in queue, or hold time over 90 seconds.
  • Who: the other department's BDC, in a defined order (sales BDC → sales desk → service manager).
  • What they're allowed to do: take the message completely, schedule from the shared calendar if trained, or warm-transfer if a qualified person is live.
  • What they're not allowed to do: quote a repair price, promise a loaner, promise a trade number.

That last line protects both departments. Overflow coverage is about capture, not commitment. Train your sales BDC to say:

"Service is with another customer right now. I can book your appointment from here — what day works? And I'll have your advisor confirm the details by text within the hour."

Then make sure that "within the hour" actually belongs to someone. A promise made in overflow is a handoff, and handoffs need rules.

The handoff is a transaction, not a transfer

A dealership handoff process that works has the same structure every time, in both directions. Three parts:

  1. Warm introduction while the customer is live, if possible. Not "let me transfer you." Instead: "Stay with me one second, I'm getting Dana — Dana, this is Rachel, 2022 Explorer, lease up in May, she's also got a brake noise she needs looked at Thursday."
  2. A written record in the CRM/DMS with four fields: customer, what they want, what was promised, who owns the next step and by when.
  3. An acknowledgment. The receiving person confirms they have it. No acknowledgment inside 30 minutes, it bounces back to the sender.

That third part is the one everybody skips, and it's the reason "I sent it to service" and "I never got it" are both true.

Build the acceptance rule into your day. A simple version: any handoff sitting unacknowledged at the 11a and 4p check gets read out loud by whoever is running the board. Two days of that and acknowledgment stops being a problem.

The four handoffs worth scripting

Don't script everything. Script the ones that recur:

  • Service customer with lease maturity or positive equity → sales. Trigger: equity report flag or advisor notices. Promise: sales BDC calls while the car is in the shop, not three days later.
  • Sales customer who didn't buy but needs service → service. Trigger: unsold showroom or declined deal with a current vehicle. Promise: appointment set before they leave.
  • Recall or open campaign surfaced on a sales lead → service. Promise: scheduled, with a confirmation text.
  • Service customer whose repair exceeds vehicle value → sales, carefully. Promise: advisor asks permission first. "Would it be useful to see what trading it would look like, or do you want to stick with the repair?" Permission matters here — skip it and you've turned a service visit into a sales ambush.

Find your dead ends this week

You don't need a project. You need two hours and a sample.

Pull 20 calls from last week that touched both departments — transfers, overflow pickups, anything a rep flagged. For each, answer three questions: did someone own it, did the owner respond inside the standard, and did the customer get a clear next step with a name and a time?

Score them pass/fail. You'll usually find the same two or three failure patterns, not twenty. Fix those, re-pull in 30 days.

If you'd rather not listen to 20 calls by hand, this is exactly what MoreSignal was built to do — score the handoff and response moments against your standard and tell you which queue is leaking.

Either way, the output is the same: a one-page sheet that says who owns what, how fast, who backs them up, and what a handoff requires. Tape it to the BDC wall. The sales BDC vs service BDC debate stops being a debate once the sheet exists.