Mass texting improvements

[maybejustmaybe]

Mass texting has proven useful for numerous applications; however, the processing of sending a mass test is still quite manual and error prone. We should add some tooling and guardrails around mass texting to enable a self-service model for working groups while avoiding common pitfalls.

My general idea here is that we build a 100% airtable flow for sending out mass texts. We'd use the neighbor profiles table to select folks to reach out to, and a new mass texting table to create "campaigns". A campaign corresponds to a mass text that gets sent out to some number of neighbors, where a neighbor can only be part of one mass texting campaign at a time. On the backend there would be one set of functions for managing campaigns (e.g. assigning neighbors to a campaign), and another function that sends mass texts for in progress campaigns.

Guardrails:

• Cancelation and sending window: it is very easy to overestimate your capacity and reach out to too many neighbors. We can use a "sending window" to send the messages over an extended period of time, likely days, and cancelation to end a campaign before all of the messages have been sent.
• Sending delay: don't start sending messages for a campaign until the campaign has been in progress for > sending delay
• Opt out: allow intake volunteers to mark neighbors as Does not want texts to ensure that they aren't aded to campaigns in the future
• One neighbor per campaign: we only want to use one number for mass texting. As such, we don't want to send texts from two different in progress campaigns to the same neighbor.
• Monitoring/notifications for unanswered mass texting convos (useful if a neighbor reaches back after the campaign is over)
• Exclude neighbors with open tickets: we want avoid fielding questions about deliveries in our mass texting system, so lets automatically exclude folks with open tickets (could be toggled with a field in the campaigns table)

Components:

• [ ] Add a Does not want texts? and Has open ticket? (derived) column to the neighbor profiles table
• [ ] Add a Mass texting campaigns table
• [ ] Enforce strict permissions on the campaigns table (i.e. a set of approvers that have to review new campaigns)
• [ ] Add a poll functions for campaigns table (more on this below)
• [ ] Add a function for delayed sending of texts
• [ ] Monitoring/notifications

NOTE that we should only send messages between ~9am and ~8pm

Mass Texting Campaigns Suggested Schema:

• Status: Pending, In Progress, and Completed
• Message content (might need to be multiple fields for multi part messages, validate that message is <160 chars)
• Total number of neighbors to message
• Sending delay (e.g. 10 minutes, to prevent folks from accidentally sending out a text)
• Sending window (e.g. 3 days)
• Neighbors messaged (links to neighbor profiles, deduping profiles with the same phone number)

Depends on #24

[Chrysaora]

This would be AMAZING. Some quick thoughts/questions:

• Instead of "Does not want texts"—maybe "Wants texts"? And then we can opt people in when engaging with them around grocery deliveries, for example?
• For "total number of neighbors to message": would we choose randomly within the campaign if the number specified is smaller than the total number, or provide some other filtering method?
• Are there any knowledge/skill bottlenecks this new model preserves? (for example: getting people sign ons to Twilio??) Totally fine if there are, but might be helpful to name so we can plan accordingly.

[cubeghost]

This sounds interesting! Here mostly to brain dump.

First, the script I've been using to send texts: https://github.com/bedstuystrong/firebase-functions/blob/ab/phone-number-api/functions/scripts/send-mass-text-2.js This one has an interactive CLI prompt, confirmation steps, and has a cancellable timeout. It stores some metadata about our "contacts" in the Phone Numbers table of the primary Airtable base- phone number type (from Twilio's lookup API) and human-added tags ("do not contact" etc). This is pretty similar to the neighbor profiles concept, but doesn't attempt to associate a name with a phone number.

Some notes on Twilio pricing. Currently, mass texting costs us around $0.015/text. For the past two campaigns we were a lot more careful with who we texted, and sent messages to about 1000-1500 contacts. In October, when we ran 3 really aggressive campaigns, we spent $200 total just on outbound texts. Because we have a 10 digit number (as opposed to a 5 digit shortcode), we'll probably soon face some new fees for certain carriers as they attempt to regulate SMS spam (unless we can find a way to register as a business with Twilio– I need to open a support ticket w/ them).

• Monitoring/notifications for unanswered mass texting convos

This would be huge, I've already wanted to add some automation around Twilio Flex tasks and workers (i.e. automatically setting new workers to have a larger task capacity) but haven't had time. This all goes through TaskRouter.

• Message content (might need to be multiple fields for multi part messages, validate that message is <160 chars)

Right now we don't attempt to send multi-part messages because I haven't been able to verify that sending multiple Notify messages to the same number will send them in the correct order. A useful validation would be whether or not the message encoding conforms to GSM-7 or not like this tool does. Non-GSM segments are much shorter than the 160 characters per GSM segment (modern phones will join the segments automatically anyway but for older phones I don't like to send more than 2 segments).

To answer a specific part of @Chrysaora's question: the main reason Twilio Flex access is bottlenecked right now is because I have to manually enable multitasking when each person joins– if we add automation to handle that it won't be a problem any more :)

Overall, my only general concern is that by making this so self-service, we open back up the possibility that neighbors will end up oversaturated with messages, especially when they haven't opted in. I honestly think some oversight (maybe owned by comms?) might be warranted with such a powerful tool.