Investigate subscriber connectivity with iPilot and human approval

A subscriber reports repeated disconnections, but support sees an active account and the NOC has no confirmed cause. Restarting equipment immediately may interrupt service without explaining the fault. Start with a bounded investigation that separates account status, authentication evidence and device health, then require an operator decision before any change.

Define the case and prerequisites

Use this walkthrough for one subscriber whose connection repeatedly drops. The reported symptom is the starting point, not a diagnosis: an active account does not prove successful authentication, and a connected session does not prove stable service.

Before opening the investigation, collect the subscriber identifier, affected service, approximate incident times with time zone, and whether the connection recovers on its own. Ask whether all devices lose connectivity or only one endpoint. These details help distinguish an access problem from a narrower customer-side symptom without assuming either cause.

For the evaluation, confirm that iPilot is separately activated and that the assigned operator can access the relevant subscriber and connected systems. Its tools are scoped to authorized data and devices; do not assume that every router or access device is available. Identify who may approve changes and who will confirm service restoration with the subscriber.

Before implementing any proposed action, validate the applicable device and software versions, service contracts, configurations and local regulations. These are checks against your operating environment, not a requirement to deploy a new management stack. If a necessary system is unavailable, record that gap rather than treating an incomplete investigation as conclusive.

Workflow: investigate one disconnecting subscriber

1. Resolve the subscriber and scope. In the engineering workspace, ask iPilot to investigate the identified subscriber during the reported period using read-only checks. Ask it to identify the associated service and devices before drawing conclusions. A useful prompt is: “Investigate repeated disconnections for this subscriber during the reported window. Show the evidence, identify missing context and do not make changes.” This is an investigation request, not a device command.
2. Check service and billing context. Review the account, plan and service status alongside relevant invoice or balance information. If the records suggest a service restriction, ask billing to confirm its meaning under the subscriber’s contract. Do not infer that a balance necessarily caused the disconnections or alter commercial records simply to test connectivity.
3. Inspect authentication and sessions. Ask for available RADIUS authentication and disconnect evidence associated with the subscriber. Compare it with the reported times and session context. Distinguish a failed attempt to establish service from an established session that later ended. If no relevant records are available, keep both possibilities open.
4. Inspect the associated network path. Use the authorized tools to examine relevant router state and, for a fiber service, OLT and ONU health or optical evidence. Check that the device belongs to the subscriber’s path. Expand the scope to other subscribers only when the evidence justifies testing a shared fault and the operator has the required access.
5. Separate findings from hypotheses. Request a summary of observed facts, possible explanations and the next discriminating check. A device alarm occurring near a disconnect is a lead, not proof of causation. If the evidence points toward a physical access fault, inspection may be the appropriate next step rather than a configuration write.

At this stage, “done” means the subscriber and affected scope are identified, relevant evidence has been inspected, and the team has either a supported diagnosis or a specific unanswered question. It does not mean the assistant must recommend a change.

Approve an action, then verify the outcome

Diagnosis and execution are separate decisions. If iPilot proposes a supported change, the approving operator should review the exact commands, affected scope, risk and expected result. Check that the target matches the investigated device and that the action addresses the observed fault rather than merely clearing its symptoms.

Changes need operator approval and verification. The documented workflow distinguishes read-only inspection, controlled changes and destructive actions, with explicit approval for sensitive work. Establish an owner policy that makes approval a deliberate decision, not a routine response to an AI recommendation.

Before approving, define the success test and an operator-owned recovery plan. Confirm what happens if the action interrupts management access or affects neighboring services. If the action’s support, impact or recovery path is unclear, stop and resolve those questions through the applicable engineering procedure.

After an approved action, recheck the evidence that motivated it: session state, subsequent disconnects and relevant device health. A successful command response is not proof of subscriber recovery. Ask support to confirm the original symptom with the subscriber and use an observation period appropriate to the reported recurrence pattern.

If service remains unstable, preserve the result and return to the unresolved hypothesis. Avoid stacking additional changes merely because the first one failed. Close the case only when the result is verified, or hand it off with the remaining uncertainty explicitly stated.

How ISPbills supports the investigation handoff

ISPbills connects subscriber, billing, support and network workflows in one operational system. For this case, that shared context helps teams examine the relationship between service status and access evidence rather than exchanging isolated account and device descriptions.

Within ISPbills, iPilot uses authorized, tenant-scoped operational tools to investigate subscriber and device state. Its documented investigation areas include billing, RADIUS, MikroTik, OLTs and ONUs. Verify which systems and tools are actually accessible for your test subscriber before relying on a complete view of the path.

Visible tool activity, evidence, proposed commands and verification results remain in the engineering timeline. That supports a more concrete NOC-to-support handoff: what was checked, what was found, whether an action was approved, and what the recheck showed. Ask the receiving team to confirm that the summary answers its operational question rather than merely listing tool output.

iPilot is a separately activated credit product, not an unlimited entitlement included in every ISPbills plan. Review the current feature and pricing pages for availability, demo eligibility and commercial terms before planning team use.

Limitations: keep missing evidence visible

Scoped access limits what an investigation can establish. An inaccessible router, missing disconnect record or incorrect subscriber-to-device association can leave a plausible explanation untested. Ask iPilot to state those gaps explicitly; absence of retrieved evidence is not proof that an event did not occur.

The supplied documentation does not establish compatibility for every device model, software version or configuration action. Verify support for your environment and inspect any proposed command before approval. Do not turn a natural-language suggestion into an assumed vendor procedure.

Physical faults may still require field work, and commercial decisions remain with the responsible billing team. Human approval also does not make an incorrect diagnosis safe. Its value depends on an operator checking scope, evidence and consequences before authorizing execution.

Next steps: run a bounded demo evaluation

Open the engineer demo from the current product page and choose one authorized subscriber case with a known service path. Start read-only. Record the expected subscriber-device association and the available incident evidence beforehand so the team can compare the investigation against something concrete.

• Scope test: Does the investigation resolve the correct subscriber, service and devices without introducing unrelated systems?
• Evidence test: Can an engineer see which tools were used, distinguish facts from hypotheses and identify missing records?
• Approval test: If a supported change is appropriate, can the operator review its exact scope and expected result before explicitly approving it? Do not create a disruptive fault just to exercise this step.
• Verification test: Does the follow-up assess the original connectivity symptom rather than only reporting execution success?
• Handoff test: Can support and billing understand the outcome, their next task and any unresolved uncertainty?

Proceed beyond the evaluation only if the team can establish correct scope, inspect supporting evidence, retain approval control and verify outcomes. If any of those checks fails, document the specific access, integration or procedure gap and retest it before expanding use.

Sources consulted: AI Network Operations for ISPs | ISPbills (checked 2026-10-07). AI-assisted content prepared for automatic publication after automated checks; not a claim of human or hardware verification. Validate versions, device models and deployment conditions before making changes.