一个做食品的朋友问我微信小店的货想靠推客往外打软件公司报价一个八万一个十二万功能清单拉得跟小说似的。我说先别急着签推客系统的钱到底贵在哪、哪些功能你根本用不上、哪些部分必须老老实实自己写这几点想明白成本能砍掉一大半。这两年我帮几个品牌方从零搭过类似的推广分销系统跑通之后推客带进来的订单能占到四成以上开发投入却比大多数人预期的低得多。这篇就围绕微信小店商家自己开发推客系统这件事把账怎么算、模块怎么切、链路怎么搭、哪里最容易翻车一次讲透。1. 别急着找外包先把账算清楚很多人一想到推客系统第一反应是我是不是要把商城整个重做一遍于是拿着外包的功能清单对比越看越贵。其实推客系统的钱由三块组成功能开发、基础设施、维护迭代。功能开发是最大头包括推广关系判定、佣金结算、素材中心、数据看板这些模块基础设施是服务器、域名、短信、接口调用这些杂项维护迭代则是上线之后改规则、修数据、跟微信接口升级的隐性成本。外包报价高通常不是因为开发工作量真的那么大而是功能清单里混进了一堆你现阶段根本不需要的东西比如多级分销、直播拼团、会员储值、积分商城。这些模块每一个都是钱但对推客拉新起不到决定作用。1.1 自研还是买SaaS先按两年算一次账我把自研和SaaS放到一起算了一笔账。市面上的分销SaaS工具年费几千到上万的都有部分还会按成交额抽点常见在0.5%到2%之间。假设你一个月流水二十万抽点按1%算一年光抽点就是两万四这还没算年费。自研一套精简版推客系统外包找靠谱的团队大概三到五万自己团队做大概一个人月后续每年服务器和维护成本控制在一两千以内是常态。两年下来自研的总成本通常就比SaaS低。反过来如果你的月流水还不到五万SaaS的费用也花不了多少这时候用现成工具甚至表格加人工过渡都行没必要背一个开发的包袱。方案一次性投入每年固定成本适合阶段第三方分销SaaS低年费成交抽点月流水5万以下、规则通用即可外包定制3-8万不等服务器维护有明确规则但团队无开发能力团队自研精简版1-2个人月服务器维护约1000-3000/年月流水较大、规则要沉淀表格人工几乎为0人工成本推客只有十几个的冷启动期什么时候自研最省钱答案不是看功能多少而是看你的GMV能不能摊薄一次性成本。流水够大、经营周期够长自研就是赚的还在摸索期的店铺先别急着上重型系统。2. 省钱的本质交易层用微信小店推广层自己写真正省钱的思路只有一条交易不用你操心把推广归因和佣金结算做薄。很多商家最贵的错误就是把商城重新写了一遍。你在微信小店上架、收款、发货、处理售后这些环节已经是一套成熟交易系统在跑。推客系统本质是一个中介层它做的事只有两件事第一记住某个买家是被哪个推客带来的第二订单成交后按规则分钱。把这一点想透你的开发量至少砍掉一半。先看看微信小店自己给了什么。小店后台确实有一套关于推广角色和分享员的基础能力佣金设置方面也有现成入口。我的建议是官方能力能覆盖的需求直接先用官方功能免开发还稳定。你真正需要自研的是官方没做或者做不灵活的边界部分。2.1 必须自己写的四个模块按照多年踩坑的经验有四个模块必须自己写而且迟早要写。第一个是推广身份绑定。推客分享的链接或海报里要带他的专属参数用户点进来之后系统要把这个买家的身份和推客绑定。第二个是订单归因。订单成交后系统要能通过订单数据判断归属这决定了钱分给谁。第三个是佣金计算。按商品、按分类、按比例还是按等级规则得可配置不能写死在代码里。第四个是提现结算。推客在后台看到可提现金额发起提现你通过微信支付的商家转账把钱打到他的零钱。这四个模块的共同特点是离开了它们推客系统就是个空壳它们又直接决定了你的钱会不会算错、推客会不会信任你。所以这部分不能省、不能抄、不能套一个改不明白的模板。2.2 可以直接租的部分剩下的大可不必自己开发第一版。素材中心听起来很需要但推客只有几十个的时候一个企业微信群、一个腾讯文档、一个草料二维码生成器就能完成90%的素材分发。数据看板先用表格过渡看微信小店后台报表、导出Excel、配个简单的定时任务拉数据比从零开发一套BI划算得多。消息通知用公众号模板消息、订阅消息或者企业微信成本低还稳定。后台权限管理第一版就一张用户角色表别一上来就上RBAC权限框架。这些模块的特点是不直接影响钱分得准不准早做晚做都一样那就晚做。判断一个功能该不该进第一版就一句话它是否直接影响这个订单归谁、分多少钱的准确性。影响就做不影响就拖。3. 微信小店对接的最小可行链路链路设计是推客系统的骨架骨架错了后面全是补丁。我按靠谱的顺序给你过一遍这是几十个项目验证过的标准时序。第一步推客进入你的H5或公众号菜单通过微信授权拿到他的身份标识。第二步系统给推客生成带专属参数的推广链接和推广海报。第三步用户点击推客的链接落地页记录下用户的身份并和推客建立绑定关系这里一般还会设置绑定有效期比如7天内成交都算这个推客的。第四步用户跳转到微信小店完成下单支付交易发生在小店内但订单数据会同步到你的后台。第五步你的系统通过微信小店的订单接口周期性拉取订单按绑定关系做归因。第六步订单确认收货、过完售后期系统计算佣金。第七步推客在后台发起提现你审核后通过商家转账把钱发出去。3.1 关键字段与接口看懂官方文档比写代码更重要技术细节上有几个点我第一次做的时候也绕了弯。身份标识要注意openid和unionid的区别。同一个用户在公众号、小程序、H5里拿到的openid可能各不相同openid是每个应用一把钥匙unionid才是跨应用的身份证。如果你的推客端以后要同时上H5和小程序提前把unionid的体系接好不然到时候两边数据对不上佣金归属会乱。订单接口那边重点不是拉单而是读状态。待发货、已发货、已完成、退款中、已退款不同状态对应不同的佣金处理。最容易漏的是退款单接口很多新手只同步订单不同步退款结果佣金发出去收不回来。数据库里至少备三张核心表推客表存openid、unionid、状态订单表存微信小店订单号、实付金额、归属推客、订单状态佣金流水表存每次计算和冲正的明细。对账就查这三张表逻辑干净。转账环节用微信支付官方的商家转账功能按openid打款别手动一笔笔转也别在这时候搞复杂的微信支付分账。分账能力确实强但规则复杂、要为每笔订单实时处理第一版统一结算后转账逻辑简单得多也少踩很多坑。3.2 H5先行、小程序后补为什么我建议H5先行、小程序后补一是H5不用过小程序审核改bug当天能上线小程序要发布审核迭代周期长二是H5的成本低一套H5后端就是你的整个服务端不用额外再包一层小程序工程三是入口简单公众号自定义菜单挂链接就能用。等到推客数量上来、需要订阅消息提醒提现到账、或者推客每天要高频翻素材和看数据的时候再补小程序版不迟。4. MVP阶段的开发顺序与预算MVP阶段最考验的其实不是技术而是敢不敢砍功能。我见过的失败项目大多不是开发能力不够而是第一版功能太多上线拖了三个月窗口期过了。4.1 第一版先砍掉的功能第一版先砍掉的功能我给你列一个清单多级分销和团队裂变这是合规雷区也是开发量黑洞第一版不做自动发素材、定时群发不做优惠券、拼团、秒杀这些营销组件不做复杂的数据报表不做规则引擎、自定义结算周期之类的高级配置不做。第一版只留六样东西推客注册和身份绑定、推广链接生成、订单归因、佣金计算、提现申请、后台人工审核打款。每一件都是钱和归属的直接环节做完就能跑。你能砍掉的功能以后能不能补能。但第一版功能越多上线越晚试错越慢。跑通了再迭代永远比憋大招靠谱。4.2 后端选型用能快速上线的组合后端选型不要纠结语言团队熟什么用什么。如果是小团队没有专职运维我建议直接上微信云托管或者云开发这类方案按量付费流量小的时候一个月可能就是几十块钱省掉了配服务器、配HTTPS、做备份的琐事。数据库选MySQL就行订单、推客、佣金流水各一张核心表前面已经说过了。定时任务每小时拉一次订单晚上再跑一次结算任务。这些逻辑都很标准教程也很多真正要把时间花在规则梳理上而不是环境搭建上。有一点要特别提醒别一开始就买一年期的固定套餐。很多团队惯性以为服务器必须包月包年买结果流量没起来钱先花出去一大截。云托管按量付费不会贵量大了再切固定套餐这才是真正把钱用在刀刃上。4.3 预算表把每一笔钱写在明面上支出项说明大概费用域名和SSL证书备案域名.com或.cn50-100元/年云资源微信云托管按量或轻量服务器0-300元/月起步短信/模板消息提现通知、异常提醒0.03-0.05元/条第三方工具腾讯文档、草料等0-200元/年开发投入自研约1个人月外包3-5万视团队情况这套预算的前提是你不做小程序、不做素材库、不做活动营销。做到这几点第一年的硬成本可以控制在一个非常低的数字大头只剩人力和外包费。5. 最容易翻车的三件事对账、合规、退款钱相关的模块光逻辑通不够还得扛得住真实业务的脏数据。最容易翻车的三件事我一个个说。5.1 佣金不是订单金额乘比例那么简单计算基数一定要用实付金额扣掉优惠、运费、部分退款之后才算结算时点要放在确认收货且过售后期不要用户一支付就算佣金已经发放的佣金遇到退款必须有冲正机制所以佣金数据要按流水记录不能只存一个总余额。后台一定留一个人工调整入口总会有订单因为归因失败、改地址、异常拦截等原因算错人工能兜底才不会引发推客投诉。另外订单被判定为异常订单或者刷单的时候要能整个撤销归属。这块逻辑不复杂但一定要做成后台可操作而不是靠改数据库。改库一时爽对账火葬场说的就是这种情况。5.2 分销红线与结算合规微信对多级分销、拉人头、入门费这类玩法极其敏感超过三级或者按人头计酬的规则轻则接口被封重则整个账号受影响。最稳妥的设计是一级佣金最多加一个基于团队销售额的管理津贴不设置入门费佣金只和商品成交挂钩和拉了多少人没有直接关系。这条规则不仅写进代码还要写进推客合作协议里避免推客自己搞出违规操作连带商家遭殃。企业给个人推客发佣金该走的个税申报流程要安排上用对公流转账而不是私人微信转账账目才经得起查。很多小商家觉得走私人号方便等到推客规模大了、税务问起来补起来相当痛苦。这块不属于开发范围但属于系统的运营前提越早规划越好。5.3 归因规则不提前定推客先吵起来用户先点了A推客的链接又点了B推客的链接最后下单佣金算谁的我的推荐方案是最后点击优先绑定有效期7天过期作废。推客自己买自己的货能不能拿佣金可以但规则要写清楚避免有人刷单套佣金。这些规则不光是技术逻辑还要写进推客合作协议里出现争议时按规则处理而不是临时吵。实际运营中还有一种常见情况用户点进落地页后没有立刻下单隔了两天才从收藏夹里翻出来从别的入口成交了。这个订单往往归因失败会出现在未归因订单列表里。别急着放弃这批订单定期人工处理能挽回不少推客的信任。6. 上线后我最想提醒的几件事系统能跑之后先别急着铺量有几件小事看起来不起眼却决定了项目能不能走远。第一批推客一定要人工跑通全流程。找十个信得过的朋友当推客每个都真实分享、真实下单每笔订单手动在后台核对归属和佣金。这个阶段暴露的问题越多越好错单、漏单、归因失败全在内部消化掉别让第一批社会推客来替你付学费。对账口径要固定下来。以微信小店后台导出的报表为基准每周和系统数据对一次差异率超过千分之五就暂停发放佣金先查原因。实际运营里大部分差异来自退款和售后少数来自身份绑定失败。跑完三个月你就能积累出一张常见的异常订单清单处理速度会越来越快。迭代节奏上我的原则是三个月看一次成本。GMV涨了、推客过了三百人再讨论要不要上小程序、素材库、更复杂的报表。每次加功能先问一句它是不是直接影响归因准确率或结算效率是就做不是就继续拖。推客系统不是一个越复杂越好的系统它是一个越准确越值钱的系统。我个人做这类项目最大的体会是把推客系统当成一个结算工具来做而不是营销工具。你把钱分得准、分得快推客自然愿意跟你干你把精力花在裂变玩法和花哨功能上最后大概率死在售后和对账上。微信小店商家如果真的想靠推客打开销量先按这条路径把基础链路跑通成本可以比多数外包报价低一个量级。等推客队伍有了规模再把预算花在体验和数据上那时候每一分钱都花在了刀刃上。