红人营销 App 的系统怎么设计?|App 开发篇

上一篇我们讲的是合作链路，这一篇再往下一层，讲系统怎么拆。很多商家一开始以为，红人营销 App 无非就是一个后台、几条链接和一套折扣码。合作一多才会发现，真正难的不是“有没有页面”，而是：

后台、红人端、自动化、发货和 Tracking 到底怎么分工。

先给结论

如果你要把红人合作做成一套能放大的 App，我会建议至少拆成 5 个责任域：

1. CMS 运营后台

2. CCP 红人端

3. 系统自动化

4. 发货

5. Shopify / Tracking

很多团队早期会把这些都堆进一个后台里，短期看起来省事，长期最容易变成“谁都能点，谁都说不清”。

第一块：CMS 运营后台

CMS 运营后台不是给红人用的，它是给团队控流程和控风险的。最适合放的动作是：

• 创建和审核红人资料

• 创建和审核合作单

• 配置内容要求、选品池、佣金和折扣规则

• 审核素材

• 打款和评价

如果把这些动作放到红人端或者聊天记录里，后面最容易出现的问题就是版本不一致。

第二块：CCP 红人端

这里先沿用你给的叫法，CCP 可以理解成红人侧的合作入口。

它不是一个“看数据的大后台”，而应该是一个更轻的协作入口，重点处理：

• 选品

• 确认地址

• 签约

• 提交素材

• 提交 Post Link / Ad Code

这块如果做得太重，红人会不愿意用；做得太轻，团队又会回到聊天里追着问。

第三块：系统自动化

很多人做这类 App 时，最容易忽略这一层。真正把流程串起来的，往往不是页面，而是自动化。

它负责的是：

• 审核通过后生成入口和通知

• 需要签约时生成合同链接

• 签约后生成折扣码或合作资料

• 发货后定时同步状态

• 妥投后触发内容提交提醒

• 交付完成后进入 tracking 和结算

• 评价完成后判断是否二邀

如果没有这一层，系统就会退化成“一个能录数据的后台”，而不是“一个能驱动合作往下走的系统”。

第四块：发货

发货看起来是中间的一步，但它本质上已经是履约链路。这里最重要的不是页面长什么样，而是系统要不要把下面这些状态接起来：

• 待发货

• 已创建订单或草稿单

• 已发货

• 物流同步中

• 已妥投

• 异常处理

发货域不等于一定要先接 ERP。

如果商家已经有成熟的 ERP / WMS / 仓储系统，当然可以接。但如果是小商家或第一版产品，也完全可以先走 Shopify 原生路径。

按 Shopify 官方 Admin API，系统可以直接创建：

• draftOrderCreate

• orderCreate

而且订单创建后，Shopify 会自动生成 FulfillmentOrder，不需要你自己手动去建。

从系统设计角度看，发货域更像是一层订单与履约状态管理。它后面可以接 Shopify，也可以接 ERP，但第一版不一定要把 ERP 当成前提。

第五块：Shopify / Tracking

这一层最容易被误解成“就是看个订单”，其实它真正承接的是结果数据：

• 折扣码

• UTM campaign / content

• Pixel 行为

• Shopify 订单 webhook

• attributed orders

• tracking summary

真正要盯的，不是页面，而是 3 条状态线

如果把系统再收一层，我会建议团队盯住 3 条状态线：

1. 红人状态从新建、审核通过，到成功合作、暂停合作或黑名单。

2. 合作单状态从建单、选品、签约、待发货，到交付完成。

3. 订单与归因状态从订单创建、发货、妥投，到 tracking 和 attributed orders 汇总。

很多系统之所以越做越乱，不是因为页面不够，而是因为这 3 条状态线没有接成一体。

为什么很多团队做到一半就乱？

因为他们常常会犯 3 个设计错误：

1. 把所有动作都堆进 CMS

结果是后台越来越重，红人端越来越弱，团队自己也越来越依赖人工跟进。

2. 只做页面，不做触发

页面能录数据，不代表流程真的会往下走。没有自动化，很多节点最后还是靠人盯。

3. 先做“展示结果”，后补“状态管理”

这样会导致数据报表看起来有了，但合作为什么卡住、哪一步没走完、该不该二邀，系统仍然回答不了。

最后一句建议

如果你在做这类红人营销 App，第一版最该先搭的，不是所有功能，而是这 5 个责任域和 3 条状态线。先把谁负责什么、状态怎么流、数据往哪回设计清楚，后面不管你是继续接 ERP、扩展自动化，还是做更复杂的二邀逻辑，都会稳很多。

这类 App 真正的门槛，不是会不会做页面。而是能不能把合作、履约和归因放进一套说得清、跑得通的系统里。