When an internet service interruption produces a wave of customer contacts, the network and billing teams need a shared incident picture. Some customers may be unable to authenticate, some may have paid shortly before the interruption, and others may be reporting an unrelated account problem. Treating every contact as the same fault can lead to unnecessary account changes and inconsistent explanations.
This guide recommends an incident-coordination workflow for an ISP. It does not assume that a router's health controls a payment provider's settlement process, or that a billing platform automatically compensates every outage. Network restoration, payment investigation and customer remedies should each follow the operator's documented responsibilities and policies.
Open one incident record with a clear scope
Create an incident record as soon as a shared service problem is suspected. Record the first known observation, its timezone, the affected site or service and the person coordinating the response. Distinguish the time a customer noticed the problem from the time the team confirmed it.
Describe the current scope without overstating certainty. “Several customers on this access segment cannot complete the agreed browsing test” is more useful than declaring every subscriber offline before checking. Add evidence as the investigation develops and keep earlier observations available in the incident history.
Choose a shared update route for the staff who need it. Customer support, network operations and billing should be able to find the current incident reference and latest confirmed status. Avoid creating separate, contradictory summaries in several chat groups without a named person responsible for keeping them aligned.
Separate the service checks
Establish what is working and what is failing. Check management reachability, the subscriber's access path, authentication and traffic as separate observations. A response from a router's management interface is not the same test as a subscriber reaching an external destination.
Use a designated test account and a repeatable procedure where possible. Record the device, location, connection type and test time. Compare another service that shares part of the path only when that comparison can help narrow the investigation.
For deployments using RADIUS, the RouterOS RADIUS documentation provides the relevant authentication and accounting context. Preserve the difference between an explicit rejection and an exchange that did not receive a usable reply. Have the responsible engineer interpret those observations alongside the actual deployment rather than changing account credentials in response to every timeout.
Give customer support a usable status note
Provide a short note that customer-facing staff can use consistently. Include the known affected scope, what the team is checking, the next planned update and any safe action requested from the customer. Be clear when the cause or recovery time is still being investigated.
Do not ask every subscriber to reset equipment or repeat a payment unless an approved, evidence-based procedure requires it for that specific case. Repeated customer actions can create additional support work and make the original timeline harder to reconstruct.
Tell staff how to identify a contact that may fall outside the shared incident. An account-specific rejection on another site may need a separate investigation even while a wider incident is open. Link related cases to the incident while preserving their individual observations, so that they can be checked after the shared service recovers.
Keep payment cases connected but distinct
When a subscriber reports paying without receiving service, verify the transaction through the approved billing process and identify the intended account and package. Record the payment observation separately from the network symptom.
A confirmed collection does not establish that the current device has authenticated or that the access path is healthy. Equally, a network interruption should not automatically be described as a missing payment. The support record should say which part has been verified and which part remains under investigation.
Use the operator's normal approval process for a correction, refund or other customer remedy. Do not invent a new payment-to-router gate during an incident, and do not promise a provider-side outcome before it has been confirmed. If the customer needs an update from a different team, assign the handover explicitly instead of leaving the case marked only as “network issue.”
Protect recovery options during technical work
The engineer making a production change should identify the affected services and the available management and recovery paths. Preserve the information needed to restore the previous state through the operator's approved process. Keep credentials and recovery material in the authorized location.
Record the hypothesis behind the proposed action, what will change and which observation will indicate success. Where the action may interrupt other subscribers, coordinate the decision with the incident lead and communicate the impact to the relevant staff.
Apply a bounded change and repeat the original test. If the expected result does not occur, record it and reconsider the hypothesis. Avoid accumulating undocumented exceptions because each one can complicate later diagnosis. The goal is a controlled recovery whose result another engineer can understand and reproduce.
Verify restoration from the subscriber side
When infrastructure appears healthy again, repeat the agreed subscriber journey. Include the service types and affected paths that were part of the incident. For a HotSpot deployment, verify the intended portal and login journey using the MikroTik HotSpot documentation as technical background for the installed service.
Record which tests passed, when they were performed and any remaining limitation. Ask customer support to confirm a representative affected case where practical. A recovery message should describe the service observations that support it rather than promising that every unrelated account issue is also resolved.
Check the linked payment and subscriber cases separately. Some may be resolved by the shared recovery; others may still require an account correction or transaction investigation. Give each remaining case an owner so that closing the network incident does not silently close unfinished customer work.
Review customer remedies through the approved policy
If the operator offers outage credits or another remedy, establish eligibility and the relevant time window using the documented policy. Preserve the evidence used for the decision. Do not assume that every active account experienced the same interruption or that a service already expired before the incident lost the same period as another subscriber.
Have the authorized team review exceptions and record any action taken. Customer communications should explain the actual decision clearly, including what has been applied and what is still being considered. Avoid quoting a compensation formula or promising an automatic adjustment unless it is the policy and workflow actually in use.
Keep restoration and remedy decisions linked in the incident record without treating them as interchangeable. Restoring connectivity answers an operational question; applying a customer adjustment answers a separate service-policy question. Both need a traceable outcome.
Build a timeline that supports learning
After the urgent response, assemble the significant observations, decisions and changes in time order. Include detection, initial customer impact, major tests, recovery actions and subscriber-side verification. Explain any uncertainty in the incident start or end time.
Separate the established cause from contributing conditions and untested hypotheses. If the cause remains unknown, record the next evidence needed instead of inventing a definitive explanation for the report. Retain the relevant logs according to the operator's normal data-handling process.
Review how the teams coordinated. Note where support lacked a current status, where a billing exception lost its owner or where the technical team repeated a test because the earlier result was not recorded. Convert those findings into specific changes with a responsible person and a completion check.
Close the incident without losing follow-up work
Publish a final internal summary that states the confirmed impact, restoration evidence and outstanding actions. Keep individual customer cases open when they still require work, and reference the shared incident so staff can find its context.
Update the installation, monitoring or handover checklist when the findings justify it. Measure the effect of the change using actual records rather than claiming an improvement that has not been observed. A smaller, evidence-based improvement is more useful than an impressive but unsupported statistic.
Contact CENTRANET to discuss how your subscriber, billing and router-support workflows fit together. A clear incident timeline and a list of unresolved handover gaps provide a practical starting point.