Resolve unsubscribe tickets without a MailForge login

Build me an app my support team opens to fix email subscription problems without ever logging into MailForge. It is a two pane working screen: a queue of relevant Zendesk tickets on the left, and the live MailForge state for that ticket's requester on the right. One person at a time, driven by an inbound support request.

Left pane, the ticket queue. Use the Zendesk Search Tickets operation with Zendesk query syntax to pull open and pending tickets about unsubscribes, unwanted email, and missing email (wording like unsubscribe, stop emails, remove me, too many emails, not receiving your emails, never got the email). Each row shows the ticket subject, its status, when it was last updated, and the requester's email address, which is the key to everything on the right. Resolve the requester to an email address using Zendesk Search Users, or Show User with the requester id on the ticket. Sort so the longest waiting tickets come first, and let me click a row to load it.

Right pane, the live MailForge state for that address. Three blocks. First, the contact record: call List Contacts with the email filter to get their name, status, and fields. If no contact exists for that address at all, say so plainly, because that changes the fix entirely. Second, list membership: call List Contact Lists to get every list in the organization with its subscriber counts, and cross reference against List Contacts filtered by list so I can see exactly which lists this person sits on. Third, suppression: call List Suppressions to check whether the address is on the suppression list and for what reason.

Put the suppression reason at the top of the right pane, large and impossible to miss, with a plain language explanation next to it, because a hard bounce needs a completely different answer than someone who clicked unsubscribe. A hard bounce means the mailbox rejected us and re-subscribing the same address will simply bounce again, so the customer needs to supply a working address. A spam complaint means they reported us and should generally stay suppressed. A manual unsubscribe means they chose to stop and can be re-subscribed if they are now asking to receive mail again. Shape the recommended fix around which of these it is, and never show the raw reason code on its own without that explanation.

From that same screen, let my agent take action on the address. Suppress it with Add Suppression so no future campaign reaches it. Lift a suppression with Remove Suppression when someone asks to start receiving mail again. Add them to a specific list with Add Contact to List, choosing which list from the ones already loaded. Subscribe a brand new address with Subscribe Contact when no contact record exists yet. Correct their name and other fields with Update Contact. Every one of these asks for confirmation first and shows exactly what is about to change.

Then close the loop on the ticket. After a change is applied, use Zendesk Update Ticket to post a reply and set the ticket status. Pre-fill the reply with the exact change that was just applied, written in plain customer facing language, and let me edit it before it sends. Support posting an internal note instead of a public reply when the change is not something the customer needs to read. Every applied change must end up written into the ticket one way or the other, so the ticket itself becomes the compliance trail.

Also keep an in-app log of every change applied through the app: the email address, what changed, which ticket it came from, who applied it, and when. The marketing ops owner occasionally audits what was changed, so give them a view they can scan and filter by date and by address, separate from the working queue.

Add a Read the thread button on each row that kicks off a background agent. The agent calls Zendesk List Ticket Comments to read the whole ticket conversation, checks the same MailForge state the right pane shows (List Contacts, List Contact Lists, List Suppressions), and decides whether this is a full unsubscribe, a single list opt out, or a deliverability complaint. It then writes back onto the row a recommended action, the reasoning behind it, and a draft reply. Its output lands on the row where the support agent can read it, edit it, and approve it.

Nothing is ever applied automatically. The embedded agent only recommends and drafts. A human clicks to apply every suppression, every lifted suppression, every list change, and every reply. Make that obvious in the interface so nobody assumes the agent already acted.

Who uses it: a support agent working the queue all day, and a marketing ops owner occasionally auditing what was changed. Design for the support agent first: the queue on the left and the answer on the right, with the suppression reason readable at a glance.