The Slack notification that would have posted 200 times on day one

I’m building a bridge that polls ConnectWise tickets and posts updates to Slack.

The premise is simple: MSP technicians live in Slack, not in ConnectWise. When a ticket changes status or a customer posts a reply, you want to know in the channel where your team already is — not via email, not via CW’s built-in notification system, not by checking the queue every few minutes.

I had the basic flow working in a weekend. Cron fires every 60 seconds, checks for updates, posts to Slack.

Then I ran it for the first time on a real tenant and it posted 200 messages in 10 seconds.

The flood

The bridge had never seen the tenant’s ticket queue before. From its perspective, every open ticket was “new.” Every one of the 200 open tickets was a NEW notification. The Slack channel got a wall of messages before I could close my laptop lid.

The team muted the channel. Nobody un-muted it.

This is the first failure mode of any notification product: the day-one flood. It happens whenever you install something that’s supposed to tell you about events, and the system has to figure out what it already knew.

The fix is a concept I’m calling “quiet bootstrap” — the first time you poll, you learn the world without telling anyone about it. You snapshot everything you see, advance the cursor, and emit nothing. The second tick is the first one that can produce notifications, because now you have a baseline to diff against.

def tick(self, tenant_id: str) -> TickResult:
    prior = self.state.load_snapshots(tenant_id)

    if self.quiet_bootstrap and not prior:
        # First ever tick: learn, don't notify
        snapshots = self._fetch_current_state(tenant_id)
        self.state.save_snapshots(tenant_id, {s.id: s for s in snapshots})
        self.state.save_cursor(tenant_id, max(s.updated_at for s in snapshots))
        return TickResult(bootstrapped=True)

    # Normal tick: diff against prior state, emit events
    ...

One branch. Every notification product that processes an existing state needs this.

The ongoing noise

Quiet bootstrap fixes day one. It doesn’t fix day 47.

After three weeks of running the bridge, the team was getting 30+ Slack messages per hour. Every time a tech added a note, every status change, every time a customer replied — notification. The channel became background noise. People stopped reading it.

This is the second failure mode: the ongoing flood. Not a burst, but a slow accumulation of signal that nobody asked for.

The fix for this is digest mode. Instead of posting every event in real time, the bridge batches updates and posts a digest on a schedule (every 15 minutes, or every hour, or once a day — configurable per channel).

The digest has a different shape than a notification:

📋 ConnectWise updates — last 15 min

🆕 NEW — SR-14523: Intermittent VPN disconnects (Acme Corp)
↳ Status: Open · Priority: Medium

✅ RESOLVED — SR-14518: Email sync failure (Contoso Ltd)
↳ Closed by: Tim S. · Time: 3h 45m

💬 2 customer replies — SR-14491, SR-14511

Five events that would have been five separate pings are now one compact block that someone can scan in 3 seconds. The channel stays low-traffic. The information density is the same.

I ship both modes — real-time and digest — and let the channel’s admin choose. The default is digest, because that’s the one that doesn’t destroy the channel’s signal-to-noise ratio.

Why I’m building this

Every MSP I know has a version of this problem. CW notifications go to email. Nobody reads email. Slack is where the team lives. There’s no good connector.

The existing connectors I could find were either enterprise-pricing ($200+/mo for a multi-tenant bridge), brittle (using CW webhooks that require inbound internet access to the customer’s CW On-Premise instance), or too generic (Zapier works but requires building a multi-step zap per tenant and has no concept of a digest).

I wanted something that: polls (no inbound firewall holes needed), handles both cloud and on-premise CW, has a sane default mode (digest, quiet bootstrap), and costs like a utility ($25/mo for a small MSP).

That’s what I’m building. I’m running it in beta now and looking for MSPs to try it.

The quiet bootstrap pattern and the digest mode are the two things I got right. Everything else is plumbing.