Skip to content
Back to Resources
Use Cases

Who Spoke to This Customer Last, and What Did They Say?

Skopx Team
August 5, 2026
12 min read

An email lands in the founder's inbox on a Tuesday morning. It is three lines long and the tone is off.

"Following up again. Still waiting to hear back on the renewal terms we discussed. Let me know if there's someone else I should be talking to."

The founder does not recognise the thread. There is no earlier message from this person in her inbox. The word "again" is doing a lot of work in that email and she has no idea what it refers to. Before she can reply she needs to know one thing: who at the company spoke to this customer last, when, and what was actually said.

She checks Slack first, because that is where she is. Search for the customer's name. Fourteen results. Most are the account name appearing in a weekly revenue rollup. One is a message in #sales from three weeks ago that says "hopping on with them Thursday." Another is in #support and says "they're asking about the API rate limits again, I told them we'd check." Neither has a follow-up. Neither says what happened.

She opens the CRM. The account record shows a last activity date of eleven days ago, logged as a call, with a note field containing the single word "good." The renewal opportunity is still sitting in the same stage it was in six weeks ago. The owner of the record left the company in March and the account was reassigned to someone who has never spoken to this customer.

She checks the helpdesk. Two tickets, both closed. The most recent one closed nine days ago with the customer's own reply: "Ok. Will raise with our team and come back to you." Nobody came back to them.

Now she has four fragments from four systems and no idea which one is the most recent thing this customer heard from her company. She also has no idea whether the "renewal terms we discussed" were discussed on the Thursday call, in the closed ticket, or in a Gmail thread belonging to someone else entirely, which she cannot see from her own inbox.

She Slacks the team: "Who's been talking to Northline? What did we tell them about renewal?" Three people answer within the hour, each describing their own piece. The picture assembles itself in a thread, badly, forty minutes before she needed it.

Why none of the four tools can answer this on its own

It is worth being precise here, because the failure is not that these tools are bad. Each one answers its own question well. The problem is that the question spans all of them and none of them can see outside itself.

Gmail search is genuinely good. It will find every message in the mailbox you are searching. What it will not do from your own account is search a colleague's mailbox, and most customer email lives in colleagues' mailboxes. Unless every outbound sales email is copied into the CRM, and it never is entirely, half the conversation history is invisible to anyone but the sender.

Slack search is also good, and it does something the CRM cannot: it holds the informal record. The "I told them we'd check" message is a real customer commitment that exists nowhere else. But Slack search is keyword search over channels you belong to. A DM between two account managers about this customer is not searchable by anyone else, by design and correctly. And Slack cannot tell you whether that three week old message is the last thing this customer heard from you, because it has never heard of your helpdesk.

The CRM's activity timeline is the tool built specifically for this. It is the right answer in a company where everyone logs everything. What it actually holds is a record of what people remembered to record, filtered through what they were willing to write down in a field their manager reads. "Good" is what a real human types into a call note at 6pm. The gap between what happened and what got logged is the entire problem, and no amount of pipeline hygiene training closes it.

The helpdesk knows about tickets. It does not know that the support conversation about rate limits and the sales conversation about renewal terms are the same relationship, because tickets are keyed to a requester email and opportunities are keyed to an account.

The standard advice, from every CRM vendor and every sales ops playbook, resolves to the same recommendation: get everything into the CRM. Log the call. Sync the email. Connect the channel to the account record. It is good advice and it is worth doing. It also assumes the behaviour it is trying to produce. The reason you are searching four tools at 9am is precisely that the logging did not happen, and a recommendation that only works when people log everything is not available to you in the moment you need it.

What the question actually requires joining

Strip the situation down and the question "who spoke to this customer last" needs four things that live in four shapes:

SourceWhat it holdsWhat identifies the customer
GmailThe actual sent and received messages, across several mailboxesEmail domain of participants
SlackInformal commitments, internal context, "I told them we'd check"Company name typed by a human, inconsistently
CRMLogged activities, opportunity stage, ownerAccount ID
HelpdeskTicket threads, resolution notes, customer's last replyRequester email address

Two of those four keys are email domains. One is a name typed by hand, sometimes as "Northline", sometimes as "Northline Logistics", sometimes as "NL". One is an internal ID that appears nowhere outside the CRM.

And crucially, the answer to "what did they say" is not a field. It is a sentence somebody wrote. It is the body of an email, the text of a Slack message, the last comment on a ticket. There is no column called last_thing_we_told_them.

This is the structural reason business intelligence tools do not cover this ground. BI connects to databases and modelled sources. Looker supports SQL dialects. Metabase ships nineteen official drivers and every one of them is a database. Power BI, Looker and Tableau all have capable natural language layers now, and they will answer a question in plain English about the data they are connected to. But a Slack thread is not a modelled source, and the sentence "I told them we'd check the rate limits" is not going to appear in a semantic model no matter how good the question is. That is not a limitation of the query interface. It is a limitation of what the tool is connected to.

Internal tools builders have the mirror problem. Retool and its peers build genuinely good interfaces over the resources you point them at, they can generate a first version from a prompt, and they can run write actions against your systems. A customer panel built that way will show the CRM record, the ticket list and the invoice history well. The hard part here is not the interface. It is that answering this question means reading prose in four places and judging which sentences are about this relationship, and that is a different shape of work from rendering records.

The automation platforms are the wrong shape entirely. Zapier and Make fire when something happens. You could build a Zap that logs every future Slack mention of an account to the CRM, and that is a reasonable thing to build. It does nothing for the email sitting in the founder's inbox right now, which is about a conversation that already happened. This question is retrospective, and trigger-based tools cannot look backwards.

Asking it in one sentence

Skopx connects to nearly 1,000 SaaS tools alongside direct database connections, which in this case means Gmail, Slack, the CRM and the helpdesk are all readable from the same place. You ask in chat, in the words you would use with a colleague:

"Show me every interaction with Northline Logistics in the last 60 days across Gmail, Slack, HubSpot and Zendesk, in order, with who it was from and what was said."

The join happens on what is actually available: the customer's email domain resolves the Gmail threads and the Zendesk requester, the CRM account gives the canonical name and its variants, and those name variants are what get searched in Slack. Where a Slack message mentions the account without any structured link, the model reads it and decides whether it is about this relationship, which is a judgement a keyword search cannot make and a human reading fourteen search results makes in about a second.

The answer comes back with citations. Each line points at the message it came from, so the founder can open the actual Slack thread or the actual email rather than trusting a summary of it.

If the same question is going to be asked about a different account next week, and it will be, you can turn it into a screen. Internal Apps builds a console from a sentence: you describe the page, it runs the query against what you already connected, measures what came back and renders it. The sentence here would be something like "an account timeline page: choose a customer, show every Gmail thread, Slack mention, CRM activity and Zendesk ticket in one reverse-chronological list, with a summary of the last three things we said to them."

What the console shows

A control at the top to choose which account you are looking at. Below it, three metrics that answer the panic directly: days since last outbound contact, days since last inbound contact, and a count of commitments made in writing with no visible follow-up. Then the timeline itself, one table, every row from a different system, sorted by time, with a column for source, a column for who, and a column holding the actual sentence. A small bar chart of contact volume by week, because a customer who went from nine touches a week to zero is a different problem from one who was always quiet.

Nothing you select on that page is saved anywhere. The console is a view over the tools you already connected, rebuilt from them each time it loads.

At the bottom, two buttons. One drafts a reply in Gmail with the timeline underneath so the founder can write on top of it. One posts a summary into the account channel in Slack so the three people who each hold a fragment can see the whole. Each button runs a single action in a single connected tool, each asks for confirmation first, and neither does anything until a person clicks it.

The honest limits

The console reads, and it acts only when someone clicks. It holds no data of its own, it does not write anything back into your CRM, it does not backfill the missing activity log, and it does not fix the underlying hygiene problem. The next time someone types "good" into a call note, that is still what the note says.

It cannot see what it is not connected to. A conversation that happened on a phone call and was never written down anywhere is not recoverable by any tool, including this one. Same for a WhatsApp thread on someone's personal phone.

Access follows access. If a Slack DM is private, it stays private. If a mailbox is not connected, its threads do not appear. This is correct behaviour, but it means the timeline is complete only to the degree your connections are, and you should read a quiet week as "no recorded contact" rather than "no contact."

And the model is reading prose to decide relevance. It will occasionally pull in a Slack message that mentions a similarly named company. The citations exist so you can catch that in two seconds rather than acting on it.

What she actually needed

The founder did not need a dashboard. She needed to know, before she hit reply, what her company had already told this customer and who had said it. That question has an answer. It is just scattered across four tools in four shapes, and three of those shapes are sentences a person typed rather than rows in a table.

The tools that are good at tables cannot see the sentences. The tools that hold the sentences cannot see each other. Fixing that by insisting everyone logs everything is a plan for next quarter. Reading across all four right now is a different thing, and it is the thing you need at nine in the morning with an unanswered email open in front of you.

Share this article

Skopx Team

The Skopx engineering and product team

Related Articles

Stay Updated

Get the latest insights on AI-powered code intelligence delivered to your inbox.