"FLLR helped us turn TCPA from a risk discussion into an operational system."
A multi-location healthcare services organization operating across the United States found itself at a familiar crossroads. Growth had accelerated, digital acquisition channels were expanding, and SMS had become a critical engagement tool. But behind the scenes, consent management had not kept pace.
Like many organizations navigating state-level privacy laws and TCPA requirements, consent lived in too many places. Preferences were inconsistent, propagation across systems was unreliable, and internal teams lacked confidence that outreach aligned with how and when patients had actually opted in.
They engaged our team to change that. Not by adding more tooling, but by designing a consent architecture that could finally operate at scale.
The Challenge
The organization's core challenge was TCPA compliance at the operational level. Consent data existed, but it was fragmented and brittle.
No Global Preference Center
- Three different preference center concepts had been explored internally, but none had made it to launch
- Each attempt stalled under the weight of competing business requirements, technical uncertainty, and a lack of clear ownership
Inconsistent Consent Propagation
- Consent signals were not consistently propagated between systems
- Sales teams, marketing teams, and call center operations were often working from different interpretations of the same customer record
- Salesforce Sales Cloud and Salesforce Marketing Cloud both depended on consent data, but neither could reliably act as a source of truth
Operational Risk
- The pressure came from US state compliance and the growing complexity of TCPA and "mini-TCPA" enforcement
- The risk was not theoretical—it showed up in slowed campaigns, manual list scrubbing, and recurring internal debates about whether a given outreach was defensible
The Missing Piece
- The organization already had strong platforms in place
- What was missing was how those platforms were designed to work together
Our Approach
We were brought in to architect a consent system of record using OneTrust Consent and Preference Management. The goal was straightforward but non-trivial. One place to determine consent. Every downstream system aligned to it.
From the outset, this was treated as an enterprise architecture initiative, not a marketing configuration. Executive sponsorship extended from the CIO down, and participation spanned business stakeholders, legal, call center leadership, product teams, and technical owners across Salesforce and messaging platforms.
We started with a reality check. A rapid audit of how consent was currently being captured, stored, overwritten, and ignored across systems. This surfaced predictable gaps between what teams believed was happening and what was actually happening in production.
From there, we focused on design before configuration. That meant defining consent semantics that could hold up under TCPA scrutiny. What constitutes express written consent in this environment. How revocation should behave. Which system is authoritative when conflicts arise.
Implementation
Global Preference Center
First, we designed and launched a true global preference center using OneTrust. This was not a cosmetic front end. It was built to serve as the system of record for consent and communication preferences across channels.
Salesforce Integration
Next, we architected consent flows into Salesforce Sales Cloud and Salesforce Marketing Cloud. Consent status, timestamps, and source metadata were standardized and mapped so that downstream teams could act with confidence. The bottom line was that Salesforce no longer had to guess.
Attentive SMS Integration
Midway through the project, Attentive was introduced to improve SMS opt-in rates from the website. Rather than bolting it on, we integrated Attentive directly into the same consent architecture. Website opt-ins flowed into OneTrust, were validated against defined consent logic, and then propagated cleanly to Salesforce and messaging workflows.
Cross-Functional Alignment
Throughout implementation, we facilitated working sessions that brought together teams who rarely shared the same room. Call center leaders could see how marketing consent decisions impacted outbound calls. Product teams understood how small UX choices affected TCPA defensibility. These alignment moments were as critical as the technical work.
Scale
In total, the system was designed to process and manage consent for approximately 20 million data subjects, with consistency and auditability as non-negotiables.
Results
Consent Source of Truth
- Before: Fragmented across multiple systems; three failed preference center attempts
- After: OneTrust as single system of record for consent
Salesforce Operations
- Before: Teams working from different interpretations of customer records
- After: Standardized consent status, timestamps, and source metadata with full clarity
Campaign Execution
- Before: Slowed by manual list scrubbing and internal debates over defensibility
- After: Faster launches with fewer internal checkpoints; consent logic no longer ambiguous
TCPA Compliance
- Before: Recurring risk discussion
- After: Embedded operational control teams can point to
SMS Opt-In
- Before: N/A
- After: Attentive integrated into consent architecture, improving performance without adding compliance risk
Conclusion
This engagement reinforced a pattern we are seeing across regulated industries. TCPA compliance is not solved by policies or point solutions. It is solved by operational design.
By treating consent as enterprise data and OneTrust as infrastructure rather than a checkbox tool, this organization built a system that scales with growth, withstands scrutiny, and enables the business rather than slowing it down.
If your team is still debating consent instead of operationalizing it, that is the moment to step back and rethink the architecture. We are seeing what actually works, and it starts with a single source of truth.
