Leon B.

That's the whole game, turning a score into a sentence. "Call this account because X just happened" is doing three things at once: it surfaces the signal, it removes the interpretation step, and it tells the rep exactly where they are in the buying cycle. The score was always just a proxy for that sentence. Once you build toward the sentence as the output, the warehouse architecture question almost answers itself.

Ayse G., you nailed the blocker. Most founders try to own the new category that's the costly play. But Rashi doesn't have to. She anchors to "the execution layer that replaces your GTM rules engine." That's not a new category, it's a replacement narrative. Every RevOps leader has spent the last two years wiring tools together with brittle if/else workflows that break when a campaign pivots. She's the alternative to that broken workflow, not a new thing to learn. When you see the tech, test that framing in discovery and watch if it moves faster than the category approach.

Rashi A., one more thing as you run the positioning exercises: test "Stateful GTM Architecture" against your ICP first. VPs of RevOps and Sales Ops will get it immediately. Sales leaders might need the execution angle (no more manual state rebuilds when campaigns pivot). Watch which language moves faster in discovery. Also curious what you discover about the 500+ account state problem that's where you'll find your strongest proof points.

Alexandra B., the first loss-of-state event was usually 3-4 weeks into a campaign when context dropped. A rep touches an account, moves on, comes back two weeks later and the custom script that was enriching data based on previous touches now has no memory of what we learned. The fix requires either: (a) rebuilding the entire context on every interaction (expensive), or (b) storing state in a separate system and syncing it back (latency + manual work). Most teams choose (c): give up and let the rep operate from what they see in Salesforce. That's why stateful architecture is the actual moat. What's the state problem you're bumping into?

Rashi, the architecture is clean, but Vern's point lands hard: if the messaging output lives in your system and the rep has to context-switch to send it, you've still got the latency problem we talked about with Nikhat. How are you collapsing that into the rep's existing workflow? Because "tell reps what to say" still requires them to leave their tool to execute it.

Exactly. We're seeing this with Obvio's enforcement data the jurisdiction officers have three tools they live in (their dispatch system, email, a city portal). The signal has to collapse into one of those, not exist in a fourth dashboard. Otherwise it's theater.

Hey Constantin, I’m doing this right now but moving beyond basic "Skills." I built a custom Python engine that uses LLMs to scrape ATS data (Greenhouse/Lever) for high-intent hiring signals. Instead of spending hours on Apollo or Lemlist, the script finds the leads and drafts the outreach logic based on their specific technical needs. It’s basically building your own "Sovereign Agent" for your pipeline. Sourcing is the easiest thing to automate once you stop looking for 'lists' and start looking for 'triggers.' Happy to show you the architecture I’m using.

Hey Anoushka, I’d love to help with this. I’m a GTM Architect with an MBA, but I also run a project called "The Human Mechanic" where I help people untangle their relationship with tech. I’ve worked with tons of founders and I’m great at asking the deep "architecture" questions that get people talking without the usual boring corporate speak. I'm based in Mountain View but I can be in SF whenever you need. Happy to chat if you're still hunting for someone.