Message parts to messages

[ccostino]

As a part of our pricing plan for partners, we're going to be adjusting the way we look at and calculate the sending of messages. Instead of calculating quotas and costs by message parts or fragments, we're going to shift to just calculating based on messages alone.

Note "message parts" may also appear in the UI as "usage"....

For the backend

• Quota & usage calculations should be based on just messages, not message parts

  • Pre-send quota checks
  • Quota values in database
  • Quota setting when service is created

• Maintain a record of message parts for our own accounting purposes

• Update default quota to 100,000 free messages from 250,000 message parts

For the frontend & docs

Should mention only messages and no message parts now:

• Review and update Send message flow
• Review and update Using Notify
• Review and update the Dashboard
• Message status, daily chart...
• Review and update Total messages chart on dashboard and usage.html with new data from backend #1543
• Review and update Onboarding materials
• #2304
• #2305
• #2306
• #2307
• #2312

For partnership & comms

• Update MOU and IAA to not use message parts anymore (updated; need final OGC/etc approvals)
• Let partners know this is coming & about the conversion
• Do we need to get partners on the new MOU or can we just roll them over progressively? (should be able to roll them over progressively)

[ccostino]

@stvnrlly this is the start of the messages parts to messages epic - please feel free to adjust with any other details you may have!

[ecayer]

Paging @CathyBeil and @dmvancura who may have thoughts on how to roll out this change... (feel free to add a comment or edit the description directly)

[CathyBeil]

@stvnrlly I'd like to discuss/confirm the 100k message-limit mentioned above. I'd thought we were going with 250k messages since even though the cost is doubled if all of those messages are used and use two message parts, it's still pretty low regardless, and, thus far, our free-tier partners' (other than Census, which will likely shift to paid anyhow) use cases use way less than 250k messages OR message parts in a year.

I'm open to having it at 100k, since based on their current use, this wouldn't impact current partner's services, but it would/could impact the addition of more use cases (which maybe is the point and maybe that's okay!) and could limit the market for additional free partnerships with local agencies (but again, maybe that's the point?) I do think it would obviously better to increase the limit rather than have to decrease it over time, so that's possibly another argument for the lower limit.

[ecayer]

Ooops, we had a second epic going briefly! The one additional note is that we will ideally also have some way to grant additional messages (in particular, one partner is already over their quota by the new calculation but not by the message parts calculation. According to the agreement they signed, they should still have a few left to experiment if they want).

[ecayer]

Open questions: does this include code or just content visible to users?
This is mostly about quotas & tracking... so yes, code changes to make sure we're getting the right info to display to the user

User-facing components to update:
Send flow
Dashboard
Documentation
Admin panel

[ecayer]

Answering "Decide if we want to give any visibililty into message parts at all (& do what we decide :) )" with a provisional "no" -- later we may want some site admin visibility.

[heyitsmebev]

Just adding a note for later regarding the usage page and bringing message parts into the platform admin instead.

https://gsa-tts.slack.com/archives/C0107UC0W1M/p1737671650055409

[dmvancura]

in a separate epic we could track the changes needed in the "platform admin" view changes (related to Bev's comment)