Everyone seems to think Sembly's "follow-up detected" feature is a productivity miracle. I see it as another notification stream waiting to be piped somewhere useful—or at least somewhere you'll actually notice it before the quarter ends.
Since Sembly thoughtfully provides webhooks, we can make Slack nag you instead. You'll need admin access to both services. In Sembly, navigate to the team settings and find the webhook section. Create a new one, pointing it at a Slack incoming webhook URL (you'll have to set that up in Slack's app config first). The payload Sembly sends is a bit sparse, so you'll likely want to use Slack's Block Kit builder to format it into something vaguely human-readable. The key is mapping Sembly's JSON to something that includes the actual follow-up item and the meeting it came from, otherwise you're just getting an alert that says "something happened."
It's about five minutes of configuration, which is five minutes more than you'll save if the alert just drowns in the other channel noise. But at least it's not another email.
/c
Beware of free tiers
> "It's about five minutes of configuration, which is five minutes more than you'll save if the alert just drowns in the other channel noise."
You're being generous calling it five minutes. I've done this exact pipe twice now (different CRMs, different quarters) and the real time sink is figuring out what Sembly actually sends when the webhook fires. Their docs claim the payload includes "follow-up items" but half the time the field is null or nested under some meetingId object that Slack's Block Kit can't parse without a Zapier middleman. So now you're either writing a tiny middleware yourself or paying for another connector.
My experience: the alert becomes useful for exactly one week, then you start ignoring it because Sembly's "follow-up" detection is about as accurate as a coin flip. Half the alerts are actually action items from someone else's meeting that got cross-tagged. The other half are things like "check email" which isn't a follow-up, it's a generic command.
Still, if you're the type who likes to see every pipe fail before moving on, this is a solid first step. Just don't expect it to fix your quarter-end procrastination.
That's a fair point about the payload. I've seen the same thing with webhook implementations that don't match their own documentation. It creates more work than it solves.
Your second point on detection accuracy is the real blocker, though. If the source data is unreliable, automating the alert is just a faster way to get bad information. I've found you have to manually verify the detected items for a solid month before trusting the automation, which defeats the purpose.
Have you found any other service that handles this with better precision, or is the whole "AI detected follow-up" category still not ready?
—AF
You're right about the payload being the real time sink. I've spent more time mapping that JSON than I did on the actual integration.
The detection accuracy is another layer entirely. We ran a similar pipeline and found ourselves tuning the alert rules more than we were acting on the alerts. It became a feedback loop where you're essentially training the system post-hoc. If you're not prepared for that maintenance, the setup time is indeed a lot longer than five minutes.
Stay grounded, stay skeptical.