0

I have been banging my head against the wall for a month now. The keyword functionality in SFMC is really under par.

Our plan is to have different keyword for different type of communication. For example one for marketing and one for surveys. First of all, it is not possible to connect a STOP-keyword to a keyword which the contact is opted in to. What this means is that when a contact reply the STOP-keyword, you are unsubscribed from all keywords. This I solved by opting the contact back in to the keywords the contact didn't unsubscribe from.

With this, the next problem surfaced. If the contact is added to multiple keywords and opted out from one of them. SMS sent to the keyword the contact is opted out from, still goes through. So this plan failed all together.

Has anyone had a similar use case and how did you solve it? Would additional long codes solve it? My fear is that if we get more long codes. Opting out of one of them would mean you get opted out from all of them.

1

Would additional long codes solve it?

Yes, having one keyword per long code would solve this issue - I tested this and using the STOP keyword functionality opts you of all keyword located under the long code that you sent the message to (keywords on other long codes are not affected).

Alternatively you could work around this:

  • Journey Builder configuration for SMS sends that respects opt-outs with multiple keywords under one long code (it's strange)

  • Introduce new keywords (but not custom STOP keywords) that trigger text messages (of the Text Response type) that writes data extension records for an automation that unsubscribes people from specific keywords with import definitions, but they're also quirky in their behavior (and the unsubscribe is not instant as it has to wait for the automation to run)

  • When somebody would send one of the default STOP keywords (STOP, QUIT, CANCEL, END, and UNSUBSCRIBE) they would still be removed from all keywords under that long code

2
  • Thanks for your answer. As you can see I also posted an answer to that thread. When it comes to one time send outs. The behavior works differently. In the one time send outs, the behavior is the same regardless of which option you choose. In the end, I think different long codes is the way to go. Apr 7 '20 at 13:51
  • Oh, sorry, missed your username there. Yeah, the separate long code solution might be actually the safest to implement. Apr 7 '20 at 13:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.