Automations

Streampoint’s B2B event platform hit a scaling wall: every non-trivial event configuration required engineers to create the automations. Complex international events, geographic compliance rules, conditional content display, etc. The bottleneck capped account volume, delayed customer launches, and surfaced as a specific blocker during enterprise evaluations.

I led design on a self-serve visual rules engine that let event ops and customer success teams setup complex conditional logic without writing code. The interaction model balanced power-user capabilities (nested conditions, multi-depth rules, real-time evaluation) with accessibility for casual users who needed to handle common cases. Beta cut developer config requests by 85% and removed eng from the critical path on complex international events.

1. Developer bottleneck. Every customer configuration request required engineering. Significant delays.
2. Content personalization limits. Static event pages couldn’t adapt to attendee characteristics. Engagement and conversion suffered.
3. Enterprise sales friction. Lack of advanced automation surfaced as a specific barrier during evaluations, especially for large organizations.

The growth ceiling was literally engineering capacity, because every new event setup was a ticket. The opportunity was compounding: move config from eng to self-serve, free eng for platform work, shorten enterprise sales cycles, and grow account volume without growing headcount.

• Real-time rule evaluation is non-trivial. BE needed rework to support what the interaction model implied.
• One builder, two distinct user types. Power users (nested rules) and occasional users (basic show/hide).
• No-code assumption. Customers and CS are the target. Anything that looked like a code editor would fail.
• Multi-depth conditional logic. Real events need nested conditions. The visual language had to express depth without becoming a tree diagram.
• Competitive bar. Cvent and Bizzabo offered basic conditional logic but lacked intuitive visual builders.

Customer interviews surfaced two distinct automation needs: compliance-driven rules for regulated industries, and engagement-optimization rules for marketing teams. One builder had to serve both.

Competitive analysis on Cvent and Bizzabo confirmed feature parity wasn’t the bar. Both offered basic conditional logic. Neither had a visual builder that occasional users could learn without training.

Power users from CS were brought into the prototype loop early. Their multi-region compliance scenarios drove the depth features. The top priority was moving the workload from engineering to CS, so their scenarios were essential.

• Self-serve is a scaling essential. When setup tickets bottleneck growth, moving to self-serve compounds: eng time returns to platform work, customer time-to-live drops.
• Visual builders sell themselves to non-technical users but have to be designed for power users. The depth has to be real or power users bounce back to eng tickets. Designing accessibility in without losing depth was the whole job.
• Early feasibility review at low-fi saves mid-build rework. BE caught the real-time evaluation gap at wireframe stage. Avoided a rebuild.
• If repeating: build CS enablement materials earlier. Adoption depended on CS being able to confidently onboard customers; those materials shipped later than ideal.