Which SendGrid Delivery Failures Turned Into Support Tickets

A lifecycle marketing manager and a support lead are on a call on a Tuesday morning. The support lead shares her screen first: Zendesk, a view filtered to tickets created in the last seven days, sorted by newest. She scrolls. "I didn't get the receipt." "Password reset never arrived, tried three times." "Is my account suspended? Nothing since Thursday." Fourteen of them, maybe more, scattered across three different forms and two email aliases, none tagged in any consistent way because the agents who took them were solving each one individually, not counting them.

Then the marketing manager shares hers: SendGrid Activity Feed, filtered to the same seven days, dropped and bounced events only. There were 3,142 of them. Most are the ordinary churn of a large list, addresses that stopped existing months ago. But somewhere in that 3,142 are the fourteen people who cared enough to open a ticket, and probably another two hundred who cared and didn't.

The question on the call is not "how is deliverability." It is narrower and more useful: of the failures we had last week, which ones actually cost us a support conversation, and is there a pattern in them. Because if the fourteen tickets all trace back to one receiving domain, that is a two hour fix. If they trace back to one template that started tripping spam filters, that is a different two hour fix. And if they are just fourteen unrelated people, the honest answer is to stop worrying about it and go do something else.

Neither screen answers that. Both screens are correct.

What SendGrid shows, and where it stops

SendGrid is genuinely good at the record side of this. The Activity Feed gives you per-message events with timestamps: processed, delivered, deferred, bounced, dropped, spam report, and the SMTP response the receiving server sent back. You can filter by recipient address, by subject line, by category, and search a specific address to see everything that was ever attempted to it. The Suppressions lists tell you exactly why an address stopped receiving mail, whether it was a hard bounce, an unsubscribe, a spam complaint, or a manual block. Bounce classification separates invalid addresses from reputation blocks from content rejections. The Event Webhook will push all of this to your own endpoint in near real time, and the Email Activity API lets you pull it back out for a window of history depending on your plan.

So SendGrid can tell you, with precision, that mail to j.okafor@example.co.uk was blocked on Thursday at 14:02 with a 550 response citing a reputation block, and that the same domain rejected 340 other messages in the same hour.

Where it stops is human reaction. SendGrid sees the SMTP conversation between your sending infrastructure and the receiving server. It has no visibility into what happened next inside the recipient's head or inbox. It cannot know that Jane waited two days, assumed her subscription had lapsed, and wrote to your support team. It cannot know that of the 340 people on that blocked domain, three wrote in and 337 shrugged. Nothing in the SendGrid data model has a field for that, and reasonably so, because that event happened on a completely different system.

What Zendesk shows, and where it stops

Zendesk is equally good at the other half. Every ticket carries a requester, a created timestamp, a channel, a status, an assignee, and the full comment thread. You can build a view of tickets in a date range, filter by tag or form or group, and search the ticket body text. Explore will happily chart ticket volume by tag over time, first reply time by group, and satisfaction by agent. If your agents tagged consistently, you can pull "every ticket tagged email_not_received in July" in about ninety seconds.

Where it stops is the underlying cause. Zendesk knows Jane wrote in. It does not know that mail to her domain was being reputation blocked, because nothing about that fact ever entered Zendesk. The ticket says "I never got my reset link," which is a description of an absence. The evidence that explains the absence lives in a different product, under a different login, keyed by an email address that may not even be the address on Jane's Zendesk profile if she wrote in from her phone.

And there is the tagging problem, which is not a Zendesk failing so much as a fact about how support actually works. Agents tag when the taxonomy is obvious and there is time. A ticket that says "is my account suspended" gets tagged billing by a reasonable person, because that is what the customer appeared to be asking. It was a delivery failure. It will never show up in your email_not_received count.

Why the gap is structural, not a missing report

Look at what each half of the evidence actually is.

One side is a record. The other side is prose. That asymmetry is why this is not a feature either vendor forgot to build, and it is also why the usual tools around them do not close it either.

Automation platforms like Zapier and Make are excellent at what they are built for, and they are trigger based: something happens, and they move a record forward. You can absolutely have Make watch the SendGrid Event Webhook and open a Zendesk ticket on a hard bounce, and plenty of teams do. But a trigger fires forward in time. It cannot be pointed at last week and asked what already happened, because the moment to act on those events has passed and no record of the join was written down while it was passing. Asking a trigger based system a retrospective question is asking it to do the one thing its architecture does not do.

BI tools have the opposite constraint. Power BI Copilot and Looker Conversational Analytics both handle natural language over data well. But they read databases and modelled sources: tables, semantic layers, defined measures. Ticket volume by tag lands in that world cleanly. The sentence "I never got my reset link, tried three times since Thursday" does not, because the meaning of it was never modelled into a column. You could stand up a pipeline that classifies ticket bodies into a delivery-failure flag and feeds that column to the warehouse, and if this question were a permanent part of your reporting, you probably should. For a question you ask once a quarter, that is a project, not an answer.

What the join actually requires

The key is the email address, and it is a weaker key than it looks. The SendGrid event is keyed to the address the message was sent to, which came from your application database. The Zendesk ticket is keyed to the requester's Zendesk identity, which may be a secondary address, a work address when the account uses a personal one, or an address with a plus tag. Matching on the exact string will find most of them and silently lose the rest. Domain level matching catches more but overmatches for anything on gmail.com.

Then there is the part that is not matching at all. Once you have a ticket from someone who had a delivery failure in the same window, you still have to decide whether the ticket is about the delivery failure. A customer who was hard bounced on Monday and wrote in on Wednesday about a pricing question is a coincidence, not a case. That decision requires reading the ticket body and forming a judgement: does this text describe an email that did not arrive. No field holds that answer. A join on timestamps and addresses will hand you a candidate list; something has to read the list.

Answering it with Skopx

Skopx connects to both sides, along with nearly 1,000 other tools and your databases, and the asking surface is chat. The realistic sentence is close to how you would say it out loud:

Pull every bounced, dropped, or blocked event from SendGrid in the last 7 days, then find Zendesk tickets created in that window from those same email addresses. For each match, read the ticket and tell me whether it's actually about a missing email. Group the real ones by recipient domain and by which SendGrid category the message was.

What comes back is a short list, usually shorter than the raw match count, with a citation on every line: the SendGrid event with its timestamp and SMTP response, and the Zendesk ticket with its number and the line from the body that decided it. On the Tuesday call above, the useful version of that answer was that nine of the fourteen traced to one corporate mail gateway that had started greylisting a specific transactional template, and the other five were unrelated. Nine is a fix. Five is life.

If the answer matters enough to want it standing rather than asked, you can describe the same thing as an internal app and get a console your support lead opens on Monday morning without typing anything: last seven days of failures with confirmed ticket matches, broken out by receiving domain, each row expanding to the event and the ticket side by side, and a button on each row that adds a delivery-failure tag to the ticket in Zendesk so the taxonomy stops lying to you next quarter. That button asks for confirmation before it writes, and it is the only write on the page.

What this does not do

It does not find the people who did not write in. The 337 who shrugged are invisible to this method and always will be, because they left no evidence anywhere. Treat the ticket count as a floor, never as the size of the problem.

It does not catch a customer who wrote in from an address you never sent to. If the match key is missing, the case is missing.

It does not run on its own. Nothing here watches SendGrid and pages someone at 3am. There are no scheduled runs, no alerts, and no forms. It answers when you ask, and the console reflects the current state when someone opens it.

It does not store a joined dataset. Each answer is computed against both systems live, which is what keeps it honest and also what makes it slower than a query against a warehouse table you already built.

And it does not replace the fix. It tells you nine tickets came from one gateway greylisting one template. Getting off that gateway's list is still a conversation with your deliverability provider and possibly a rewrite of the template. This closes the diagnostic gap, not the operational one.