We want to improve how Staircase detects and surfaces risk-related events (e.g., “Extremely negative sentiment,” support escalations). Some customers report too much noise; others want higher recall. We’re exploring configurable sensitivity, simple presets, tenant-specific examples, consolidation of similar events, and clearer context in the timeline.
Your input will guide what controls we build and how different personas (execs, managers, CSMs) consume these signals.
Context for you:
- Current pain: Overfiring for some tenants, mixed accuracy, negative vs extremely negative imbalance.
- Directions being considered:
- Sensitivity presets (loose/medium/strict), optional per persona or account tier
- Tenant-provided examples to tune what should/shouldn’t trigger
- Consolidation of similar events and lightweight context/hover summaries
- Possible split of signals (support escalation vs sentiment vs high-severity alert)
- Optional admin rename of event types to match internal language
- Goals: Improve signal quality and reliability, reduce noise, keep critical issues visible, and fit different org needs without heavy admin lift.
Questions
How should we balance sensitivity and control so these signals are trusted, actionable, and aligned to your org’s workflows?
Supporting questions:
- If we offered presets (loose/medium/strict), how would you want to apply them: globally, by persona (exec/manager/CSM), by account tier, or another way?
- What feedback controls are most valuable: submitting “should trigger/should not trigger” examples, renaming event types, consolidating similar events, or routing rules (who sees what and where)?
- In your day-to-day use, what minimal context do you need with each event (e.g., key quote, who said it, artifact link, severity rationale) to decide whether to act without opening the full thread?
