Clarify that hard bounces are actionable

[adriannelee]

Description

As a Sender, I need to know how to prevent hard bounces repeating so that I can reduce the chance that my service will be suspended.

WHY are we building? Participants during testing didn't understand there was a subset of failures that they should act on and that this subset influenced whether they are suspended. This means that when we suspend clients, it can feel unjustified.

WHAT are we building?

• Perhaps a new label for "Problem email addresses"
• Actionability baked into the error messages, even for teams that already have a process to manage distribution lists
• Re-designed report screen filter and "Review address" column
• Increasing knowledge that tests are consequential (maybe within the API flow?)
• Make sure that the suspension email also clarifies that the suspension is due to factors the client has influence over

VALUE created by our solution

• Lower overall bounce rate

Documentation and Artifacts

Good docs, figma mockups, ADRs, screenshots etc.

Acceptance Criteria

To a client that doesn't know anything about the global bounce rate, when they monitor their failures, it's clear which ones are preventable next time they send.

• [ ] 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

• Error messages lacked actionability
• Many download the report but the 'Review address' column isn't included in the download. Regardless, this column & new filter was difficult to understand.
• Tests aren't considered consequential
• Need more certainty to remove or correct contact information
• Participants who already have a team process might be less likely to adapt a new process
• The feature is not discoverable because of clients' reliance on alerts for issues and because "problems" are synonymous to "failures"
• "Problems" were not understood to be issues that can be actioned on
• There are barriers to adaption
• Suspension email worked well but its success relies on clients understanding that "problems" are actionable
• 'Why’ we need clients to manage their distribution lists is understandable. But the feature lacks value because it’s not understood.

QA Steps

• [ ] Tested in a realistic production scenario

[yaelberger-commits]

LGTM @adriannelee

[andrewleith]

Part of this work could be to update the existing guidance page to add a table of "problem email address" statuses, what they mean, and possible actions a user can take to fix them. The guidance page has most of this content already, but re-organizing it in a more tabular format that is action-oriented may be useful. cc: @YedidaZalik

[YedidaZalik]

Discussed with @yaelberger-commits. System status page takes priority and content can work on this once that is finished.

[yaelberger-commits]

Hey team! Please add your planning poker estimate with Zenhub @amazingphilippe @YedidaZalik