ActiveCampaign SMS 10DLC
Overview
ActiveCampaign is an omni-channel marketing automation platform. Our SMS channel is historically undervalued. In anticipation of a changing SMS regulatory landscape, my team kicked off this work to ensure that:
- our SMS features are legally compliant
- users don’t suffer from complexity introduced by SMS regulation
- our org is well-positioned to make long-term investments in SMS
What is A2P 10DLC?
- Short for “Application to Person 10-Digit Long Code”
- A2P 10DLC registration is part of an industry-wide push by carriers to regulate against fraudulent SMS practices and bad actors
- The industry goal is to reduce SMS spam and fraud for US-based consumers
- Our goal was to develop a low-friction in-platform registration experience to:
- Protect AC and its users from the financial impact of changing regulations
- Shield users from industry complexity while helping them remain compliant
- Avoid SMS service interruption and set the stage for further investment
‣
Scale of customer impact
- At the outset of the project, about 4,000 customer accounts (~2.5% of user base) were using SMS
- The financial implications of poor implementation here would have had an outsized negative impact on our business and on our customers’ bottom lines
‣
Success metrics
- Accounting for external dependencies, our goal was to reach a 90% registration success rate for new registrants within one month of release. One month following M1 release, we’d achieved a 94% success rate.
- We continued iterating until reaching a 99% success rate—there will always be some margin of error as users sometimes submit bad data.
‣
Financial implications
- Violations of new SMS content guidelines can result in a per-occurence fine of $10k
- This work categorizes players in the SMS space so that fees would be routed to the correct party, and not all absorbed by ActiveCampaign
- However, our goal is to create an SMS environment that educates users about compliance—not simply pass along fees
- By implementing native registration, we avoided indeterminate and theoretically capless financial detriment for ourselves and our customers
External partners
📱 Twilio: Third-party vendor providing our SMS infrastructure. While our customers automate flows around SMS inside our platform, we pass message content to Twilio for distribution. The design of our registration flow is heavily informed by our backend ties to Twilio.
⚖️ TCR: The Campaign Registry is an independent org that faciliates the registration of messaging vendors and their users, with the goal of creating an accountable SMS landscape. Both ActiveCampaign and Twilio shaped custom in-platform experiences based on the TCR’s guidance.
Because 10DLC represents an unprecedented push for SMS accountability, requirements were constantly in flux. And because of the high cost of penalties, small missteps in our experience could quickly translate to extremely expensive fees for ActiveCampaign and our customers. Constant collaboration and communication with our external partners was critical to our success.
Identifying requirements & documenting solutions
- In my ideal workflow, requirements gathering is a collaborative, cross-func process
- I worked with Product and Eng to identify needs, settle scope, and develop strategy
- This sort of collaboration unfolds across a variety of touchpoints and artifacts.
ℹ️ #1 → additional detail shared during live sessions
- The fidelity and specificity of these artifacts evolves alongside our discovery
ℹ️ #5 → additional detail shared during live sessions
Milestone 1 release
Let’s walk through the prototype →
👋 This link is made available during live sessions.
Goals for Milestone 1:
- Coordinate with external partners to understand reqs
- Implement a vendor-agnostic registration experience
- Coordinate with marketing to execute parallel outreach campaigns informing affected users
- Release M1 before industry-wide 10DLC enforcement, to avoid service interruptions for top 50 users
- Create an experience that shields users from industry complexity
Milestone 2 release
Let’s walk through the prototype →
👋 This link is made available during live sessions.
Goals for Milestone 2:
- Map benefits of registration to ActiveCampaign’s customer tiers; grant higher tiers access to greatest benefits
- Ensure regulatory compliance and a consistent experience for all ActiveCampaign customers
- Evaluate M1 registration data to identify root causes for registration errors; iterate to reduce error rates
- Develop mechanism to avoid service interruption for new registrants post-industry enforcement
- Reduces likelihood of non-compliance
- Takes decision off users’ plate
- Reduces time to value
- Allow higher tiered ActiveCampaign users to register additional campaign use-cases
- Improve the design and utility of the post-registration dashboard
Prototype iterations
ℹ️ #2 → Product design can be messy. Let’s take a look at a working file to provide a sense of how I like to iterate through feature work when faced with rapidly changing requirements.
👋 This link is made available during live sessions.
Looking to the future
This project’s release sets up ActiveCampaign for continued investment into the SMS channel. With 10DLC compliance in check, our team is exploring new and exciting improvements to our SMS offering, including:
- Improved error handling in 10DLC registration
- Leveraging APIs to auto-populate registration fields for new registrants
- Exciting new integrations between SMS and other platform channels
- Clearer visibility and more granular control of TCR sender profile
- and much more...
Key decisions and challenges
‣
Establishing vendor agnosticism
PM and I formed a hypothesis that our platform experience should be vendor-agnostic. We wanted to avoid hard-coding Twilio dependency in our platform. To do this:
- We avoided using Twilio’s nomenclature in the user-facing experience
- Our developers implemented data storage and handoff using a custom pooling mechanism rather than passing details directly into Twilio—allowing us to maintain customer details, ensuring that a decision by Twilio to end our partnership wouldn’t break the registration experience for our users
‣
Rapidly evolving, often opaque requirements
- This project was unique in that the parameters and behavior of our in-platform experience were dictated by external partners
- Guidance changed often, deadlines regularly shifted, and poor documentation from fourth-party dependencies threatened to translate to financial detriment for our users
- Our team developed opinionated, cautious approaches toward registration data collection and distribution; we pursued our own ambitious deadlines to execute before the rest of the industry
‣
Creating a system that accomodates current and future SMS users
ℹ️ #3 → additional detail shared during live sessions
- In addition to registration, we faced the challenge of needing to categorize users’ current SMS content. Then we’d pass it to third parties for compliance checks—without interrupting their ongoing message automations
- To do this, I worked with PM to develop a default use-case mechanism in which we’d categorize active content without interruption
- This solution shielded users from having to recreate their current automated messaging content just to comply with 10DLC regulations—as long as they completed registration, they were all set
Collaboration style
As with all product initiatives, I worked directly every day with PM and Engineering to accomplish this work. My style of cross-func collaboration is thorough. Some highlights about my work style include:
📝 Documentation is key
My design process involves a lot of reading and writing. Collaborative design is as much about strong documentation as it is about interaction design. I communicate with developers async through documentation to create a record of design iterations throughout the project lifecycle. For 10DLC in particular, this has meant creating numerous prototype walkthrough recordings for every major iteration of the experience. Documenting progress this way is helpful for other product designers, too. And artifacts like these are useful in pursuing stakeholder approval, testing solutions with users, and as a tool for gathering asynchronous design critique.
ℹ️ #4 → additional detail shared during live sessions
🗣 Consistent, flexible and async-friendly communication
Our team uses Jira as a source of truth for project progression. As such, I’m heavily involved in Jira. I believe it’s important for designers to meet developers where they are, so I never impose design tooling on my teammates unnecessarily. If design decisions ever feel like a windfall surprise to my developer counterparts, it means that I’ve dropped the ball—so I communicate progress consistently and always make myself available for ad hoc collaboration.
ℹ️ #6 → additional detail shared during live sessions
🤝 Collaboration at every step in the process
For me, there’s no substitute for being in the thick of problem-solving with a cross-functional team. Design should never feel like a siloed function. I stick with developers and product leaders throughout the full project lifecycle—starting with early discovery, and well past release. I join my more technical counterparts every day and participate in engineering ceremonies. This helps me design more well-rounded and realistic solutions, and helps engineers avoid confusion and rework.