andrewleith
commented
2 years ago Just making a note of some of the investigation outcomes we may want to revisit outside of this work:
- Bulk API sending does not check daily limits, but the celery task that sends the notification does, resulting in the system correctly respecting the daily limits but API users not knowing the send didn't take place
- CSV sending through the the UI checks daily limits differently than UI one-off/API one-off/API bulk, which means two code paths to maintain and debug for daily limit checking
yaelberger-commits
SPIKE: How might we make senders aware before they go over their daily/annual text message limits?
Description
As a Notify sender, I need Notify to tell me how many message parts I'm about to send, before I send them, so that I can stay within my daily and annual SMS limits and keep to the SLA, and shorten my templates
or spread out my batches to send fewer SMS at a time.Notify should take care of batching for our clientsWHY are we building? Currently, Senders have no way of knowing how many actual text message parts they will be sending, or have sent from the template or the dashboard. Senders might go over their annual limits for SMS without realizing it because they think they're sending 1,000 SMS but they might actually be sending 4 message parts per template, or 4,000 SMS.
Notify admin can't enforce our SMS limits or prevent incidents if we are not making Senders aware how many SMS they are actually sending before they hit the Send button.
We're not building something for the API senders: API is tricky. Stopping a send might go unnoticed
WHAT are we building? An intervention or multiple interventions to let Senders know before they send a bulk SMS how many actual message parts they are sending.
An intervention or error message that stops a Sender from sending more message parts in a bulk SMS send than they are permitted to send within their daily and annual limits.
Show progress on annual limits on dashboard
VALUE created by our solution No senders going over their daily or annual limits Reduction in SMS-based incidents by 50%? Saving money by reducing # of SMS per service.
Senders will have a better understanding of how many text message parts they have sent or will be sending, and how many they have left before they run out of SMS sending capacity. Reduce frustration. This may nudge Senders along to send shorter, more concise text messages, improving recipient UX. Could prevent future SMS incidents when a Sender sends too many SMS per second, gets flagged by carriers as spam. Senders better understand the concept of sms parts, and ideal sms use cases (ie: not urgent bulk).
Acceptance Criteria** (Definition of done)
To be refined through discussion with the team
Each service can only send maximum of 100,000 SMS message parts per yearGiven a sender is preparing to send a text message or many text messages using Notify, when they call the API, prepare to send to one text message recipient phone number, or upload their CSV to send text messages, then they know before the messages are sent exactly how many message parts they will use up out of their quota and will be stopped from sending if they are going to go over their limits.
QA Steps