Practical guides for better networks, smarter ISP operations and reliable infrastructure.

1. Define what you are selling

Decide whether customers are buying daily access, weekly access, monthly access, fixed home service, hostel WiFi or another clearly defined service. Your plans should specify duration, device allowance and any service rules customers need to understand.

2. Separate the network into layers

A clean deployment usually has distinct jobs: the upstream internet connection, the router/gateway, switching, backhaul between locations and access points that serve users. Avoid making one device perform several unrelated roles simply because it is available.

3. Design coverage before selling

Test the actual rooms, corridors, floors and outdoor areas where customers will use the service. A strong signal beside the access point does not prove the whole building is covered. Check signal quality and usable throughput at the difficult edges of the site.

4. Create a subscriber record system immediately

Track each customer, internet username, plan, site, subscription dates, payment state and support details from day one. Waiting until you have many subscribers makes cleanup much harder.

5. Define the payment-to-activation workflow

Payment confirmation should not be confused with router activation. A clean flow is: payment pending → payment confirmed → pending activation → active. Once router automation is connected, the activation step can happen automatically.

6. Prepare customer support before launch

Customers should know how to connect, where to see their account status, how to renew and how to report a problem. A customer portal and short tutorial videos reduce repetitive WhatsApp questions.

7. Grow only after the first site is stable

Before adding another site, confirm that billing records, coverage, power, router access, support and customer onboarding are repeatable. Expansion should copy a working system, not multiply unresolved problems.

Profiles, users and sessions are different things

A hotspot profile defines technical behaviour for a class of users. A hotspot user is the credential allowed to authenticate. A session is the current connection created when that user logs in. Keeping these concepts separate makes troubleshooting easier.

Do not use profile names as your accounting system

Your router should enforce access, but your management system should hold the business meaning: Paid, Complimentary, Admin Wi-Fi or Staff Wi-Fi. This prevents technical router profiles from becoming your only source of customer history.

Preserve existing router users when integrating software

If a router already has hotspot users, a good integration should detect them and allow the operator to link them to customer records instead of deleting and recreating them.

Performance mode can stay simple

When bandwidth shaping is not required, keeping FastTrack and avoiding large numbers of Simple Queues can reduce unnecessary router processing. Authentication, validity and subscriber status can still be managed without imposing a per-user speed limit.

A simple architecture

Think of the network as: Starlink → router/gateway → PoE/network switch → access points and wireless backhaul. The Starlink link provides internet; the MikroTik handles hotspot authentication and network policy; the switch distributes Ethernet and power; access points serve customers.

Backhaul and WiFi access are not the same job

A point-to-point radio is best used to move network traffic between buildings. An access point is designed to serve phones, laptops and other client devices. Separating those roles makes the network easier to tune and troubleshoot.

Avoid hidden bottlenecks

Check the Ethernet speed of switches, injectors and radios. A 100 Mbps link in the middle of a faster internet connection can become the limit even when wireless signal looks excellent.

Test stability, not only speed

Run tests at different times, watch packet loss and latency, and test through the complete network path. A single impressive speed test beside the router does not prove the customer experience is stable.

Start with the building

Record the number of floors, walls, corridors, rooms, likely user density and where Ethernet can be installed. Concrete walls and long corridors can change the number of access points required.

Use more well-placed APs instead of one overpowered AP

Phones and laptops have limited transmit power. Increasing AP power does not automatically improve the return path from the client. Multiple access points placed closer to users usually produce a better two-way link.

Plan channels

Nearby APs should not all compete on the same channel when non-overlapping alternatives are available. In dense deployments, channel planning and sensible power levels help roaming and reduce co-channel interference.

Use wired backhaul where practical

Ethernet backhaul generally gives predictable capacity. Wireless backhaul is valuable where cabling is difficult, but it should be designed as infrastructure rather than treated as an accidental extension of client WiFi.

Test the worst locations

Measure at room corners, staircases and the far end of corridors — not only directly under the AP. The weakest real customer location is often more informative than the strongest.

Define the objective for every camera

Is the camera meant to detect activity, observe a general area, recognise a person, capture a face at an entrance or read vehicle details? The required image and placement depend on that objective.

Map entrances and critical areas

Prioritise gates, doors, cash points, equipment rooms, parking, corridors and other locations where an incident would matter. Avoid wasting cameras on overlapping views that do not improve evidence quality.

Consider night conditions

Check where lighting comes from, whether headlights point into the camera and whether infrared reflections or backlighting may hide a face. A daytime test alone is not enough.

Plan storage and power

The recorder, PoE switch, cameras and networking equipment need stable power. Decide how much recording history is required, then size storage and backup power around that requirement.

List every device and its real power draw

Include the internet terminal, router, switches, access points, wireless bridges and any other equipment that must remain online. Add the loads together to estimate the continuous power requirement.

Decide the required backup hours

A system designed for two hours of outage is very different from a network expected to operate through the entire night without grid power.

Allow for conversion losses and reserve

The energy stored in a battery is not all delivered to the load. Inverter efficiency, DC conversion and battery operating limits reduce usable energy. Build reasonable reserve into the design.

Solar must power the load and recharge the battery

Panels are not sized only to match the instantaneous load. They also need enough daytime energy to replace what was taken from the battery while accounting for weather and charging losses.

Bank transfer and online payment can coexist

Bank transfer is familiar and easy to offer. A gateway such as Paystack can provide quicker online confirmation and transaction references. The important part is that each payment is tied to the correct customer, organisation, plan and purpose.

Use unique references and verify server-side

For online payments, verification should happen on the server, not by trusting what the browser says. Check the transaction reference, amount, currency and organisation before marking the payment confirmed.

Do not jump straight from payment pending to active

A clearer state chain is Payment Pending → payment confirmed → Pending Activation → Active. This makes it obvious whether money has been received but router activation is still outstanding.

Each ISP should receive its own customer money

In a multi-ISP platform, customer payments should normally go directly to the ISP that provides the service. Platform subscription payments are a separate transaction between the ISP and the software provider.

Subscribers needing action

Watch pending activations, expired accounts, unresolved payments, incomplete router links and customer support issues. A “Needs Attention” list is often more useful than a dashboard full of totals.

Network health

Know which sites and routers are online, whether upstream internet is healthy and whether any equipment has failed or requires maintenance.

Revenue and payment status

Track confirmed revenue separately from unpaid or pending subscriptions. Complimentary, Admin WiFi and staff access should not be counted as customer revenue.

Upcoming expiries

Renewal reminders work best when customers receive them before service becomes a surprise. A grace period can reduce unnecessary disconnections while still keeping payment discipline.

Support patterns

If many customers ask the same question, turn the answer into a help article or short video. Repeated support questions are often a sign that onboarding or self-service information can be improved.

Customers need basic account visibility

A customer should be able to see the provider, site or hotspot, plan, subscription status, payment state, internet account and support options without asking the ISP to look it up manually.

Self-service renewals reduce friction

When renewal options and payment methods are visible, the customer can act without waiting for a support reply. That improves the experience and reduces repetitive administrative work.

Help content belongs inside the customer journey

Connection guides, troubleshooting steps and short videos should be available where the customer already manages the account. This makes help easier to find than scattered messages or old social-media posts.