The fee-in-charge cut off the net sounds like one of the simplest logics in the billing system.——The account balance is insufficient and the Internet is stopped. But it's actually the most easy point to trigger user complaints in the WiFi network billing system of the entire campus. It's not because logic is wrong, but because many details are mishandled and students feel that they have been mistreated."They're in a hole."Or..."The system's pulling money."This article is about the non-payment of fees, from strategy design to experience details.
Let's get to the bottom of the scenes that break the net.
The fee-for-net breakout is not a single scenario, with at least three different triggers:
The first is that the balance runs out of real time. Users are accessing the Internet, traffic is depleted or the balance is held to zero, system is sending off the network's command in real time and user networks are immediately interrupted. This is the most direct but also the highest risk of complaint——Users are talking video or submitting their jobs, suddenly breaking the web and experiencing very poor experiences.
The second is the break-in. The system automatically stops authorization when the package expires. In this case, the break-up usually takes place at a full point or early morning, which is relatively milder than when the break is being used, but if users do not receive an alert for expiry, they still feel that they are going to be able to use it."It's just a mystery."。
The third is that traffic quotas run out of nets. There's a flow ceiling, the net cutout, and the setup itself isn't over yet. This is the most controversial scenario, because users often don't know what they have left, and the first reaction to the breakup is when they lose them."Is it a network malfunction?"The complaint came in and explained the cost.
Different trigger scenarios require different coping strategies and cannot be treated in a single set of off-grid logics.
Design of breakup time: direct break or buffer period
Many early campus network billing systems use hard-wire strategies: zero balances or a set of meals expire, immediately release the network command. The logic is technically sound, but there are many problems from a user ' s perspective.
The recommended approach is to introduce buffer mechanisms. For example, a low balance threshold could be set, such as triggering reminders when the balance is less than $10 instead of breaking the network, allowing users to continue online for a period (for example, 24 hours) in case the balance is insufficient, while pushing the chargeable alarm through text messages, micromails or Portal pages.
The package is treated in a similar way. Reminders are sent three days before the maturity date and one day after the expiration date, allowing the grace period to continue (e.g. 24 p.m. on that day), with no perceived recovery of the extension period and non-renewal of the time limit.
The core value of the buffer mechanism is to give users a processing time window, avoid hard breaks in use and contribute to an increase in the rate by promoting charging through reminders.
Notification of the T-Tarts is the most undervalued part of the breakup strategy.
A large proportion of user feedback in complaints about fee-for-money breakout is:"I didn't know it was coming."Or..."No reminders received.". From a systemic point of view, the notice may have been sent; but the users actually do not see it or the channel is not suitable for them at all.
The effectiveness of the notification channel needs to be taken seriously. Text messages are the most basic, but many students now have a low level of attention to text messages, too much spam and too little system text. Portal redirection alerts are more direct.——The user opens the browser and sees a replenishment alarm page, but only triggers when the user has active access to the HTTP page. If the user uses APP and HTTPS throughout the process, Portal alarms are disabled.
The CVP is a relatively good way to reach the current impact, but there is some loss in binding rates by requiring users to bind the public. The ideal solution is multi-channel combinations: text messages+Portal+mics, covering different user groups with different usage habits.
The content of the notice is also important."Your package will expire on X-day."Far more than"Your account is about to expire"The balance alerts include the current balance and projected days available, rather than simply time."Insufficient balance"It's much more useful.
Experience design after the break: not just black.
When a user pays the network off, access to the network is interrupted. If the system does nothing, the user sees no connection, knows nothing about what happens and many people think that the network is broken and start contacting the administrator for the alarm.
It is reasonable to retain access to Portal pages after a break. When users try to access any of the HTTP pages, they redirect them to the late payment alert page, clearly indicating: account arrears, current balances (or package status), full value entry (or renewal entrance). This allows users to handle themselves and reduce the operator ' s exposure pressure.
The design of the fill entrance is also correct. If a charge page requires login, and users are unable to use the network properly because they have no money to pay off the net, the charge becomes very difficult in itself.——Users need to use mobile data first, which is a real barrier for some students (especially in rural boarding schools).
Some schools will set up."Charging exclusive network": Allow access to the domain names associated with the charge, all others, in a state of underpayment. This option requires firewall strategy collaboration, but experience is significantly enhanced and users do not need to switch networks to complete the charge.
About"I got a lot of money."Complaints: accuracy of the calculation
In the Balance Class Charge System, another type of HF complaint is"I'm not using it. The money is fast."Or..."I've already charged the money. How can I show you what's in arrears?"These two types of complaints often point to the accuracy of the billing and the transparency of bills.
The accuracy of the billing is common in systems that are long and on time, where users forget to get offline, equipment keeps connected, and the system keeps charging, but the user may have turned off the lights and slept. This is typical in the dormitory scene, where students sleep with computers at night, network connections are maintained, traffic/balances are consumed the next day, complaints are made."System button."。
To deal with such problems, it can be set"Free timeout break"Mechanisms: The mechanism is effective in reducing the length of time that a account connects but has a flow of zero (or very low) more than N-minutes, automatically disconnects it and stops billing.
In terms of bill transparency, users should be able to identify the time, length, consumption flow or amount of each authentication. Many systems have only balance queries, no details on consumption, no way for users to see how money is withheld, and there are naturally more complaints.
Several special groups in the campus network WiFi web-based billing system need separate strategies
The following categories of people deserve to be considered separately:
Some boarding schools have a policy of free Internet access for poor students with slotting cards.
Graduate students: The student account number should be automatically downgraded or closed after a certain node of time, but the student may also need to access campus network resources (e.g. downloading paper format templates, accessing library databases).
The system is not suitable for the default logic of a network that is usually paid by schools on an annual basis, without the student-based charging process. If the staff and students in the system follow the same account numbering system, the disconnection strategy will make it possible to distinguish between account types.
A wiring perspective: Disconnective strategy is configured and retraceable
From a carrier perspective, the configuration flexibility of the break-net strategy is important. Once the policy is written down in the code, each time an adjustment (e.g. extended buffer time during school hours, holiday webing) needs to be made, it will be costly to take a release process. A good design is to make the break-off threshold, buffer duration, and notification timing key parameters backstage for configuration, so that managers can adjust them on the interface.
The traceability of the offline operations is equally important. Each breakup should have a logbook: what time, why, which account number, corresponding balance or package status. This allows managers to quickly find out about the situation when users come to complain and to find evidence, rather than explaining it to them.
The fee-free network function is technically easy, but it requires both user and carrier perspectives. A good breakup strategy is that schools receive the fees, they don't generate complaints, and managers are not flooded by press barriers, which all three do at once to get this in order to really put the details where they want to go.