Customer Discovery Plan: Notification volume from Slack alerts is overwhelming and uncontrollable

Problem Statement

FlowPilot users across startup, team, and SMB segments are experiencing unmanageable Slack notification volume, with no controls for filtering by severity, batching into digests, or setting quiet hours. This all-or-nothing notification model has led users to mute the FlowPilot Slack channel entirely, creating a secondary problem where critical workflow failure alerts go unnoticed. The absence of granular notification settings is a consistent, high-confidence complaint that undermines the core value of Slack-based alerting.

Evidence Summary

20 feedback items span startup, team, and SMB segments, with 17 rated MEDIUM severity and 3 rated LOW, indicating a broadly felt and moderately urgent issue. Startups report muting channels entirely ('I turned off all Slack notifications because there were too many. Now I miss the important ones.') and team-level frustration ('My team is annoyed.'). Team segment users explicitly call out the lack of severity filtering ('I need to filter by severity, not every error needs immediate attention') and missing quiet hours ('Getting Slack pings at midnight is too much'). SMB users confirm the all-or-nothing problem ('Please add notification settings. Right now it's all or nothing') and express a desire for failure-only alerts ('I want to be notified only when a workflow fails, not every time it runs'). Digest-style batching is requested by both startup and team users. No segment reports satisfaction with current notification behavior.

Priority Rationale

The signal scores 78/100 with high confidence, reflecting strong cross-segment consistency and a clear pattern of workaround behavior, muting channels, that actively degrades product value. The problem affects all three surveyed segments (startup, team, SMB), meaning it is not niche. The downstream consequence of missed critical alerts represents a trust and reliability risk for FlowPilot that compounds over time. Addressing this now prevents further channel-muting behavior and alert fatigue from becoming an entrenched user habit.

Acceptance Criteria

• Users can configure Slack notifications to trigger only on specific event types, at minimum distinguishing between workflow failures and successful runs, as requested by SMB users ('I want to be notified only when a workflow fails, not every time it runs').
• Users can enable digest-mode notifications that batch multiple events into a single Slack message on a configurable interval, addressing startup and team requests for batching ('Is there a way to batch notifications? I don't need one per workflow run').
• Users can set severity thresholds so that only alerts meeting a defined severity level are sent to Slack, addressing team and startup feedback ('I need to filter by severity, not every error needs immediate attention').
• Users can configure quiet hours during which non-critical Slack notifications are suppressed or deferred, addressing the team segment request ('Can I set quiet hours for notifications? Getting Slack pings at midnight is too much').
• After the feature ships, the rate of users reporting they have muted the FlowPilot Slack channel decreases measurably, validated through follow-up survey or in-app instrumentation tracking active Slack notification configurations.

Hypothesis

If FlowPilot provides granular Slack notification controls, including severity-based filtering, digest-mode batching, and quiet hours, then users who have muted or reduced notifications will re-engage with Slack alerting, reducing missed critical alerts while eliminating low-value notification noise, because the evidence shows the current all-or-nothing model is forcing users to choose between alert fatigue and operational blindness.

Target Accounts

• ·Startup segment users who have explicitly muted the FlowPilot Slack channel, as they represent the most severe failure state, complete disengagement from alerts, and can speak to the specific volume thresholds that triggered that decision.
• ·Team segment users who cited team-wide annoyance or midnight pings, as they surface both a quiet hours use case and a workspace-level impact that may require admin-level controls rather than individual preferences.
• ·SMB segment users who requested failure-only notifications, as they articulate a clear and simple threshold-based use case that could validate the minimum viable version of severity filtering.
• ·Team or startup users who described difficulty distinguishing which errors need immediate attention, as they can help define the severity taxonomy and labeling logic that would make filtering meaningful rather than arbitrary.

Discovery Questions

1. Walk me through what happens in Slack on a typical day when FlowPilot is running, how many notifications do you receive and how do you currently decide which ones to act on?
2. You mentioned the volume is overwhelming, have you changed any Slack settings or FlowPilot settings to cope with this? If so, what did you change and what was the tradeoff?
3. When you think about a Slack notification from FlowPilot that you would never want to miss, what does that look like, what event, what severity, what context does it need to include?
4. If you could only receive one Slack message per hour from FlowPilot instead of one per event, what information would you need in that message to feel confident nothing critical slipped through?
5. Have you or your team ever missed an important workflow failure because of how your Slack notifications are currently configured? What happened and what was the impact?
6. If you could design the ideal notification system for FlowPilot from scratch, what controls would you want, and are there any tools you currently use where notifications work the way you wish FlowPilot's did?
7. How do different people on your team feel about the current notification volume, is this a personal preference issue or has it caused coordination or reliability problems across the team?

Open Questions

1. Is the notification overload primarily driven by high workflow run frequency, step-level granularity of alerts, or both, and does the answer differ meaningfully across segments in a way that should shape the default configuration?
2. Do users want notification preferences set at the workspace or channel level, or at the individual user level, given that team-segment complaints reference team-wide annoyance, suggesting workspace-level controls may be more important?
3. Are there specific workflow types or failure categories that users universally want alerted on regardless of other settings, which should inform safe defaults that prevent critical alerts from being silenced?