The ability to upload spreadsheets of subscribers helps Revere Mobile stay integrated even if an organization’s CRM is not one that can send data to the system automatically. But a frequent occurrence is that someone might have a list of every phone number that has given permission to receive texts, rather than an updated, constantly-changing list. This can make it a challenge to ensure that we do not re-add anyone who has opted out of the program and to make sure that welcome messages go out only to the people who need them.
Creating a staging list and a migration flow ensures that you can deal with both of these challenges at once. Programs that do frequent uploads can reuse the staging list and migration flow as often as necessary.
The staging list is a safe list to upload subscribers to and should never be broadcasted to. There is no setting or any way to prevent it from receiving broadcasts, but it will not be visible to the client and program managers should always be aware that they are not to send messages to a staging list.
Create the staging list under your admin credentials (on the same shortcode as the program) and give it a name that ties it clearly to the program it’s meant to feed. As an example, if your client is the Shoemakers of America, their subscription list should be called “Shoemakers subscribers” and their staging list should be “Shoemakers staging list”. Because you created it under your admin credentials, only a Revolution Messaging staffer will be able to see it.
The Migration flow does the heavy lifting of assigning subscribers to the correct subscription list and welcoming only the people who need a welcome message.
This should also be created on the program’s own shortcode while under your admin credentials. It will look much like the standard subscription flow for that program, except you will leave the “Already Subscribed” portion of the subscription component unchecked. Include any Tag Metadata components that you would include in any other subscription flow, but do not include any outbound messages except for the subscription message.
Uploading and Migrating
Now that you have the staging list and migration flow, when you receive a list to upload, go through the normal procedure of uploading, but upload to the staging list and not to your subscription list (with this system, it’s safest to simply never upload to a subscription list).
Once the list is fully uploaded, you will need to broadcast the migration flow to the staging list. The broadcast will show as going to the entire staging list, but because the “already subscribed” component of the migration flow is unchecked, anyone who is already on the subscription list will not receive a message.
This process works because people who have texted in a STOP keyword are removed from all lists on that shortcode and are blocked from ever being uploaded into the system again, therefore even if they are in the spreadsheet to be uploaded, they will not be added back. The migration flow will only send messages to people in the broadcast audience who aren’t on the subscription list, so no one will receive a second welcome message as a result of the migration.
Someone who is removed from the subscription list manually (as a result of an inbox check, for example) will not be blocked from being re-uploaded into the staging list and will therefore become subscribed to the subscription list again as a result of this. Whenever possible, subscribers who would like to get off a list should be encouraged to reply STOP themselves to avoid this happening.