ByondVoice — Administrator & Operations Manual

Ch. 01 · Welcome

1.2 Who this manual is for

This manual is written for the people who operate ByondVoice from the console — not for the end users who simply make and receive calls. Two operator roles share the console, at different levels of the hierarchy described in § 1.3:

Throughout the manual, a procedure that is reserved for the platform operator is flagged as such; everything else applies to any operator with rights over the tenant in question. If a screen is not visible to you, it is because your scope does not include it — that is the multi-tenant model working as designed, not a fault.

1.2.1 What you are assumed to know

You do not need to be a SIP engineer. You should, however, be comfortable with a few baseline ideas, because the manual uses them without re-explaining:

• An extension is an internal number (for example 1001) that a person or device answers. Users dial extensions directly to reach each other.
• A SIP device registers to an extension to become reachable — a desk phone, a softphone app, or the ByondVoice softphone PWA. "Registered" means online and ready to ring.
• A DID (Direct Inward Dial) is a public phone number, such as +65 3159 0010, that the outside world can call. DIDs are delivered by a carrier and pointed at routing inside ByondVoice.
• A carrier / SIP trunk is the link to the public telephone network. Without one, ByondVoice still does everything internal; with one, it also reaches the outside world.

ByondVoice — Administrator & Operations Manual

Ch. 01 · Welcome

1.3 The hierarchy every chapter assumes

ByondVoice is organised as four nested levels. Almost every screen in the console is scoped to one of them, and almost every procedure in this manual begins by establishing which level you are working at. Internalise this model now and the rest of the book reads easily.

The arrows go one way: a platform contains many resellers (and may hold tenants directly); each reseller contains many tenants; each tenant contains many users; each user owns one or more extensions and the devices registered to them. Configuration and visibility flow strictly down this chain — a tenant operator can never see another tenant's data, and a user's portal is scoped to their own extension only.

ByondVoice — Administrator & Operations Manual

Ch. 01 · Welcome

1.4 Your first sign-in

Before any of the rest of the manual is useful you must reach the console. Signing in is the simplest procedure in the book, so it is a good place to learn how procedures are presented here: a faithful screen, then numbered steps, then a worked example.

1.4.1 Procedure — sign in to the console

1. Open the console. Browse to admin.byondvoice.com. If you have never signed in, the dark console is hidden and only the sign-in card is shown.
2. Enter your username or email. Type the operator identity issued to you.
3. Enter your password, then select Sign in.
4. Complete multi-factor authentication if prompted. If your account has MFA enabled, enter the 6-digit code (from your authenticator app, or the one-time code emailed to you), then submit again.
5. Confirm you have landed in the console and that the environment chip reads ENV: PROD. You are now in the control plane.

ByondVoice — Administrator & Operations Manual

Ch. 01 · Welcome

1.5 The four callouts

Set off from the running text you will find four coloured callouts. Each carries a specific kind of operational judgement; learn to read them at a glance, because the most important safety guidance in this manual lives inside them.

ByondVoice — Administrator & Operations Manual

Ch. 01 · Welcome

1.6 How screens, steps and examples are presented

Every procedural chapter follows the same rhythm. Recognising it lets you skim for exactly the part you need.

1.6.1 Screens are reproduced, not screenshotted

Because the console evolves continuously, this manual does not paste live screenshots. Instead each screen is redrawn as a branded mockup that faithfully matches the real panel's layout, fields and labels. A mockup carries small numbered annotation markers — the pink circles — and a matching numbered legend beneath it. Marker "3" in the picture always corresponds to item 3 in the list. Each figure ends with a caption, and figures are cross-referenced by their number (for example, "Figure 1.2").

1.6.2 Procedures are numbered steps

Instructions are given as a numbered list with gradient step chips, like the sign-in procedure in § 1.4.1. Follow them in order. The lead phrase of each step (in bold) is the action; the rest of the sentence is the detail. A procedure is almost always followed by a worked example with concrete values.

1.6.3 Worked examples and "Try it" exercises

A worked example traces a procedure end-to-end with realistic values — extension 1001 "Alice Tan", tenant "Acme Corp", ring group pilot 6000 "Sales", DID +65 3159 0010 — so you can see the outcome. A Try it box (the dashed pink panel) poses a short hands-on task to rehearse in a safe environment and tells you what "done" looks like.

1.6.4 Typographic conventions

A few notations recur throughout the manual:

ByondVoice — Administrator & Operations Manual

Ch. 01 · Welcome

1.7 What lies ahead

The chapters that follow walk the console in roughly the order you will use it, grouped exactly like the navigation rail you met in Figure 1.1. Use this as a map; each entry is a group of screens you can jump to.

ByondVoice — Administrator & Operations Manual

Ch. 02 · Architecture

2.1.1 What isolation actually means

“Multi-tenant” is easy to say and easy to get wrong, so be precise about what ByondVoice guarantees. Every record that matters carries the tenant it belongs to, and that scope is enforced in the control plane on every request — not merely hidden in the user interface. The practical consequences are worth committing to memory.

Two extension 1001s can exist happily in two different tenants — the number is unique only within a tenant. The same is true of ring-group pilots and conference rooms. This is why nearly every screen in the admin console shows the tenant it is scoped to in its breadcrumb (the // hosted PBX · tenant Acme Corp subtitle): you are always acting inside one tenant at a time.

2.1.2 White-label is per reseller

When a reseller such as Nimbus Telecom is enabled, its tenants experience ByondVoice under the reseller’s brand and domain, and — if the platform permits it — over the reseller’s own carrier credentials. The branding is applied at the edge (see §2.4.3), so the same platform serves many brands without per-brand deployments. From an administrator’s seat the screens are identical; only the wordmark, domain and, where configured, the trunk differ.

ByondVoice — Administrator & Operations Manual

Ch. 02 · Architecture

2.2 The three surfaces

People meet ByondVoice through three front-ends, each aimed at a different job. Knowing which surface does what — and, crucially, what each one is not allowed to do — prevents most “why can’t I see that?” support questions.

The figure below is the surface this manual lives in — the admin console, showing the Extensions & Devices screen. Every later admin screen reuses this same frame, so the parts are numbered once here.

ByondVoice — Administrator & Operations Manual

Ch. 02 · Architecture

2.2.1 The user self-service portal

Your users never sign in to the admin console. Instead each user gets my.byondvoice.com — a portal scoped strictly to their own line. From here a user reviews their extension and numbers, plays visual voicemail, checks recent calls, sets up call handling (do-not-disturb, forwarding, follow-me), and manages their registered devices. The portal cannot see other users, other tenants, or any operator screen; its API is locked to the signed-in user’s own extension(s).

2.2.2 The softphone PWA

The softphone at my.byondvoice.com/phone is a Progressive Web App — a branded softphone that runs in the browser and installs to the home screen like a native app. It registers over a secure WebSocket (see §2.4.2) and supports two-way audio and video, a mid-call video toggle with picture-in-picture, hold, blind transfer, conference, DTMF and mute, alongside team Chat, Contacts and History tabs. Incoming calls ring with a notification — including a lock-screen “ring while locked” alert that the user taps to answer.

ByondVoice — Administrator & Operations Manual

Ch. 02 · Architecture

2.3 The telephony fabric

Under the three surfaces sits the part that actually carries voice. You do not operate it directly — your console settings configure it — but an administrator who can picture the fabric can reason about almost any call problem. ByondVoice separates the work into clean layers: an edge where devices register and media is relayed, a media/PBX tier where calls are switched, a control plane that holds configuration and authenticates devices, and the data beneath it all.

A handful of facts about this fabric are worth carrying with you, because they explain behaviour you will meet throughout the manual:

• The SBC is the front door. Every device — desk phone or softphone — registers to ByondSBC, not directly to the PBX. If a device is “not registered”, the SBC and its credentials are the first place to look.
• ByondSwitch renders routing at call time. Ring groups, auto-attendants and per-user call-handling rules are not pre-compiled — the PBX reads the saved configuration when the call happens. A rule you save now takes effect on the very next call.
• Signalling is cheap; media is the cost. SIP signalling is light; the media path (and TURN relay) is where bandwidth goes. This is why the media tier is the part that scales horizontally.
• The control plane authenticates devices dynamically. SIP credentials are validated against the API at registration, so changing a device secret in the console takes effect without redeploying anything at the edge.

ByondVoice — Administrator & Operations Manual

Ch. 02 · Architecture

2.3.1 How a device registers through the edge

Registration is the act of a SIP device telling the platform “extension 1001 is reachable at this device, right now”. It is the foundation of everything else: an unregistered extension cannot ring. Devices register to ByondSBC at the edge, which validates the credentials against the control plane before accepting the registration. The dialog below is where you create the device and reveal its secret once.

2.3.2 Procedure — register a device to an extension

1. Open the extension. In Hosted PBX›Extensions & Devices, confirm the breadcrumb reads tenant Acme Corp, then open extension 1001.
2. Add a device. Select New device to open the dialog above. Give it a clear label (for example “Alice — desk phone”).
3. Capture the secret. ByondVoice generates the SIP password and shows it once. Copy it immediately into the device’s SIP account — you will not see it again.
4. Point the device at the SBC. Set the device’s registrar / SIP server to the registrar shown (sbc.byondvoice.com), with TLS transport for a hardware phone.
5. Save and watch for registration. The device sends a REGISTER to ByondSBC; the SBC validates the credentials against the control plane. Within seconds the row’s status flips to registered.

ByondVoice — Administrator & Operations Manual

Ch. 02 · Architecture

2.3.3 The life of one internal call

To make the planes concrete, follow a single internal call — Alice (1001) dialling Ben (1002) — across the fabric. This is the path every voice interaction takes, and it is the mental model to reach for when a call “doesn’t connect” and you need to know where to look.

1. The caller’s device sends the call. Alice’s registered device sends an INVITE for 1002 to ByondSBC — the same edge it is registered to.
2. The SBC admits and dispatches. ByondSBC checks the device is registered and allowed, then dispatches the call inward to the hosted PBX. The softphone’s INVITE arrives the same way, over secure WebSocket.
3. ByondSwitch renders the route. The PBX looks up 1002 in the tenant, reads Ben’s call-handling rules at that moment, and rings his registered device(s) — or sends the caller to voicemail if he has do-not-disturb on.
4. Media connects. Once Ben answers, voice (RTP/SRTP) flows between the two endpoints — directly where the network allows, or via the TURN relay when either side is behind a restrictive firewall or symmetric NAT.
5. The call is recorded to history. When the call ends, a call-detail record lands in each user’s Recent Calls, and any unanswered leg leaves visual voicemail.

2.3.4 Media relay and TURN

browser softphone and SIP both try to send voice media on the most direct path between endpoints. On many corporate and mobile networks that direct path is blocked — symmetric NAT and strict firewalls prevent the two sides from reaching each other. ByondVoice solves this with TURN (Traversal Using Relays around NAT): when a direct path cannot be established, the media is relayed through a TURN server that both endpoints can reach, so the call still connects with audio (and video) intact.

ByondVoice — Administrator & Operations Manual

Ch. 02 · Architecture

2.4 The control plane, secure transport and the edge

Three properties of the fabric deserve a closer look because they shape how you administer ByondVoice every day: the control plane is the single source of truth, transport is encrypted end to end, and white-labelling happens at the edge.

2.4.1 The control plane holds configuration and authenticates devices

The control plane is the API behind all three surfaces. It stores every piece of configuration — tenants, users, extensions, numbers, ring groups, auto-attendants, voicemail boxes, call-handling rules — and it is also what authenticates SIP devices. Crucially, device authentication is dynamic: when a device registers, the SBC asks the control plane to validate the credentials in real time, rather than relying on a static file baked into the edge. Two consequences follow directly.

• Changes take effect immediately. Regenerate a device secret, reassign an extension, or change a rule, and the next registration or call uses the new value — there is nothing to redeploy.
• Secrets live in one place, encrypted. SIP passwords are stored encrypted at rest and shown reveal-once; voicemail and conference PINs are hashed and never shown. The console reveals a secret exactly once, at creation, and never again.

2.4.2 softphones use secure WebSocket

A hardware SIP phone registers to ByondSBC over SIP / TLS. The softphone PWA cannot use raw SIP from a browser, so it registers over a secure WebSocket (WSS) to the same SBC — the SBC speaks both. This means the softphone’s signalling is encrypted in transit just like a desk phone’s, the registration appears in the same Extensions screen, and the call path is identical from ByondSwitch’s point of view. The only difference is the transport the device dialled in on.

2.4.3 Voice is white-labelled at the edge

Because a reseller’s tenants register to and route through the same fabric, ByondVoice applies branding at the edge rather than by spinning up a separate platform per reseller. The reseller’s brand, domain and — where permitted — its own carrier credentials are presented at the edge, so Nimbus Telecom can sell “Nimbus Voice” to its customers over the very same hosted PBX that serves every other reseller. From your operator seat the screens are identical; only the wordmark, the domain and, if configured, the trunk differ.

ByondVoice — Administrator & Operations Manual

Ch. 02 · Architecture

2.5 What works today versus what needs a carrier

This is the single most important operational distinction in ByondVoice. A great deal works the moment you provision a tenant — with no carrier connected at all. A specific, predictable set of capabilities — everything that touches the public telephone network — waits until a carrier (a SIP trunk) is connected via a Connector. Setting this expectation correctly with a new customer prevents the most common “why can’t I…?” conversation on day one.

In short: everything internal works today; everything that crosses to the public network needs a trunk. The dividing line is the carrier Connector — the screen at Carrier›Connectors where you integrate a carrier, test it, sync numbers, and provision DIDs. Until a connector is live and a number is delivered, external calls have no path in or out.

ByondVoice — Administrator & Operations Manual

Ch. 03 · Sign-in & Tour

3.1.1 Procedure — sign in to the console

1. Open the console. Browse to admin.byondvoice.com using your own bookmark. Until you have authenticated, the dark console is hidden and only the sign-in card is shown.
2. Enter your username or email. Type the operator identity issued to you. Email and username are interchangeable in this field.
3. Enter your password, then select Sign in. Passwords are case-sensitive.
4. Clear MFA if prompted. If your account has MFA enabled, enter the 6-digit code from your authenticator app — or the one-time code emailed to you — then submit again (see §3.1.2).
5. Confirm where you have landed. You should arrive on the first screen your role can see, with the navigation rail on the left and the environment chip in the top bar reading ENV: PROD. You are now in the control plane.

3.1.2 Multi-factor authentication and email one-time codes

MFA adds a second proof of identity after your password. ByondVoice supports two second factors: a time-based code from an authenticator app (Google Authenticator, 1Password, Authy and the like), and an email one-time code sent to the address on your account. The second factor is requested only on a fresh sign-in, and only once your password has already been accepted — so an attacker who lacks your password never even sees the code prompt.

ByondVoice — Administrator & Operations Manual

Ch. 03 · Sign-in & Tour

3.2 The console frame at a glance

Once you are in, every screen in the console shares the same chrome — a persistent frame that never changes as you move between Numbers, Extensions, Ring Groups and the rest. Only the central working area swaps out. Learning this frame once means every later chapter can simply say “open Hosted PBX›Extensions & Devices” and trust that you know where to look. The figure below numbers all eight elements of the frame; the rest of this chapter takes each one in turn.

ByondVoice — Administrator & Operations Manual

Ch. 03 · Sign-in & Tour

3.3 The navigation rail

The rail down the left edge is how you move around the console. Its items are deliberately grouped into five headings that follow the lifecycle of a hosted phone system — from the raw supply of phone numbers, through the hosted PBX that gives people extensions and voicemail, to the call routing that decides where calls land, the carrier link to the outside world, and finally the revenue the platform bills. Reading the rail top-to-bottom is reading the system end-to-end.

Each item shows a live count or marker on its right. 42 next to Extensions & Devices means forty-two extensions exist; $ next to Wholesale Meter marks a billing screen rather than a counted collection. The item you are on is highlighted with a gradient bar — in the figure in §3.2 that is Extensions & Devices. Counts refresh as the underlying data changes, so the rail doubles as an at-a-glance inventory.

3.3.1 The five groups and where they lead

ByondVoice — Administrator & Operations Manual

Ch. 03 · Sign-in & Tour

3.4 Breadcrumb and scope

The breadcrumb sits at the top-left of the working area and answers two questions at once: which screen am I on? and what is it scoped to? The title (for example Extensions & Devices) is the screen; the mono subtitle beneath it — // hosted PBX · tenant Acme Corp — names the group and the tenant whose data you are looking at. Throughout this manual we write the same path as a chip, e.g. Hosted PBX›Extensions & Devices, so a procedure can point you precisely without a screenshot.

Scope matters because the console is multi-tenant: platform → reseller → tenant → users. The same Extensions screen shows Acme Corp’s extensions when scoped to Acme Corp, and a different set when scoped to another tenant. Before you create, edit or delete anything, read the scope in the subtitle — it is the difference between changing the right customer and the wrong one.

3.5 Global search

Global search is the fastest way to reach a specific object without clicking through the rail. Press ⌘K on macOS, or Ctrl+K on Windows and Linux, from anywhere in the console, then type. Search spans extensions, numbers, ring groups, conference rooms and tenants; results are grouped by type and you open one with ↵.

3.5.1 Procedure — jump to an object with search

1. Open search. Press ⌘K (or Ctrl+K) from any screen.
2. Type a fragment. Enter part of a name, an extension number, a DID or a room ID — for example 1001 or Alice.
3. Pick the result type. Results are grouped by kind; move with ↑ ↓ to the row you want.
4. Open it. Press ↵ to jump straight to that object’s screen, or Esc to dismiss search.

ByondVoice — Administrator & Operations Manual

Ch. 03 · Sign-in & Tour

3.6 The account menu and the environment chip

Two controls live at the right end of the top bar and they work as a pair. The environment chip tells you which deployment you are acting on; the account avatar — your initials — opens a menu confirming who you are, the scope you hold and how to sign out. Read the chip before you act, and use the menu to verify your identity and scope whenever a screen does not look the way you expect.

ByondVoice — Administrator & Operations Manual

Ch. 03 · Sign-in & Tour

3.7 The health and build footer

At the very bottom of the navigation rail sits a small but important panel. The first line is an overall health line — ALL SYSTEMS OPERATIONAL when everything is well — and the second names the running version, region and build, e.g. v1.0 · sg-south · build 2026.06. This is the first thing to check if something feels wrong and the first thing support will ask you for.

3.8 How to read every later screen

The working area (element 8 of the frame in §3.2) is the only part that changes between screens, and it is built from the same handful of pieces every time. Learn these six and you can read any screen in the console — Numbers, Voicemail, Ring Groups or Connectors — the first time you open it.

ByondVoice — Administrator & Operations Manual

Ch. 03 · Sign-in & Tour

3.8.1 The status-pill vocabulary

Pills mean the same thing on every screen, so once you learn them you can scan any table at a glance. The table below is the full vocabulary you will meet across Numbers, Extensions, Ring Groups, Conferences and Connectors.

3.9 A first-sign-in orientation routine

Bring the chapter together with a short routine to run every time you start a session. It takes under a minute and catches most surprises before they become incidents.

1. Confirm the environment. Read the chip — ENV: PROD means live. Know whether you intend to make real changes.
2. Confirm your identity and scope. Open the account menu (§3.6); check the name, role and scope are yours and correct.
3. Glance at the rail counts. Do Numbers, Extensions and the rest look like the figures you expect? Investigate anything surprising (§3.3).
4. Check platform health. The footer should read ALL SYSTEMS OPERATIONAL; note the build in case you need to raise a ticket (§3.7).
5. Set your scope before acting. Confirm the breadcrumb subtitle names the tenant you mean to work on, e.g. // hosted PBX · tenant Acme Corp (§3.4).

ByondVoice — Administrator & Operations Manual

Ch. 04 · Roles & Access

4.2 The tenancy hierarchy

The platform is divided into nested tiers of ownership. Each tier can only ever reach down into the tier it contains — never sideways to a sibling, and never up to its parent. A reseller cannot see another reseller’s tenants; a tenant cannot see a sibling tenant under the same reseller; a user cannot see another user’s line. This single direction of travel is what makes ByondVoice safe to white-label and resell.

Two ownership pointers wire this hierarchy together, and they are the whole of the relationship:

A tenant record itself carries a reseller_id: when set, the tenant belongs to that reseller (a white-label customer); when NULL, it is a direct platform customer that you, the platform admin, manage yourself. This one column is what lets a reseller see “their” tenants and nobody else’s, and lets you tell a partner’s customer apart from a direct one at a glance.

ByondVoice — Administrator & Operations Manual

Ch. 04 · Roles & Access

4.3 How tenant scoping works

The promise that makes a hosted-PBX platform safe to sell is simple to state: an account from one tenant can never read or change another tenant’s data. ByondVoice enforces this not with hope but with a single rule applied to every request that touches tenant-owned data. The platform calls it the tenant scope, and it resolves identically everywhere — the Numbers pool, the Extensions list, the Voicemail boxes, the Ring Groups, the call records. There is no per-screen access logic; there is one rule.

When any account asks for tenant-owned rows, the platform narrows the request by the caller’s identity, in this exact order:

4.3.1 The self-service portal is scoped twice

An ordinary user is scoped to their tenant and then again to their own extension. The portal at my.byondvoice.com never exposes another colleague’s devices, voicemail or call-handling rules, even though those rows live in the same tenant. Concretely: Alice Tan (ext 1001) opening My line›Voicemail sees only mailbox 1001; she has no path, in UI or by URL, to Ben Ong’s mailbox 1002. Tenant-wide objects such as ring groups and auto-attendants are administered in the operator console by a tenant admin, not from a user’s portal.

4.3.2 What the sign-in token carries

After a successful sign-in, ByondVoice issues an access token that encodes the few facts the scope needs, so every later request is evaluated without a second password prompt:

// decoded access-token payload
{
  "sub": "a3f1…",        // the account id
  "tier": "tenant",     // platform | reseller | tenant | user — drives every check
  "tid":  "7c2e…",      // tenant_id   (null for platform admin and resellers)
  "rid":  null,         // reseller_id (set for resellers, and on reseller-owned tenants)
  "ext":  "1001"        // the extension a user is bound to (user tier only)
}

ByondVoice — Administrator & Operations Manual

Ch. 04 · Roles & Access

4.4 The platform administrator console

The platform admin holds the widest console on ByondVoice. It is the only tier that can create resellers and direct tenants, manage the shared carrier Connectors and the session border controller, set platform-wide security policy, and run the Wholesale Meter that bills resellers for the traffic their tenants carry. When you sign in as a platform admin, the navigation rail shows every group — Supply, Hosted PBX, Call Routing, Carrier and Revenue — and every list spans the whole platform. The figure below shows the platform-overview landing screen, scoped to all tenants.

4.4.1 Procedure — confirm you are at platform scope

1. Open the console. Browse to admin.byondvoice.com and sign in with your platform-admin credentials.
2. Check the breadcrumb scope. The subtitle under the title should read // platform · all resellers & tenants — confirmation you are not scoped into one partner or customer.
3. Check the avatar tier. The top-right avatar should read PA (platform admin). If it reads a reseller or tenant name, you are signed in at a narrower tier.
4. Confirm the environment chip reads ENV: PROD before you make any change — every action here is live and platform-wide.

ByondVoice — Administrator & Operations Manual

Ch. 04 · Roles & Access

4.5 Where identity is managed

Each tier’s identity is created by the tier directly above it, and only there. The platform admin creates resellers and direct tenants; a reseller creates the tenants beneath it; a tenant admin creates the users (extension owners) inside its own tenant. This top-down ownership is the practical face of the hierarchy in §4.2 — you can only ever provision downward. The table fixes who creates what and where.

The dialog below is the create-tenant form. Creating the tenant also creates its first administrator — the tenant-admin owner login — from the username and owner password you supply, so a customer is born with both its record and a way in, in a single action.

4.5.1 Procedure — provision a reseller, a tenant, then a user

1. Create the reseller. As platform admin, open Tenancy›Resellers and select New reseller. Give it a display name, an owner login and a wholesale plan.
2. Create the tenant under it. Open Tenancy›Tenants, choose New tenant, fill in the form above, and set Reseller to the partner from step 1 (or leave it Direct).
3. Hand the tenant to its admin. Give the tenant-admin owner the username and a way to set their password. From here, the tenant admin runs its own PBX.
4. Create users inside the tenant. Signed in as the tenant admin, open Hosted PBX›Extensions & Devices and select New extension for each person — provisioning their extension, the user who owns it, and a SIP device (see §4.7 and Chapter 7).

ByondVoice — Administrator & Operations Manual

Ch. 04 · Roles & Access

4.6 What each tier sees and does — and least-privilege guidance

The cards below summarise the day-to-day surface of each tier. The hierarchy already enforces the boundaries; least-privilege is about choosing the narrowest tier that still lets a person do their job, so that an account’s reach is never wider than it needs to be.

4.6.1 Capability matrix

When you are unsure which tier a task belongs to, this matrix is the quick reference. “Own” means within the caller’s own scope only.

4.6.2 Suspend, never over-grant

Two operational habits keep the access model tight. First, prefer the narrowest tier: a customer’s receptionist who only manages their own line should be an ordinary user, not a tenant admin; a partner’s onboarding staffer needs a reseller login, never a platform-admin one. Second, suspend rather than over-grant or delete: setting a tenant’s status to suspended blocks every login beneath it without destroying any configuration, and re-activating restores access instantly.

ByondVoice — Administrator & Operations Manual

Ch. 04 · Roles & Access

4.7 Reveal-once secrets and hashed PINs

The access model is not only about who may act — it is also about how ByondVoice handles the credentials those actors create. Two principles run through every screen that mints a secret, and they are deliberately different because the two kinds of secret are used differently.

The dialog below appears the instant a tenant admin creates a SIP device under an extension. The generated password is shown once, with a copy control; close the dialog and it is gone for good.

4.7.1 Procedure — handle a reveal-once device secret

1. Create the device. Under an extension in Hosted PBX›Extensions & Devices, add a SIP device. The dialog above appears with the generated password.
2. Copy the secret immediately. Use Copy secret and paste it straight into the phone’s SIP settings — or transmit it to the user over a secure channel, never plain email.
3. Copy the provisioning URL too, if you are auto-provisioning a hardware phone; it is one-time in the same way.
4. Close the dialog only when copied. Selecting Done discards the readable copy permanently.
5. If it is ever lost, re-generate. Re-issuing produces a fresh secret and invalidates the old one, so the device must re-register with the new value.

ByondVoice — Administrator & Operations Manual

Ch. 05 · Resellers

5.1.1 The four-tier hierarchy at a glance

Every object in ByondVoice belongs to exactly one tier above it. Knowing which tier an action belongs to tells you who can perform it and who can see the result. The table below is the map you will return to throughout this chapter.

ByondVoice — Administrator & Operations Manual

Ch. 05 · Resellers

5.2 Creating a reseller

Creating a reseller is the first step in onboarding a partner. You give it an identity, a primary contact, and an initial set of caps; branding (§5.3) and carrier (§5.5) follow. A reseller created here can sign in immediately at the platform login and begin adding tenants up to the caps you set.

5.2.1 Procedure — create a reseller

1. Open the screen. In Tenancy›Resellers select New reseller.
2. Name the reseller. Enter the partner’s name (e.g. Nimbus Telecom).
3. Set the short code. Type an uppercase code such as NIMBUS. Confirm it — it is permanent.
4. Enter the primary admin email. Use a monitored mailbox (e.g. [email protected]); this person receives the password-setup invitation.
5. Choose a plan and region. Select the wholesale plan and the home region (e.g. sg-south).
6. Create. Select Create reseller. The reseller appears in the list with a status of active and zero tenants.

ByondVoice — Administrator & Operations Manual

Ch. 05 · Resellers

5.2.2 What exists immediately after creation

A freshly created reseller is a real, sign-in-ready tenant container — but a bare one. Before it is ready to sell, you will normally complete three more things. The table records the state at each stage so you can hand a partner over confidently.

ByondVoice — Administrator & Operations Manual

Ch. 05 · Resellers

5.3 Branding a reseller

White-labelling is what makes a reseller worth selling. The brand you set here replaces “ByondVoice” everywhere the reseller’s tenants and their users look: the login page, the user self-service portal at my.byondvoice.com, and the softphone PWA at my.byondvoice.com/phone — including the icon installed to a phone’s home screen. A brand has two parts: visual identity (logo, wordmark, colours) and a login domain (the verified host the partner’s users sign in on). Recall that the voice path itself is white-labelled at the edge (see Chapter 2), so SIP banners and provisioning URLs also carry the partner’s identity, not yours.

ByondVoice — Administrator & Operations Manual

Ch. 05 · Resellers

5.3.1 Procedure — apply visual identity

1. Open the reseller. In Tenancy›Resellers select Nimbus Telecom, then the Branding sub-screen.
2. Set the display name and wordmark. Enter the brand (e.g. Nimbus Voice) and the emphasised wordmark suffix (e.g. Voice).
3. Set the colours. Enter the partner’s primary and accent hex values (e.g. #1E6FE0 and #0BC5C5).
4. Upload the logo and home-screen icon. Provide a vector or transparent-PNG logo and a square 512×512 PWA icon (used when a user installs the softphone to their home screen).
5. Preview, then save. Select Preview to check the portal and softphone, then Save brand to publish.

5.3.2 Procedure — verify a login domain

A login domain is the partner-branded host on which its tenants’ users sign in (e.g. voice.nimbus.sg) instead of the shared my.byondvoice.com. ByondVoice serves the portal and softphone on the partner’s domain once it is verified and a certificate is issued.

1. Enter the domain. In the Login domain panel type the host the partner will use (e.g. voice.nimbus.sg).
2. Create the CNAME. Ask the partner to point that host at the target shown — brand.byondvoice.com — in its DNS.
3. Verify. ByondVoice checks the record and requests a TLS certificate automatically. When complete the panel shows verified.
4. Confirm. Browse to the domain; the partner-branded sign-in card should load over HTTPS with the partner’s logo and colours.

ByondVoice — Administrator & Operations Manual

Ch. 05 · Resellers

5.4 Entitlements and caps

Within its brand, a reseller provisions its own tenants, numbers and extensions. Entitlements decide which features a reseller may switch on for its tenants; caps decide how much it may consume. Together they let you wholesale capacity safely: you sell Nimbus, say, 200 extensions and 10 concurrent PSTN channels, and the platform enforces those ceilings no matter how Nimbus distributes them across its tenants. Caps protect your infrastructure and your commercials; entitlements protect feature tiers (so a basic wholesale plan cannot quietly enable a premium feature).

ByondVoice — Administrator & Operations Manual

Ch. 05 · Resellers

5.4.1 The cap reference

These are the ceilings the platform enforces on every reseller. Each is counted across all of the partner’s tenants combined; a reseller may sub-allocate freely beneath the ceiling but can never exceed it.

Internal calling, extensions-to-extension, ring groups, voicemail and call handling all work without a carrier and do not consume the concurrent-PSTN cap; only calls that leave over a trunk do. This is why a small concurrent-PSTN cap is usually sufficient even for a partner with many extensions.

5.4.2 Suspending a reseller

Setting a reseller’s status to suspended is the platform’s commercial brake — typically for non-payment. Suspension freezes provisioning and new outbound for the partner and every tenant beneath it; calls already connected are not cut. Inbound delivery and outbound PSTN are blocked until you reactivate. Use it deliberately and reverse it the moment the reason is resolved.

1. Open the reseller. In Tenancy›Resellers select the partner.
2. Change status. Set status to Suspended and confirm. The partner and all its tenants move to suspended.
3. Reactivate when resolved. Set status back to Active; provisioning and calling resume immediately with no reconfiguration.

ByondVoice — Administrator & Operations Manual

Ch. 05 · Resellers

5.5 Bring-your-own carrier credentials

A reseller may already have a wholesale voice contract with a carrier, or may need numbers in a country your platform carrier does not cover. Bring-your-own (BYO) carrier lets a partner attach its own SIP trunk so that its tenants’ external calls leave over the partner’s carrier and bill to the partner’s carrier account — while everything else (PBX, routing, softphone, branding) stays on ByondVoice. The connection is configured the same way as any carrier in Carrier›Connectors, but the connector is owned by the reseller rather than the platform, so it serves only that partner’s tenants.

Remember the carrier gate: outbound PSTN, inbound DID delivery, and reaching an auto-attendant from an external number are all available only when a carrier is connected. Internal calling works regardless. For a BYO-carrier partner, that carrier is the one that lights up PSTN for all of its tenants.

ByondVoice — Administrator & Operations Manual

Ch. 05 · Resellers

5.5.1 Procedure — attach a reseller’s own carrier

1. Enable the entitlement. On the reseller’s Entitlements & caps screen confirm Bring-your-own carrier is on (§5.4).
2. Open Connectors. Go to Carrier›Connectors and select New connector.
3. Set the owner to the reseller. Choose Reseller · NIMBUS so the trunk is scoped to that partner.
4. Enter the carrier details. Provide the SIP host, auth username and secret, and the authorised caller-ID prefix from the partner’s carrier.
5. Test the trunk. Select Test trunk; ByondVoice registers/authenticates and reports reachability before you rely on it.
6. Save & sync. Select Save & sync. The connector is now live for the partner’s tenants; numbers can be searched/ported and outbound PSTN flows over it.

5.5.2 Platform carrier vs. reseller carrier

ByondVoice — Administrator & Operations Manual

Ch. 05 · Resellers

5.6 How white-labelling flows down

The power of the reseller model is that you configure the brand and carrier once, at the reseller tier, and they cascade automatically to every tenant beneath — and to every user beneath each tenant — with no per-tenant re-skinning. This section traces exactly what each layer inherits, and where the inheritance can be overridden.

So when Nimbus’s administrator creates the tenant Acme Corp, Acme is born Nimbus-branded: its admin and its users sign in at voice.nimbus.sg, see Nimbus colours, and place outbound calls over Nimbus’s carrier — without Nimbus touching a single branding field on the tenant. The user portal (§ user-manual) and the softphone PWA pick up the partner brand from the domain they are served on. The one thing a user still controls is their own outbound caller-ID, chosen from the numbers their tenant holds (subject to the partner’s authorised range).

ByondVoice — Administrator & Operations Manual

Ch. 05 · Resellers

5.6.1 Metering wholesale usage

Branding and carrier flow down; cost flows back up. The Wholesale Meter (Revenue → Wholesale Meter) is the one revenue screen that lives in the admin console and that this chapter touches: it sums each reseller’s consumption — extensions, numbers, and metered call usage on the platform carrier — so you can preview and run the platform-to-reseller bill. A BYO-carrier partner’s PSTN minutes bill to its own carrier, so the meter for that partner reflects platform service (seats, numbers, features) rather than call minutes you carried.

ByondVoice — Administrator & Operations Manual

Ch. 05 · Resellers

5.7 Operating a reseller well

The mechanics of creating, branding, capping and metering a reseller are straightforward; operating a healthy partner over time is where judgement pays. The practices below come from running multi-tenant voice at scale.

5.7.1 Onboarding checklist

ByondVoice — Administrator & Operations Manual

Ch. 06 · Tenants

6.2 The Tenants screen

Every tenant on the platform is listed under Tenancy›Tenants. This is the operator’s home base for customer accounts: a searchable, filterable table with a live count, the owning reseller, the licence headline and the current status of each tenant. From here you create a new tenant, open one to configure it, or change its status. The figure below reproduces the screen with the key elements numbered.

ByondVoice — Administrator & Operations Manual

Ch. 06 · Tenants

6.3 Creating a tenant

Creating a tenant is a single dialog that produces two records at once: the tenant container and its owner login — a tenant-type user who can administer the account and create the first extensions. You supply the customer’s identity, a unique slug, an owner email and an initial password; ByondVoice does the rest. The dialog is reached from + New tenant on the Tenants screen.

6.3.1 The create-tenant dialog

6.3.2 Procedure — create a tenant and its owner

1. Open the dialog. In Tenancy›Tenants select + New tenant.
2. Enter the display name. Type the customer’s name as it should appear everywhere, e.g. Acme Corp.
3. Choose a slug. Type a short, lower-case, globally unique handle, e.g. acme. Pick it carefully — it is fixed once saved (see the warning).
4. Enter the owner email (e.g. [email protected]) and an owner password that meets the platform password policy. A weak password is rejected with a validation error before anything is saved.
5. Assign a reseller (optional). Pick the owning reseller — here Nimbus Telecom — or leave it Direct (none) for a platform-direct account.
6. Set a dial prefix (optional). Leave blank unless the carrier requires a leading prefix on outbound calls.
7. Create. Select Create tenant. ByondVoice creates the tenant and its tenant-type owner login in one step.
8. Verify isolation. Have the owner sign in at my.byondvoice.com. They should see an empty-but-entirely-their-own tenant — never another customer’s data.

ByondVoice — Administrator & Operations Manual

Ch. 06 · Tenants

6.3.3 Worked example — onboarding Acme Corp

Worked examples run a procedure end-to-end with realistic values so you see the result, not just the steps. Here is the creation of our running customer, Acme Corp, a 20-person company being resold by the partner Nimbus Telecom.

6.3.4 Tenant fields — reference

The fields you set on a tenant, what they mean, and whether they can be changed later:

ByondVoice — Administrator & Operations Manual

Ch. 06 · Tenants

6.4 Configuring limits and licensing

A tenant’s licence is the set of caps that decide how much telephony it may consume: how many extensions and SIP devices it can provision, how many numbers it can hold, and — the one that maps directly to carrier capacity — how many concurrent calls it may run at once. Open a tenant and the licence panel slides out; this is where you set those caps and the per-tenant capability toggles. The caps are enforced live: the platform combines the stored cap with a running count, so raising a cap takes effect immediately, with no re-provisioning.

ByondVoice — Administrator & Operations Manual

Ch. 06 · Tenants

6.4.1 Procedure — set a tenant’s limits

1. Open the tenant. In Tenancy›Tenants select Open › on the tenant’s row to slide out its licence panel.
2. Set the extension and device caps. Enter Max extensions and Max SIP devices. Leave 0 for unlimited; set a real positive number to impose a ceiling.
3. Set the number cap. Enter Max numbers (DIDs) — the most external numbers the tenant may hold from the pool.
4. Set concurrent calls. Enter Max concurrent calls to match what the customer bought and what the carrier behind them can carry.
5. Flip the capabilities you want. Enable or disable outbound PSTN, voicemail-to-email and call recording for this tenant.
6. Save. Select Save licence. The new caps take effect immediately on the next provisioning action.

6.4.2 The caps — reference

ByondVoice — Administrator & Operations Manual

Ch. 06 · Tenants

6.5 The tenant scope selector

Most ByondVoice screens — Extensions & Devices, Voicemail, Ring Groups, Auto-Attendants, Conferences — operate on one tenant at a time. The tenant scope selector is the control that decides which one. It lives in the breadcrumb of every PBX screen: the part of the subtitle that reads tenant Acme Corp. Set the scope and the whole console pivots — the tables, the counts in the navigation rail, the KPIs and the New extension action all now refer to that tenant. There is no way to provision an extension “in the wrong tenant” by accident, because every create action inherits the current scope.

6.5.1 Procedure — switch the active tenant

1. Find the scope control. On any PBX screen, locate Tenant: … ▾ (or open the tenant from Tenancy›Tenants with Open ›).
2. Pick the tenant. Choose the customer you want from the list (type-ahead by name or slug).
3. Confirm the breadcrumb. Check the subtitle now reads tenant <your choice> before you change anything.
4. Work, then re-check on every screen. The scope persists as you move between PBX screens; glance at the breadcrumb each time you make a change.

ByondVoice — Administrator & Operations Manual

Ch. 06 · Tenants

6.6 Suspending, reactivating and deleting a tenant

A tenant has a lifecycle beyond creation. Day-to-day you will suspend a customer (for non-payment, abuse or at the customer’s request) and later reactivate them — both non-destructive, fully reversible status changes. Far more rarely you will delete a tenant, which permanently removes it and everything it owns. The golden rule: suspend first, delete almost never.

6.6.1 Suspend and reactivate (the reversible path)

Setting a tenant’s status to suspended blocks every login in that tenant and stops it placing or receiving calls — but it keeps every extension, number, voicemail and routing rule intact. Reactivating restores service exactly as it was. Nothing is lost; this is the right tool for billing disputes, suspected compromise, or a customer pausing service.

1. Open the tenant. In Tenancy›Tenants select Open › on the row.
2. Set the status. Toggle the status from Active to Suspended and save. Every login in the tenant is refused at the next sign-in with “account is not active”, and live calls are no longer routed.
3. Reactivate when resolved. Toggle back to Active and save. Service resumes immediately with all configuration intact.

6.6.2 Delete (the irreversible path)

Deleting a tenant removes the tenant and all of its extensions, SIP devices, voicemail boxes, ring groups, auto-attendants, conferences and users. It cannot be undone. Reserve it for genuinely finished accounts, and only after you have released the tenant’s numbers and exported anything the customer is owed. The console requires you to type the tenant’s slug to confirm, precisely because the action is so final.

1. Suspend first. If there is any doubt, suspend (§6.6.1) instead — it achieves “cut off service” reversibly.
2. Release numbers and export data. In Supply›Numbers release the tenant’s DIDs, and export any call history or voicemail the customer is owed.
3. Confirm scope and environment. Verify the breadcrumb names the right tenant and the chip reads ENV: PROD.
4. Open delete and type the slug. Choose Delete tenant, read the object count, type the slug acme, then select Delete permanently.

ByondVoice — Administrator & Operations Manual

Ch. 07 · Users

7.1.2 Why the split matters operationally

The separation is not academic — it changes how you carry out everyday tasks. Four scenarios show why you should think in terms of users and extensions rather than treating them as one thing.

ByondVoice — Administrator & Operations Manual

Ch. 07 · Users

7.2 The Users screen

Users for a tenant are managed under Hosted PBX›Users. The screen lists every person who can sign in to that tenant’s portal or softphone, the extension(s) each one is linked to, the state of their login, and whether they have a second authentication factor enabled. It is the home base for the rest of this chapter: every procedure starts here.

ByondVoice — Administrator & Operations Manual

Ch. 07 · Users

7.2.1 Reading a user row

Each column on the Users screen answers a question you will ask repeatedly during support and audit. Memorise the meaning of the two badge columns — Security and Status — because together they tell you, in one glance, whether a person can sign in and how strongly they are protected.

ByondVoice — Administrator & Operations Manual

Ch. 07 · Users

7.3 Linking users to extensions

The link between a user and an extension is what makes the self-service portal useful: when Alice signs in, the portal shows her line because her user record points at extension 1001. You manage links from the user’s detail drawer. A user may hold a single primary extension, several extensions (with one marked primary for outbound caller-ID and voicemail defaults), or none.

7.3.1 Procedure — link an extension to a user

1. Open the user. In Hosted PBX›Users click the person’s row to open their detail drawer, then the Extensions tab.
2. Search for the extension. In Link another extension type the number (e.g. 1050) or its label. Only extensions in this tenant that are free or marked shared are offered — an extension already owned exclusively by someone else will not appear.
3. Choose the role. The first extension you link becomes primary automatically. Add further extensions as secondary; use Make primary to change which one is the default identity.
4. Save. Select Save links. The change is immediate: the user’s portal and softphone pick up the new identity at their next page load or re-register.

ByondVoice — Administrator & Operations Manual

Ch. 07 · Users

7.3.2 Primary, secondary and shared lines

The primary link is more than a label. It decides three defaults for the user, so choose it deliberately and revisit it when roles change.

ByondVoice — Administrator & Operations Manual

Ch. 07 · Users

7.4 Per-user security

Each user carries their own credentials, independent of every other user and of the SIP secrets on their devices. There are two layers: the password (always present, stored hashed — never recoverable, only resettable) and an optional second factor — either an authenticator app (a time-based one-time code, TOTP) or an email one-time-code sent at sign-in. This section covers what you, the administrator, control from the console; the user manages the same settings for themselves from the portal (see § 7.5).

ByondVoice — Administrator & Operations Manual

Ch. 07 · Users

7.4.1 The two second factors compared

Both factors satisfy the same goal — proving the person holds something beyond their password — but they differ in strength, dependencies and who turns them on. Choose per the user’s role and equipment.

7.4.2 Procedure — reset a locked-out user’s access

1. Verify the request out-of-band. Confirm the person is who they say (a known colleague, a ticket from their manager) before touching credentials — resetting access on a spoofed request is the classic social-engineering attack.
2. Open their Security drawer. Users → the person → Security.
3. Send a reset link. Click Send reset link. ByondVoice emails a one-time, time-limited link to the address on file; the user sets a new password themselves. Prefer this — you never see or type their password.
4. If email is unavailable, set a temporary password. Use Set temporary password, read it to the user over a trusted channel, and confirm Force change at next sign-in is on so it cannot persist.
5. If their second factor is lost too, and you have verified identity, clear the authenticator enrolment or temporarily switch the user to email one-time-code so they can get back in, then have them re-enrol an app.

ByondVoice — Administrator & Operations Manual

Ch. 07 · Users

7.5 The user and the self-service portal

Everything a user record holds — its password, its second factor, the extensions linked to it — comes together at the self-service portal, my.byondvoice.com, and the softphone at my.byondvoice.com/phone. The portal is the user-facing mirror of the work you do in the admin console: the user signs in with the credentials on their user record and sees only the extension(s) linked to them. This is enforced strictly — a user’s portal API is scoped to their own extensions, so one person can never read or change another’s line.

ByondVoice — Administrator & Operations Manual

Ch. 07 · Users

7.5.1 What the user controls versus what you control

The portal and the admin console act on the same underlying records, so it helps to be clear about who owns which setting. As a rule: the user owns their personal security and their line’s day-to-day behaviour; the administrator owns the records’ existence, the links between them, and the SIP device secrets.

ByondVoice — Administrator & Operations Manual

Ch. 07 · Users

7.6 Provisioning a user end-to-end for Acme Corp

This is the chapter’s capstone: a complete walk-through that creates a brand-new person on the tenant Acme Corp, links them to an extension, sets their security, and hands over the softphone — turning every concept above into one continuous procedure. We will onboard Priya Nair, a new account manager, on extension 1006.

7.6.1 Procedure — onboard Priya Nair

1. Confirm scope. In the admin console, check the breadcrumb scope reads tenant Acme Corp and the chip shows ENV: PROD. Open Hosted PBX›Users.
2. Provision the extension first (if needed). If 1006 does not yet exist, create it under Extensions & Devices with label Priya Nair. (You can also create it inline from the dialog’s Link extension picker.)
3. Open the create-user dialog. Click New user.
4. Enter identity. Full name Priya Nair; username priya.nair; email [email protected].
5. Link the extension. In Link extension choose 1006. It becomes her primary automatically.
6. Choose the initial credential. Select Send invitation email so Priya sets her own password — you never handle it. (If she has no email yet, set a temporary password with Force change at next sign-in.)
7. Arm the second factor. Toggle Require second factor on for the email one-time-code, so her first sign-in is already protected.
8. Create. Click Create user. Priya appears on the roster as invited until she sets her password, then flips to active.

ByondVoice — Administrator & Operations Manual

Ch. 07 · Users

7.6.2 Provision a device and hand over the softphone

With the user and extension in place, the last mile is giving Priya something that rings. She can use the browser softphone immediately and, if she has a desk phone, register that to a SIP device on her extension.

1. Hand over the softphone. Tell Priya to open my.byondvoice.com/phone, sign in with her new password (and the emailed one-time-code), and install to home screen when prompted. The softphone registers her extension 1006 over secure WebSocket.
2. Add a desk phone, if any. Under Extensions & Devices → 1006 add a SIP device; copy the reveal-once secret (or use the auto-provisioning token URL) into the handset. Secrets are shown only once — capture it before you close the panel.
3. Have Priya finish her security. From her portal’s My Phone›Profile & security she can upgrade from email one-time-code to an authenticator app and confirm her default caller-ID is 1006.
4. Verify end-to-end. Place a test internal call to 1006 and confirm her softphone rings; dial the echo test 9196 to check two-way audio; leave a message and confirm it lands as visual voicemail and as a voicemail-to-email.

7.6.3 Off-boarding — the reverse of onboarding

1. Disable the login. Users → the person → set Status to Disabled. This ends live sessions and blocks sign-in at once, but keeps the record and the number.
2. Decide the extension’s fate. Re-link 1006 to the replacement user (the desk number is preserved), or leave it linked and forward it while the seat is vacant.
3. Revoke devices if the seat is gone. Remove or rotate the SIP device secrets on the extension so an old handset cannot re-register.

ByondVoice — Administrator & Operations Manual

Ch. 08 · Numbers

8.2 The Numbers screen

The pool lives under Supply›Numbers. This is the operator’s register of every DID the platform holds: a searchable, filterable table with KPI tiles across the top, a status filter, and a row per number showing its E.164 form, the owning tenant (if any), its routing destination and its lifecycle status. From here you preload stock, assign or reserve a number to a tenant, release one back to the pool, or open the source configuration. The figure below reproduces the screen with the key elements numbered.

ByondVoice — Administrator & Operations Manual

Ch. 08 · Numbers

8.3 The number lifecycle and status reference

Every DID in the pool is in exactly one status at any moment, and the status both describes the number’s situation and decides which actions the Manage menu offers. Understanding the four states — and the legal moves between them — is the key to running the pool cleanly. The normal life of a number is available → (reserved) → assigned → released → available; the parenthesised reserve step is optional.

8.3.1 Status reference

8.3.2 Procedure — read the pool with KPIs and filters

1. Open the pool. Go to Supply›Numbers. The KPI row reports the pool at a glance: In pool, Available, Assigned, Reserved.
2. Check free stock first. Read the Available tile. If it is low — say below your re-order threshold — plan a preload (§8.5) before you run out.
3. Filter by status. Click Available to list only free stock you can hand out, or Assigned to audit what is in use.
4. Type to find a number or tenant. Enter digits (e.g. 0010) to jump to one DID, or a tenant name (e.g. Acme) to list everything that customer holds.
5. Open a row. Select Manage › to act on a single number; the menu shows only the moves legal for its current status.

ByondVoice — Administrator & Operations Manual

Ch. 08 · Numbers

8.4 Assigning, reserving and releasing

These three actions move a number through its lifecycle. Assigning draws an available number out of the pool and into a tenant; reserving earmarks one without making it live; releasing hands one back. All three are reached from Manage › on the number’s row, and all three respect the tenant’s number cap (§6.4) — you cannot assign a fourteenth number to a tenant licensed for ten.

8.4.1 The assign dialog

8.4.2 Procedure — assign a number to a tenant

1. Find free stock. In Supply›Numbers filter to Available and locate the DID (e.g. +65 3159 0010).
2. Open the action. Select Manage › then Assign.
3. Choose the tenant. Pick the new owner, e.g. Acme Corp. If Acme is at its number cap, the assignment is refused — raise the cap first (§6.4).
4. Optionally route now. Set Route inbound to to an extension, ring group or auto-attendant — or leave it for §8.7.
5. Optionally make it the default caller-ID and add a label so colleagues recognise the number’s purpose.
6. Confirm. Select Assign number. The row’s status flips to assigned, ownership shows the tenant, and the Available KPI drops by one.

ByondVoice — Administrator & Operations Manual

Ch. 08 · Numbers

8.4.3 Reserve — earmark a number without making it live

Reservation holds a number for a named tenant while you arrange the rest — a port that has not completed, a customer who is signing but not yet onboarded, or simply a memorable number you want to protect from the next preload. A reserved number is invisible to other tenants and excluded from the available pool, but it does not ring and does not yet consume the tenant’s live cap. When you are ready, you confirm the reservation, which assigns it for real.

1. Open the number. On an available row select Manage › then Reserve.
2. Name the tenant to hold it for. Choose the customer, e.g. Acme Corp, and optionally a note (“awaiting port”). The status becomes reserved and ownership shows the tenant with a hold marker.
3. Confirm to go live. When ready, select Manage › then Assign on the reserved row — this converts the reservation to assigned, after which you route it (§8.7).

8.4.4 Release — hand a number back to the pool

Releasing detaches a number from its tenant, clears its routing, and returns it to the pool. Use it when a customer gives up a number, when you suspend or delete a tenant (suspension does not auto-release — §6.6), or to un-reserve a hold. A released number frees a slot against the tenant’s cap and becomes available stock again.

1. Open the number. On an assigned or reserved row select Manage › then Release.
2. Confirm the release. The dialog warns that inbound delivery to this DID will stop and routing will be cleared. Confirm to proceed.
3. Verify it returns to stock. The row drops its tenant, shows released (then available after any cool-down), and the Available KPI rises by one.

8.4.5 Worked example — assigning +65 3159 0010 to Acme reception

ByondVoice — Administrator & Operations Manual

Ch. 08 · Numbers

8.5 Bulk preload of stock numbers

When a carrier hands you a block of numbers — a contiguous range, or a list pasted from a carrier order — preload loads them into the pool as available stock in one action, instead of typing each by hand. Preload only stocks the pool; it never assigns to a tenant. You preload, then assign from stock as customers need numbers (§8.4). Reach it from + Preload numbers on the Numbers screen.

8.5.1 The preload dialog

8.5.2 Procedure — preload a block of stock

1. Open preload. In Supply›Numbers select + Preload numbers.
2. Pick the mode. Choose Range for a contiguous block, or Paste list for an ad-hoc list (one number per line, E.164).
3. Enter the numbers. For a range, type From and To (e.g. +65 3159 0020 to +65 3159 0039) and confirm the live count looks right.
4. Choose the source & country. Pick the carrier source the block belongs to and the country code; leave Initial status as Available unless you are pre-reserving.
5. Read the pre-flight summary. Confirm will be added, and note any duplicates (skipped) or invalid entries (rejected).
6. Commit. Select Preload 20 numbers. The pool grows; the In pool and Available KPIs rise by the count loaded.

ByondVoice — Administrator & Operations Manual

Ch. 08 · Numbers

8.6 The number source configuration

A source is where a block of numbers comes from — a carrier or upstream DID provider, identified by a name and backed by the credentials needed to talk to it. The source configuration stores those credentials. Crucially they are held write-only: you can enter or replace a secret, but the console never shows an existing one back. This mirrors how SIP device secrets are handled across ByondVoice — a secret is something you set, never something you read. Open it from Source config on the Numbers screen.

8.6.1 Procedure — configure a number source

1. Open source config. In Supply›Numbers select Source config (or open an existing source from the list).
2. Name and type the source. Enter a clear name (e.g. Nimbus SG trunk) and pick the provider type.
3. Enter the account and endpoint. Add the account / API username and the endpoint / host your carrier gave you.
4. Set the secret. Paste the API key / secret. To rotate later, type the new secret over the masked field; to leave it unchanged, leave the field blank.
5. Test, then save. Select Test connection to confirm the credentials work, then Save source. The status banner should read Connected.
6. Stock from the source. Use this source when you preload (§8.5) so each loaded number is tied to the carrier that delivers it.

ByondVoice — Administrator & Operations Manual

Ch. 08 · Numbers

8.7 Mapping numbers to extensions and DIDs

Assigning a number gives a tenant ownership; mapping it gives an inbound caller somewhere to land. The mapping is the heart of inbound: it answers the question “when this DID is dialled, what rings?” A number can route to any of four destination types, and you set the mapping on the assigned number’s Manage › Routing panel.

8.7.1 Procedure — map a number to a destination

1. Open routing. On the assigned number’s row select Manage › then Routing.
2. Choose the route type. Pick Extension, Ring group, Auto-attendant or Conference.
3. Choose the target. Select the specific destination — e.g. extension 1001, ring group 6000, or conference 3000.
4. Set options. Optionally add a caller-ID prefix and enable an out-of-hours voicemail fallback.
5. Save and test. Select Save routing; the row’s Routes to column updates. With a carrier attached, dial the DID and confirm the right destination rings.

ByondVoice — Administrator & Operations Manual

Ch. 08 · Numbers

8.8 Edge cases and best practice

The pool is shared and the actions are live, so a few habits keep it tidy and keep customers’ calls flowing. The table below collects the situations that most often trip up operators, with the right move for each.

8.8.1 End-to-end recap

Putting the chapter together, the full supply path for a new inbound line is: (1) ensure stock exists — preload a block from the right carrier source (§8.5–8.6); (2) assign a number from stock to the tenant, respecting its cap (§8.4.2); (3) optionally reserve first if the line is not yet ready (§8.4.3); (4) map the number to its destination (§8.7); and (5) confirm a connected carrier actually delivers it (§8.1, §Carrier). Release reverses the path, returning the number to the pool (§8.4.4).