PisoWiFi Daily Operator Checklist
Tech GuruA PisoWiFi operator needs a short morning routine that proves the business path works: power, ISP, gateway, APs, DHCP, DNS, portal page, voucher or payment flow, bandwidth limits, active sessions, and the daily log. Ten quiet minutes can prevent a day of customer complaints.
Operator rule: Prove one fresh customer journey from association through paid or voucher-authorized internet, then reconcile the transaction and session records. A green router dashboard is supporting evidence, not the customer test.
The Short Version
- Test like a customer, not only like an admin dashboard.
- One low-value test voucher or test payment route proves the portal path better than a green router icon.
- Daily notes make ISP, voucher, payment, and power problems easier to spot over time.
The Reader Question
What should I check every morning before customers complain?
This checklist is for a single-site owner or shift operator using a voucher, coin, or digital-payment captive portal. It assumes authorized access to the gateway, portal, payment dashboard, and daily log, plus one clean test device. Platform-specific menu names vary, so the workflow follows the customer path rather than one vendor screen.
Platform Context: 15 July 2026
Current RouterOS documentation warns that HotSpot can be disabled by device mode, that MikroTik HotSpot uses the default routing table rather than PCC multi-table routing, and that its documented HotSpot path remains IPv4-dependent. Check /system/device-mode/print, HotSpot status, and the deployed RouterOS release before blaming vouchers. On Apple and Android devices, private or randomized Wi-Fi addresses mean a phone can appear as a different client; do not treat a MAC address as durable customer identity or ask users to weaken privacy by default.
Before You Start: Safe Defaults
- Keep a spare access method for the gateway and portal.
- Use a UPS for modem/ONT, gateway, switch, and APs where possible.
- Track voucher rolls and revenue/payment counts daily.
- Document ISP latency and outages before calling support.
Reference Model
The reference model below shows the practical order for piso wifi daily operator checklist. Open each step for the operational detail behind the diagram.
Decision Matrix
| Choice | Best Fit | Watch Point |
|---|---|---|
| Manual morning check | Small single-site operator | Depends on discipline. |
| Uptime monitor | Catch ISP/DNS/portal failures early | Needs alert tuning. |
| LTE backup | Revenue protection during ISP issues | Data caps and cost. |
| No routine | Avoid | Customers become the monitoring system. |
The Ten-Minute Checklist
Check UPS and power first, then ISP reachability, AP status, SSID visibility, DHCP lease, DNS resolution, captive portal popup or login URL, voucher redemption, active sessions, speed limits, and errors. Record the result even when everything works.
One Test Customer Workflow
Use a phone that is not already authenticated, with its normal private-address behavior left enabled. Join the SSID, record the lease and client time, confirm IP, DNS, and gateway, open the portal, redeem a dedicated test voucher or sandbox/low-value payment path, verify the authorized session and intended limits, reach a known HTTPS site, then log out or let the test session expire. Do not reuse a staff phone whose cookies and remembered authorization hide first-visit failures.
Red Flags
Rising latency, frequent DHCP exhaustion, stale sessions, repeated voucher failures, AP reboots, unexplained revenue drops, and portal login complaints are operational signals, not random annoyances.
A Practical Pilot Scenario
Run the checklist before opening on one fresh client while no customer depends on the test. Capture the time at power, DHCP, portal display, authorization, internet access, and logout. Use a marked test voucher or payment account so the financial record can be reversed or reconciled without being mistaken for revenue.
The run passes only when gateway, portal, voucher/payment ledger, and active-session record agree on the test. For payment integrations, a browser success page is not settlement evidence. Maya’s documentation tells integrations to parse webhook payment status and test changes in sandbox; duplicate, delayed, or missing notifications require idempotent handling and reconciliation against the provider dashboard.
Implementation Details
The daily routine should be read-only except for the marked test transaction and documented cleanup. Export gateway and portal configuration before firmware, routing, walled-garden, payment, or rate-limit changes. If the test fails, preserve timestamps and logs before rebooting; a reboot can restore service while erasing the evidence needed to find the recurring cause.
- Check UPS/power and outdoor enclosure condition.
- Confirm ISP reachability, latency, packet loss, and failover status.
- Check gateway, APs, SSID visibility, and client counts.
- Use a fresh device to test DHCP, DNS, portal, login, and internet.
- Redeem a test voucher or test payment flow.
- Review active sessions, expired vouchers, and error logs.
- Record daily revenue/payment count, ISP status, and incidents.
Evidence To Collect
- Timestamped power/UPS state, WAN address, gateway reachability, loss and latency, DNS result, AP status, and client count.
- Fresh-client lease, randomized/private client address as observed for that session, portal load time, auth result, assigned plan, and post-auth internet result.
- Test voucher ID or payment reference, webhook/status trail where used, portal session ID, amount, duration, and cleanup or refund record.
- Voucher/payment totals reconciled to the portal and provider dashboard, with discrepancies assigned to an operator.
- Error-log window, configuration backup age, prior known-good configuration, escalation contact, and the exact action taken.
Validation Checklist
- Fresh customer device reaches portal and authenticates.
- Speed limits match the intended plan.
- DHCP/DNS/gateway work on guest network.
- APs and gateway show normal load and no obvious errors.
- Daily log has time, status, incidents, and corrective action.
Maintenance Cadence
- Every opening shift: run the customer-path test and record payment/voucher reconciliation and unresolved incidents.
- Weekly: review lease-pool pressure, stale sessions, AP reboots, packet loss, voucher failures, webhook retries, and unexplained revenue differences.
- Monthly: test alert delivery, inspect UPS battery state and outdoor enclosures, export configuration, and verify restore instructions.
- Before upgrades or routing changes: confirm device mode and platform limits, preserve the known-good config, and schedule a customer-path rollback test.
Troubleshooting
| Symptom | Likely Cause | First Check |
|---|---|---|
| Customers connect but complain | Portal, DNS, bandwidth, or ISP issue | Run the fresh-device customer workflow. |
| Voucher works inconsistently | Clock, voucher roll, payment backend, or stale session | Check portal logs and time sync. |
| Wi-Fi visible but slow | AP load, interference, ISP, or rate limits | Compare wired/gateway test with Wi-Fi client test. |
Common Mistakes
- Checking only the admin dashboard.
- Never testing an actual voucher.
- Letting stale sessions consume capacity.
- Ignoring UPS battery age and outdoor moisture.
- Not recording ISP symptoms before support calls.
Useful Gear And Buyer Notes
Buy only against a recorded failure mode: insufficient UPS runtime, no backup uplink, weather exposure, damaged cabling, or unreliable receipt handling. Verify electrical load, cellular bands and data caps, enclosure rating, cable construction, printer interface, consumables, support, warranty, and return policy for the exact deployed environment.
Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.
- Amazon search: UPS for router modem
- Amazon search: LTE backup router
- Amazon search: outdoor access point enclosure
- Amazon search: weatherproof Ethernet cable
- Amazon search: voucher receipt printer
Related TechGeeks Reading
- PisoWiFi Operations Notes: Start Here
- Networking Field Notes: Start Here
- Network Security Field Notes: Start Here
What This Does Not Protect or Validate
One successful morning transaction does not prove all phone models, private-address rotations, voucher batches, peak loads, ISP paths, webhook retries, or failover routes will work. Ping does not prove DNS or portal health, and a portal success screen does not prove financial settlement. The RouterOS constraints cited here do not automatically apply to UniFi, pfSense, OPNsense, or a vendor appliance.
No original PisoWiFi site or payment lab was performed for this article. Keep gateway access, transaction records, customer identifiers, and support logs restricted and retained only for legitimate operations. Philippine privacy rules require transparency, legitimate purpose, and proportionality; payment, refund, tax, telecom, and consumer obligations depend on the business and provider, so confirm them with the relevant authority or qualified adviser rather than treating this checklist as legal or accounting advice.
Practical FAQ
Do I need monitoring?
Yes, even simple ping/DNS/HTTP checks help. Start small and tune alerts.
Should I test payment every day?
Test at least the path that customers use most, using a safe low-value or test method.
What should I log?
ISP status, portal status, voucher/payment count, revenue count, incidents, and fixes.
References
- https://manual.mikrotik.com/docs/authentication-authorization-accounting/hotspot-captive-portal/
- https://help.mikrotik.com/docs/spaces/ROS/pages/93749258/Device-mode
- https://support.apple.com/en-us/102509
- https://source.android.com/docs/core/connect/wifi-mac-randomization
- https://developers.maya.ph/reference/receive-real-time-payment-information-using-webhooks
- https://www.bsp.gov.ph/PaymentAndSettlement/PPDD_Payments_Bulletin.pdf
- https://privacy.gov.ph/data-privacy-act/
Final Thought
A good PisoWiFi checklist proves the customer path before customers become the alarm system.
