Public site sets expectations about daily limits

[adriannelee]

Description

As a potential client, I need to be able to understand the max numbers of emails and text messages I can send with Notify so that I can decide to use Notify or not.

WHY are we building?

• We'll need to provide education about limits upon/before account creation to increase awareness so that this is information that they look out for when they send messages.

WHAT are we building?

• Updates to the public site (unauthenticated) to better communicate that there are daily limits (how many emails, SMS, and how many characters within templates)

VALUE created by our solution

• Better likelihood that Senders have the right expectation when creating an account and using GC Notify. This prevents disappointment and wasted time for Senders.
• Fewer support tickets asking about this from people who don't have an account

Documentation and Artifacts

https://docs.google.com/document/d/1NunyGV_vldNeYR3HuhjW2HORNtqIxWQdn7aeFp4W2sk/edit

Acceptance Criteria

When a public servant is trying to evaluate whether GC Notify will be useful for them, they can confirm this information without creating an account or contacting support.

• [ ] Generate appropriate log messages so that executions of this feature can be tracked

• [ ] Can misuse of this feature cause harm? If yes, create an alert

• [ ] Update the status of related findings, insights, and hypotheses on the Research Airtable

• [ ] Once change/fix/feature is implemented, link relevant Airtable records to design artifacts (Figma)

• A11y

• Bilingualism

• Privacy considerations

• Security controls in place

• Measuring success and metrics

Related Research Airtable records

• Daily limits is a blocker they would like to prevent
• None of the participants considered daily limits as part of their sending process.

QA Steps

• [ ] Tested in a realistic production scenario

GC Articles Publish checklist

• [ ] Supporting feature is released and unflagged
• [ ] Create or update slug
• [ ] Page content and slug is translated
• [ ] Document links to and from the page
• [ ] Add page slug and title to inventory
• [ ] If new page, add WAF rule
• [ ] Create new page or update existing page content
• [ ] Create or update translation to the page
• [ ] Link translations by choosing an assigned translation
• [ ] If new page, save as draft
• [ ] If existing page, update the page
• [ ] Post page in Slack for last minute reviews
• [ ] On staging: Clear the cache through GC Notify's admin panel
• [ ] On staging: Check links, images and language toggle
• [ ] Give a heads up to the app-team channel once ready to publish
• [ ] On staging and production: Clear the cache through GC Notify's admin panel
• [ ] Clear Cloudfront cache in GCA as needed (Andrew and Phil are GCA admins)

[yaelberger-commits]

I would recommend we try making these changes on the "Features" page as a start