The most discussed discussion about WiFi's web-based billing system is how the package should be priced and how the flow should be calculated, but few people are seriously discussing a question that looks technically and practically most prone to dispute:Which minute does the package start and which day ends?. If this is not written before the project is online, the first month of operations will be flooded with user complaints:"I only charged yesterday. Why are we three days short today?""I'm opening the 15th. Why is the 30th due?"
The three usual ways of doing this first are not absolutely right or wrong, but the scene is completely different.In force immediately: The user ' s first charge starts immediately and the package expires at the same time after 30 days. This is the simplest mode, with intuitive experience.——The money is available immediately, and the maturity system automatically counts. This is basically the case for short-cycle scenarios such as apartments, hotels, temporary visitors.
The second is...Days of reconciliation: No matter when you are charged, the package starts on the first of next month or from a fixed date in the month. For example, students pay on February 15, which is set at the first of each month, and how does it run between February 15 and February 28? Usually, it is converted to day-to-day, until March 1 becomes official for the full month. This model is suitable for campuses like school year-to-year, monthly-managed scenarios: all students have a consistent billing day, financial reconciliations simple, and lot charges alerts work well.——The money just paid isn't going to be available for a month."Transition"A few days.
The third is...Entered into force the following month: Users buy a package this month, but only next month on the first. This mode is less used and usually only when users already have one to use and buy an upgrade.——This month, for example, is 10M, and users buy a 50M upgrade package, so they don't want to waste the remaining 10M this month, so that the new set comes into effect next month. It's not the main billing model, it's the transition rule in the package change.
The V7 NATHHELL_AUTH_BILLING system supports, in its billing strategy, the daily business closure and daily down-flight checks of year, month, day, hour and time, with precision flow."From what day?"This rule is not set by the system's default.It's the parameters that operators have to choose when they configure the package.The system gives us the ability to calculate how the date is set, how the first day is counted, and how the month is converted, in conjunction with the business scene. That is why Rule Kari has repeatedly stressed that the design of a package strategy is the most time-consuming thing to be done before the project, not when it's online.
For example, the user bought a 30-dollar monthly package on February 20, which is effective immediately and which expires on March 22. If the operator wants to use the day-to-day uniform mode, the user of February 20 charge will first count how much he converted by day for the nine days from February 20 to February 28, and the official month from March 1 is the month:How do you fix the exchange rate?. is renting by month, how much a day is it or a fixed number"Day rent"Count? The two algorithms will lose a few dollars in the month and months. Users will not do their own calculations, but they will ask if they see the bills wrong at the end of the month.
There is another special case:The user package was half-spanned.The student is on leave from school, the tenant moves early, the hotel guest leaves early, and the monthly fee that has been withheld."It's been used for more than half a month."The rules are a one-size-fits-all rule. Both algorithms leave users much money when they leave early. The most pragmatic approach is to show them the refund rule when they open their accounts, not to wait until he returns.
The timing and the speed of the notice.The previous discussion of maturity alerts, if all users are immediately effective and the due date is spread over every day of a month, the system sends a series of renewal reminders daily, which users feel too many. If the daily pattern is uniform, the warning is sent in a single number of days per month, with low cost of notification and user perception. This is not a technical choice, but an operational rhythm option. Short-cycle mobile scene (consions, hotels) is appropriate for immediate effect because users move quickly and need no fineness; fixed crowd setting (campus, enterprise accommodation) is suitable for day-to-day unification because of relative stability and high reconciliation requirements.
This is a power boundary:The holsters are operational, not product functionality deficiencies. Some clients ask when they choose"Do you have a system that doesn't support the settlement of accounts on a single date?"The answer is yes, but how exactly, how to convert and how to refund a fee over the month needs to be confirmed on site in conjunction with client financial systems and user group characteristics."Both."Yes. V7 provides a billing engine, and it's what you have to do with the client during the project implementation phase.
Finally, a move that must be done before we get online:Take the real date sheet and run the period.. The date of February, month, month, year, January 31 user charge is listed, and the system's automatic calculations are done manually. Many account periods bugs are not logical, but boundary dates are not considered——For example, the month packs bought on January 31, 28 days in February, 28 days or 30 days?
I think we can get to the point where WiFi's least visible in the billing system."From what day?"The rules that affect user experience and financial reconciliation are the most. They are now valid for a mobile setting, with a single day for a fixed population, and the rules on trans-monthly conversions and refunds need to be written and tested in advance.