Which Trello cards are waiting on an external reply

It is Tuesday morning and the delivery lead is on a call with the client's programme manager, sharing her screen. On the left is the Trello board for the migration: forty-one cards spread across Backlog, In Progress, Blocked, Waiting, and Done. On the right, minimised, is her Gmail inbox.

The programme manager asks a reasonable question. "Which of these are actually with us, and which are with you?"

She scrolls the Blocked list. Nine cards. She opens the first one: "Confirm SFTP credentials for finance feed." The description says who owns it. The last comment, from eleven days ago, says "emailed their infra team, waiting." Was that eleven days ago, or has someone replied since and nobody updated the card? She does not know. She has to alt-tab, search Gmail for "SFTP", and read down a thread to find out.

Nine cards. On a call. With the client watching.

This is the report nobody has. Not "what is blocked," which Trello answers instantly. The question is narrower and much more useful: which blocked cards are blocked on somebody outside this company, and how long have they been silent. That distinction decides whether the delivery lead chases her own team or picks up the phone to the client. Getting it wrong in front of the client is worse than not knowing.

What Trello shows on its own

Trello is honest about what it is. It is a board of cards with lists, labels, members, due dates, checklists, comments, and an activity stream. All of that is real, queryable data. The API will hand you every card on a board with its list, its labels, its members, its due date, and its full comment history, and it will do it fast.

If your team is disciplined, Trello already tells you a lot. A "Blocked" list plus a label like waiting-on-client plus a due date gets you most of the way to a report. Butler automations can move a card when a label is applied, nudge on a due date, or post a comment on a schedule. Card ageing shows you which cards have gone quiet.

Where it stops is precise and it is not a flaw. Trello knows the card was moved to Blocked on the 14th. It knows a comment was added on the 15th saying "chased them again." It does not know whether the person on the other end of that chase replied on the 19th, because that reply did not happen in Trello. It happened in an inbox.

So Trello's timestamps answer "when did we last touch this card," and everyone reads them as "when did we last hear anything." Those are different facts, and the gap between them is exactly where the report goes wrong. A card with no activity for eleven days might be genuinely stalled, or it might have been resolved by email on day three by a person who never went back to the board.

What Gmail shows on its own

Gmail is very good at the other half. Search operators are genuinely strong: from:, to:, newer_than:14d, has:attachment, label:, in:anywhere. You can find every thread with a given external domain in seconds. Threading is reliable, so a conversation stays a conversation. Gmail even nudges: "Sent 5 days ago. Follow up?"

What Gmail does not have is the work. It has no idea that the thread with the client's infra team is the reason a card called "Confirm SFTP credentials for finance feed" has not moved since the 14th. It has no concept of a card, a list, a board, or a delivery milestone. It sees a thread with a subject line and some participants.

There is a second, subtler limit. Gmail can tell you the last message in a thread arrived on the 19th and came from an external address. It cannot tell you whether that message answered the question. "Thanks, I'll check with our security team next week" is an inbound reply. Structurally it looks identical to "Here are the credentials, attached." One unblocks the card and one does not. Gmail's data model has no field for that, and no realistic one could.

Why the gap is structural, not a missing feature

Put the two halves side by side and the shape of the problem is obvious.

Half the evidence you need is a database row. The other half is English written by a stranger at another company, on their schedule, in their words.

This is why the join is not a reporting feature Trello forgot to build. To ship it, Trello would have to read your mail, understand which threads correspond to which cards, and then judge whether the prose in the last reply resolves the blocker. That is not a report. That is three products, two of which are not Trello's business.

It is also why the automation platforms do not close it. Zapier and Make are excellent, and they genuinely will do this: new email arrives, comment on the card. That is a real integration and plenty of teams run it happily. But automation is trigger based. It moves records forward from the moment it is switched on. The delivery lead's question is retrospective, about forty-one cards and six months of mail that already exist. There is no trigger for "what already happened." Turning on a Zap today does not tell you which cards went silent in March.

BI tools have a different and equally structural limit. Power BI, Looker, Metabase all connect to databases and modelled sources, and Power BI Copilot and Looker Conversational Analytics will answer a plain English question about that model perfectly well. But the deciding evidence here is a sentence a client wrote in an email thread. It is not in the warehouse and it is not going to be modelled. It is outside what those tools can see at all, and no amount of natural language on top of a semantic layer reaches it.

The gap is not inside either product. It is between them.

What the join actually requires

Two things, and they are different in kind.

The key. Something must connect a card to a thread. In practice one of these is usually available:

• A card ID or ticket reference in the subject line, if the team is that disciplined
• The external participant's email domain, matched against the client or vendor named on the card
• The card title's distinctive nouns, matched against subject lines and thread bodies
• A link to the Trello card pasted into the email, or the email's permalink pasted into a card comment, which many teams already do by hand

None of these is perfect. Domain matching is the most reliable in practice and the least precise: it tells you a conversation with that company happened near that date, not that it is about this card. Getting from "probably related" to "this thread" needs reading.

The judgement. Once you have the thread, someone has to decide what the last inbound message means. Is it an answer, an acknowledgement, or a deflection? Did they commit to a date? Did they ask a question back, which means the ball is actually with us and the card is mislabelled?

Matching gets you the candidate. Reading gets you the answer. That second half is the part no rule engine has ever been able to do, and it is precisely the part that is now tractable.

How you would answer it with Skopx

Skopx connects to nearly 1,000 SaaS tools plus your databases, and it answers questions across all of them with citations back to the source. You ask in chat.

The realistic sentence, typed the way the delivery lead would actually type it:

For every card in Blocked or Waiting on the ACME Migration board, find the most recent email thread with anyone at acme.com that matches the card, and tell me whether we are waiting on them or they are waiting on us, and how many days it has been silent.

What comes back is a list, card by card, with the thread it matched, the date of the last message, who sent it, a one line reading of what that message actually said, and a link to both the card and the thread so she can check any line herself. The cards where nothing matched are called out separately as unmatched rather than quietly assumed resolved, which matters, because "no evidence" and "no reply" are not the same finding.

You can ask a follow up in the same conversation. "Which of those did we never chase after the first email?" That one is often the uncomfortable answer.

If this is a question the team asks every week, the next step is a standing console. You describe it in a sentence and Skopx builds the interface: Internal Apps turns that request into a live view over the same two sources.

A useful one here would show:

• Every open blocked card, sorted by days since the last external message rather than days since the last card update
• Who the ball is with: them, us, or unknown
• The matched thread, the last sender, and the last line of it
• An unmatched column, so cards with no email evidence are visible instead of invisible
• A Post an update comment on this card button, which asks for confirmation before it writes anything

That last one is the only thing the console writes. Everything else is read.

Honest limits

Worth being plain about what this is and is not.

It does not store anything. The console holds no records of its own. It has no forms, it creates nothing, it does not run on a schedule, it sends no alerts, and it has no public link. It reads Trello and Gmail live and shows you what is there. The single write is the confirmation button, clicked by a person.

It does not replace card hygiene. If a card title is "Follow up re: thing" and the email says "the item we discussed," nothing will match them, and Skopx will tell you it could not rather than guess. Teams with a client name and a real noun in the card title get dramatically better results.

It cannot see mail it is not connected to. If the client conversation happened on the account manager's personal laptop, in a WhatsApp thread, or on a call, it is not evidence and it will not appear. Skopx scopes what each viewer can see to what they are permitted to see, which also means a report run by one person may legitimately differ from the same report run by another.

The reading is a judgement, and judgements can be wrong. "I'll get that to you shortly" being classified as a non answer is a call, and a defensible one, but it is still a call. That is why every line cites the thread it came from. Check the ones that matter before you say them out loud on a client call.

It is not a replacement for a Zap. If you want a comment posted on the card every time a client emails, an automation platform is the right tool and it does that well. Use both. They solve different halves.

Team is $16 per seat per month and includes 2.3 million AI tokens; Solo is $5. SOC 2 controls are in place.

The question at the top of this article took the delivery lead about twenty minutes of alt-tabbing to half answer, live, in front of the person who asked it. It is one sentence now, and the answer arrives with its sources attached.