PisoWiFi Operations Notes: Start Here

PisoWiFi is part network engineering, part small business operations, and part customer experience. A good PisoWiFi setup is not just a box with a coin slot and an internet connection. It needs stable backhaul, clean WiFi coverage, fair bandwidth control, reliable power, sensible pricing, secure customer isolation, and a maintenance routine that keeps the service running after the excitement of installation is over.

The short version: start with a site survey and backhaul test, place customers on an internet-only network, protect management on a separate network, set conservative per-user limits, monitor from both sides of the router, and document how to restore service after power, ISP, portal, or hardware failure. Buy hardware only after those requirements are known.

This post is the starting point for TechGeeks PisoWiFi content. We will cover both the technical side and the operational side, because the customer only sees one thing: does the connection work when they pay for it?

Think Like A Service Provider

A PisoWiFi deployment may be small, but it still behaves like a service provider network. Customers expect access. The owner expects revenue. The operator needs visibility. If you treat it like a casual home router, problems will pile up quickly.

Good operations start with these questions:

• Where are the users physically located?
• How many users may connect at peak time?
• What internet backhaul is available?
• How will power interruptions be handled?
• Who collects money and checks the device?
• Who responds when customers say it is slow?
• How will abuse, bandwidth hogging, and device issues be controlled?

The answers shape the network design more than the brand of hardware.

Site Survey Comes First

Before installing anything, look at the site. A good survey checks:

• Building layout and materials.
• Where users gather.
• Outdoor coverage needs.
• Existing WiFi interference.
• Power outlet quality and grounding.
• Safe mounting locations.
• Weather exposure.
• Backhaul path to the ISP or upstream router.

WiFi problems are often physical problems wearing a software costume. Concrete walls, metal roofing, poor antenna placement, crowded channels, weak power, and bad cables can ruin an otherwise decent configuration.

Backhaul Determines The Ceiling

The backhaul is the connection feeding the PisoWiFi system. It could be fiber, cable, wireless point-to-point, LTE/5G, or an ISP link from a nearby node. The backhaul sets the ceiling for what customers can experience.

If the backhaul is unstable, no portal, voucher system, or fancy router will fix the customer experience. Monitor latency, packet loss, and uptime. If possible, use equipment that can fail over to a secondary link or at least alert you when the upstream path is down.

Design The Customer Network For Isolation

Customers should not be able to reach management devices, cameras, admin computers, or other customers. The customer network should be separated from operations and management.

A simple design often includes:

• Management network: router, access point management, portal admin, and monitoring.
• Customer network: paid users with internet-only access.
• Owner/admin network: trusted devices for maintenance.
• Optional business network: store POS, cameras, or internal devices if the same internet feed is shared.

Use firewall rules to block customer access to management IPs and private internal networks. Turn on client isolation where appropriate. Do not expose router administration to the customer side.

Bandwidth Control Must Feel Fair

Unlimited speed for every customer sounds attractive until one user consumes the link and everyone else complains. Bandwidth control should match the backhaul, pricing, and expected usage.

Good policies usually include:

• Per-user rate limits.
• Session time limits.
• Fair sharing during peak hours.
• Separate limits for trial access, paid access, and admin devices.
• Basic abuse control for heavy downloads or suspicious traffic.

The goal is not to punish customers. The goal is to keep the service usable for everyone.

Power Is Part Of The Design

Many small deployments fail because power was treated as an afterthought. A PisoWiFi system may need a UPS, surge protection, clean cable routing, weatherproof enclosures, and a plan for outages. If the coin box, router, access point, and backhaul radio do not come back cleanly after a power interruption, the operator gets a support call.

At minimum, label power supplies, avoid overloaded extension cords, protect outdoor equipment, and test restart behavior after power loss.

Portal And Voucher Experience Matters

The portal is where the customer feels the service. It should be simple, fast, and obvious. Customers should understand how much time or data they are buying, what to do if payment fails, and who to contact for help.

Operationally, track:

• Voucher sales or coin revenue.
• Failed login attempts.
• Most common support complaints.
• Peak usage times.
• Devices that reconnect repeatedly.
• Access points with weak signal or heavy retries.

Small improvements to the portal and support flow can reduce daily headaches.

Monitoring Prevents Blind Operations

If customers report problems before you know there is a problem, you are operating blind. Monitoring does not need to be expensive. Start with:

• Backhaul uptime and latency.
• Router CPU and memory.
• Access point client count.
• Wireless signal quality.
• Interface errors.
• WAN bandwidth usage.
• Portal or voucher system status.

Even a basic dashboard can tell you whether a complaint is caused by the ISP link, WiFi signal, overloaded router, power issue, or one customer device.

Maintenance Is Where Profit Is Protected

Installation gets the service online. Maintenance keeps it profitable. A simple maintenance routine should include:

• Check device uptime and logs weekly.
• Inspect outdoor cables and enclosures.
• Review revenue and usage patterns.
• Back up router and portal configurations.
• Update firmware during planned windows.
• Clean up old vouchers, test accounts, and unused admin accounts.
• Review customer complaints for patterns.

PisoWiFi is not set-and-forget if you want it to be reliable. The best operators treat every complaint as data and every outage as a chance to improve the design.

Use A Simple, Testable Topology

A small site does not need an enterprise diagram, but it does need explicit boundaries. The WAN connects only to the edge router. The router owns firewall policy, customer addressing, queues, and the captive-portal path. Managed switches and access points carry separate management and customer networks. The portal or voucher controller should not become a bridge around the firewall.

Zone	Allowed	Denied By Default
Customer	DHCP, DNS, captive portal, and internet after authorization	Router management, portal administration, private subnets, point-of-sale systems, cameras, and other customer devices
Management	Router, switch, access point, portal, logs, backup, and update services	New or unmanaged customer devices
Owner or staff	Only the business systems staff need	Network administration unless the device and user are authorized
Backhaul	Required upstream and monitoring traffic	Inbound management from the internet unless a secured, documented remote-access design requires it

Client isolation on an access point limits direct communication between clients associated to that access point. It may not cover traffic between access points, wired customer ports, or paths routed elsewhere. Use VLAN and firewall policy for the network boundary, then add wireless client isolation as another control. Test IPv4 and IPv6; an IPv4-only rule set is not a complete isolation design when clients receive IPv6 connectivity.

Commission The Site Before Taking Payment

Save an exported configuration before commissioning, and keep a redacted network diagram, address plan, device inventory, firmware list, and recovery contact outside the installed controller. Never publish real administrator passwords, voucher secrets, public addresses, or unredacted customer records in a diagram or support screenshot.

1. From a customer device, join the service set identifier (SSID), receive an address, and open the portal without a saved session.
2. Confirm a paid or test voucher grants exactly the advertised duration, data, and speed. Verify expiration and logout behavior.
3. Attempt to reach the router, access points, portal admin page, owner network, private address ranges, and a second customer device. Each path outside policy should fail.
4. Run latency, loss, and throughput checks near each access point and at expected busy locations. Record conditions and client type; one speed test is not a capacity study.
5. Disconnect the ISP path and verify the portal gives a useful failure state rather than accepting payment for unusable access.
6. Remove utility power during a controlled window. Confirm the UPS behavior, shutdown plan, and boot order when power returns.
7. Restore the saved configuration to spare hardware or a lab device when the platform permits it. An export is not a recovery plan until its dependencies and restore process are understood.

Acceptance should be specific: customers can authenticate, policy limits apply, prohibited lateral paths fail, the weakest intended coverage area remains usable, monitoring detects an upstream outage, and the operator can find a current backup. These are planned site checks, not claims that TechGeeks tested a particular PisoWiFi deployment.

Triage Complaints By Layer

• No portal: check association, DHCP lease, DNS, captive-portal detection, certificate validity, and whether the client has a VPN or private-DNS feature that changes the path.
• Portal works but no internet: check voucher state, firewall/NAT, WAN address, upstream gateway, and DNS from the router itself.
• Fast near the access point, slow elsewhere: inspect signal, channel use, retries, client band, obstructions, and whether another access point is needed. Increasing transmit power alone can make the link asymmetric.
• Everyone slows at once: compare WAN utilization, latency under load, packet loss, router CPU, queue drops, and the ISP handoff.
• One user is slow: compare that client's signal, negotiated rate, retries, data cap, queue, device power saving, and VPN use before changing the whole network.
• Revenue and sessions disagree: preserve transaction and portal logs, stop configuration changes, reconcile time settings and payment records, and involve the platform or payment provider.

Security, Privacy, And Business Boundaries

A captive portal is an access-control and billing component, not end-to-end protection for customer traffic. Encourage customers to use HTTPS, multi-factor authentication, and a trusted VPN for sensitive activity. Protect operator accounts with unique credentials and multi-factor authentication where supported. Restrict administration to a management network or authenticated VPN, remove unused accounts, and review logs for failed logins and configuration changes.

Collect the minimum customer and device information needed to operate the service. Define retention for voucher, payment, IP, MAC-address, and support records; limit staff access; and delete records when the purpose and legal retention period end. MAC addresses can be randomized and should not be treated as durable identity. If the service collects personal data, payment details, or identity information, obtain advice for the applicable privacy and consumer rules. In the Philippines, review National Privacy Commission guidance and the Data Privacy Act rather than assuming a small hotspot is exempt.

Before selling access, confirm that the upstream ISP contract permits resale or shared public access, and check local permits, tax, radio, consumer-disclosure, and payment requirements. State the price, duration or data allowance, refund path, and support contact clearly. This article is operational guidance, not legal or electrical advice; outdoor power, grounding, poles, surge protection, and building penetrations should follow local code and qualified installation practice.

Recovery Order

When the site fails, restore the smallest known-good path first: power and UPS, backhaul modem or radio, edge router, management switch, portal, then access points. Keep a break-glass local administrator account and its recovery material secured offline. If a firmware or configuration change caused the outage, preserve logs, restore the last known-good configuration, and reintroduce the change later in a test window. Do not factory-reset several devices at once; that destroys evidence and can turn one fault into a full rebuild.

What We Will Cover Next

This category will cover practical PisoWiFi topics such as router layout, MikroTik profiles, UniFi access points, voucher planning, bandwidth queues, captive portals, customer isolation, tower or wireless backhaul, monitoring, power backup, and troubleshooting real-world slow internet complaints.

The mission is simple: build small access networks that are stable, fair, secure, and manageable. If customers can connect easily and the operator can see what is happening, the service has a much better chance of lasting.

What This Does Not Prove

This documentation-backed operating guide does not prove that a particular access point, captive portal, payment workflow, or bandwidth plan will be reliable, secure, lawful, or profitable at your site. No radio survey, load test, payment audit, security assessment, or outage drill was performed for this article. Test with representative client devices, verify customer isolation, review local privacy and business obligations, and rehearse recovery before accepting paid traffic.

References

• MikroTik RouterOS HotSpot documentation
• MikroTik RouterOS WiFi documentation
• Ubiquiti: Network and Client Isolation in UniFi
• NIST SP 800-153: Guidelines for Securing Wireless LANs
• Philippines National Privacy Commission: Public Wi-Fi Privacy Guidance