When a subscriber cannot sign in, the first task is to establish which decision or exchange failed. A rejected credential, an unavailable authentication service, an expired entitlement and a device that never reached the login stage are different incidents. They can look similar to a customer, but they should not lead the support team to make the same changes.
This guide recommends a practical way to investigate authentication complaints across an ISP's billing and network operations. It emphasizes account matching, timestamps, privacy and controlled verification. It does not prescribe a universal router configuration or assume that every billing platform exposes the same controls.
Turn the complaint into a precise support record
Ask the subscriber what they were trying to do and what appeared on the device. Record the connection type, the site and the approximate time. Distinguish a missing login page from an explicit rejection and from a successful login followed by failed browsing.
Use the operator's normal process to confirm that the person requesting help is entitled to discuss the account. Collect the account identifier needed for the investigation rather than asking for a password in an ordinary chat. If the customer sends a screenshot, check that it does not expose unrelated personal information or a reusable sign-in token.
Record whether the service previously worked and whether a package renewal, device replacement, account edit or site change preceded the complaint. Those details help choose a hypothesis. They should be treated as a timeline to investigate, not as automatic proof that the latest change caused the problem.
Match the account, service and device carefully
Find the intended subscriber record and confirm which service is being used. Similar names, shared phone numbers and a customer with more than one connection can make a quick lookup ambiguous. Use the identifiers supported by the billing and network records together.
Compare the intended account with the identity seen in the relevant connection attempt. Where the operator uses device identifiers, treat them as one part of the evidence rather than assuming that a device has the same identity in every circumstance. Follow the supported account-recovery process when an identifier has changed.
Avoid creating a second subscriber record simply because the first lookup is inconclusive. A duplicate can make later payment matching and support history harder to understand. Resolve the identity question first, document the match, and keep corrections attributable to the staff member who made them.
Establish whether a request reached authentication
Reproduce one authorized test attempt and note the exact time and timezone. Ask the responsible network and application teams to locate the corresponding event. If their clocks differ, account for that difference before concluding that an event is absent.
For HotSpot service, consult the RouterOS HotSpot documentation and distinguish access to the portal from the authentication outcome. For other subscriber services, follow the documented connection sequence appropriate to the deployment.
If the client has not reached the relevant stage, focus on the preceding path instead of resetting credentials repeatedly. A support record that says “no matching request was found in the checked time window” is more precise than “the authentication server rejected the user.” Record which system was checked and what evidence was available so another engineer can verify that conclusion.
Interpret the actual response
RouterOS can use RADIUS for supported subscriber authentication services. MikroTik's RADIUS documentation describes the client settings and counters for accepts, rejects, timeouts and bad replies. Preserve those distinctions in an investigation.
An explicit rejection calls for checking the account and service policy associated with that attempt. A timeout or unusable reply requires investigation of the exchange and the participating systems. Do not infer a wrong customer password merely because the service did not complete a successful exchange.
Ask the authentication service owner for the reason associated with the matching request, using the minimum identifiers needed. Compare that reason with the customer-facing symptom and the account's intended state. If the evidence is incomplete, record the uncertainty and identify the next observation needed. This prevents one untested assumption from becoming the basis for several unrelated changes.
Verify entitlement independently of a payment receipt
If the complaint follows payment, confirm the transaction through the operator's approved billing process. Match it to the intended subscriber, package and service period. Check whether the record is confirmed, pending, failed or requires an operator action according to the configured integration.
A valid receipt and a successful network session answer different questions. Follow the sequence from transaction matching to the intended subscription state and then to the connection attempt. Record where the observed result diverges from the expected result rather than assuming that every step happened automatically.
Do not request another payment merely to test whether the first one worked. Do not grant an unrelated entitlement or bypass account restrictions to make the complaint disappear. Where a correction is justified, use the supported billing workflow, record the reason and verify its effect on the intended service. Keep receipt details out of public troubleshooting channels.
Check for configuration disagreement without broad resets
When the account appears correct, compare the participating systems' view of the service. Confirm that the request comes from the expected router or site and that it is being evaluated against the intended subscriber policy. Ask the responsible engineer to review any mismatch using the deployment's current documentation.
Review recent changes in a controlled way. A migrated account, a renamed service or an edited profile may deserve attention, but each needs evidence connecting it to the failure. Avoid broad configuration resets that would erase the information needed to understand the incident or affect customers who are currently working.
Keep management access and existing service dependencies in mind before changing a router. Prepare the relevant recovery material and agree on the scope of the action. A single subscriber complaint should not automatically result in changes across every router or account in the organization.
Recheck sessions and customer traffic
After correcting the identified cause, repeat the authorized connection attempt. Confirm both the recorded authentication outcome and the customer's observed result. If the connection now authenticates but browsing still fails, open a focused traffic-path investigation rather than repeating the same credential change.
Where a reconnect or session action is needed, follow the platform's documented process and explain the impact to the subscriber. Do not disconnect a broad group simply because a single test account has an ambiguous session record. Keep the action limited to the supported scope.
Use a known test sequence for the affected service and record the result from the subscriber side. Include access to an agreed external destination and any other behavior required for that package. A green account status alone is not a complete acceptance test for a customer who reported that they could not use the connection.
Use a compact escalation template
Escalation should help the next engineer continue the investigation without repeating every question. Include the incident time and timezone, the affected service and site, the account reference, and the observed connection stage. Add the relevant error or response and a concise list of tests already completed.
Describe each change and its result. State whether the customer was affected by the test and whether a rollback is available. Remove credentials, shared secrets, tokens and unnecessary personal details before attaching logs or screenshots.
A hypothetical escalation might say that the correct account is confirmed, the current entitlement matches the intended package, a timed authentication attempt is explicitly rejected, and the authentication team has been asked to provide the matching policy reason. Another might report that no usable reply was received. Those notes create different, actionable next steps without pretending that the cause has already been established.
Close the loop and improve the process
Confirm the result with the subscriber where possible and document the cause once it has been established. Keep the distinction between the verified cause, a temporary recovery action and any unresolved follow-up work.
Review recurring patterns with the people responsible for billing, authentication and network operations. Improve the handover fields, account-matching procedure and test checklist based on actual incidents. Small improvements in those shared records can prevent repeated confusion without introducing risky configuration shortcuts.
Set an owner and a due date for any remaining action, and give the subscriber a clear route to report a recurrence. The goal is a service that the team can explain and verify consistently.
Contact CENTRANET to discuss your subscriber onboarding and support workflow. A clear incident timeline and a carefully matched account make that review more productive.