RevOps/Sales Ops question: Are your teams drowning in alerts but don't know what actually needs attention? Building a revenue decision engine that filters cross-system noise (DocuSign/Stripe/QuickBooks/CRM) to surface only signals requiring human intervention. Need some early feedback on the same as currently in testing the water phase. Happy to share a demo for the same.
Interested in this — the cross-system noise problem is real. What's your approach to maintaining signal coherence when the sources have different data schemas/refresh rates? That's usually where decision engines either compound or fragment.
Simon L. yeah that's great question. Current approach (MVP) :
Web-hook-first for timeliness: Web-hook are instant, the enrichment happens on-demand or when threshold crosses (contract viewed 3x).
Abstraction - Currently, the signal is per system rather than unifying (will be handled later)
Noise filter: hard gates (value > $X, late-stage, assigned owner) + confidence scoring (e.g., 3+ views in 36h + no progress = high signal; single view + active product usage = low)
Refresh rate mismatches are tricky. Right now: - Web-hooks = instant - API enrichment = on-demand (when signal fires) - CRM data = polling every 15-30 min (eventually) So there's potential for stale context if I'm pulling CRM data that's 20 min old while web-hook is real-time. Honestly, I haven't fully solved coherence at scale yet. Currently testing with limited integrations where I control refresh. You said "compound or fragment" - have you seen this problem firsthand? What breaks first in your experience? And what would "good enough" coherence look like vs perfect? Would love 15-20 min to dig into this with you if you're open to it. You clearly think and know this stuff deeply.
The detail here is helpful! Refresh mismatch is where things crack, yeah. The problem isn't staleness — it's if/when the decision fires before context catches up. So for example, 20-min CRM lag + real-time webhook = system potentially acting on partial truth. Implications really depend on the specific customer/service it's for. "Good enough" coherence to me means the system knows what it doesn't know. Confidence degrades when context is stale, not just when signals are weak. Is staleness a scoring input for you yet, or just signal strength? Btw — is this a product you're building or internal for a company?
No, staleness is not part of scoring but I wonder would 20-min lag is going to be a problem(any ex.)? . I am building this product not for company. Also, I was thinking to build this product for Manager rather than individual with defined ownership for each such signal. what do you think ? Happy to share a small MVP demo.
Naren Yeah, the 20-min lag example — picture this: prospect views the contract a third time at 1am, DocuSign webhook fires instantly, your engine tags it high signal. But the AE had a call 30 min earlier where the prospect said they're going with someone else. AE updated the CRM to closed-lost at 12:45. Your last CRM poll was 12:40. So your engine sees: 3 views in 36h + active deal + late-stage + assigned owner. Everything passes. Manager gets a "high intent" alert on a deal that's already dead. At your current scale it's probably rare enough to shrug off. But when you've got 50 integrations with different refresh rates, every signal is potentially sitting on stale context somewhere — and the manager can't manually verify each one without defeating the purpose of the engine. That's why I'd bake staleness into scoring now rather than later. Doesn't need to be complex — even just flagging "CRM context is X min old" in the confidence output changes how the recipient treats it. System that knows what it doesn't know compounds trust. System that presents stale context with full confidence erodes it. I agree with targeting managers, that's the right call. Signals need someone with authority to act, not just observe. The thing I'd watch for: if every signal routes to one manager, you've just moved the drowning problem up a level. The architecture question is really about ownership routing — signal goes to the person who can close it, manager sees the pattern across signals, not every individual alert. That's what separates a decision engine (which I believe you're building towards) from a "smarter" dashboard. Happy to see the demo — send it over whenever!
Simon L. Yeah, great point about staleness. How exactly manager does today ? Currently I plan to assign to the person owner from the CRM data. Would you be willing to be part of pilot or introduce me to the group who would be willing to pay. Here's the demo - https://www.loom.com/share/765d5bceaa504485ba6b70fea7e30ec5 .
Naren I just watched the demo — the Slack-native approach is smart, especially for smaller teams who aren't going to check yet another dashboard. Genuine question: who specifically is receiving these alerts? A founder wearing the finance hat needs a different message than a RevOps person. Right now it feels a bit one-size-fits-all. Might work well for startups where one person IS the revenue team — but worth being deliberate about that.
