What is a BDC opt-out workflow?

A BDC opt-out workflow records a customer's request, identifies the number and communication involved, updates the relevant calling and texting systems, assigns an owner for exceptions, and preserves the source message or call note for review. The dealership should have qualified counsel approve the policy and scope.

Does a customer have to text STOP to opt out?

No single keyword should be treated as the only possible request. The FCC's 2024 order lists several standard reply words and says other words and methods may also express revocation. The dealership should preserve the customer's exact language and follow its counsel-approved process.

Should a BDC opt-out update both calling and texting systems?

The workflow should evaluate every relevant communication system rather than updating one platform in isolation. The exact scope can depend on the message, consent basis, campaign, and current law. Record the request once, route it for review when needed, and let approved policy determine which queues must stop.

What should a dealership keep in an opt-out record?

Keep the customer identifier, phone number, timestamp, source channel, exact wording or call note, related campaign, systems updated, effective status, exception owner, and final disposition. Retention and access rules should come from the dealership's legal, compliance, and information security policies.

BDC Opt-Outs: Build One Workflow Across Calls and Texts

Build a BDC opt-out workflow that captures customer intent, updates campaign eligibility, and leaves a clear audit trail across calls and texts.

A BDC opt-out is a request to stop contact. Treating it as a keyword in the texting platform leaves too much room for another queue to miss it.

The process needs to capture what the customer said, update the right calling and texting systems, and leave a record someone can review. This is an operating framework, not legal advice. The dealership's counsel should decide which rules apply, how broadly a request must be honored, and how long the supporting records should be kept.

Quick answer

A workable BDC opt-out process should:

Keep the customer's exact request and source channel
Match it to the correct person, number, campaign, and consent record
Update the relevant dialer, texting platform, CRM queue, and vendor list
Send uncertain identity or scope questions to a named reviewer
Verify the new status before the next automated contact

The point is simple: every communication system needs to act on the same decision without losing the context behind it.

Why a STOP-only model is incomplete

Keyword handling is useful. It catches standard replies quickly. It can also miss a clear request because the customer used different words or made the request during a call, voicemail, email, or website submission.

The FCC's 2024 TCPA consent order says consumers may revoke prior express consent for covered automated calls and texts in any reasonable manner that clearly expresses a desire not to receive further communications. It identifies STOP, QUIT, END, REVOKE, OPT OUT, CANCEL, and UNSUBSCRIBE as standard text responses. The order also says other words and phrases may express the same intent.

Automation can handle the obvious cases. People still need a route for plain-language requests and requests that arrive outside the texting platform.

Preserve the customer's exact words

A status such as "opted out" is necessary for systems. It is not enough for a later review. Keep what the customer said, where they said it, the time, the phone number involved, and the communication or campaign that prompted the request.

For a text, retain the message body and provider event. For a call, save the exact note or transcript segment permitted by policy. For voicemail, email, or a web form, link the source artifact instead of rewriting the request from memory.

That detail matters when the wording is narrow. "Do not text me about this vehicle" contains more information than a bare suppression flag. A BDC agent should not have to make a legal scope decision during a live conversation. The agent should preserve the words and route the question.

Separate acknowledgment from the system update

An agent can say, "I understand," while the customer remains active in another queue. The acknowledgment and the eligibility change are separate events. Both need confirmation.

First, the agent confirms the request using approved language and does not argue about the customer's choice. Then the system changes the appropriate contact status, pauses queued work, and records which destinations received the update.

The record should move through clear states: requested, under review when needed, applied, and verified. A note without a status change is unfinished. A status change without the source request is difficult to audit.

Use one event record across the stack

The CRM, dialer, texting provider, email tool, campaign file, and outside BDC may each hold a copy of contact eligibility. Separate manual updates make it easy to miss one.

Create one opt-out event with the customer identifier, phone number, source channel, exact request, timestamp, campaign or message category, consent record reference, intended scope, owner, and status. Downstream systems should consume that event or reconcile against it.

The event should record each attempted update and its result. If the texting platform updates but the dialer fails, the record stays open. It does not report completion because one platform accepted the change.

Only approved roles should change the final status or override a suppression. The dealership should name who can resolve an identity mismatch, restore eligibility after a new customer request, or approve a limited exception.

Do not overread the 2026 waiver

The FCC issued a January 2026 order that extended a limited waiver until January 31, 2027. The delayed requirement concerns applying an opt-out made in response to one type of informational message to all future robocalls and robotexts from the same caller on unrelated matters.

The order says the waiver is limited and does not change other prior FCC rules or rulings about revocation. Turning that into "the whole revocation rule was delayed" would be wrong.

Agents should not interpret the waiver. Counsel should define the current policy for message categories, consent bases, exemptions, and channels. The BDC process should keep enough detail to apply that policy and stop for review when the category or scope is unclear.

Test requests that do not look alike

A happy-path test with the word STOP proves that the texting provider recognizes STOP. It does not prove the BDC process works.

Test a standard keyword reply and a plain-language text such as "please don't message me again." Test an oral request during a call, a voicemail, a record with two phone numbers, a duplicate customer profile, and a request tied to one message category. Include a case where one downstream platform rejects the update.

For each case, check the source record, contact status, queue removal, downstream results, owner, timestamp, and final review state. Then confirm the next scheduled automated action does not run when approved policy says it must stop.

Give managers an exception queue

Some records will not resolve automatically. The phone number may belong to two profiles. The customer may ask to stop one type of message but continue another. A vendor may report an opt-out without the original body. The CRM may reject the update because an integration failed.

These cases need an exception queue with one owner and a deadline set by approved policy. The reviewer should see the original request, customer-match evidence, current communication statuses, campaign context, and every update attempted so far.

This is where clear lead disposition definitions and a written vendor access plan help. The first keeps customer intent separate from contact outcomes. The second limits who can alter suppression and consent records.

What the working document should contain

The final procedure should identify accepted intake channels, required source evidence, identity-matching rules, automatic actions, exception owners, downstream systems, verification steps, override authority, retention references, and review timing.

It should also name the system of record. If a BDC manager cannot tell which status controls tomorrow's dialer and texting queues, the process is still ambiguous.

A reviewer should be able to reconstruct three facts: what the customer requested, what the dealership changed, and whether the relevant automated contact stopped. Everything else supports those answers.

Reviewing your BDC contact controls? Talk with Paramount Lead Solutions about mapping customer requests, queue ownership, and system updates before the next campaign launches.