Which Deals Are Waiting on You, Not on Them

The forecast call is Tuesday morning. The pipeline report says forty-one open opportunities, $2.4 million weighted, nothing overdue, nothing stalled past thirty days. The VP of Sales scrolls it once and moves on to hiring.

Then on Thursday a customer emails the CEO directly, politely, to ask whether anyone is still working on their contract. They sent the redlines eleven days ago. Nobody wrote back. The deal is in Negotiation, close date end of quarter, last activity logged nine days ago because someone clicked into the record to update a field. By every measure the CRM reports on, that deal is fine.

It is not fine. It is waiting on us.

This is the difference between a deal that is stuck and a deal that is stalled by us specifically, and pipeline reports do not separate the two, because the distinction lives in a place the report cannot see: the direction of the last message in the thread.

What "no stage change" actually hides

Pipeline hygiene reporting is built on two columns. Stage, and close date. Most stalled-deal reports are some arrangement of those two: days in current stage, close date in the past, close date pushed twice, no activity in N days.

Each of those measures whether something happened. None of them measures who owes whom.

Consider four deals, all sitting in Negotiation for twelve days, all with a close date three weeks out, all showing "last activity: 4 days ago" because the rep logged a call note:

Two of those need a reply today. Two need patience, or a different kind of nudge. The report treats all four identically because the report is looking at the record, and the answer is in the mailbox.

The "last activity date" field makes this worse, not better. Most CRMs stamp last activity when anything touches the record: a logged call, a sequence email, a field edit, sometimes just an email sync in either direction. A deal where the customer wrote to you and got silence back often has a fresher last-activity date than a deal where you are legitimately waiting, because their inbound mail counted as activity. The metric moves in the wrong direction from the thing you care about.

There is also a human reason this stays hidden. Nobody ignores a deal on purpose. The Northwind redlines went unanswered because they needed legal input, legal was slow, the rep meant to chase it, then a bigger deal came in on Thursday and the thread scrolled out of the inbox. There is no bad actor here and no field anyone forgot to fill in. The information was never in the CRM in the first place.

Why the tools you have cannot answer it

Be precise about this, because the tools are good at what they do.

Your CRM reports on the CRM. HubSpot and Salesforce both sync email into the activity timeline, so the messages are visible on the record if you open it. What neither ships out of the box is a property that says "the last message was inbound and nothing outbound followed it", which is the thing you would need in order to filter a list view or build a dashboard on it. Ask around and the standard advice is some version of: add a custom property, build a workflow that stamps it when mail arrives, unstamp it when a reply goes out, maybe write a custom coded action for the edge cases. That is honest advice. It is also a project, and it only starts working from the day you finish it, which means it tells you nothing about the six threads sitting there right now.

BI tools connect to databases and modelled sources. Power BI's Copilot will answer questions in plain English. Looker's Conversational Analytics will too. Tableau Pulse will surface a metric change nobody asked about. These are real capabilities and it would be silly to pretend otherwise. The constraint is upstream of the interface: Looker's connections are SQL dialects, Metabase ships nineteen official drivers and every one of them is a database. A modelled semantic layer over your CRM tables will happily tell you how many deals sit in Negotiation, and it will do it better than anything else. But the sentence "Attached are our redlines, let us know your thoughts", sitting in a Gmail thread with a customer domain in the From line, is not in any table those tools connect to. The question is not hard for them. It is outside what they can see.

Automation platforms run forwards. Zapier and Make are trigger based by design. A new inbound email fires a Zap, the Zap does something. That is genuinely useful and if you build it today it will help you tomorrow. It cannot look backwards. The eleven day old Northwind thread already happened. No trigger will ever fire for it.

So the question sits in the gap: its evidence is a sentence rather than a row, it is not a CRM property, and it is retrospective in a world of triggers.

What the question actually requires joining

Written out plainly, "which deals are waiting on me" needs three things brought together.

One: open deals with owners. From the CRM. Deal name, associated company, associated contacts and their email addresses, stage, amount, close date, owner. This part is easy and every tool can do it.

Two: the last message in each deal's thread. From the mailbox. For each deal, find the most recent message exchanged with any of its contacts, and determine its direction. Inbound means the From address is the customer's. Outbound means it is the rep's. This is where the answer lives, and it requires reading actual message metadata, not a synced activity count.

Three: the judgement about what the message meant. A last message being inbound does not automatically put the ball in your court. "Thanks, we will circle back after the board meeting on the 20th" is inbound and you are not blocked. "Attached are our redlines" is inbound and you are very much blocked. Distinguishing those requires reading the sentence. That is a language problem, not a query problem, and it is the reason a stamped custom property would still miscall a good share of these.

The join key is the contact's email address, which appears on both sides. Everything else follows from that.

Answering it with Skopx

Skopx connects to nearly 1,000 SaaS tools, HubSpot and Salesforce and Gmail and Outlook among them, and you ask it questions in chat. It answers across those tools with citations, so every claim points back to the message or record it came from.

Start by just asking. Something like:

For every open deal in HubSpot with a close date this quarter, find the most recent email between the deal owner and any contact on the deal. Show me the ones where the last message came from the customer and nobody has replied since, oldest first, and tell me what the customer was actually asking for.

That runs across both systems: it pulls the open deals, resolves each deal's contacts to email addresses, searches the mailbox for the most recent thread with each of those addresses, checks the direction of the final message, and reads the ones that are inbound to summarise what the customer wanted. The answer comes back as prose with links to the threads.

When it is an answer you want to look at every Monday rather than retype, you can describe it as a screen instead and have Skopx build it as an internal app: you write a sentence describing the console you want, Skopx runs the query against the tools you have already connected, measures what comes back, and renders a page.

Build me a page called Waiting On Us. One row per open deal where the last customer email is unanswered, showing company, deal value, owner, days since their message, and a one-line summary of what they asked. Sort by days waiting, longest first. Put the total value of unanswered deals at the top. Add a button on each row that posts the deal to our #sales-floor Slack channel so the owner sees it.

What the console shows

A tile at the top with the count of unanswered threads and the combined deal value sitting behind them, which is usually the number that gets a sales leader's attention. A bar chart of unanswered deals by owner, because this problem is rarely evenly distributed. And a table, one row per deal.

Company, amount, stage, owner, the date the customer wrote, days waiting, and a short line of what they asked for, pulled from the message itself. Northwind Logistics, $84,000, Negotiation, sent redlines, 11 days. Ironbark Systems, $31,500, security questionnaire requested, 6 days. Each row links out to the thread in Gmail and the deal in HubSpot so nobody has to take the console's word for it.

The buttons are the part worth being careful about. A button on a row runs one action in one connected tool, when a person clicks it, with a confirmation before it fires. Post this deal into the Slack channel. Open a Linear ticket for legal on the redlines. Assign a task on the HubSpot record to the owner. The console itself sends nothing on its own, does not run on a schedule, does not email anyone at three in the morning, and keeps no copy of your pipeline. It reads what is there when you open it, and acts only when somebody clicks.

The honest limits

Judgement calls stay judgement calls. "We will get back to you next week" reads as not blocked, and usually that is right, but the customer who wrote it may well be waiting on something you promised earlier in the thread. The console shows the summary so a human can disagree with it in two seconds. Treat it as a triage list, not a verdict.

Mailbox access is per person. Skopx reads the mailboxes that have actually been connected. If a rep has not connected Gmail, their threads are not in the answer, and the console will show their deals as having no email evidence rather than quietly marking them fine. That is the right failure mode but it is still a gap you have to close by getting people connected.

Threads outside email are outside scope here. If half your customer conversation happens in a shared Slack Connect channel or in WhatsApp on someone's phone, this particular console only sees the email half. Slack Connect can be brought in as another source. The phone cannot.

It reads, it does not store. There is no form here, nothing is written into a new table, no field on the deal gets stamped by the page itself. If you want the "waiting on us" state to live in HubSpot as a property, that is still the custom automation project, and it is still a project. The console answers the question without asking you to build that first, which is a different and usually more useful thing.

What the report was never asked to do

Pipeline reports answer "did anything move". That was the right question when the alternative was no report at all. It is a weak proxy for the question a sales leader actually has on Tuesday morning, which is: of everything open right now, what is sitting still because of us.

The evidence for that question has always existed. It is in the mailbox, in the direction of the last message, in a sentence a customer wrote and nobody answered. It was never going to appear in a chart, because it was never in a table. Ask it as a question instead, and it turns out to have been answerable the whole time.