Kiapoynt
Fibre ISP · multi-tenantInternally: sply-smart-api

ISP operations platform

Optical monitoring, billing and bank payments in one operations system. Two operators run on it, isolated from each other.

SmartOLTSplynxNCBABullMQPostgres
The situation

An ISP running optical monitoring in one platform, billing in another, and bank payments arriving as unread webhooks. Nothing shared a view. An ONU going dark meant a customer complaint arrived before anyone technical knew, and opening a support ticket meant someone manually matching a serial number across two separate portals.

What we built
  • 01

    A multi-tenant operations platform sitting on top of SmartOLT (optical monitoring), Splynx (billing) and NCBA bank payments — not replacing them, integrating them.

  • 02

    Scheduled polling of optical equipment with a toggle per tenant, so one operator's maintenance window doesn't affect another's monitoring.

  • 03

    Automatic optical alerting that opens a Splynx support ticket directly, with deduplication so a flapping connection doesn't spawn duplicate tickets.

  • 04

    A four-tier, time-based escalation system: a ticket left open past a configured threshold reassigns itself to a wider support group and raises its own priority.

  • 05

    Migrated the whole platform from a single shared instance to true multi-tenancy — isolated API credentials per tenant, and a circuit breaker so one tenant's SmartOLT outage can't stall polling for the other.

  • 06

    A payments dashboard for NCBA transactions, and churn analytics with PDF/CSV export for operator reporting.

In production

Real interfaces, not mockups.

NCBA payments dashboard
Optical alert & ticket view
Churn analytics export
Under the hood

Isolating two tenants that used to share everything

The platform originally held one shared SmartOLT/Splynx client per process — fine for a single operator, unsafe for two. Making it multi-tenant meant moving every service (SmartOLT client, Splynx client, ticket handling) from a single shared field to a Map keyed by tenant instance ID, so each tenant's credentials, cached state and in-flight requests never cross paths. The circuit breaker sits at the same boundary: if one tenant's SmartOLT account starts failing, its breaker trips and the poller keeps servicing the other tenant on schedule instead of stalling behind retries.

Outcome
2

ISP tenants running on one platform

417

ONUs polled per monitoring cycle

4

escalation tiers, fully automatic

Something similar to build?

Tell us what you run today and where the manual work sits.