Definition
A data plan is a data product for IoT SIM cards. It includes the tier (for example 1 GB or 5 GB), the plan cycle (monthly, quarterly, or annual), and the billing mode. Plan packaging turns a carrier tariff into a plan that can be sold. The user buys it through plan subscription, and plan delivery puts it on the card so it takes effect.
Data Plan Types
- Single-card data plan: A standalone data plan per card, each card billed individually, suitable for scenarios where usage can be predicted.
- Data pool plan: Multiple cards share a data pool , the total data in the pool is used by all cards, suitable for projects with fluctuating usage.
- Monthly/Quarterly/Annual Package: Divided according to the data plan cycle . Generally, the longer the cycle, the better the unit price.
Key Points of Data Plan Design
When plan packaging turns a carrier tariff into the enterprise’s own plan, the packaging has to set the data tier, the cycle, the price, the carrier mapping, and whether overage billing is allowed. The plan is what plan subscription and a plan change use. After plan delivery, the card receives that allowance. A different billing mode (by data volume, by duration, or by data pool) needs a different plan structure.
Data Plan and the Market
The data plan is the core product of IoT SIM card service. It has to be designed against demand, the carrier tariff, and what competitors sell. A monthly plan fits steady usage. An annual plan usually has a better unit price and fits a card that stays online for a long time. Tiers such as 1 GB, 5 GB, and 10 GB cover different users. The price has to leave room for cost, margin, and the channel revenue-sharing ratio. Listing, delisting, and promotions are set in the packaging layer. The design shows up directly in traffic billing, the bill, and whether the user is satisfied.
Data plan and card management
After plan packaging, the data plan is what plan subscription and a plan change use. Plan delivery puts the allowance on the card. The plan cycle starts on the subscription date or the activation date. When the plan is used up, it can trigger suspension or overage billing. A pool plan needs a data pool, and the cards in it share that pool. The data plan is the core product form of IoT SIM card service. Together with the agent price list and agent-price procurement, it is what the channel sells.
Data plan and billing
The data plan’s billing mode, plan cycle, and overage billing rules are set during plan packaging. That design shows up in traffic billing, the bill, and whether the user is satisfied. The price has to cover cost, margin, and the channel revenue-sharing ratio. The data plan is the center of product management on the IoT Cloud Platform, and it stays tied to carrier mapping and the carrier tariff. Listing, delisting, and promotions are also set in the packaging layer.
Define the tier, the cycle, and the reset rule together
A data plan is a usage contract sold to a card or to a data pool. It is not just a number of gigabytes. The definition has to state, at the same time, the quota, the length of the cycle, when the cycle starts, whether what remains at the end of the cycle is cleared, whether it can roll over, and the default response when it is used up. A monthly pack that rolls 30 days from the activation date, and one that follows the calendar month, expire on different dates when activation falls in February or at the end of a month. Writing only “5 GB monthly pack” leaves the delivery parameters without a start point. The carrier then settles on its own default month, the platform displays a rolling month, and the user sees the quota suddenly return to zero in the middle of a cycle.
The quota of a single-card plan serves only that card. The quota of a pool plan serves the pool. A card that joins the pool does not bring another copy of the same quota, unless the rule says that joining consumes a personal pack first. Copying a pool plan onto every card by the member count multiplies total usage several times. Whether an annual pack is issued as twelve calendar months or given in full at once also has to be written into the plan. Otherwise a suspension and a later reactivation in the middle do not know which slice of quota to restore.
Listing or delisting must not rewrite a contract already in effect
Delisting a plan only stops new orders. An instance already delivered to a card keeps running on the quota, unit price, and expiry date from the time of the order, until the cycle ends or the user changes it. Changing the quota directly on the product makes the remaining traffic of cards already sold change with it. A change should create a new plan version. New orders use the new version. Old instances stay on the old version. An upgrade or a downgrade has to say how the difference is charged, whether unused traffic is converted, and whether it takes effect immediately or next cycle.
Price also has to leave a place for the channel price and the user price, but those are not part of the plan quota. A wrong quota makes both billing and the carrier side wrong. A wrong price only affects how much money is collected. SimtoLink’s data plan design puts quota, cycle, reset, and the response when the quota is used up into a sellable version, then maps that version to a carrier plan, so changing one word of the sales name does not rewrite the contract of cards already in service.
The rollover cap belongs in the plan version
When remaining traffic is allowed to roll into the next cycle, also write the rollover cap, how many times it may roll, and when rolled traffic expires. Without a cap, low-traffic months pile the quota up without limit, and the overage judgment in later periods loses its meaning. Rolled traffic should be booked apart from the new quota of this period, and the order in which they are consumed has to be stated. A common rule is to consume the rolled portion first. When the card is upgraded to another plan version, whether rollover from the old version comes along has to be stated in the change rule. It cannot default to clearing, or default to bringing all of it. SimtoLink plan design puts the rollover parameters into the version. A card already sold keeps the rollover cap from the time it was ordered.