Give Your 3CX Clients Scoped Access — Without Handing Over the Keys

The problem: customers keep calling to ask if the phones are working

If you manage 3CX for other businesses, you know this rhythm. A customer's internet hiccups for ninety seconds and the front desk calls you to ask whether their phone system is down. A manager wants to know why a call dropped this morning. Somebody emails to ask if last night's backup ran. And every few weeks, like clockwork: "can you change our after-hours greeting?"

None of these are hard. All of them are interruptions. And the instinctive fix — "just give them a login" — is the wrong one, because the only login most PBX tooling offers is some flavor of admin. Hand a customer real 3CX management access and you've handed them the ability to break their own routing, see things they shouldn't, and generate a far worse class of ticket than the one you were trying to avoid.

What customers actually want is narrow: a way to see that their system is healthy, and occasionally, a way to update their own greeting. Neither one requires the keys to the PBX. Sikurd splits "customer access" into two purpose-built models so you can give clients exactly that — and nothing more.

Model 1: Customer Status Pages (public, no login)

Every PBX in your fleet can publish its own status page at a public URL — /status/{slug}. Think of it as a status.yourcompany.com for one customer's phone system: a clean, white-label snapshot they can bookmark, post in a lobby, or forward to their leadership. No account, no password to remember (unless you want one), no way to touch anything.

The point of a status page is that you control exactly what appears. Each section is an independent toggle in the configurator on the instance's detail view, so two customers can have very different pages. The sections you can switch on:

• Overall status + Health Score

  A single "All Systems Operational" badge, and optionally the 0–100 health score with its uptime / backup / license / trunk / version breakdown.
• Uptime (last 30 days)

  A rolling 30-day availability percentage — the number a customer's leadership actually asks about.
• SIP trunks

  How many trunks are registered out of the total, with a Degraded badge if any are down. Recent incidents render alongside it.
• Backups — including the restore certificate

  The last backup's status and time, plus the most recent restore-verification certificate (a Verified badge, the ID, and a link to the full tamper-evident proof at /verify/{id}).
• Active calls + office hours + holidays

  A point-in-time active-call count, the published weekly office hours pulled live from the PBX (with an Open now / Closed now pill), and the next several upcoming holidays.
• The call-flow diagram (read-only)

  A visual of how inbound calls route through trunks, DIDs, IVRs, ring groups, and extensions — so a client can see and discuss their setup without being able to change it.

A few things worth calling out, because they're the difference between a status page that's useful and one that's a liability:

• Sensitive counters default to OFF. Headcount-style numbers — total users, queues, ring groups, digital receptionists — are opt-in. A freshly created status page will never leak a customer's employee count to a public URL just because you forgot a setting. You have to deliberately turn each one on.
• It's white-labeled. The header shows your logo (from Settings → Branding); it only falls back to the Sikurd wordmark if you haven't uploaded one. A small "Powered by Sikurd" line stays in the footer, but the page reads as yours.
• It can be password-protected. Flip the page to private and set a shared password — it's hashed with bcrypt, and no data renders until a visitor enters it. Public for a lobby display, private for the leadership team: your call, per page.
• The URL isn't guessable. Slugs are derived from the instance name plus a random suffix, so nobody finds the page just by typing the customer's name.

Model 2: Client Portal Access (a login, scoped to one instance)

Some customers want more than a status URL. They want to log in, look around their own system, and — crucially — handle their own greetings without opening a ticket. That's what the CUSTOMER role is for: a real login that is fenced into exactly one instance and is view-only across the board, with one deliberate exception.

Here's the precise shape of what a CUSTOMER-role user can do:

• See their own instance — health, status, and the operational detail for the single PBX they're attached to. And nothing else: they can't see your other customers, full stop.
• Self-serve their voice prompts — record or replace their own greetings, hold messages, and after-hours prompts. This is one of only two things they're allowed to write.
• Self-serve their business info — keep their own contact and business details current. The second, and last, write capability.
• Nothing else. No billing. No team management. No settings. No routing changes, no trunk config, no extension edits, no access to any instance but theirs.

The mental model: it's the visibility of a status page, plus a tightly scoped self-service desk for the two things customers ask for most — and a hard wall around everything that can actually break a phone system.

Which model should you use?

They're complementary, not either/or. A useful rule of thumb:

• Use a Customer Status Page when the customer just wants to know. They want a link to check that the phones are up, see uptime for the month, or show their boss the backup is green. No login to provision, nothing to support. Great for a lobby display, a leadership bookmark, or a "here's your status page" line in your onboarding email.
• Use Client Portal Access when the customer wants to do something — specifically, manage their own greetings and keep their business info current — and you want that handled without a ticket. It's the right tool for the marketing coordinator who changes the holiday greeting four times a year, or the office manager who'd rather not email you to update a hold message.
• Use both for your more engaged accounts: a public status page for passive, share-anywhere visibility, plus a scoped login for the one or two people who actually self-serve.

The security boundary, in plain terms

The reason you can hand this out freely is that the limits are real, not cosmetic. A couple of principles are worth understanding because they're what make "give the customer access" a safe sentence:

Scoped to one instance — by design, not by hiding

A CUSTOMER login is bound to a single instance. There is no list of your other customers to stumble into, because the role simply isn't granted access to them. This is enforced where it counts — on the server, on every request — rather than by hoping a hidden menu item stays hidden. UI hiding is a convenience; the server-side check is the boundary.

View-only, with exactly two exceptions

Every write a CUSTOMER attempts is denied unless it's one of the two self-service workflows — voice prompts or business info — and the system requires that self-service intent to be explicitly declared for the write to go through. There's no general "save" path a customer can reach to mutate anything else. If a new feature ships tomorrow, it inherits this posture by default: closed to CUSTOMER unless someone deliberately opens it.

Fails closed

If a user's role is ever missing, malformed, or unrecognized, the system treats them as a CUSTOMER — the most restricted role there is. A bad value can't accidentally widen access; the worst case is the safest case. That's the right default for anything you're exposing to people outside your own team.

Why this matters for an MSP

Two things happen when customer access is scoped correctly. First, you delete a category of repetitive tickets — the status checks and the greeting changes that interrupt real work without being real work. Second, you give customers something that feels like transparency and control, which is exactly the thing that makes a managed-services relationship sticky, without taking on any of the risk that usually comes with it.

The pitch to your own customer is simple and honest: "Here's a live window into your phone system, and here's a place to update your own greetings — and you can't break anything, because you don't have the keys." That's a sentence most PBX tooling can't say truthfully. Sikurd can.

Adjacent reading

• Best tools for managing multiple 3CX servers — where customer access fits in the broader fleet picture.
• How to monitor 3CX trunk health — the trunk data that shows up on a status page.
• 3CX MOS scoring explained — the voice-quality signal behind the health score.