The requests that were handled in the channel, and never became tickets

It is the first week of July. Priya runs the service desk at a 900 person company, and in last week's planning meeting her CIO asked a question that sounded simple: how much work is your team doing that we never see?

She has two screens open trying to answer it.

On the left is ServiceNow. Incidents and requests, filtered to the Service Desk assignment group, resolved between April 1 and June 30. The list returns 2,140 rows. Every one of them has a number, a caller, a category, a resolution code, and a pair of timestamps.

On the right is Slack, the #it-help channel, roughly 11,000 messages over the same three months. Within a minute of scrolling she finds a thread from mid-May: someone in finance asking to be added to a reporting group before a board call, Marcus from the platform team replying "added", a thumbs up, nothing else. That request was made. It was handled. It is not one of the 2,140.

The question is not how many tickets, and it is not how many messages. It is: which requests were actually handled in the channel, and how many of them never became a ticket. Neither screen answers that.

What ServiceNow shows, and where it stops

ServiceNow is complete over its own tables, and that completeness is the product. Every ticket carries opened_at, resolved_at, the caller tied to the directory, assignment group, category and subcategory, close code, reassignment count, SLA state. Reports and Performance Analytics will slice those a hundred ways: volume by category, first-contact resolution, mean time to resolve by group, week over week trend. If the event is in the table, ServiceNow will tell you almost anything about it.

It is also fair to say that the ServiceNow app for Slack is real and useful. If you connect ServiceNow and Slack through it, people can raise an incident from a message with a shortcut or an emoji reaction, look up ticket state without leaving the channel, approve changes, and get updates posted back into the thread. Where teams have adopted it, a meaningful slice of channel work does become records.

Where it stops is the boundary of the record itself. ServiceNow holds the requests somebody chose to turn into a request. The finance thread in May has no row, because no row was ever created. This is not a reporting gap. There is nothing to report on. The event never entered the system, and ServiceNow is honest about only counting what did.

What Slack shows, and where it stops

Slack holds the other half in full. Every message in the retention window, every thread, every reaction, who replied and how long they took. Search with in:#it-help from:@marcus and you get the raw material immediately. Channel analytics on paid plans will tell you messages posted, members, and how many of them were active.

Where Slack stops is that it has no concept of a request. Every message is the same object: text, author, timestamp, optional thread parent. A question, an answer, a joke, a deploy notification and a stand-up update are structurally identical. Search "access" across the quarter and you get several hundred hits with no way to separate the ones that were resolved from the ones that were ignored, or the ones that were requests at all. Analytics counts volume, and volume is not outcome. And Slack has no idea whether that May thread corresponds to a ServiceNow ticket, because it has never heard of ServiceNow tickets.

Why the gap is structural

Half of the evidence is a record. The other half is a sentence somebody wrote.

Every cell on the left is a field. Every cell on the right is an inference. "Hey, any chance someone can get me into the finance dashboard before the 3pm board call" has no state field, no category, and no closure event. It closes when the conversation stops, which is indistinguishable from being abandoned.

So the join between the two sides is not a report either vendor forgot to build. ServiceNow's reporting is complete over records. Slack's analytics are complete over messages. Connecting them means deciding whether an English paragraph describes the same event as a row in a table, and that is an interpretation rather than a lookup.

This is also where the neighbouring categories genuinely stop. Automation platforms like Zapier and Make are trigger based, and a Zap that fires on a tagged message and opens a ticket is one of the better fixes for this problem going forward. But a trigger exists only from the moment you switch it on, and its job is to move a record forward, not to look backward. It cannot tell Priya what happened in April. BI tools are the mirror image. Power BI Copilot and Looker Conversational Analytics are strong over modelled sources, and you can absolutely land the ServiceNow tables in a warehouse. But the evidence on the Slack side is prose. Even if you export every message into a table, the column that says "this was a handled access request" does not exist, because nobody wrote it. The thing you want to count has to be read before it can be counted.

What the join actually requires

There is one clean key and two weak ones.

The clean key is the integration itself. Where the ServiceNow app for Slack was used, the bot posted the ticket number into the thread, or the ticket carries the Slack permalink. Extract that and the converted subset is joined exactly, with no guessing. Do this first, because it is cheap and certain. At most teams it accounts for a minority of the channel traffic.

For everything else there are two weak keys. Identity: the Slack profile email mapped to the ServiceNow caller, which breaks for contractors, shared accounts and anyone whose Slack address differs from their directory address. And time: a thread at 14:02 and a ticket opened by the same person at 14:19 on a related subject are probably one event.

Weak keys produce candidates, not matches. What closes the gap is three judgement calls that require reading:

1. Was it a request at all? "Is anyone else's VPN dropping?" followed by two "same here" replies and silence is a complaint, not a handled request.
2. Was it handled in the channel? A thread ending with "raise a ticket and we'll pick it up" is intake working correctly. Counting it as shadow work inflates the number and misleads the CIO.
3. Is the nearby ticket the same request? Same person, same hour, different subject happens constantly on a busy desk.

A person can do this by hand at maybe forty threads an hour, and gets less accurate as they go.

How you would answer it with Skopx

Skopx is connected to both systems, along with nearly 1,000 others, and you ask it in chat. The realistic sentence is close to how Priya would brief a new analyst:

Read #it-help from April 1 to June 30. Find threads where someone asked IT for something and got it done in the channel. For each one, check ServiceNow for a ticket from the same person within 24 hours on the same subject. List the threads with no matching ticket: who asked, what they wanted, who handled it, and the link.

What comes back is a list where every row cites the Slack permalink and either the ticket it matched or the ServiceNow search that returned nothing. That matters more than the total at the bottom, because the first pass will get some of the judgement calls wrong and the citations are how you find which. Then you argue with it: drop anything where the answer was "open a ticket", group the rest by what was asked for, separate the ones that took more than one reply.

Once the definition is settled, the same question can stand up as a console. You describe it in a sentence and Skopx builds the internal app around it, no dashboard configuration and no SQL. What it shows: unticketed handled requests per week across the quarter, a breakdown by request type read out of the text itself (access grants, password and MFA resets, licence requests, how-do-I questions), a breakdown by responder, and the underlying table of threads with permalink, responder, and match verdict. The responder panel is usually the uncomfortable one, because it tends to show two or three engineers absorbing most of the invisible load.

It reads on open, and it holds nothing of its own. The one thing it can write is a button on rows where a matching ticket does exist: attach the Slack permalink and a one line summary as a work note on that ticket. It names the ticket and asks for confirmation first. That is the only write anywhere in it.

Honest limits

It sees what your account sees. Private channels you are not in and direct messages are invisible, and a good share of genuine shadow IT requests live in DMs to the one engineer everybody knows. This measures channels, and you should say so when you present the number.

It is reading, so it is fallible. Ambiguous threads get classified wrong in both directions, and you should budget for overturning some rows every time you look. Use the output for magnitude and concentration, not as a figure you would defend in an audit or attach to someone's performance review.

It is not a monitor. Nothing runs on a schedule, nothing alerts, nothing opens tickets for you, nothing is published to a link, and no data is stored. When you want it, you open it and it re-reads the sources.

It is also not intake reform. Knowing that 380 requests bypassed the process last quarter does not change the process. If you want conversion to happen at the moment somebody asks, the ServiceNow app for Slack and a trigger based automation are the right tools for that, and they are good at it. This tells you how large the problem is, what kind of requests it consists of, and who is carrying it.

Which is the answer Priya actually needed. Not 2,140 tickets, not 11,000 messages, but something like: 610 requests were handled in #it-help last quarter, 380 of them never became tickets, three fifths of those were access grants, and two engineers handled half. That is a staffing conversation, and it took a question rather than a project.