How it works
Six steps from an empty account to a ringing phone.
Nothing to rack, nothing to install, nothing to patch on a Sunday. What you get instead is four things you can name, and one diagram per number saying exactly what happens when it rings.
One number, one path
- inMain number
- step 1Open hours?
- step 2Reception group
- answeredAnswered
Turn-up, in order
Each step depends on the one above it
A real sequence, so it is numbered. The product ships a progress panel for the same reason.
Step 1: Say where the office is
A site is an address, a time zone, opening hours and a calling policy. Everything underneath inherits them, so this is the only place most of it gets typed.
Step 2: Add the people
A line needs a name, an email and a site. The extension is suggested from the next free one and stays editable. Nothing else is required, and the browser phone works the moment you save.
Step 3: Attach numbers
Numbers are inventory. Give one to a line, a group or a call flow, or to none of them yet. Bringing an existing number runs in parallel and does not hold the rest up.
Step 4: Pick a call flow
Every number starts from one that already works: straight through, ring the team then voicemail, open and closed with a greeting, a small menu, or a queue with overflow. Edit from there.
Step 5: Plug the phones in
Type a MAC address and a model, choose the line, and the handset configures itself the first time it boots. Nothing to copy, and no credentials on screen to copy wrongly.
Step 6: Clear the leftovers
An onboarding panel lists what is still open: a group with no overflow destination, a device that has not registered, a line without a service address. Working out the dependency order is the product's job, not yours.
Drawn, not filmed
Two of those steps, running
A line being made, and a handset setting itself up from the network. Both are drawings that move, so they stay sharp at any size and hold still if your machine asks them to.
Already answered
Questions you will never be asked
Every one of these is a real question a widely used PBX puts in front of an administrator before anything works. We answered them once, internally, so the first thing you do here is name a person rather than choose a transport protocol.
- "Which SIP driver should this extension use?"
- An internal implementation choice dressed up as a product decision. There is one transport here, and per-handset quirks live in a device profile you never open.
- "What is this extension's codec string and contact rewrite?"
- Forty-field extension forms exist because nobody separated the settings almost every office touches from the rest. Simple mode contains no protocol concept at all.
- "Have you built your dial plan in the separate designer application?"
- Call routing is edited on one canvas inside the product. There is no cliff between a small menu and anything more ambitious than that.
- "Which of the eleven reports has the answer?"
- Two dashboards: what happened, and how it sounded. Every queue and attendant links straight to its own filtered view.
Worth knowing
When a call sounds wrong, you get the evidence
Every call carries its own jitter, packet loss and quality score, on the call record, per endpoint and per network.
That is the difference between a diagnosis and an argument. When somebody says the calls were breaking up yesterday afternoon, you open yesterday afternoon and look, instead of trading opinions with whoever supplies the line.
Browser calling and desk phones both ride the link between the office and the internet, so a saturated connection is something to fix rather than something to live with. The dashboard is how you find out that is what it was.
What a call record holds
- Mean opinion score, jitter and packet loss, per call
- The endpoint that took it and the network it was on
- Answered, missed and abandoned, by line and by group
- Busiest hours, and how long people waited
Next
Start with one site and one line
You can be making calls from a browser before you have decided which handsets to order.