This is a design/engineering write-up for our EchoStack pivot. We’re packaging Voice-AI playbooks (like After-hours Answering and Lead Qualifier → Auto-Book) into deployable solutions with no-code setup, safe rollouts, and KPI tiles.
Status: Early Access only — we’re validating integrations and rollout safety with a small group before opening signups.
Why playbooks (not tool soup)
Teams don’t buy models; they buy outcomes: fewer missed calls, more booked meetings, lower AHT. The hard parts are barge-in latency and safe deployment, not the LLM itself.
Latency budget we hold ourselves to (p95 targets)
- ASR partials: 60–90 ms
- LLM first token: 80–120 ms
- TTS first audio: 50–80 ms
- Network buffers: 40–60 ms → Goal: < 300 ms p95 end-to-end (barge-in friendly).
Rollout safety (what we’re building)
preflight → plan → apply (blue) → smoke test → switch (green) → rollback
- Preflight checks scopes, latency probes, and config drift.
- Plan shows a human-readable diff.
- Apply deploys to an inactive slot (blue).
- Switch flips traffic; Rollback is one click.
Integration surface (first adapters)
- Telephony: Twilio/Plivo/SIP
- Voice agent: Retell (others later)
- Calendar: Calendly/Google
- CRM: HubSpot/Salesforce (Sheets fallback)
- Helpdesk: Zendesk (optional)
What exists today
- Data model + manifests for two playbooks
- No-code configuration flow (internal)
- Preflight → plan → apply skeleton
- KPI tiles (self-serve %, AHT, booked meetings) wired to session events
What we’re validating next
- Region-aware routing under load
- Failure modes during blue/green switches
- Adapter ergonomics (CRM/calendar/telephony edge cases)
Looking for feedback
- Are these p95 targets realistic for your use case?
- What minimum logs/SLAs make you comfortable with rollout?
- Which adapter combo should be prioritized?
More context: https://getechostack.com/playbooks
Early Access (no public demo yet): https://getechostack.com/contact?subject=Early%20Access
Top comments (0)