Why we built ivrloom — and why your files never leave your browser

Update, October 2026: signed-in projects now save to ivrloom automatically by default — the parsed project, not the file — because work kept only in a browser was lost when that browser’s data was cleared. A workspace owner or admin can turn it off. The .zip itself is still never uploaded, and prompt audio never leaves your browser.

If you’ve ever opened the Five9 IVR Script Designer, you know the feeling: a Java window from a forgotten decade, a flat list of script files, no undo to speak of, no way to make the same edit across thirty flows. You change one menu prompt and spend the rest of the afternoon clicking through the same screens.

We started ivrloom because the next time we’d have to do that, we’d rather quit.

The plan in one sentence

Drop a Five9 .zip export, edit it visually with bulk refactoring and an AI assistant, download a modified .zip, re-import to Five9. No API integration. No credentials. No cloud round-trip for your bundle. Your IVR stays on your machine.

Why offline-first matters

We had two paths early on. The first: integrate with Five9’s Configuration Web Services API, store admin credentials in a vault, push edits live. The second: ingest a .zip export, edit in the browser, emit a .zip the admin re-imports themselves.

The first path was tempting because of the “one-click push” UX. It was also a non-starter for everything else:

• The SOAP API doesn’t support MFA, so customers would have to create dedicated service accounts
• IP allowlists at most Five9 customers force a static egress IP before the first deal
• SOC 2 Type II becomes a prerequisite for selling — $45K and 6-12 months
• Liability for a bad push is catastrophic (dropped live calls)
• Procurement reviews kill $99/mo SaaS that touches production systems

Offline-first removes most of these costs in exchange for a 3-step manual workflow (export → edit → re-import) that admins already know. We ship faster and carry far less compliance burden at v1. The marketing story flips from defensive (“trust us with your credentials”) to offensive (“your IVR stays on your computer by default”).

That last bit isn’t marketing fluff: we literally don’t have a backend endpoint that receives .zip files. ZIP parsing, IR transformations, and the editor canvas all run client-side in your browser. Your bundle never touches our servers unless you choose to save a version of it — and AI assistance sends only the slice you ask about to our AI provider, with the exact data flow described on the Security & Privacy page. Everything else stays local. (Updated 2026-09-25: “Cloud Save” is now called saving a version, and a test scenario you save in the simulator of a signed-in project is stored with the project too — the Security & Privacy page lists both.)

What’s coming

The current build does the basics: drop a .zip, see every flow in a sidebar, pick one to edit on a React Flow canvas, simulate a call by queueing DTMF inputs, export a modified .zip. The simulator engine is also the test framework — every fixture has named scenarios that auto-run in CI.

Next up:

1. AI chat with structured tool use — natural-language bulk refactors like “add a high-volume announcement before every Spanish skill transfer.” Runs against your bundle locally; only the relevant slice of IR is sent for processing.
2. PR-style change review — every modification surfaces as a diff you can check before download (AI changes need your approval first). Saved scenarios re-run automatically to flag path regressions before you commit.
3. Genesys Cloud, NICE CXone, Amazon Connect — the IR is platform-agnostic from day one. Five9 is the first vendor implementation, not the only one.

If you’re a Five9 admin who’s tired of waiting through Java startup screens, we’d love to hear from you: hello@ivrloom.com.