Kandiantong: Product stock is shared across platforms by default
Comparison note: this article makes a scenario comparison from public product positioning and from Kandiantong project delivery experience. It does not maliciously disparage any vendor. Each product's capabilities change as versions iterate. Before a project starts, follow official materials and a written quote. Kandiantong offers both templated and custom delivery. Decisions fit better by matching the scenario than by an absolute better or worse.
Choose a platform by the goal
Opening WeChat, Douyin, Xiaohongshu, Alipay, Baidu, and other ends at the same time is the easiest way to lose operating focus and tear inventory apart. The default suggestion is one main base plus one supporting base. Stabilize transactions, fulfillment, after-sales, and members first, then amplify proven hit products onto the second end. Below is how to choose a platform by the goal, a 90-day validation sequence, and system priority.
For private-domain repeat purchase and communities, prefer the WeChat mini program and WeCom. The system focus is members, coupons, SOP, and tags. For a content burst and livestreaming, prefer a Douyin mini program or a Kuaishou mini program. The system focus is livestream price, stock, and after-sales SLA. For trust and seeding, and for search, prefer Xiaohongshu. The focus is note handover, a detail page that matches, and import into the private domain. For payment and local services, prefer an Alipay mini program. For search intent and information queries, look at a Baidu smart mini program or WeChat Search. The focus is SEO, the landing page, and conversion components.
Four decision steps: draw the path from awareness to trust, first order, and repeat purchase, and mark which platform each step sits on. Choose the main base and set metrics that can be measured in 90 days (first-order cost, return rate, repeat-purchase rate), not follower count alone. The system connects products, orders, and members first, then adds complex marketing and distribution. The supporting base only amplifies SKUs already proven on the main base. Do not copy a whole operation from zero.
Different platforms should use different KPIs. Douyin leans on content output and ad efficiency. WeChat leans on LTV and repeat-purchase rate. Xiaohongshu leans on the conversion rate from seeding to a completed sale. If the same team mixes the KPIs, it is easy to chase a short-term number and damage the brand over time. When setting KPIs, pair them with a list of what not to watch, and state which metrics are not used for assessment on that platform. For example, do not require Douyin to hit WeChat's repeat-purchase rate, and do not require Xiaohongshu to hit Douyin's ROAS. Also name one owner for each platform. Content schedule, stock requests, and customer-service wording all go out through that person, so one platform does not have three people speaking and the supply chain does not know whom to follow.
Middle-platform priority and master-data governance
P0: one SKU, sellable stock, a price system, and after-sales tickets. P1: member ID mapping, coupon and point rules, and channel reports. P2: omnichannel distribution, complex settlement, and self-serve BI analysis.
When putting P0 in place, the five master-data items below need one definition first. Otherwise every new platform multiplies the error. SKU coding rules and barcodes, including how bundles, gifts, and replacement parts are coded. The definition of sellable stock: how in-transit, locked, defective, and store-owned stock are each calculated. Price types: retail price, member price, channel price, and livestream price, and the priority and mutual exclusion among them. Mapping rules between member ID and phone number, including one person with several numbers and a phone-number change. After-sales reason codes and who is responsible. Every platform must share the same set of enum values. Rushing to add a platform before P0 is done usually ends with each end having its own spreadsheet, and in the end nobody dares use any of the numbers.
The three most common mistakes are these. Opening a livestream before stock is unified, which causes overselling and orders cancelled at the last minute. A promise on the content end that does not match the product detail page, so the return rate and bad reviews rise together. Customer-service wording that is not the same across platforms, so one question gets two answers on two channels. What these three share is that the platform was not chosen wrong. Master data and the process were not aligned first. There is also a quieter mistake: treating the supporting base as the main base for headcount, while still assessing it with the main base's KPIs. The supporting base's job is to amplify SKUs that are already proven. It does not carry trial and error from zero. If it is given the same growth target as the main base, the team can only push volume with low prices, and that eventually eats the main base's price system.
Industry leanings are only a reference. Beauty and skincare often use Xiaohongshu plus WeChat as the main base, and Douyin as the supporting base to test hit products. Casual food often uses Douyin or Kuaishou as the main base, and WeChat as the supporting base for repeat purchase. Large home goods often use WeChat plus content as the main base, and Xiaohongshu scene notes as the supporting base. Local life often uses WeChat or Alipay as the main base, and Douyin local promotion as the supporting base.
Validation, the supply chain, and when to expand
After the main base is chosen, write the assumption as a sentence that can be falsified, for example private-domain first-order acquisition cost below a certain amount within 30 days, or the first-month return rate not above a certain ratio. Review fulfillment time, return rate, and customer-service satisfaction every week. If they are not met, adjust the assortment or pause adding platforms, rather than blindly adding another end.
A validation sheet should have only four columns: assumption, current value, target value, and the next action. Do a first mid-point check on day 30. If two of three assumptions are clearly off, adjust the assortment directly rather than adding spend. On day 60, confirm whether fulfillment and customer service can take the current order volume. On day 90, decide whether to stay or leave. Every review leaves a written conclusion and an owner. Otherwise, three months later, nobody can say what the original target was.
Before expanding across platforms, if the ERP is not live yet and stock is still kept in a manual spreadsheet, govern the master data first. Otherwise every new platform multiplies the error, and finance reconciliation will eventually drag operations down. A sound order is to put an ERP in place, or at least one unified stock table, and then open the second front-end platform, not three front ends at once. Otherwise each platform will ask to sell first and sort it out later. Finance reconciliation stays manual for a long time, and management cannot trust any report. In other words, platform choice should follow how mature the supply chain is, not push the supply chain from the other direction.
Before a major promotion, do not open a new platform, and do not change price rules on a large scale. Do not let two high-risk things collide. Expansion of the supporting base should be scheduled in a slow season, and measured with the 90-day validation sheet to see whether it is worth keeping. More strictly, open a new platform only when all four of these hold: the main base's 90-day KPIs are met, stock and the after-sales SLA are stable, the team has spare capacity or has already hired a dedicated person, and the new platform has a clear role (acquisition or amplification, not a repeat of an existing function). Otherwise the new platform only splits assets and customer service, and GMV falls instead of rising. On the system side, before opening a new end, also check interface rate limits, product-sync delay, and whether refund rules match the existing platforms. When an Alipay mini program or a Baidu smart mini program is a supporting base, it often serves a specific audience or a search scene. It should not simply copy the same campaign page as WeChat.
Each additional primary platform usually means another content rhythm and another customer-service peak. List platform-specific headcount on its own line in the budget, next to software cost, rather than looking only at a mixed total. If headcount cannot increase, reduce the number of platforms, rather than cutting the software budget. A system such as Kandiantong can reuse one admin. It cannot reuse a Douyin short-video script or a WeChat private-domain SOP. That is an organization cost. Buying one license does not solve it. Each new platform should also update the organization RACI once: who owns stock, who owns content, who owns customer service, and who may change a price. When duties are unclear, cross-platform stock and price problems pile up on the day of a major promotion. The main-base owner should also have scheduling priority in the weekly meeting, so a supporting-base campaign does not crowd out stock and customer-service capacity and pull the main-base KPIs down. A middle-platform project and platform expansion should also be staggered, so the process and the organization are not both changing at once.
Two questions come up almost every time. Do both an Alipay mini program and a WeChat mini program have to be built? It depends on the target user's payment habits and on platform subsidies. Do not open both by default. Does a Baidu smart mini program have value? When search intent in the business is strong, it can be a supporting base for search traffic. It is not a fit as a main base for a cold start from zero. Each quarter, ask four questions: is the main-base KPI still ahead; does the supporting base bring increment or diversion; have stock and customer service been dragged by the new platform; is it worth opening a third end next quarter. If two of those answers are no, pause expansion rather than adding spend. Platform choice is a decision that moves. It is not settled for life by one bid. A new-platform pilot also needs a clear exit standard: if the assumption is not met in 90 days, archive the experience and stop the spend, rather than extending without limit. Write the pilot conclusion into the knowledge base, so the next selection can cite it directly.
The conclusion is plain: less is more. Go deep on the main base, and use the supporting base to amplify. Spending on the system and the middle platform should both serve that principle. There is no perfect-score answer for platform choice, only the best fit under current resources. A main-base strategy is not a refusal to expand. It ties the timing of expansion to validation data. Write down the platforms you are not doing for now, together with the reason and the data assumption at the time. That stops the organization from arguing again over an option already rejected, and it lets the question be reopened half a year later under new data, rather than stepping in the same hole because people changed. Investment in the system and the middle platform should lead platform expansion by half a step, not lag by half a year and then be used to repair the damage.
Source: https://www.kandiantong.com/compare/platform-selection.html