Automations
Visual rules engine for Streampoint's B2B event platform. Cut developer configuration requests by 85% in beta by letting customer success teams build complex conditional logic themselves.
Case highlights
85% ↓
Dev config requests
during beta vs pre-launch baseline
Days saved
Event setup time
complex international events, eng off the critical path
Visual rule builder
Surface
nested conditions through hierarchy, no tree diagrams
- Developer bottleneck. Every customer configuration request required engineering.
- Content personalization limits. Static event pages couldn’t adapt to attendee characteristics.
- Enterprise sales friction. Lack of advanced automation was a specific barrier in evaluations.
Launch
Self-serve adoption
- 01 Developer ticket reduction for configuration requests.
- 02 Customer success teams handling configuration end-to-end.
- 03 Rules engine adoption rate among existing customers.
- 04 Configuration resolution time.
Strategy
Platform compounding
- 01 Eng capacity returned to platform work.
- 02 Enterprise deal velocity.
- 03 Customer time-to-live on complex events.
- 04 Differentiation against Cvent and Bizzabo.
- Two distinct automation needs: compliance-driven rules for regulated industries, engagement-optimization rules for marketing teams. One builder had to serve both.
- Competitive analysis on Cvent and Bizzabo: both offered basic conditional logic; neither had a visual builder occasional users could learn without training.
- Power users from CS were in the prototype loop early. Their multi-region compliance scenarios drove the depth features.
Wireframes-first to validate the interaction model with engineering before investing in high-fidelity. Real-time rule evaluation surfaced as a backend blocker at this stage and got reworked before high-fi started.
High-fidelity builder states. Same surface scales from a flat condition + action (occasional users) to multi-depth nested rules (power users).
REEL Final builder
Production rules engine in motion. Visual builder, real-time evaluation, accessible to CS teams without engineering involvement.
Visual builder, not code-like editor
Target users are customers and CS. A visual builder was the only form that could serve them. Accepted UI complexity in exchange for a fully self-serve experience.
Depth through hierarchy, not tree diagrams
Tree views are accurate but intimidating. Indentation, grouping, and visual hierarchy let occasional users read top-down without confronting a diagrammatic structure.
Power-user-informed iteration
Power users from CS were in the prototype loop from day one. Their multi-region compliance and regulated-industry scenarios drove the depth features.
-
85% ↓
Developer config requests
During beta. Customers and CS handled the vast majority of logic themselves.
-
Days saved
Event setup time
Complex international events. Developer involvement removed from the critical path.
-
Closed
Enterprise-evaluation blocker
Advanced automation gap was a specific barrier during enterprise evaluations for global organizations. Resolved.
-
Unblocked
Platform scalability
Engineering capacity was the growth ceiling. Self-serve config compounds: eng time returns to platform work, customer time-to-live drops.
-
Two user types
One builder
Occasional users (basic show/hide) and power users (multi-region compliance) both served by the same surface.
Deep dive
Curious about the specifics?
Adoption cohorts, revenue pivot data, prototype walkthrough videos, and the internal PRD are available on request during a portfolio review.