How to Change Your Call Flow Safely: Draft, Test, Publish

Tom Reed · Updated 17 October 2026

To change a call flow without losing calls, treat it like any other change to your business. Sketch the new flow on paper, build it as a draft, validate it, test it with a short script of real calls from outside, then publish at a quiet time and keep a copy of the old flow so you can put it back. Agree up front who is allowed to edit the flow and who approves the change. On SessionPBX, the Visual Call Flow Designer lets you "connect menus, schedules, announcements, ringing destinations and voicemail in a visual editor", then "save changes as a draft, validate the flow and publish when it's ready". It's part of Teams Business, which is a SessionPBX plan, not Microsoft Teams.

This guide is about changing a call flow you already have: sketching, ownership, drafting, testing, publishing and putting things back.

What is a call flow, and why do changes break it?

A call flow is the path a call takes from the moment someone dials your number to the moment it reaches a person, a ring group, a queue or a voicemail box. It usually includes a greeting, perhaps a menu, opening-hours rules, and somewhere for unanswered calls to go. If you need the basics first, our guides to the auto attendant phone system and the PBX phone system explain the building blocks.

Call flows rarely break on their own. They break when someone changes them. A new menu option points nowhere. Holiday hours are left switched on after the office reopens. A leaver is still in the sales ring group, so calls ring a phone nobody answers. A greeting mentions a team that no longer exists. Each change looked small, and none was tested from a caller's point of view. The routine below catches those mistakes before your callers do.

How do you sketch a call flow before you touch the phone system?

Start on paper, or in a spreadsheet, not in the phone system. A one-page call flow diagram forces you to answer the awkward questions first: what happens when nobody answers, when a caller presses the wrong key, and when you're closed.

Sketch the flow as it is today, then the flow you want. The difference is what goes in your change note. For each inbound number, write down:

• The greeting or announcement callers hear first.
• Each menu option, if you have a menu, and where it sends the caller.
• The destination: a person, a ring group, a queue or another part of the flow.
• The no-answer route: where the call goes if nobody picks up.
• The invalid or no-input route: what happens if the caller presses a key that isn't on the menu, or presses nothing at all.
• The out-of-hours route: where calls go when you're closed.

Call flow sketch template

Any empty cell is a gap a caller could fall into. If you're redesigning where calls should go, our guide to call routing for small businesses covers the design choices in more depth.

Who should be allowed to edit and approve call flow changes?

In a small business, the safest set-up is simple: one person owns the call flow, and a second person approves changes to it. The owner makes the edits and keeps the sketch current. The approver checks the change note, agrees the timing and helps with test calls. Name a backup for each, so a holiday doesn't stop an urgent fix.

Everyone else asks the owner rather than editing the flow themselves. Call flows touch every caller, and two people editing the same flow at once is a common way to end up with a menu nobody understands. Keep the list of people who can edit routing short, and review it when people join, leave or change jobs.

Every change gets a short written change note. A shared document or an email is enough, as long as it answers five questions. This is a phone-specific take on the general process in our guide to change management for small businesses.

Change note template

The last field matters most. If you can't say how you would put things back, you aren't ready to publish.

How do you build and validate the change as a draft?

Never build a change straight onto the flow your callers are using. Work in a draft, check it, and only then make it live.

On SessionPBX, the Visual Call Flow Designer is built around that routine: you "save changes as a draft, validate the flow and publish when it's ready". Whatever system you use, run through these checks on the draft before you publish:

• Every branch ends somewhere. Follow each path against your sketch. A route that leads nowhere is the most common way calls get dropped.
• Invalid and no-response routes are set. SessionPBX auto-attendant menus send each choice "to the right person, group or queue, with routes for invalid input or no response". Make sure both routes go somewhere sensible, such as repeating the menu once and then reaching a person or voicemail.
• Greetings and announcements are in place. SessionPBX lets you "upload or record greetings and announcements". Check every new menu has its recording, and that old recordings don't mention options you've removed.
• Opening hours and time zone are right. On SessionPBX you "set opening hours for each day and choose your time zone", then route calls differently when you're closed. Check the hours against the change note, and check the time zone if your team works across regions.
• Ring groups and queues have the right people. Ring groups let you set "how long to ring and where unanswered calls go". Queues let you set "ring times, maximum waiting time and an overflow destination". Check members, and check the unanswered and overflow routes against your sketch.

Run the validation once the draft looks right, and fix anything it flags before you go any further. Validation catches structural problems; it can't tell you whether a greeting sounds right. That's what test calls are for.

How do you test a call flow before and after publishing?

The only test that really counts is a real call from outside, made the way a customer would make it. Internal calls between extensions can skip parts of the flow, so use a mobile that isn't connected to your phone system. Check the draft against your sketch before publishing, then run the full script on the live flow straight afterwards.

Here's a simple IVR testing script to adapt. Two people make it quicker: one calls, one watches where it lands.

1. Call each inbound number from an outside mobile and listen to the full greeting.
2. Press every menu option in turn and confirm each one reaches the right person, group or queue.
3. Press a key that isn't on the menu and confirm the invalid-input route works.
4. Stay silent after the menu and confirm the no-response route works.
5. Call during opening hours and when you're closed, or temporarily adjust the hours in a draft, to check both routes.
6. Let a ring group ring out with nobody answering and confirm the call goes where your sketch says.
7. Let a queue call wait unanswered and confirm the overflow destination works.
8. Leave a voicemail and confirm it arrives with the person or team who should get it.

These are tests for you to run, not features of the phone system. Write the results down against the checklist below and attach them to the change note.

IVR test-call checklist

Any fail means you stop and fix it before calling the change done.

When should you publish, and how do you roll back if it goes wrong?

Publish at a quiet time: early in the morning, after closing, or during your slowest part of the day. Avoid Monday mornings and the day before a holiday. Tell the people who answer phones that a change is going live, so they can flag anything odd.

Straight after publishing, re-run a shortened test script: each number, each menu option, and one unanswered call. Then watch calls for the rest of the day. Ask reception and your ring group and queue members whether calls are arriving where they expect.

Rolling back is a process, and you prepare for it before you publish. Before you change anything, save the old flow: your before-sketch, plus screenshots of each part of the existing flow in the editor. If the new flow causes problems you can't fix quickly, the owner rebuilds and republishes the previous design from those notes, then runs the short test script again. Agree in the change note what counts as "going wrong", such as calls reaching the wrong team, so nobody debates whether to go back.

Once things are settled, update the sketch so it matches what is live. The after-sketch from this change becomes the before-sketch for the next one.

What call flow changes should you plan for every year?

Many call flow changes are predictable. Put them in a shared calendar with the owner's name against each, so they're planned rather than rushed:

• Bank holidays and closures. Christmas, Easter, public holidays and office moves. Plan the closed announcement, check where calls go, and set a reminder to switch back. Our guide to out-of-hours call handling covers what callers should hear when you're closed.
• Seasonal hours. Summer hours, late opening in busy months or reduced cover during quiet periods.
• Joiners, leavers and role changes. Add new starters to the right ring groups and queues, and remove leavers on their last day. Keep extensions tidy too; our guide to a phone extension numbering plan helps.
• New numbers and campaigns. A new marketing number, a new product line or a new office needs its own route, sketched and tested like any other change.
• Greeting refresh. Review greetings and announcements at least once a year, and whenever services, hours or team names change.

It's also worth reviewing your flow when the same calls keep getting transferred. If reception passes the same kind of call to the same team every day, a menu option or a dedicated number may serve callers better; see our guide to warm and blind transfers for when to fix routing instead of transferring.

Call flows on SessionPBX

SessionPBX is a hosted PBX with native apps for desktop and mobile. Its Visual Call Flow Designer lets you "connect menus, schedules, announcements, ringing destinations and voicemail in a visual editor. Save changes as a draft, validate the flow and publish when it's ready." Around it you get auto-attendant menus "with routes for invalid input or no response", business-hours routing where you "set opening hours for each day and choose your time zone", ring groups, call queues with an "overflow destination for callers who need another route", and the option to "upload or record greetings and announcements". These features are part of Teams Business. Teams Phone and Teams Business are SessionPBX plans, not Microsoft Teams. If you're comparing systems, our hosted PBX call queues and IVR buyer guide and overview of the cloud-based phone system are good next reads. Compare plans and start a free trial on the SessionPBX hosted PBX page.

FAQ

What's the difference between a call flow and an auto attendant?

An auto attendant, or IVR, is the menu step: the greeting that asks callers to press a key. The call flow is the whole path, including opening hours, ring groups, queues, overflow and voicemail. Our auto attendant guide covers the menu itself.

How often should you test your call flow?

After every change, and before planned closures such as bank holidays. Between changes, a quick routine check from an outside mobile is sensible, because staff changes can quietly break a flow nobody has touched.

Can I change my call flow without taking the phones offline?

On SessionPBX, you save changes as a draft, validate the flow and publish when it's ready, so you can build and check a change without editing the live flow as you go. Publish at a quiet time and run the short test script straight afterwards.

Who should own the call flow in a small business?

One named person, usually whoever already looks after the phone system, with a named backup. A second person approves changes and helps with test calls. Keep the list of people who can edit routing short.

Do I need a diagram tool to map my call flow?

No. Paper or a spreadsheet using the sketch template above works well for most small businesses. A visual editor helps when you're building the flow, because you can see each branch and spot ones that lead nowhere.