How cluster-detect turns forty-seven unrelated tickets into one coordinated incident, and the dispatch decision into a ninety-second exercise.
The old way. 19:20. Forty-seven customers go offline within an hour on the same fibre route. Each calls support. Each ticket is opened individually. The NOC engineer sees a list of forty-seven names and starts calling each customer back. Two hours pass before anyone notices the geographic clustering.
By 22:00, support has logged the same incident under twelve different categories. The NOC has dispatched two crews to two different splice points. Finance has not yet realised that any of these accounts will need credit notes.
What ISPCQ does. Aelita's cluster-detect engine recognises within minutes that two or more customers in the same neighbourhood dropped offline within a short window as a single infrastructure event. One incident note is created with all forty-seven contracts attached. The on-call NOC engineer opens it, runs cable-fault impact analysis, sees the affected splitter, and dispatches one crew to one location.
The operational outcome. By 21:30 the splice is repaired. Forty-seven customers are back online. The credit-note queue auto-populates based on the outage duration. One incident, one dispatch, one repair, one Friday evening.
One of twenty-two detailed articles on real ISP workflows. Each walks through the problem, what teams used to do, what ISPCQ does, and the operational outcome. The architecture is the same; the workflows differ.