SMS Technical Deep Dive

The latest edition of the Technical Marketers Monthly Meeting was all about email deliverability. Kevin Ryan, Product Manager at Salesforce for SMS took us through three product areas he and his team are responsible for: Mobile Connect, Journey Builder SMS Activity, and SMS APIs. You can catch the session in its entirety via this recording link. Below are five key points from the session as outlined in Guilda’s post on Twitter.

You can access the recording by using the registration link in the Tweet above

One thing I learned from this session is that content is not shared between Mobile Connect and SMS Activities in Journey Builder. Each app has its own content store. Mobile Connect manages its content while SMS Activities relies on Content Builder for its content.

QRG = Quick Reference Guide for Mobile terminology
Short Message Service (SMS) is the most common form of text messaging
Multimedia Messaging Service
Mobile Terminated (MT) are outbound mobile messages sent to your customers/subscribers
Mobile Originated (MO) are inbound mobile messages sent by customers/subscribers
Delivery Receipts (DLR) only let you know whether a message was delivered, it does not confirm that it was read
Application-to-Person (A2P) messaging is where a person receives messages from an application – IN scope in this post
Person-to-Person (P2P) messaging is where a person receives messages from another person – Out of scope in this post

SMS Messaging and Value Chain Process – Image from presentation

What’s required to send SMS from Marketing Cloud?

There are three attributes the are required to deliver SMS messages from Marketing, they are:

1. Subscriber Key
2. Mobile number
3. Locale (Country)

The Locale value is inferred when using the contact model. You can use a Data Extension (DE) too, but you must include the appropriate, 5 alphanumeric locale (country code) in order to send from the DE, said Kevin. I’ve reference a number of resources for this topic in the Resources section at the bottom.

Do I Have Permission?

May I vs. Can I? Just because you (technically) can, doesn’t mean you should send SMS without explicit opt-in (permission) from the recipient. Otherwise, you come off looking like this…

Source: Gifer

Subscriptions live at a code and keyword level. What this means is that when inbound mobile messages sent by customers/subscribers are received, Marketing Cloud will first match to account (MID) that is associated with that code. Second, it will route to the keyword owner, which is at the Business Unit level. Several more checks and validations are applied to ensure that wishes of the person sending the SMS are respected and handled appropriately. For a deeper look at this process, you should look slides 21-22 and/or watch the recording around the 21 minute mark.

Inbound Messaging Outline as shown on slide 22

Summary

Kevin included a lot of good, easy to digest examples and use cases for leveraging MobileConnect, including many tips, tricks, and sample code. In addition to the excellent information shared in this session, I’ve added a few more to supplement it, below. Hope you enjoy(ed) the session as much as I did. Additional resources, including the recording and slides, as well as a number of other SMS related resources, are linked below.

Resources

SMS Technical Deep Dive session recording (56 minutes)
SMS Technical Deep Dive session slides (downloadable PDF)
SMS Subscription Management (B2C Marketer Group London recording)
Mobile Messaging Strategies (Trailhead module)
Mobile Contact Management (Trailhead module)
SMS Messaging with MobileConnect (Trailhead module)
Digital Engagement SMS Messaging Reference (Salesforce Knowledge Article)
Mobile Concepts and Definitions (Salesforce Knowledge Article)
What is P2P and A2P messaging? (Twilio Support Article)
Mobile Keywords and Codes (Salesforce Help Doc)
MobileConnect Guides for SMS Sending (Salesforce Help Doc)
Valid Locales for Data Extension Sends (Salesforce Help Doc)
Data Extension Sends (Salesforce Help Doc)
ISO 3166 COUNTRY CODES (International Organization for Standardization)

Babyforce 2.0

I cannot take credit for the original idea, that honor goes to Brian Kwong, aka The Wizard. His version was born in a browser before Salesforce1 (S1) and Publisher Actions (did I get it right Shannon?) were introduced. So when my youngest was born, I built Babyforce 2.0 as way to pass the time during those late nights and amuse myself by building an app my wife could easily use to track diaper changes and baby wipes. Easy, right?

Actually, yes it is. That’s the beauty of S1, anyone can build an app, no code required! In my case I had several objectives:

  1. Had to be short and sweet – no way I’m getting Wifey to use this if it’s hard
  2. Had to include only the essentials – no need to get fancy
  3. Had to be measurable – how else would I justify my experiment?

After few minutes, Babyforce was mobile! Over the first month, my lovely wife amused me by participating in my little experiment. We collectively tracked 357 “transactions” and broke them down few different ways. I give you the BabyDash!

Salesforce DashboardHere a couple of screenshots in Salesforce1 including a couple reports and the Publisher Action used to track each change.

Salesforce1 Report View

Salesforce1 Publisher Action

It was a fun way to brush up on the functionality of Salesforce1 and did not take long to create. Safe Harbor, Brian is working on Toddlerforce 1.0. Stay tuned!