Practical operating guide
How to update a phone script without breaking a working call flow
By ByTomorrow · Published
A small wording change improves one question but breaks an existing transfer or repeats a confirmation. The team remembers what changed, but cannot reconstruct the exact script that previously worked.
Updating a phone script is a behavior change. The old call paths still need to work after the new wording is introduced.
Diagnosis
Identify the failure before changing the flow
The draft is already on the live route
Retell documents that both draft and published versions can be attached to phone numbers. A draft label alone is not proof that editing is isolated from customers. Check the actual number or environment assignment.
Too many changes share one release
A new greeting, different voice and revised routing make a failure harder to attribute. Keep a change focused when possible and record every affected setting.
Rollback restores words but not dependencies
A prior script may reference a destination or field that also changed. Restoring that script cannot repair a removed dependency by itself.
Practical worksheet
A script-change checklist with before-and-after replay cases and rollback criteria
Change record
Fill in: observed problem ___; old version ___; proposed version ___; exact wording or rule changed ___; affected tools and destinations ___; owner ___; expected improvement ___. A preference without a concrete expected behavior needs clarification.
Before-and-after replay matrix
Use columns for scenario, expected outcome, old result, new result, evidence and reviewer. Include the motivating failure, a routine request, a correction, a human request, an unavailable action and the closing record. Keep synthetic inputs comparable.
Version and assignment check
Record the version actually used by the test route and the live route. Retell documents read-only published versions and movable environment tags. Verify assignments directly; a successful test of a draft does not identify what the production number uses.
Rollback criteria
Agree conditions such as a wrong destination, false action-success statement or loss of an essential confirmed field. Record the prior working version, dependencies it needs, rollback operator and verification case. Define how open customer requests will be reconciled.
Release evidence
After authorized activation, verify the actual route uses the intended version and inspect a permitted test call. Keep old and new results with the change record. A saved prompt is not evidence that the phone route switched.
Use the worksheet
Put it into practice
Capture the current working state
Record version, route assignments and dependent settings before editing. Keep the change in an isolated test configuration.
Replay affected and unchanged cases
Run the matrix, then inspect both the conversation and downstream records. Hold a release with an unresolved critical regression.
Switch under the agreed authority
Use the approved release process, verify the deployed route and apply the predetermined rollback if its conditions occur.
Questions
Straight answers.
Do not assume it does. Inspect whether each number is assigned directly to a version or follows a tag, and verify which version is active.
Scale the check to the change. If the text is spoken, interpreted as an instruction or used in a condition, verify the affected behavior before relying on it.
Sources and further reading
- Retell agent versions and environment tags
Supports editable drafts, read-only published versions, phone-number assignment to either type and movable environment tags. Regression matrix and rollback criteria are original recommendations.
Checked .
Bring a concrete example
Use a synthetic call and your current business rules to discuss this workflow. Confirm the intended behavior before enabling it for customers.
Discuss your workflow