Brevo list health check before every marketing send

Build me an app that my marketing ops person opens before every send, to check that our Brevo lists are not putting our sending reputation at risk. It is a list level triage console: the risk scoring and the actual cleanup both happen inside the app.

The home view is a list health table. Use Brevo List Contact Lists to get every contact list, and Get List Details for each one to pull its subscriber count and list level statistics. For each list, calculate hard bounce, soft bounce, unsubscribe and complaint rates over the last 90 days: use List Email Campaigns to find the campaigns sent to that list and read their statistics, and use Get Email Event Reports over the same 90 day window to count the individual hard bounce, soft bounce, unsubscribe and complaint events attributable to that list. Render one row per list showing the list name, the subscriber count, and then the four rates side by side. Sort the table worst first using a combined risk score that weights hard bounces most heavily. Show a red flag on any row where a rate crosses its threshold, and make the offending cell itself visibly red so it is obvious which metric caused the flag.

Thresholds are configurable by the user and must persist between sessions. Give me a settings area where I can set a threshold per metric, with sensible defaults to start from (roughly 2 percent hard bounce, 5 percent soft bounce, 0.5 percent unsubscribe, 0.1 percent complaint). Also let me change the 90 day reporting window. Show the current thresholds somewhere on the home view so it is always clear what the red flags are measured against.

Clicking a list row opens a triage pane for that list. Populate it with the list's problem contacts using List Contacts scoped to that list, and use Get Contact to pull the detail for contacts as they are inspected, including bounce history, existing blocklist status and last engagement. Label each contact with the reason it is a problem, such as hard bounced, repeatedly soft bounced, complained, or never opened in the window. Every contact row has a checkbox so I can select many at once, with a select all for each reason group.

With contacts ticked, I can take one of four actions. Send a re-engagement email using Send Transactional Email. Blocklist them using Update Contact to set their blacklist status. Take them off this one list only using Remove Contacts from List. Or delete them entirely using Delete Contact. Show the selected count on each action button.

Bake in two rules. First, nothing destructive happens without a confirm step showing exact counts. Blocklisting, removing from a list and deleting must each open a confirmation that states precisely how many contacts are affected, names the list involved, and describes what will change, with an explicit confirm to proceed. Never fire a destructive action straight from a single click, and never silently expand the selection. Second, re-engagement is always offered before removal. When I choose to blocklist, remove or delete, the confirm step must tell me how many of the selected contacts have not yet been sent a re-engagement email, and present re-engaging them as the recommended alternative alongside the destructive action. The reason matters and should be visible in the UI: Brevo automatically blocklists hard bounces only after the damage is done, and a high hard bounce rate can get an entire account suspended, so the app exists to catch this before a send rather than after.

Every removal is appended to a Google Sheets audit tab using Append Values, so we can prove what we cleaned and when. Write one row per affected contact with the timestamp, the list name, the contact email, the action taken (blocklisted, removed from list, or deleted), the reason it was flagged, and the metric value that triggered the flag.

When I finish a session, post a one paragraph summary to our marketing channel using Slack Bot Send a Message. The summary should say which lists were reviewed, how many contacts were re-engaged, blocklisted, removed and deleted, and which lists are still above threshold and should not be mailed yet.

Keep the home table fast to scan, since it is the thing I look at before every send. Handle large lists with pagination in the triage pane, and show a clear loading state while the 90 day statistics are being assembled, because that is the slowest part of the app.