The contract is the central record connecting every department. When support opens a ticket, they see the billing balance and signal levels instantly. No integrations, just one unified database.
In most ISP operations, the customer exists in five places: as an account in the billing system, as a device record in the network management tool, as a ticket in the helpdesk, as a line item in the inventory system, and as a row in a finance spreadsheet. Each system has its own version of the truth. When these versions disagree, and they always do, someone has to reconcile them manually.
ISPCQ eliminates this by design. There is one customer record. One contract. That contract connects to the billing ledger, the installed equipment serials, the OLT port assignment, the signal history, the support ticket timeline, and the payment history.
This is not an integration layer sitting on top of separate systems. It's a single application with a single data model. The billing engine writes to the same ledger that finance reads. The network provisioning system reads the same contract that support sees.
There is no synchronization delay, no mapping table, and no "sync failed" error at 3 AM.
A battle-tested stack designed for operational reliability. Multi-region, multi-tenant, AI-native, configuration-driven.
One codebase, infinite localizations. An ISP group running operations in multiple countries doesn't need separate installations or code forks. Regional differences (address formats, tax rules, currency display, payment gateway configuration) are handled through data-driven configuration layers.
ISPCQ runs on a proven stack optimized for ISP transaction volumes: thousands of billing cycles, hundreds of concurrent users, and continuous network polling, all on modest server hardware. Designed for operators who want fast page loads and low maintenance, not engineering teams managing microservices.
Embedded LLM intelligence powered by Claude. Aelita operates within the same permission boundaries as the logged-in user. She can draft, suggest, and analyze, but she cannot act without human approval. AI acceleration without AI risk.
Payment gateways, OLT and network drivers, and messaging channels ship as self-contained, manifest-described extensions, switched on per-tenant through database configuration. No code forks, no core edits. Each extension declares its own boot files, dependencies, and config keys, so an operator's capability set is composed from configuration rather than custom builds.
Scenario. Customer #4721 calls to cancel their service. In a disconnected stack, cancellation is a multi-step process across four systems: the support agent creates a cancellation request, someone in billing has to stop the next invoice, the NOC team needs to deprovision the OLT port, and the inventory team needs to schedule equipment recovery. If any of these steps is missed, the customer gets billed after cancellation, or the ONU sits at their premises for months, or the OLT port stays allocated and unavailable.
In ISPCQ. The support agent opens the contract and initiates cancellation. This single action triggers a coordinated workflow: billing is scheduled to stop on the service end date with any required proration, the OLT port is flagged for deprovisioning, the inventory system creates a recovery task for the assigned ONU (serial number pre-filled), and the contract status changes to "Pending Termination", visible to every team. If equipment is not recovered within the configured window, an automated reminder escalates to the field supervisor.
The result. Every step is connected because every module reads from the same contract record. There is no handoff email. There is no "I didn't know they cancelled." The contract is the nucleus, and every team orbits around it.
ISPs handle sensitive customer data, financial records, and network credentials. Where that data lives matters, not just for compliance, but for operational confidence. Two equally legitimate deployment paths; same architecture either side.
ISPCQ keeps every department on the same operational timeline: customer lifecycle, network state, financial status, and field actions.
One contract record powers support, billing, network, and inventory workflows. When a field technician installs equipment, the contract updates. When billing generates an invoice, the contract reflects it. When NOC detects a fault, the affected contracts are identified automatically.
Every ISP operates slightly differently. ISPCQ adapts through database-driven configuration: form fields, validation rules, approval chains, notification triggers, and regional variations. No code changes required. The operations team can adjust workflows as the business evolves.
Every significant action is logged: who changed a plan, who approved a credit note, who closed a ticket without resolution evidence, who dispatched a technician. This creates an operational timeline that leadership can review, not for surveillance, but for process improvement and accountability.
Less cross-system friction. Teams stop re-entering data and reconciling conflicting records between tools. A support agent doesn't need to ask "what's the billing status?" because it's on screen. A finance clerk doesn't need to email NOC asking "is this customer actually disconnected?" because the contract status is shared.
Faster operational decisions. When the COO asks "how many customers are affected by that fiber cut?", the answer is available in seconds, not after someone queries three systems and cross-references in a spreadsheet. Decision-makers see billing risk, network health, and field status in one place.
Stronger accountability. Every key action is visible and traceable across teams. When something goes wrong (a customer billed incorrectly, equipment missing after an install), the audit trail shows exactly what happened, when, and by whom. This shifts culture from "who's responsible?" to "how do we prevent this?"