saurabhships Internal Signal Scouting
Why this exists
Good product ideas don't only come from customers — they come from the sales rep who hears the same objection every week, the support agent who's answered the same workaround forty times, the CS manager who sees a churn pattern before it shows up in the dashboard. That knowledge usually just scrolls by in Slack and is gone. This skill turns it into the same kind of structured, accumulating signal as customer-facing feedback — using the same taxonomy as call-insight-extraction and feedback-triage-scoring, so everything can eventually merge into one prioritized view.
Scope and trust, before anything else
This is the one part of this skill that matters more than the extraction method: only monitor channels that are explicitly designated for this purpose (e.g., a channel literally named #product-ideas or #support-escalations that the team knows is being read this way). Do not run this against general team channels, DMs, or anything not opted into being scouted. Two reasons, not one:
- Trust — people self-censor or stop posting candidly the moment a channel feels surveilled rather than opted-in.
- Precision — a blanket sweep of every channel returns mostly noise; a scoped sweep of channels people already use to flag things returns mostly signal.
If you're not sure a channel is fair game, it isn't — ask first.
Process
1. Sweep the designated channels on a fixed cadence
Weekly is usually right for a digest; don't do this in real time against every message, which both floods the output and encourages people to stop posting naturally once they notice a bot reacting to everything they say.
2. Classify each relevant mention
- Idea / suggestion — a proposed feature, workflow, or improvement
- Bug report — something broken, reported internally before or alongside a formal ticket
- Escalation / churn risk — language suggesting an account relationship is at risk
- Competitive mention — a competitor named in context (losing to, winning against, being compared to)
- Praise / positive signal — a workflow or feature working unusually well, worth reinforcing rather than just fixing problems
Skip anything that's just discussion or venting without a concrete, extractable point — this isn't a transcript, it's a signal filter.
3. Capture source context, and weight by corroboration
For each item, note who raised it (role/team, not to judge the person but to weigh the signal — a pattern independently flagged by both sales and support is stronger than the same team mentioning it twice) and link the thread. If the same underlying issue surfaces from two different teams independently in the same week, treat that as a single stronger signal, not two separate line items — that corroboration is itself the most useful thing this skill produces.
4. Check against what's already tracked
Before adding anything as new, check it against the existing backlog and against the outputs of call-insight-extraction and feedback-triage-scoring. If it matches an existing tracked item, log it as reinforcement (with a count) rather than creating a duplicate.
5. Tag using the shared taxonomy
Use the same tags as the other skills in this repo — product area, severity/urgency, sentiment — so this output can be merged into the same triage process rather than living in a separate, disconnected list.
6. Handle urgent items out of band
Most of this should roll up into a weekly digest. The exception: anything tagged escalation/churn-risk that reads as time-sensitive should be flagged immediately to the relevant owner rather than waiting for the weekly rollup — a quiet retention risk is exactly the kind of thing this skill exists to catch before it's too late to act on.
7. Output format
## Internal Pulse — Week of [date]
**Escalations needing immediate attention:** [any urgent items, flagged separately at the top]
| Signal | Type | Source(s) | Corroboration | Tag | Status |
|---|---|---|---|---|---|
| [summary] | idea/bug/escalation/competitive/praise | [team(s) + thread link] | [single mention / corroborated by N teams] | [area/severity] | [new / reinforces #ticket] |
Anti-patterns to avoid
- Don't expand scope to channels beyond what's explicitly designated, even if a genuinely useful signal seems to be sitting in an adjacent channel — flag it to a human and ask before including it, don't just start reading it.
- Don't turn this into a real-time firehose that reply-bots every mention — that changes how people behave in the channel and degrades the signal you're trying to capture.
- Don't create a second, disconnected backlog — always check against the outputs of the other skills in this repo so signal accumulates in one place.
- Don't flatten corroborated signals into separate line items — the fact that two teams independently said the same thing is more valuable than either mention alone, and that value is lost if they're logged separately.
Example (illustrative, placeholder channels and companies)
Input (from #support-escalations and, separately, #sales-notes, same week): A support agent posts that three tickets this week all involve customers confused about a permissions setting after last month's redesign. Independently, a sales rep posts in #sales-notes that a prospect's IT admin flagged the same permissions screen as "confusing" during a security review call.
Output:
## Internal Pulse — Week of 2026-08-24
**Escalations needing immediate attention:** None this week.
| Signal | Type | Source(s) | Corroboration | Tag | Status |
|---|---|---|---|---|---|
| Permissions settings screen confusing post-redesign | Bug/UX | Support (#support-escalations), Sales (#sales-notes) | Corroborated — 2 teams, independent | Admin & Permissions / Important | New — no existing ticket found |
Note this became one line item, not two, and the corroboration column is what makes it worth escalating even though neither single mention would have stood out on its own.