Salesforce Do Not Call Requests: What Should Happen After a Mobile Call?
A customer says, “Please stop calling me.”
The rep hears the request clearly. The mobile call ends. Then the risk begins.
If the request stays in the rep’s memory or disappears inside a vague call note, another seller may call tomorrow. A campaign may add the person to a new list. An automated agent may start an outreach sequence without knowing that the customer already changed their preference.
Salesforce can hold communication preferences at several levels, from a simple Do Not Call field to detailed consent records for a channel, contact point, purpose, and brand. But the model only helps when the request reaches the right record quickly and accurately.
For mobile teams, that starts with capturing the conversation where the preference was actually expressed.
What should happen when someone says do not call?
The safest operational answer is simple: stop avoidable phone outreach immediately, preserve what the person said, identify the correct person and phone number, update the appropriate Salesforce preference record, and make sure every calling system uses the same decision.
That process should not depend on the rep remembering to type a note at the end of a busy day.
It should also avoid treating every phrase as identical. “Do not call me again” is different from “Call me next quarter,” “Use my work number,” or “Email me instead.” Each statement can require a different Salesforce action.
Why mobile calls create a communication preference gap
Most preference management designs focus on forms, emails, subscription centres, and contact centre interactions. Those are important sources, but customers also state preferences during ordinary conversations with account executives, recruiters, field service staff, relationship managers, and customer success teams.
The customer may call a direct business mobile number. A rep may return a call while travelling. A relationship manager may speak to a client through the phone’s normal cellular service rather than a browser dialler.
If that call never reaches Salesforce, the organisation can have two conflicting versions of the truth:
-
The customer believes the request has been made.
-
Salesforce still shows the person as available for phone outreach.
The next caller does not see the conversation. The campaign system does not know it happened. The customer experiences the second call as a failure to listen.
A do not call request is not always one Boolean field
Salesforce includes Do Not Call options for Leads and Contacts. For some organisations, that field is the practical control used to stop phone outreach. Other organisations need more detail because the preference varies by channel, number, purpose, brand, or period.
Salesforce’s consent data model supports several levels of preference.
Global preference
An Individual record can hold broad privacy choices, including whether the person wants solicitation. This is wider than one phone number or one campaign.
Channel preference
A Contact Point Type Consent record can describe whether the person permits contact through a channel such as phone or email.
Contact point preference
A Contact Point Consent record can distinguish between specific details. Someone may reject calls to a personal mobile number while allowing calls to a work number.
Purpose and brand
The reason for contact also matters. A person may reject promotional calls but still expect necessary service messages about an active contract. A preference may also apply differently across brands in the same Salesforce organisation.
Salesforce’s consent data model explains these levels and recommends considering the most restrictive related request. The right design depends on the organisation, its Salesforce products, its legal basis, and the jurisdictions in which it operates.
The crucial point is operational: a generic call note should not become the only place where a material communication preference lives.
What should Salesforce capture from the conversation?
A useful preference record needs enough context to prevent another unwanted call without turning an AI interpretation into legal fact.
1. The person and the Salesforce record
Match the caller or recipient to the correct Lead, Contact, Person Account, or other approved identity record. If the number matches several records, or no record at all, route the item for review rather than guessing.
2. The affected phone number
Record whether the request applies to the number used on the call, every known number, a personal number, or a work number. Do not assume that a preference about one contact point automatically defines every other contact point.
3. The customer’s actual words
Preserve the relevant statement in the source transcript or recording where policy and configuration permit. A concise note can help people act quickly, but the source language matters when the request is ambiguous.
4. The channel
Separate phone calls from email, text, social messages, and post. “Please email me instead” is a channel preference, not a request to end the relationship.
5. The purpose
Distinguish sales or marketing outreach from service, billing, account security, contractual notices, and other defined purposes. The organisation should decide these categories with appropriate legal and privacy guidance.
6. The effective time
Store when the request was made and when the operational restriction should begin. A spoken request should not wait for a weekly data clean up before calling systems respect it.
7. Any stated duration
“Do not call until January” is a pause, not necessarily a permanent preference. Record the date and the condition exactly. Do not invent an expiry when the customer did not give one.
8. The capture source
Record that the preference came from a mobile call, along with the call time, direction, user, and linked activity. This creates a traceable route back to the source event.
9. Review status
Use a clear state such as confirmed, pending identity review, ambiguous, or superseded. That prevents a low confidence interpretation from silently becoming permanent customer data.
A practical Salesforce workflow for mobile do not call requests
The exact objects and automation will vary, but a reliable workflow usually follows this sequence.
Step 1: Capture the completed mobile conversation
Bring the call event into Salesforce with the time, direction, duration, business user, and matched record. Add the recording and transcript only where they are configured and permitted.
Step 2: Detect possible preference language
AI can flag phrases such as “stop calling,” “email me instead,” “use my office number,” or “try me after the new year.” The flag should start a workflow, not make the final consent decision.
Step 3: Apply an immediate operational hold where appropriate
If the language clearly asks for phone outreach to stop, the organisation may choose to prevent avoidable calls while the record is reviewed. The rule should be designed by the relevant privacy, legal, operations, and Salesforce owners.
Step 4: Confirm identity and scope
Check that the call is attached to the correct person and number. Determine whether the request applies to one phone number, the phone channel, a defined purpose, one brand, or all solicitation.
Step 5: Preserve the source evidence
Keep the original activity and the permitted source material linked to the preference change. Record who reviewed it, what decision was made, and when.
Step 6: Update the approved Salesforce control
That control may be the Do Not Call field, a Contact Point Type Consent record, a Contact Point Consent record, an Individual preference, or a governed combination. Salesforce’s Sales Cloud consent guidance describes the standard Do Not Call option for Leads and Contacts.
Step 7: Propagate the decision to every outreach path
Sales diallers, campaign tools, contact centre platforms, mobile teams, outsourced providers, and AI agents should consult the same approved preference before a call begins. A correct Salesforce record has limited value if another system continues to use an old list.
Step 8: Resolve conflicts conservatively
Duplicate Leads, converted records, multiple Contacts, shared phone numbers, and separate brand records can produce conflicting preferences. Route conflicts to a defined owner and use the organisation’s approved precedence rules.
Step 9: Test and audit the closed loop
Create test cases for clear refusals, temporary pauses, channel changes, number specific requests, unknown callers, record merges, and later preference changes. Measure whether the request reached Salesforce, whether suppression took effect, and whether any later call bypassed it.
Where AI helps and where it should stop
AI is useful for finding preference language at scale. It can locate relevant transcript passages, suggest a category, identify a date, create a review task, and alert an owner.
It should not decide the legal meaning of every statement by itself.
Consider the difference between these examples:
-
“Stop calling me.”
-
“Do not call this mobile. Use my office number.”
-
“I cannot talk this month. Try me in January.”
-
“Do not call about upgrades, but contact me if the service is affected.”
-
“I never asked to be added to this campaign.”
The first may appear absolute. The others contain limits involving a contact point, time, purpose, or source. Tone and sentiment alone cannot resolve those limits reliably.
The responsible pattern is to keep three layers separate:
-
Source evidence: what the person said.
-
Suggested interpretation: what AI or the rep believes the request means.
-
Confirmed Salesforce status: the preference approved under the organisation’s process.
Why outbound AI makes this more urgent
Outbound systems can now start more conversations with less manual effort. That increases the value of a clean preference check before every call.
Speed is useful only when the underlying decision is current. An AI agent that can call within seconds can also repeat an unwanted contact within seconds if the last mobile conversation never reached Salesforce.
This is why communication preference capture belongs upstream of campaign execution. The organisation needs a reliable source event, a trusted identity match, a governed consent decision, and a shared suppression path before it scales outreach.
How RocketCell fits into the workflow
RocketCell is built for Salesforce teams whose customer conversations happen through ordinary business mobile calling.
Users make normal cellular calls through a RocketCell business line. After a completed call, the activity is logged in Salesforce and can include the matched record, recording, transcript, summary, and suggested next actions according to the customer’s configuration and policy.
For communication preferences, RocketCell’s role is the capture layer. It helps the organisation preserve the mobile conversation that may contain a stop request, a channel change, a timing preference, or a number correction.
The customer still decides its consent model, legal basis, access rules, review process, suppression logic, and downstream integrations. RocketCell should not be treated as legal advice or as an automatic consent authority.
Questions to answer before rollout
-
Which phrases should create an immediate hold on phone outreach?
-
Who confirms an ambiguous request?
-
Is the Do Not Call field sufficient, or does the business need channel, contact point, purpose, and brand level consent?
-
How are unknown callers and duplicate records handled?
-
Which systems must receive the updated preference?
-
How quickly must suppression take effect?
-
What happens when a person later changes their preference?
-
Which users can hear recordings, read transcripts, and edit consent records?
-
How will the team test that human diallers, campaign tools, outsourced providers, and AI agents all respect the same decision?
-
What evidence will be kept to show when, how, and through which channel the request was received?
The Information Commissioner’s Office publishes guidance for UK organisations on electronic and telephone marketing. Organisations operating elsewhere should obtain advice for the countries and customer types they serve.
Frequently asked questions
Does Salesforce have a Do Not Call field?
Yes. Salesforce provides a Do Not Call option for Leads and Contacts. Organisations with more complex requirements can also use the wider consent data model to represent preferences by channel, contact point, purpose, and brand.
Should a transcript automatically update Do Not Call?
Not in every case. A transcript can provide useful source evidence, but identity errors, transcription errors, and ambiguous language can change the meaning. Clear requests may justify an immediate operational hold, while the final record update follows the organisation’s approved process.
What if the customer says to call later?
Record the timing request precisely. A temporary pause should not automatically become a permanent refusal, and it should not be reduced to a generic follow up note that another campaign cannot see.
What if the customer prefers email?
Treat that as a channel specific preference. Record the restriction on phone outreach and the permitted alternative only after confirming the person, purpose, and scope.
Can an AI agent rely on the Salesforce field alone?
It can use an approved Salesforce preference as an important control, but the organisation should also test duplicate records, stale campaign lists, external systems, and conflict rules. One correct field does not guarantee that every calling path will consult it.
Is call recording required to capture a preference?
No. A call event and governed user confirmation can support a preference workflow. Where recording and transcription are used, they can provide stronger source context, subject to the organisation’s policy, configuration, and applicable law.
Make the request visible before the next call
A do not call request is not merely a sentence in a conversation. It is an instruction that must move from the customer’s words into the systems that control future contact.
For mobile teams, the first challenge is visibility. Salesforce cannot respect a request it never receives, and an outbound system cannot check a preference that remains in one rep’s memory.
RocketCell helps capture ordinary business mobile conversations in Salesforce so preference changes can enter a governed review and suppression process. The result is not just a better call note. It is a clearer connection between what the customer said and what the organisation does next.