Definition
Multi-Tier Channel refers to the multi-level Reseller channel system supported by ICMP, such as first-level general agents, second-level distributors, and third-level end dealers. Combined with Commission, Partner Portal, and white-label capabilities, it supports channel expansion, sales incentives, and channel management, achieving scalable market coverage.
Hierarchical Structure
Typical Multi-Tier Channel Structure: Tier 1——General distributor, directly contracts with the platform, enjoys the best price and commission; Tier 2——Purchases from Tier 1, distributes to downstream channels; Tier 3——End sales, targeting the final customer. Each tier can be configured with different rate cards, commission ratios, volume discount levels. The platform needs to support hierarchy management, order attribution, reconciliation and commission settlement.
Supporting Capabilities
Multi-Tier Channel requires supporting: commission——Sales commissions and tiered incentives for each channel level; partner portal——Channel self-service to query orders, usage, and commissions; white labeling——Channels sell externally under their own brand; sub-customers——Tier 1 can create sub-accounts and allocate resources for subordinate Tier 2. The platform needs to support channel master data, hierarchy management, and permission isolation.
Implementation in ICMP
SimtoLink ICMP supports Multi-Tier Channel: multi-level Reseller hierarchy configuration; Commission rules and settlement; Partner Portal channel portal; integration with Reconciliation; supports white-label and sub-customer management.
Order Ownership and Settlement Ownership
A multi-tier channel uses a tree to say who buys from whom, who contracts with the end customer, and at which tier commission is accrued. Each tier is a separate party, not a department alias of the same company. Order ownership says under whose name the SIM and the contract sit. Settlement ownership says at which tier the margin on this money stays. The two can differ: a SIM can be registered under a second-tier channel’s customer, while the margin is settled between the first tier and the second. If the platform has only one “owning customer” field, it cannot express both kinds of ownership at once.
Enable tiers only when each tier’s visible scope, allowed actions, and prices are configured separately. A downstream party may order for its own customers. It should not change the upstream tariff, and it should not see a sibling node’s SIMs. An upstream party may view a total, but whether it may drill into an end user’s device identity is a separate grant, and it is constrained by identity and access management. A commission rule should state whether the base is sales, cash collected, or the margin after upstream cost, and how a return reverses it. If the invoice title differs from the ordering account, keep the tier on the unified invoice, so finance does not merge only by payer and lose the channel relationship.
When a Downstream Account Sees What It Should Not
A common error is to treat the organization chart as permissions. A first-tier administrator sets a second-tier account to “the same role as me,” and the second tier can export the first tier’s entire stock and unpaid commission. Another error is that after a SIM is transferred from the first tier to the second, usage still sits on the first-tier report, while commission is accrued again on the second tier’s sales, so the same traffic is rewarded at two tiers. If a return only puts the SIM back into stock and does not reverse the original order’s tier, the next sale inherits the previous commission relationship.
Price lists also cross tiers. The upstream purchase price is shown on the downstream portal, and the downstream customer sees the price between the platform and the master agent. Each tier should see only its own purchase terms and its own selling terms. Before moving a node, freeze unfinished orders, and write down which party the SIM, the order, the invoice, and the commission each follow.
On the day the hierarchy changes, assign each unfinished order to the old party or the new party. Do not let a system default inherit it. Commission already accrued but not yet paid stays on the original tier until it is settled or reversed. The new tier affects only new orders after the change. Finance can then still see two stretches of ownership in the life of the same SIM. Historical margin is not charged to the new upstream party, and the downstream party does not, at the moment of the change, see stock that is not its own.
Price unfolds from upstream to downstream. Each tier stores only its own purchase terms and selling terms. The margin on an order is that tier’s actual selling price minus its own purchase price, not minus the platform’s deepest upstream floor. If every tier’s commission is calculated from the floor price, several tiers count the same stretch of margin again. A return reversal should run back along the original path and reverse the amount each tier accrued at the time. Reversing at the new price on the day of the return will not match the original accrual.
The parties on the order, the SIM, and the invoice can differ, but each must be traceable. When a downstream party orders for its own customer, the SIM can sit under the end customer, the invoice can be issued to the downstream party, and the margin stays between the downstream party and the upstream party. From the screen it should be possible to go from the SIM to the order, and from the order to the settlement party at each tier. Without that chain, finance sees only the payer and cannot explain why commission was paid to another account. On a hierarchy change, confirm unfinished orders one by one. Completed orders keep the original chain.
Test visibility tier by tier. A second-tier account should be unable to open first-tier stock, a sibling node’s customers, or estimated commission not yet settled to itself. A total given to the upstream party can be a sum. It need not include downstream customers’ device identities, unless the contract allows it and the permission is opened separately. Issue accounts only after that test passes. If an excess of access is found later, withdraw access to the exported file and disable the account first, then correct the role. Renaming a menu is not the fix.