<aside>

tl;dr: Email delivery statuses and automatic unsubscribe behavior are inconsistent or unclear across Engage, Data Hygiene, CSV exports, and Help Center documentation. Users cannot reliably distinguish delivery failures from subscription changes or verify whether an automatic unsubscribe was justified.

What needs to be done:

  1. Define and document the statuses and current behavior. Clearly distinguish Invalid, Bounced, Soft bounced (temporary), Hard bounced (permanent), and Unsubscribed. Explain which status appears and what the system does in each scenario. Provide equivalent information for SMS.
  2. Align the product and documentation. Use consistent status names and definitions across Help Center documentation, Engage, Data Hygiene, filters, and CSV exports. Ensure filter options and exported data accurately reflect the displayed statuses.
  3. Make failures and subscription changes visible. Show the delivery-failure type, reason, date, resulting subscription status, and whether the user or the system changed it.
  4. Review and correct automatic unsubscribe behavior. Explain what justified the affected addresses’ hard-bounce classification. Temporary failures should not trigger automatic unsubscribes or be treated as permanent solely because three delivery attempts failed.

Impact on users (critical): Previously reachable email addresses were automatically unsubscribed after delivery failures. After investigation, we suspect some failures were temporary. Without the underlying reasons, users cannot verify the classification or confidently resolve affected contacts without time-consuming manual review.

Specific examples, supporting communications, and detailed requests are listed below.

</aside>


Original issue reported on August 28, 2027 :

Givebutter’s stated rule: only hard bounces automatically unsubscribe a contact.

What is unclear: The UI only shows “bounced.” It does not show whether the failure was temporary, a hard bounce, or an invalid address. “Hard bounce” is mentioned only in the Help Center and by Support, not as a visible status in the product.

What we observed in Engage: The Bounced filter shows bounced emails that remain subscribed. The Unsubscribed filter includes 4 bounced emails that were unsubscribed, plus 6 contacts whose status is Clicked. Without the bounce type or reason, users cannot tell whether the different treatment is expected.

Requested outcome: Show the delivery-status type, reason, date, and resulting subscription status.

Email delivery-status comparison

Type Givebutter says What we see Should happen
Invalid Invalid / undeliverable address Not separately identifiable Show reason → unsubscribe if permanent
Bounced
(temporary) Delivery failed; may be temporary Engage Bounced filter: bounced, still subscribed Keep subscribed → retry / show reason
Hard bounced
(permanent) Bad, missing, misspelled, or rejected address → auto-unsubscribe Engage Unsubscribed filter: 4 bounced emails; 6 Clicked contacts. Bounce type is hidden. Label Hard bounce (or invalid) → show reason + auto-unsubscribe
There is no “Hard bounce” Type under Status on UI. It only mentions in Help Center and mentioned by Support Team.
https://help.givebutter.com/en/articles/5768477-how-to-interpret-outbound-message-data

image.png

image.png

image.png

<aside> 💡

The main problem is not necessarily the hard-bounce rule itself. It is that users cannot see the classification and reason needed to understand why a contact was, or was not, automatically unsubscribed.

</aside>


Follow up communication shared on September 8, 2026

September 8, 2026 Follow up comments to Support and Engineering teams.

Bigger issue

This is what I understand from the Engineering team’s response and the Help Center information. I couldn’t draw a clean relationship tree because the logic/reasons and the statuses (in the UI) are inconsistent or unclear. I tried anyway, based on what’s available, but the result is messy because the system and the user-facing information are inconsistent.

https://canva.link/r51br32k3w2f7h3

Five Requests

  1. REQUEST 1: Explain what happens “currently” in each scenario (listed for email only).

    The database/table below should be editable. if you can’t, please go to this page:

    _Givebutter Engage error and status [db]