What "The New Phone System Is Terrible" Actually Means
Before the plan, the diagnosis — because the plan is shaped entirely around preventing four specific outcomes.
"Calls go to the wrong person"
The routing model was never decided; it was assembled by whoever built it, from a description given in a meeting. Prevented on day one by choosing between receptionist, menu and ring-group deliberately, and on day four by drawing it before anybody opens a console.
"Nobody knows how to transfer"
Training happened once, before anyone had a real question, and then never again. Prevented on day twelve by a one-page card, and on day fourteen by a second fifteen-minute session when people finally have something to ask.
"The after-hours message is wrong"
Nobody made the after-hours decision, so a default was left in place, and the state your business is in for two-thirds of every week was configured by accident. Prevented on day two, tested on day eleven.
"It doesn't ring on my mobile"
Almost never an app fault. Usually notifications never allowed on iOS, or aggressive battery optimisation on Android, or the person simply never signed in. Prevented on days nine and ten by verifying with a real test call to each person rather than asking whether they installed it.
Four failures, four different days in the plan, and not one of them is a property of the platform you chose. That is why the sequence matters more than the shortlist.
The premise of this plan
Days 1–2: Decide, Before Anything Is Ordered
Nobody can do this part for you, and every hour spent here saves several later. Four decisions and one inventory.
- Seat types, not headcount. How many full seats with a desk phone, how many app-only seats for people in the field, how many shared seats for a workshop, reception or a warehouse, and how many common-area devices. This list — not the number of employees — is the biggest single lever on your monthly bill, and it is the one most often filled in as "one each" by default.
- The routing model. A receptionist answers everything, a menu splits by department, or calls ring a group directly. Under about thirty people, a group beats a menu almost every time. Pick one now, because rebuilding a routing model after go-live is exactly where confusion comes from.
- The after-hours position. What happens at 7pm, on a Saturday, and on Boxing Day. A message, a mailbox, a diversion to a mobile, an AI answer, or a real on-call rotation. Decide it as a business question — how much is an after-hours call worth to you — rather than as a configuration detail.
- What it must write into. Name the systems where work actually happens: CRM, calendar, job management, ticketing, accounting. If the honest answer is "nothing", say so. If it is a CRM, that changes which quote you should accept, which is why this belongs on day one rather than in month three.
- The number inventory. Every number you publish: main line, direct lines, 1300 or 1800, fax lines that a supplier still uses, alarm and lift diallers, and the number painted on the van or sitting in your Google Business Profile. Then, for each one, confirm in writing who holds rights of use. A number registered to a marketing agency or a departed IT provider is the most common unpleasant surprise in this whole process, and day one is a much better time to find it than day thirteen.
Name one owner while you are here
One person, with authority to approve greetings, hours and routing without convening a meeting. Projects without this person do not fail dramatically — they drift, and drift is how a fourteen-day plan becomes five months. If you take one thing from this article, take this: the presence of a named internal owner is the most reliable predictor of a good phone system outcome, ahead of budget, platform and provider. Our note on the setup decisions that stick goes through the four choices in more depth.
Day 3: Lodge the Port
Porting is the only item with elapsed time you cannot compress, so it goes early and everything else is scheduled around its confirmed date — not around a hopeful one.
| Do this | Because |
|---|---|
| Copy the details from a current bill, character for character | Legal entity name, account number and service address are matched strictly. "Pty Ltd" against "P/L" is enough to reject the request and cost a week. |
| Lodge every number at once, including the forgotten ones | The fax line a supplier still uses and the alarm dialler are the two that get found after cutover, when it is expensive. |
| Anchor the go-live to the confirmed date | Announcing a date to the business before the port is confirmed is how credibility gets spent early in a project that needs it later. |
| Do not cancel the old service | Cancellation before completion is the one action that can genuinely lose a number permanently. It usually happens when somebody tidies the supplier list mid-project. |
| Ask what happens if it slips | Ports slip. The right answer is a defined interim — calls diverting to the new system while the old service stays live — not an improvised morning. |
| Identify anything not portable now | So you have ten days to arrange a diversion and update listings, rather than ten minutes. |
Rights of use is a commercial question, not a technical one
The number on your signage, your vehicles and your Google listing is a business asset, and whether you own it or effectively rent it determines whether changing provider is a project or a negotiation. Check it on day one, fix it if it is wrong, and do not accept a verbal assurance. Our note on the 1300 number rental trap explains what to look for and how to get it corrected.
Days 4–5: The Call Flow, and the Network
An hour with a pen on day four prevents most of what would otherwise surface in week one. Answer eight questions, on paper, before a console is opened.
| Question | Decide | What goes wrong if you skip it |
|---|---|---|
| Who rings first, and for how long? | A group, not an individual, for 15–20 seconds. | One person's lunch break becomes a missed call. |
| Then who? | An overflow group, engaging on a stated timer. | Everything falls to voicemail after one attempt. |
| What does a waiting caller hear? | Ringing, music, a position, or a callback offer. | Silence, which callers read as a dropped call in about eight seconds. |
| When does waiting stop? | A maximum, then something definite happens. | An unbounded queue. Nobody waits four minutes. |
| What are the real hours? | Actual opening hours plus twelve months of public holidays. | Hours copied from the website, which were also wrong. |
| Outside them? | The day-two decision, made concrete. | A stock default greeting saying nothing useful. |
| How does a caller reach a person? | An escape at every step of any automated path. | A menu with no way out, which is the fastest way to lose a caller. |
| What shows on outbound calls? | Which number each team presents, and whether it can be rung back. | Customers storing a direct line instead of the main number. |
Then, on day five, the network and power check — half a day that prevents the hardest class of problem to diagnose later, because by then everyone has already decided the phone system is bad.
Wired
Desk phones on cable. Wi-fi is fine for a mobile app and a poor choice for a fixed device that will be blamed for every crackle.
Upstream
Check the upload direction, not just download. Concurrent calls plus video plus a cloud backup at 4:55pm is an upstream problem.
Priority
Quality of service so voice wins against a large file sync. Cheap to configure, invisible when it is missing until it is not.
Power
Modem, router and switch on a UPS, so a five-minute blip does not take the business off the air. Check switches supply power over Ethernet too.
Days 6–8: Build
Mostly the provider's work, but two of these ten items are yours and both are regularly left to the last afternoon.
| # | Build | Owner |
|---|---|---|
| 1 | Users, extensions, seat types | Provider |
| 2 | Groups and queues — the routing skeleton | Provider |
| 3 | Hours, holidays and the after-hours path | Provider, from your day-two decision |
| 4 | Greeting scripts, written and recorded properly | You — this is one of the two |
| 5 | Inbound routing for every number on the inventory | Provider |
| 6 | Outbound caller ID per person and per team | Provider, from your decision |
| 7 | Voicemail, transcription, and who receives shared mailboxes | Shared |
| 8 | Emergency calling addresses for every device and app | Shared — confirm each one |
| 9 | Integration credentials and field mapping | You — this is the other one |
| 10 | Recording notification wording, retention and access roles | Shared |
Two things worth ten minutes each on day six
Record greetings properly. A greeting recorded on a mobile in an open office is audible to every caller for years. Use a quiet room and a decent microphone, or have them produced. Confirm emergency calling addresses per seat. Cloud services can be used from anywhere, which is precisely why the registered address against each device and each mobile app matters, and why staff should be told plainly what a mobile app does and does not convey in an emergency. Our guide to Triple Zero and cloud phone systems covers what to tell people.
Days 9–10: Devices and the App Rollout
The most underestimated two days in the plan, because the work is fifteen minutes multiplied by everybody, and everybody is busy.
- Handsets arrive labelled. Provisioned so they configure themselves when plugged in, and labelled by user before delivery. Plug them in, and make one call from each.
- Walk-test cordless coverage physically. Warehouses, workshops, clinics and venues. Coverage problems found after go-live get blamed on the phone system rather than on the building.
- Headsets to anyone on the phone over an hour a day. The cheapest large improvement in call quality that exists.
- Desktop app installed and signed in on every machine that needs it, with a five-minute walkthrough while you are standing there.
- Mobile app — and then verify it. Installed, signed in, notifications allowed, battery optimisation exempted, and a real inbound test call made to each person. Not "did you install it?" — an actual call that actually rings.
This one step removes most week-one complaints
"It doesn't ring on my mobile" is the single most common week-one report, and it is almost never an application fault. It is notifications never allowed on iOS, aggressive battery optimisation on Android delaying or silencing the alert, or somebody who never signed in at all. Ten minutes of verification by test call on day ten prevents a fortnight of tickets and, more importantly, prevents the team forming the belief that the new system is unreliable — a belief which is very hard to reverse afterwards.
Day 11: The Test Script
Two people, two hours, written down, and no going live with an open line.
| # | Test | Passes when |
|---|---|---|
| 1 | Main number from an external mobile | Reaches the designed group, correct greeting, within 2 seconds |
| 2 | Every other number individually | Each lands where the paper design says — fax and alarm lines included |
| 3 | Overflow when the first group does not answer | Engages on time, caller hears something meaningful |
| 4 | Outbound from a desk phone and the mobile app | Correct number presented, checked on the receiving handset |
| 5 | Blind and consultative transfer, including a refused transfer | All three behave, and the caller is never orphaned |
| 6 | Hold, park, retrieve from a different device | Clean audio, no drops |
| 7 | Voicemail: leave, notify, retrieve, transcribe | Right person, within a minute |
| 8 | After-hours path, by changing the hours | Correct greeting, correct destination |
| 9 | A public holiday rule | Fires correctly — the test nobody runs and everybody needs on 26 December |
| 10 | Emergency calling address per device and app | Correct address held for every seat |
| 11 | Integration write | A real record lands in your CRM against the right contact |
| 12 | Call quality both directions, wired and mobile | No jitter, echo or one-way audio |
| 13 | Unplug the internet | Calls divert as designed, within the expected time |
| 14 | Every person makes and receives one call | Everyone is signed in and audibly notified |
Day 12: Brief the People
Fifteen minutes, one page, per group. Not a training course — a card people can keep next to the phone.
What goes on the card
How to transfer (both kinds), how to park and retrieve, how to reach voicemail, how to log in and out of a queue, what the after-hours path does, and one phone number to ring if something is wrong. Six things. Nothing else.
What to say about customers
Nothing changes for them. Same numbers, same hours. Staff who believe customers will be disrupted transmit that anxiety down the phone, and it is both unnecessary and contagious.
Who to tell about problems
One named person, one list. Ten people reporting the same fault three different ways is how a minor issue becomes a loss of confidence in the entire system.
What not to do
No configuration changes by anyone other than the owner during the first week. Well-meant fixes made in parallel are how people spend a day chasing a problem somebody else already solved.
Day 13: Cutover
Mid-week, mid-morning. Never the first Monday of the month, never the day before a public holiday, never the last week of the financial year, and never the day your biggest campaign lands.
- Before you start, agree the rollback point. A specific time, and a named person who can say "we are reverting" without a meeting. It is almost never used. Its entire value is that everybody behaves calmly because it exists.
- Numbers cut across mid-morning. Full working day ahead, provider support available, two more working days before the weekend.
- First external test call within one minute of the port completing. From a mobile, not from a desk. Then tests 4, 5 and 8 again.
- Two hours of watching live calls. Live calls, not reports. Most cutover faults appear inside the first hour and are ten-second fixes when somebody is actually looking — and week-long irritations when nobody is.
- One issues list, one owner, all day. No parallel changes.
- Fifteen-minute standup at the end of the day. What broke, what is fixed, what is outstanding, who owns each item overnight.
Day 14 and the First Week
Day 14: re-train
The second session is worth more than the first, because now people have real questions instead of hypothetical ones. Fifteen minutes on transfer, park and the mobile app is usually the whole agenda.
Sit near the phones for an hour
You will hear what nobody reports: a greeting that runs too long, a queue message that repeats too often, a transfer people are avoiding because they are not confident with it.
Freeze the design
Do not redesign the call flow in week one on the strength of three anecdotes. Collect observations, change deliberately at thirty days, and you will change the right things instead of the loudest ones.
Check the first invoice
Line by line against the quote, in the first month, while querying anything unexpected is still easy and everybody remembers what was agreed.
Day 30: The Review That Makes It Stick
This is the step that converts an installation into a working system, and the one most often skipped — because by day thirty the phones work and everyone has moved on to something else.
| Look at | Ask | Usual action |
|---|---|---|
| Answer rate | Better than the pre-cutover baseline? | If not, the routing model is wrong — not the platform. |
| Where callers abandon | At which point in the flow do they give up? | Usually silence in a queue, or overflow engaging too late. |
| After-hours volume | How many calls arrive when you are closed? | Nearly always higher than expected. Decide whether that path deserves more than a message. |
| Menu behaviour | Which option is pressed, and how many press zero? | Heavy zero-pressing means the menu is not describing what callers want. |
| Shared voicemail | Is anything piling up in a mailbox nobody owns? | Give it an owner or remove it. An unowned mailbox is worse than none. |
| Adoption | Anyone still transferring by hanging up? | A short session aimed at those specific people. |
Take the baseline before day 13, not after
Two weeks of answer rate, average speed to answer, abandoned calls and after-hours volume, captured before cutover, is the difference between a review that measures and a review that argues. It costs almost nothing and it is nearly always skipped. Our note on the five numbers your phone system should report gives definitions consistent enough to hold a supplier to.
Four Things That Ruin a Cutover
The old service gets cancelled
Somebody tidies the supplier list mid-project and cancels a service with a port still in flight. This is the one action that can genuinely lose a number permanently. Tell whoever pays the bills, in writing, on day three.
A number nobody knew about
The fax line a supplier still uses, or the alarm dialler. Found on day fifteen instead of day one, and now it needs an emergency arrangement. The inventory on day one is the entire prevention.
The date was announced before it was confirmed
A go-live promised to the business before the port date was confirmed, then moved twice. The system is now unpopular before it has carried a single call, and that reputation outlives the facts.
Everybody fixing things at once
Three well-meaning people making configuration changes on cutover morning, so nobody can tell what caused what. One owner, one list, no parallel changes — for the first week.
What to Ask So the Dates Are Real
Four questions that separate a plan with dates from a plan with hopes. Ask them before signing, not after.
| Ask | A good answer sounds like | A worrying answer sounds like |
|---|---|---|
| "What does the first ninety days look like, week by week?" | Named steps, named owners, a test day, a go-live day and a thirty-day review. | "Our onboarding team will be in touch." |
| "When will the port date be confirmed, and what if it slips?" | A stated lodgement date and a written interim arrangement with calls diverting. | "It usually only takes a few days." |
| "Who do I ring at 4pm on a Thursday, and what can they see?" | Australian support who can look at your actual call and routing in one place. | A ticket queue and a target response time. |
| "Is the thirty-day review included?" | Yes, with your numbers in front of both of you. | Silence, or a professional services rate. |
If you are also still comparing providers, our guide to what goes wrong when switching provider covers the migration risks, and comparing four quotes on one page covers the arithmetic.
How We Run the Fourteen Days
Decisions first, order second
We work through seat types, routing, after-hours and integrations before anything is ordered, because a seat mix chosen properly is worth more than any feature on the quote and is far harder to change afterwards.
The port sets the date
Lodged early with details checked against your bill, the go-live anchored to a confirmed date rather than an optimistic one, and the old service left alone until it completes. If a port slips, calls divert — they do not disappear.
We own our network
VOCPhone operates its own network rather than reselling somebody else's, so when a call behaves oddly on cutover morning there is one company looking at the network, the routing and the platform together rather than three relaying tickets.
The test script is not optional
All fourteen lines, including the public holiday rule and the emergency calling addresses. We would rather find something on a Tuesday than have your customer find it on Boxing Day.
Someone watches the first two hours
Live calls, not dashboards, with Australian support on the phone. Most cutover faults surface in the first hour and are trivial to fix while somebody is actually looking at them.
A real thirty-day review
Against the baseline we take before you go live, with the numbers in front of both of us, and one deliberate round of changes rather than a month of small ones.
Frequently Asked Questions
How do I set up a business phone system step by step?
Work in this order, because doing it in any other order is what produces the systems people complain about. Days one and two, decide before anything is ordered: seat types rather than headcount, since full desk seats, app-only seats for field staff, shared seats and common-area devices are different products at different prices and this list is the biggest lever on your bill; the routing model, choosing between a receptionist, a menu and a ring group, where under about thirty people a group usually beats a menu; the after-hours position, meaning what happens at 7pm, on a Saturday and on Boxing Day; and what the system must write into, naming the CRM, calendar or job management system where work actually happens. Build a complete number inventory in the same two days and confirm in writing who holds rights of use over each number. Day three, lodge the port with entity name, account number and address copied character for character from a current bill, and never cancel the old service. Days four and five, draw the call flow on paper and check the network, upstream headroom and power. Days six to eight, the provider builds while you write greeting scripts and supply integration credentials. Days nine and ten, devices and the app rollout, verified with a real test call to each person. Day eleven, a written test script. Day twelve, brief the staff. Day thirteen, cut over mid-week and mid-morning. Day fourteen, re-train. Day thirty, review against a baseline you took beforehand.
How long does it take to set up a phone system for a small business?
Two to four weeks is realistic for most Australian small businesses that have existing numbers to move, and the schedule is set almost entirely by one item: number porting. Everything else can be compressed; porting cannot, because it involves another carrier and strict matching of your account details. If you have no numbers to port — a genuinely new business, or one happy to take new numbers — you can be live in days, since the configuration itself is hours of work rather than days. If you are moving several sites, running deep integrations into a CRM or job management system, or you discover that rights of use over your 1300 number sit with somebody other than you, expect longer, and expect the extra time to be spent on paperwork rather than technology. The useful framing is that the elapsed time is porting and the effort is at the two ends: the decisions at the start, which nobody can make for you, and the staff adoption at the end, which is fifteen minutes per person multiplied by everybody. Businesses that finish late almost always did the reverse — they signed, waited for the provider to set it up, and started making decisions when somebody rang to ask what the greeting should say. A provider who tells you which category you are in before quoting a date is being straight with you.
What is the biggest mistake when setting up a business phone system?
Leaving the mobile app rollout and the after-hours path until last, closely followed by never naming an internal owner. The app one is the most common: about a third of a team will not properly complete the setup unless somebody checks, and the resulting complaint is always the same — it does not ring on my mobile. It is almost never an application fault. It is notifications never allowed on iOS, aggressive battery optimisation on Android silencing or delaying the alert, or somebody who simply never signed in. Prevent it by verifying with an actual inbound test call to each person rather than asking whether they installed it. Ten minutes of that prevents a fortnight of tickets and, more importantly, prevents the team concluding in week one that the new system is unreliable — a belief that is very hard to reverse afterwards. The after-hours failure is quieter and costs more: nobody makes the decision, a default is left in place, and the state your business presents for two-thirds of every week is configured by accident. The ownership failure is the one that turns a fourteen-day plan into a five-month one. One named person with authority to approve greetings, hours and routing without convening a meeting is the most reliable predictor of a good outcome — ahead of budget, ahead of platform, ahead of provider.
When should I schedule the cutover to a new phone system?
Mid-week and mid-morning, and never on the first Monday of the month, the day before a public holiday, the last week of the financial year, or the day a major campaign lands. Mid-week mid-morning gives you a complete working day with your provider's support available and two further working days before the weekend, which is precisely the window in which small faults are found and fixed cheaply rather than festering over a weekend. Four practices matter around the date. Agree a rollback point before you start — a specific time and a named person who can say we are reverting without convening a meeting; it is almost never used, and its entire value is that everyone behaves calmly because it exists. Make the first external test call from a mobile within a minute of the port completing, then repeat the outbound, transfer and after-hours tests. Have somebody watch live calls, not reports, for the first two hours, because most cutover faults appear inside the first hour and are ten-second fixes when someone is looking. And run everything through one issues list with one owner, with no configuration changes by anybody else for the first week — parallel well-meant fixes are how a team spends an afternoon chasing a problem that was already solved. Finally, do not announce a go-live date to the business before the port date is confirmed.
What should be tested before a phone system goes live?
Fourteen things, written down, worked through by two people in about two hours, with no going live while a line is still open. Ring the main number from an external mobile and confirm it reaches the designed group with the right greeting. Ring every other number individually, including the fax line and the alarm dialler. Let the first group not answer, and confirm overflow engages on time with something meaningful playing rather than silence. Make outbound calls from a desk phone and from the mobile app, checking the presented number on the receiving handset. Do a blind transfer, a consultative transfer, and a refused transfer that must return to you. Hold, park, and retrieve from a different device. Leave a voicemail and confirm notification, delivery and transcription reach the right person within a minute. Test the after-hours path by changing the hours. Test a public holiday rule, which is the test nobody runs and everybody needs on 26 December. Confirm the emergency calling address registered against every device and app. Confirm an integration actually writes a record into your CRM against the right contact. Check call quality both directions on wired and mobile. Unplug the internet and confirm calls divert as designed. And have every single person make and receive one call, which is how you find the three who never signed in and the two whose notifications were never enabled.
Will my customers notice when we change phone systems?
Done properly, no — and that is worth saying explicitly to your staff, because anxious staff transmit anxiety down the phone. Your numbers come with you, the hours stay the same, and the greeting can stay identical if you want it to. The things customers do notice are the failures this plan is built to prevent: an after-hours message that still gives last year's hours, a queue that plays silence so the call feels dropped, a transfer that orphans them because nobody was trained, and a menu with no way to reach a person. Two exceptions deserve planning rather than hope. If a number genuinely cannot be ported, you need a diversion from the old service and an early update to your website, Google Business Profile, signage, vehicles and any printed material — which is a ten-day job, not a ten-minute one, which is why the number inventory belongs on day one. And if a port slips, you want a written interim arrangement where calls divert to the new system while the old service stays live, rather than an improvised morning. Ask your provider what that arrangement is before you sign; a provider who has a documented answer has clearly done this before, and a provider who says ports usually only take a few days has answered a different question.
Do I need to keep my old phone service running during the changeover?
Yes, and this is the single most important operational rule of the whole project: never cancel the old service until the port has completed. Cancellation before completion is the one action that can genuinely lose a number permanently, and it almost never happens deliberately — it happens when somebody in accounts tidies up the supplier list mid-project, entirely reasonably, without knowing a port is in flight. Tell whoever pays the bills in writing on the day you lodge, and make sure they know the date to look for. Keeping the old service live also gives you the interim path if the port date moves, which it sometimes does: calls can divert from the old service to the new system so nothing is lost while the paperwork completes, and you should agree that arrangement in writing before you sign rather than improvising it on the morning. The same logic applies to any number that turns out not to be portable — you keep the old service, divert from it, and use the time to update your website, listings, signage and vehicles before retiring it. The overlap costs one month of a service you are leaving. That is a very cheap insurance premium against losing a number that appears on your signage and in every customer's contacts.
