What "Setting Up" Actually Involves
People imagine phone system setup as configuration — someone in a console making settings. Configuration is perhaps a fifth of it. Here is the honest shape of the work, and the point of listing it is that six of the eight parts have nothing to do with technology.
| Part | What it involves | Who owns it | Typical effort |
|---|---|---|---|
| Decisions | Seat types, routing model, after-hours position, integrations, hours, who answers what. | You. Nobody can make these for you. | 2–4 hours, spread over a week |
| Numbers and porting | Establishing what numbers exist, who holds rights of use, and moving them. | Shared. You supply evidence, the provider lodges. | Days to weeks of elapsed time |
| Call flow design | Drawing what happens to every inbound call, in every state. | You, with the provider challenging it. | 1–2 hours with a pen |
| Network readiness | Cabling, switch ports, quality of service, upstream headroom, power. | Your IT provider or the phone provider. | Half a day, plus any remediation |
| Configuration | Building the flow, users, queues, greetings, recordings, integrations. | The provider, usually. | Hours, not days |
| Devices | Handsets provisioned, apps installed, headsets distributed, everyone signed in. | Shared, and chronically underestimated. | 15 minutes per person, ×everyone |
| Testing | Working to a written script until every line passes. | You. It is your business the calls are about. | 2–3 hours |
| Training and adoption | Transfer, hold, park, queue login, voicemail, the app on a mobile. | You, with material from the provider. | 30 minutes per group |
The scheduling insight that follows. The elapsed-time item is porting and the effort items are decisions, testing and adoption. So the correct order is: decide first, start porting immediately after, design and build during the porting window, test before the port completes, and train in the days before cutover. Businesses that finish late almost always did the opposite — they signed, waited for the provider to "set it up", and started deciding when someone rang to ask for the greeting text.
Six Decisions Before Anything Is Ordered
Every one of these is a business decision, not a technical one, and every one of them is expensive to change after go-live.
1. Who holds your numbers
Check now, in writing, who has rights of use over every number you publish — the main line, the 1300 or 1800, the direct lines, the number on the van. If it is registered to your current provider rather than to you, that is the first thing to fix, because it decides whether a change of provider is a project or a hostage negotiation.
2. What seat types you need
Not "how many staff" — how many of what. A full seat with a desk phone, an app-only seat for someone in the field, a shared seat for a workshop or a reception, and a common area device are different things at different prices. Getting this list right is usually the largest single lever on the monthly bill.
3. The routing model
Three broad choices: a receptionist answers everything, a menu splits by department, or calls ring a group directly. Most businesses under thirty people are better served by a group than a menu. Decide the model before anybody builds it, because rebuilding a routing model after go-live is where confusion comes from.
4. The after-hours position
What should happen at 7pm, on a Saturday, and on Boxing Day. A recorded message, a mailbox, a diversion to a mobile, an AI answer, or a genuine on-call rotation. This is the most-skipped decision and the one customers notice most, because it is the state your business is in for two-thirds of every week.
5. What it must write into
Name the systems where work actually happens — CRM, calendar, job management, ticketing, accounting — and what should appear in them after a call. If the answer is "nothing", say so honestly; if it is a CRM, that shapes the platform choice, so decide it now rather than discovering it in month three.
6. Who owns this internally
One named person with the authority to decide greetings, hours and routing without convening a meeting. Projects without this person do not fail; they drift, and drift is why a six-week installation takes five months. This is the single most reliable predictor of a good outcome.
If you are a brand-new business
This article assumes you already have numbers, staff and habits to migrate. If you are starting from nothing — choosing a first number, deciding between a local number and a 1300, working out how many lines you need — start with our guide to setting up a phone for a new business, which covers those choices properly, then come back here for the build.
Numbers and Porting: The Critical Path
Porting is the item with elapsed time you cannot compress, so it starts on day one and everything else happens around it.
| Step | What to do | What goes wrong |
|---|---|---|
| 1. Inventory every number | Main line, direct lines, 1300/1800, fax lines still receiving anything, alarm and lift lines, and any number printed on a vehicle, a sign or a Google listing. | The forgotten number. Usually the fax line that a supplier still uses, or the alarm dialler, discovered after cutover. |
| 2. Establish who holds them | Get it in writing. Rights of use sit with an entity, and that entity is not always you. | A 1300 number registered to a marketing agency or a departed IT provider. This is the single most common nasty surprise. |
| 3. Pull the exact account details | Legal entity name, account number and service address, copied character for character from a current bill. | Porting requests are matched strictly. "Pty Ltd" versus "P/L" is enough to reject a request and cost a week. |
| 4. Lodge early, schedule realistically | Lodge as soon as the decisions are made, and treat the confirmed date as the anchor for everything else. | Promising a go-live date to the business before the port date is confirmed. |
| 5. Never cancel the old service | Leave it active until the port completes. Cancellation is the one action that can genuinely lose a number permanently. | Someone tidying up the accounts payable list mid-project. It happens more often than anyone would like. |
| 6. Handle the non-portable ones | Some numbers cannot move. Plan a diversion from the old service and a communication plan, and get the new number onto listings early. | Discovering it on cutover day, when there is no time to do either. |
Two things to settle in writing before you sign anything
First: your numbers should be registered to you. A number you rent is a number you can be charged to keep, and the number on your signage and your Google Business Profile is a genuine business asset. Our note on who owns your 1300 number explains the difference and how to check. Second: agree what happens if the port 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. A provider who has a written answer to this has done it before. Our guide to changing provider without losing calls covers the whole migration in more depth.
Design the Call Flow on Paper First
One hour with a pen prevents most of what goes wrong later. Draw the answer to eight questions before anybody opens a console.
| Question | What to decide | The common mistake |
|---|---|---|
| Who rings first? | Which device or group rings on the first inbound call, and for how long. | Ringing one person. If they are on a call or at lunch, the caller has already lost. |
| Then who? | The overflow group, and the time before it engages — usually 15 to 20 seconds. | No overflow at all, so everything falls to voicemail after one attempt. |
| What does a waiting caller hear? | Ringing, music, a position announcement, or a callback offer. | Silence, which callers interpret as a dropped call within about eight seconds. |
| When does it stop? | The maximum time before something definite happens — a mailbox, an AI answer, a mobile. | An unbounded queue. Nobody waits four minutes; they ring a competitor. |
| What are the hours? | Real opening hours, including lunch if you close, plus every public holiday for the next twelve months. | Business hours copied from the website, which were wrong there too. |
| What happens outside them? | The decision from the previous section, made concrete. | A default greeting in a stock voice giving no useful information. |
| How does a caller reach a person? | The escape from any menu or automated path, available at every step. | A menu with no zero-out, which is the fastest way to make a caller angry. |
| What shows on outbound calls? | Which number each team presents, and whether it is a number that can be rung back. | Individuals presenting a direct line customers then store instead of the main number. |
The five-second rule for menus
If you are using a menu, a caller should hear their option within five seconds of the greeting starting, and there should be no more than four options at any level. Anything longer or deeper and callers press whatever they can to reach a human, which sends them to the wrong place and makes your routing data meaningless. If your menu needs six options, the honest answer is usually that you need a person or an AI answer at the front rather than a bigger menu. Our piece on why phone menus are becoming obsolete makes the case in full.
The Network Check Almost Everyone Skips
Cloud phone systems are undemanding on bandwidth and unforgiving on jitter. The check takes half a day and prevents the class of problem that is hardest to diagnose after go-live, because by then everyone has decided the phone system is bad.
Wired
Desk phones on cable, not wi-fi. Wi-fi is fine for a mobile app and a poor choice for a fixed device that will be blamed for every crackle.
Priority
Quality of service configured so voice is prioritised over a backup upload or a large file sync at 4:55pm.
Headroom
Check upstream, not just downstream. Concurrent calls plus video plus cloud backups is an upstream problem, and upstream is the scarce direction.
Power
A modem, a router and a switch on a UPS keeps the phones alive through a short outage. Without it, a five-minute power blip takes the business off the air.
Two further items belong on this list because they are regularly forgotten. Ageing switches without power over Ethernet mean every desk phone needs a plug pack, which is a discovery best made before the handsets arrive. And a second path for redundancy — a mobile failover, or calls automatically diverting to mobiles when the site is unreachable — is a five-minute configuration that decides whether an internet outage is an inconvenience or a day off the air. Our guide to phone redundancy on a single network covers the options.
Handsets, Headsets and Apps
The most underestimated part of the whole project, because it is fifteen minutes multiplied by everyone, and everyone is busy.
| Item | What to plan | Timing |
|---|---|---|
| Desk handsets | Zero-touch provisioning where possible, so a phone configures itself when plugged in. Label them by user before delivery. | Delivered a week before cutover, plugged in and tested the day before. |
| Cordless | Warehouses, workshops, clinics and venues. Check coverage physically rather than assuming it. | Walk-test before cutover, not after a complaint. |
| Headsets | Anyone on the phone more than an hour a day. The cheapest large improvement in call quality you can buy. | With the handsets. |
| Desktop app | Installed and signed in on every computer that needs it, before cutover day. | Two days before, with a five-minute walkthrough. |
| Mobile app | The one that slips. Installed, signed in, notifications allowed, battery optimisation exempted, and a test call made by each person. | Two days before. Chase the stragglers personally. |
Notifications and battery optimisation
The most common "the app doesn't work" report is not an app fault. It is aggressive battery optimisation on Android, or notifications never allowed on iOS, so incoming calls arrive silently or late. Add both to your rollout checklist and verify them with an actual test call to each person — not by asking whether they installed it. Ten minutes here removes the single largest source of week-one complaints.
Building It: The Order That Works
| Order | Build | Why this position |
|---|---|---|
| 1 | Users, extensions and seat types | Everything else references them. |
| 2 | Groups and queues | The routing skeleton, before any decoration. |
| 3 | Hours, holidays and the after-hours path | Build the closed state before the open one — it is the state you will forget to test. |
| 4 | Greetings and recordings | Record them properly. A phone-recorded greeting is audible to every caller for years. |
| 5 | Inbound routing per number | Each number lands where the paper design says, including the ones you nearly forgot. |
| 6 | Outbound caller ID per user and team | Set deliberately. A number that cannot be rung back is a lost callback. |
| 7 | Voicemail, transcription and where it is delivered | Email, app, or both. Decide who receives shared mailboxes. |
| 8 | Emergency calling addresses | Every device and app registered against the correct service address. Do not leave for later. |
| 9 | Integrations | CRM, calendar, ticketing. Test the write, not just the connection. |
| 10 | Recording, retention and access | Notification wording, how long records are kept, and who can retrieve them. |
Emergency calling deserves a deliberate step
Cloud phone services can be used from anywhere, which is exactly why the address registered against each device and each mobile app matters. Confirm what address is held for every seat, make sure staff know that a mobile app may not convey location the way a mobile dialler does, and tell people plainly what to use in an emergency. Our guide to Triple Zero and cloud phone systems sets out the rules and what to tell staff.
The Test Script
Write it down, work through it line by line, and do not go live with an open line. Two people, two hours, one list.
| # | Test | Pass condition |
|---|---|---|
| 1 | Inbound to the main number from an external mobile | Rings the designed group within 2 seconds, correct greeting |
| 2 | Inbound to every other number, individually | Each lands where the design says — including the fax and alarm lines |
| 3 | Overflow when the first group does not answer | Engages at the designed time, caller hears something meaningful |
| 4 | Outbound from a desk phone and from the mobile app | Correct number presented, verified on the receiving handset |
| 5 | Blind transfer and consultative transfer | Both work, and both work back to the original caller if refused |
| 6 | Hold, park and retrieve from a different device | Audio resumes cleanly, no dropped calls |
| 7 | Voicemail: leave, notify, retrieve, transcribe | Arrives where it should, within a minute, to the right person |
| 8 | After-hours path, tested by changing the clock or hours | Correct greeting and correct destination |
| 9 | A public holiday rule | Fires correctly. This is the one nobody tests and everybody discovers on 26 December |
| 10 | Emergency calling address per device | Correct address held for every seat and app |
| 11 | Integration write | A real record appears in your CRM against the right contact |
| 12 | Call quality on a real call, both directions | No jitter, no echo, no one-way audio, tested on wired and mobile |
| 13 | Failover: unplug the internet | Calls divert as designed within the expected time |
| 14 | Every person makes and receives one call | Everybody has signed in, and their notifications work |
Cutover Day, Hour by Hour
Cutover is an event with a shape. Give it one.
| When | What happens |
|---|---|
| The week before | Test script fully passed. Devices delivered and signed in. Staff briefed with a one-page card. Customers told nothing, because nothing should change for them. |
| The day before | Re-run tests 1, 4, 5 and 8. Confirm the port window in writing. Confirm who is on site or on call. Agree the rollback point and who calls it. |
| Cutover morning | Mid-morning, mid-week. Numbers cut across. First test call from an external mobile within one minute of the port completing. |
| First two hours | Someone watches live calls actively — not reports, live calls. Most cutover faults appear inside the first hour and are ten-second fixes if someone is looking. |
| Rest of day one | A named person collects issues in one list. No configuration changes without that person knowing, or you will chase ghosts. |
| End of day one | Fifteen-minute standup: what broke, what is fixed, what is outstanding, who owns each item overnight. |
Do not cut over on these days
The first Monday of the month, the day before a public holiday, the last week of the financial year, or any day your busiest campaign lands. Mid-week and mid-morning is the right slot, because it gives you a full working day with the provider's support available and two more working days before the weekend. And agree a rollback point before you start — a specific time and a named person who can say "we are reverting" without convening a meeting. The rollback is almost never used. Its value is that everyone behaves calmly because it exists.
Week One
Expect a short adjustment period and plan for it rather than being surprised by it.
One issues list
A single shared list, one owner. Ten people reporting the same thing three ways is how a small fault becomes a crisis of confidence in the whole system.
Listen to real calls
Sit near the phones for an hour on day two. You will hear things nobody reports — a greeting that runs too long, a queue message that repeats too often, a transfer people are avoiding because they are unsure of it.
Re-train on day three
The second training session is worth more than the first, because now people have real questions. Fifteen minutes, focused on transfer, park and the mobile app.
Freeze the design
Resist redesigning the call flow in week one on the strength of three anecdotes. Collect observations, change deliberately at the thirty-day review, and you will change the right things.
The Thirty-Day Review
This is the step that converts an installation into a working system, and it is the one most often skipped because by day thirty the phones work and everyone has moved on.
| Look at | Question | Typical action |
|---|---|---|
| Answer rate | Better than the baseline you took before go-live? | If not, the routing model is wrong, not the platform. |
| Unanswered and abandoned | Where in the flow are callers giving up? | Usually a queue with silence, or an overflow that engages too late. |
| After-hours volume | How many calls arrive when you are closed? | Almost always higher than expected. Decide whether the after-hours path deserves more than a message. |
| Menu paths | Which option do callers actually press, and how many press zero? | Heavy zero-pressing means the menu is not describing what callers want. |
| Voicemail volume | Are messages piling up in a shared mailbox nobody owns? | Assign an owner or remove the mailbox. An unowned mailbox is worse than none. |
| Adoption | Is anyone still not using the app or still transferring by hanging up? | A fifteen-minute session, aimed at the specific people. |
| The bill | Does the first full invoice match the quote, line by line? | Query anything unexpected in the first month, while it is easy. |
Take the baseline before you go live
Two weeks of answer rate, average speed to answer, abandoned calls and after-hours volume, captured before cutover, is what makes the thirty-day review a measurement rather than a debate. It costs almost nothing and it is nearly always skipped. Our note on the metrics that matter gives consistent definitions you can hold a supplier to.
Seven Ways Setups Go Wrong
| Failure | What it looks like | Prevention |
|---|---|---|
| No internal owner | The project drifts for months; nobody can approve a greeting. | Name one person with authority on day one. |
| Ordering before deciding | Seat types and routing get chosen by whoever built it fastest. | The six decisions, settled in writing, before ordering. |
| Late porting | Go-live slips repeatedly, and each slip costs credibility. | Lodge the port first, and anchor the plan to the confirmed date. |
| Untested after-hours | Discovered on the first Saturday, or on 26 December. | Tests 8 and 9. Change the clock and prove it. |
| The app rollout | Half the team never signed in; calls "don't ring" on mobiles. | Verify with a test call per person, including notifications. |
| No baseline | Nobody can tell whether anything improved. | Two weeks of numbers before cutover. |
| Training once | People avoid transfer and park for years afterwards. | Train before, re-train on day three, and again at thirty days. |
A Realistic Timeline
For a typical Australian business of five to fifty people, with numbers to port. Elapsed time is dominated by porting; effort is dominated by decisions and adoption.
| Week | What happens | Who |
|---|---|---|
| Week 0 | Six decisions settled. Number inventory built and rights of use confirmed. Internal owner named. | You |
| Week 1 | Port lodged with exact bill details. Call flow drawn on paper and agreed. Network check performed. | Shared |
| Week 2 | Configuration built. Greetings recorded properly. Integrations connected. Hardware ordered. | Provider |
| Week 3 | Devices delivered and provisioned. Apps installed and signed in. Test script run end to end. Staff briefed. | Shared |
| Week 4 | Cutover mid-week mid-morning. Two hours of active watching. Issues list. Day-three re-training. | Shared |
| Week 8 | Thirty-day review against the baseline. Deliberate changes made once, together. | You, with the provider |
Simple installations without porting can be live in days. Multi-site rollouts, complex integrations and numbers with contested rights of use take longer, and the honest thing a provider can do is say which of those applies to you before quoting a date. If you are running several sites, our multi-site and franchise guide covers what to standardise and what to leave local.
How We Run an Installation
Decisions before ordering
We work through the six decisions with you first, because a seat mix and a routing model chosen properly are worth more than any feature on the quote — and both are painful to change later.
Porting drives the plan
We lodge early, anchor the go-live to a confirmed port date rather than a hopeful one, and keep the old service live until the port completes. If a port slips, calls divert rather than disappear.
Zero-touch devices
Handsets provisioned so they configure themselves when plugged in, labelled before they arrive. Third-party SIP handsets you already own are usually supported, so working hardware does not have to be replaced.
The test script is not optional
Fourteen lines, worked through together, including the public holiday rule and the emergency calling addresses. We would rather find it on a Tuesday than have your customer find it on Boxing Day.
Someone watches the first two hours
Live calls, not reports. Most cutover faults surface in the first hour and are ten-second fixes when somebody is actually looking.
A real thirty-day review
Against the baseline we take before go-live. Australian support, on the phone, with the ability to see your actual calls and routing rather than relaying a ticket to somebody else.