Ask a contact-center team what the IVR looked like six months ago and the honest answer is usually “we don’t know”. The current version is in the platform. Previous versions are in whatever exports somebody happened to save.

That is not negligence. The tooling does not encourage it and the work is often urgent. But the cost shows up at predictable moments.

What you lose

Root cause after an incident. Calls started misrouting on Tuesday. Something changed. Without history the investigation is reconstruction from memory, and memory is worst exactly when several people were editing under pressure.

Confidence to change anything. Teams that cannot roll back edit conservatively — patching around a problem instead of fixing it, because the fix is riskier than the workaround. Over a few years that produces the flow nobody wants to touch.

Knowing what “working” looked like. Rolling back is only useful if you know which version to roll back to.

Why the export is a good unit of history

A Five9 export is a .zip with one .five9ivr file per script. Each of those files is plain XML: every module, every connection, every condition, the prompt library, the script variables. It is complete — you can re-import it and get the same IVR back — and it is text, so two versions can be compared line by line.

That makes it a better artefact than most teams realise. A folder of dated exports is a full history of the IVR, with no infrastructure. The problem is not that the history does not exist; it is that nobody can read it.

The minimum that helps

You do not need a full engineering workflow. Three habits cover most of the value:

Export before you edit, not after. An export taken before a change is a rollback point. An export taken after is a record of the change but not an escape from it.

Name exports so they sort. 2026-08-25-main-before-holiday-hours.zip tells you when, what, and why. ivr_final_v2 (1).zip tells you nothing, and there will be four of them.

Write down why, not what. The what is in the file. The why — “Legal asked for the recording disclosure before the menu” — is the thing nobody can reconstruct later, and the thing that determines whether a future edit is safe.

Why diffs matter more than copies

A folder of exports is history, but it is not readable history. To answer “what changed between these two?” you have to open both and compare by hand, and the changes that matter most are the ones least visible that way.

Take the most dangerous edit there is: a branch that now points at a different module. In the file, that is one desc element inside one branches entry — a 32-character id that changed to a different 32-character id. Nothing else moves. The module names are identical. The canvas can look identical. A text diff will show you the line, buried among whatever else changed, and will not tell you that it means “callers who press 2 now go somewhere else”.

Compare that with the noisiest edit there is: dragging a node a few pixels. That changes locationX and locationY — two lines per module — and means nothing.

So the signal is inverted. A tool that understands the file as a graph can flip it back: match modules by moduleId, report a changed desc as a rewire, and report a changed coordinate as nothing at all. This is the specific gap ivrloom’s Compare versions view was built around. It reads two versions of a script and lists what moved — added and removed modules, changed fields on the ones that stayed, and rewired connections called out on their own — instead of leaving you to spot a changed id in four hundred lines of XML.

What to keep with each version

An export is the state. Two more things make it a version:

The reason, in one line. “Holiday hours for Thanksgiving week.” “Legal: recording disclosure moved before the menu.” “Removed option 6 — the campaign ended.”
The verification, if any. “Simulated the closed path with the clock set to 2026-11-26; reached the holiday message.” Even “dialled the main path once” is worth writing down, because it tells the next person what was and was not checked.

Neither needs a system. A text file in the same folder as the exports works. So does a spreadsheet with three columns. What does not work is nothing, which is the default.

If you want the history in one place

Saving a version in ivrloom is opt-in, and when you use it every save is a snapshot you can reopen from the History list, compare against the current version, and — if you work with other people — put through a pull-request review with comments before it is merged. A version you no longer want can be deleted from the same list. On Solo and above, each save also records what changed since the version before it, so you can read one script’s history in plain sentences, download a CHANGELOG.md between any two versions, or export only the scripts that changed. That gives you the folder-of-exports history without the folder, and the diff without opening two files — something the Five9 Script Designer does not keep for you (the side-by-side comparison lists the other differences).

But it is worth being clear that the practices above do not depend on it. A team that takes a dated export before every change and writes one line about why has ninety percent of the value of a version-control system, for free, using files they already have.

A note on who edits

The other half of version control is knowing who. In most centers, IVR access is a small group and the answer is “one of four people”. That is usually enough — as long as the change itself is recorded. The combination of a dated export, a one-line reason, and a diff you can read covers the overwhelming majority of “what happened here?” questions, without any process a busy team will abandon in month two.