The Customer Requests in Slack That Never Became Tickets

Your solutions engineer is in a shared Slack channel with a customer's data team. On a Tuesday in April, the customer's analyst writes: "the CSV export is silently dropping rows over 50k, we hit it again this morning." Your SE replies within four minutes: "yep, that's a known limit on the old export path, I'll get it filed and we'll look at raising it." Then someone posts a meeting link, the thread moves on, and the next forty messages are about a schema change.

Nothing was filed. There is no Zendesk ticket, no Linear issue, no line in the account notes. The promise exists in exactly one place: message 14 of a thread in a channel that now has thousands of messages in it.

Four months later that customer is in a renewal conversation and their VP says, offhand, "we raised the export thing in the spring and never heard back." Your account executive has no idea what they are talking about. Neither does support, because support only sees what came through the portal. The SE remembers something vaguely. The evidence is right there in Slack, and nobody can find it, because finding it means reading.

This piece is about the retrospective version of that problem. Not "how do we stop this happening" but "over the last 90 days, in our shared customer channels, how many commitments did we make that never turned into a ticket, and which accounts are carrying them."

What the situation actually looks like at scale

A company with 40 shared Slack Connect channels is not dealing with a handful of dropped promises. Assume each channel sees a few hundred messages a month. Somewhere inside that volume are three kinds of message that matter:

The customer asks for something. Sometimes explicitly ("can you add a filter for account owner"), often not ("is there really no way to see this by owner?"). The second form is a feature request wearing the clothes of a question.

Someone on your side commits. "I'll file that." "We'll get that fixed." "Let me raise it with the team." "That's on the roadmap, I'll find out where." Each of those is a promise a customer will remember and your systems will not.

Then either a ticket appears in the next few days, or it does not.

The audit is the join between the second and third. Everything else is noise. And the thing that makes it hard is not the volume, it is that the signal is prose. There is no commitment field. There is no label. A person wrote a sentence and another person understood it, and that understanding was never written down anywhere a query can reach.

Why the tools you already own cannot answer this

Start with BI, because that is where people instinctively go when they hear the word "audit."

Looker, Metabase, Power BI and Tableau are all very good at what they do, and what they do is query modelled data. Looker's semantic layer is built on SQL dialects: you point it at a warehouse and describe the tables. Metabase ships 19 official drivers and every single one of them is a database. Power BI Copilot and Tableau Pulse can both answer questions in natural language now, which is genuinely useful, but the question is answered against a dataset. The natural language is on the input side. The sources on the other side are still databases and modelled tables.

Slack messages are not in that dataset. They could be, if someone built an ingestion pipeline that landed message bodies in your warehouse, and then you would face the actual problem: a SELECT cannot tell you that "yep, that's a known limit, I'll get it filed" is a commitment while "yeah I'll get on that call" is not. There is no WHERE clause for intent. You would need something that reads.

Now the prevention tools, and this is where it is worth being fair, because they are good products solving a real problem. Pylon, Thena and Plain all exist to route shared Slack channels into a real support workflow: they watch the channel, turn messages into tickets, and give you an inbox and SLAs. If you adopt one, the class of failure described above largely stops happening.

The catch is that what you get is a workflow, not an account of the months before you had one. Adopting a tool in August is a good way to make September clean. It is not how you find out what your team promised in April, and the April answer is the one you need first, because it is what tells you whether the problem is big enough to justify changing how eleven people work every day. Buying the prevention tool in order to size the problem is backwards, and it puts a change-management project between you and an answer you could have this afternoon.

The last option is the one most teams actually pick: someone spends a Friday scrolling Slack. It works for two channels. It does not work for forty, and it does not work repeatedly.

Zapier and Make deserve a line of their own. They are trigger-based by construction: something happens, then a chain runs. That is the right shape for prevention and the wrong shape entirely for a question about the past. There is no trigger for "April."

What the question actually requires joining

Write out what you are really asking and the shape becomes obvious:

For each shared customer channel, over the last 90 days, find messages where someone on our side made a commitment. For each of those, look in the ticketing system for an issue created after that message, referencing the same subject, for the same account. Where none exists, that is an open promise.

Three distinct operations, and only one of them is a query.

The first is reading. Someone has to look at a message and decide whether it is a commitment. That is a language judgement, and the correct output is not a boolean but a short summary: what was promised, by whom, to which account, on what date.

The second is matching. A Slack message saying "CSV export drops rows over 50k" and a Linear issue titled "Export truncation on legacy path" are the same thing, and no join key connects them. It is a similarity judgement over two pieces of prose.

The third, and only the third, is the ordinary part: pull issues created in the window, filtered by the customer label or project, with their titles, dates and status. Any tool can do that.

This is why the work has stayed manual. The one step everyone can automate is the step that was never the bottleneck.

How you would answer it with Skopx

Skopx connects to nearly 1,000 SaaS tools, Slack and Linear and Zendesk and HubSpot among them, and to databases directly. You ask questions in chat and it answers across those tools, with citations back to the source message or record. Its internal apps feature takes that same capability and renders it as a console: you describe the screen you want, it runs the reads against what you already connected, measures the rows that come back, and lays out the metrics, tables and charts that fit.

For this audit, the sentence someone would actually type is close to how they would say it out loud:

"Go through our shared Slack Connect channels for the last 90 days. Find messages where someone on our team promised a customer we would fix, file, or follow up on something. For each one, check Linear and Zendesk for a matching issue created after that message. Build me a page listing the promises with no matching ticket, grouped by account, with the message date, who made the promise, what was promised, and a link to the thread."

You want to narrow it before you run it wide. Start with three channels and one month, read the output carefully, and correct the reading: "the ones where someone said 'I'll ask' are not commitments, drop those" or "treat any message from a customer domain that ends in a question mark as a request even if nobody replied." Getting the judgement right on a small window is the whole job. Once it is right, widen it.

What the console shows

The result is a page, not a chat reply, which matters because this is a thing several people will look at more than once.

At the top, counts: open promises found, distinct accounts affected, oldest unresolved promise in days. Underneath, a bar chart of open promises by account. The distribution is worth looking at before the total is, because it is rarely even, and the accounts at the top are often the ones your team gets on with best. A friendly channel produces more casual commitments.

Then the table, which is the real deliverable. One row per promise: date, channel, who on your side said it, a one-line summary of what was promised, days since, and a permalink into the Slack thread so anyone can read the original in context, ordered by age with the oldest first. That permalink is not decoration. In every meeting where this table gets shown, someone will say "I don't think that's what I meant," and the ability to click through and settle it in five seconds is what keeps the conversation about the customer instead of about the tool.

Alongside each row, a button. Clicking it creates a Linear issue in the right project, pre-filled with the summary and the Slack link. A person clicks it, sees a confirmation, and the action runs. Nothing files itself, nothing runs on a schedule, and nothing happens while you are not looking. The point of the button is that triage and filing happen in the same place, so a 40 row table becomes 40 decisions in one sitting instead of 40 tabs.

The page also holds nothing of its own. There is no stored copy of your Slack history and no saved record of what last week's run found. When someone opens it, it reads Slack and the ticketing systems again and shows what is true then.

The honest limits

The reading is a judgement and judgements are wrong sometimes. Expect both directions: a genuinely soft "we'll see what we can do" flagged as a commitment, and a real promise phrased so casually it slips past. Treat the output as a triage list a human reviews, not a verdict. It is worth the time because reviewing a page of candidate rows is a different order of work from reading every message in the channel.

Matching is fuzzier still. If a ticket was filed with a title that shares no vocabulary with the Slack thread, it may show up as an open promise when it was handled. Every list of this kind has a few of those. Your team will spot them in review, and each one you correct sharpens the next run.

Coverage is bounded by connection. Private channels nobody granted access to are invisible. Promises made on a Zoom call, in a customer's own Slack, or by email to a personal address are outside the audit entirely. What you get back is complete for the channels you connected and silent about everywhere else, and it is worth saying that out loud before anyone treats the number as the total.

There is a permission question too, and it deserves a straight answer rather than a reassurance. This reads the contents of conversations your team had with customers. That is normal for support tooling and it is still worth telling your team you are doing it, and worth agreeing which channels are in scope before the first run rather than after.

And this is genuinely retrospective. It tells you what happened. If the answer is bad enough that you want it to stop happening, that is a separate decision, and one of the prevention tools may be exactly right. Skopx is not competing for that job.

The close

The promise your SE made in April was not careless. It was a fast, helpful, human reply in a channel where being fast and helpful is the entire point. The failure was not in the reply. It was that the reply lived in prose, and every system your company owns for tracking commitments needs someone to retype it into a ticket first.

The audit exists to find out how often that retyping did not happen. It is two tools you already pay for, a 90 day window, and one question that has never been askable because the evidence was a sentence rather than a row. Ask it once. Then decide what, if anything, to change.