大型大闸蟹企业客户案例：私有化部署如何管理电商提货和分销商预储值？
大型大闸蟹企业客户案例：私有化部署如何管理电商提货和分销商预储值？
某大型大闸蟹企业在使用蟹云提货系统常规卡券、 提货、订单和发货功能的基础上， 采用阿里云服务器进行私有化部署， 同时对接抖音、天猫等电商渠道， 并根据自身分销业务定制了分销商预储值、 现货订货、铺卡以及多级卡券激活审批流程。
客户业务背景
该客户主营大闸蟹及蟹卡业务， 既有面向消费者的电商零售， 也有面向分销商的现货销售和蟹卡铺货。
与只使用提货系统管理卡券核销的商家相比， 这家企业需要同时处理三类业务：
- 消费者提货： 抖音、天猫等渠道销售蟹卡以后， 消费者需要完成线上核销和预约提货；
- 分销商现货销售： 分销商预先充值， 再自行下单购买大闸蟹现货；
- 分销商蟹卡铺卡： 先铺卡但不立即激活， 实际需要激活时再通过审批流程激活并扣款。
为什么选择私有化部署？
本项目采用阿里云服务器， 蟹云系统按照客户要求进行私有化部署。
对这类业务规模较大、内部管理流程较多， 同时还有定制开发需求的企业， 私有化部署可以让系统运行环境和企业自身的信息化规划保持一致。
独立服务器环境
系统运行在客户规划的阿里云服务器环境中， 便于企业按照自己的IT管理要求进行部署。
支持业务定制
在标准提货系统基础上， 根据企业现货、铺卡、审批及分销管理流程增加定制功能。
抖音销售的蟹卡怎么提货？
该客户在抖音销售蟹卡时， 按照对应业务要求在卡面印制抖音小程序二维码。
消费者在抖音渠道完成蟹卡购买。
消费者使用抖音APP扫描蟹卡上的抖音小程序二维码。
消费者完成卡券核销并提交收货信息。
蟹云对接抖音相关业务接口， 获取对应蟹卡提货订单。
发货人员在蟹云后台处理订单并打印快递面单， 完成大闸蟹发货。
天猫销售的蟹卡怎么提货？
天猫渠道销售的蟹卡采用的是另一种提货入口。
卡面印制蟹云提货二维码， 消费者收到蟹卡以后扫描二维码， 直接进入该企业自己的蟹云提货站点。
手机打开企业自己的在线提货站点。
输入卡券信息， 选择提货日期并填写收货人、电话和地址。
客户提交后， 商家后台可以查看并处理对应订单。
仓库工作人员在蟹云中打印快递面单， 完成订单发货。
为什么抖音和天猫可以使用不同的提货流程？
同一家企业的蟹卡， 在不同电商平台销售时， 可以根据平台接口要求采用不同的消费者提货入口， 但商家后台仍可以通过蟹云统一处理相关提货和发货业务。
天猫： 蟹云二维码 → 蟹云提货站 → 生成提货订单 → 仓库发货
对商家来说， 前端消费者入口可以不同， 后台卡券、订单和仓储发货仍然可以在统一业务系统中进行管理。
分销商为什么采用预储值模式？
除消费者提货外， 这个项目的另一项重点是分销商资金和销售管理。
在蟹云中， 客户把分销商作为会员进行管理， 分销商先向企业支付一定金额， 企业财务再把实际到账金额充值到对应会员账户。
- 每个分销商都有独立的会员账户；
- 财务根据实际收到的货款进行充值；
- 充值后形成该分销商在系统中的可用余额；
- 同一笔预储值余额既可以购买大闸蟹现货，也可以用于后续蟹卡激活扣款；
- 现货和蟹卡虽然业务流程不同，但共用同一套分销商资金账户。
分销商购买大闸蟹现货怎么处理？
分销商购买大闸蟹现货时， 使用的是“先充值、再下单、审核后扣款”的业务流程。
分销商先支付一部分货款， 财务确认到账后充值到对应会员账户。
分销商登录企业定制的分销商后台， 根据需要选择大闸蟹商品并下单， 订单金额不能超过账户可用余额。
订单提交以后， 系统自动向指定审核人员发送订单审核提醒。
审核人员可以根据实际情况录入快递费用、辅料费用， 并按照该分销商的合作条件调整产品价格。
订单审核通过后， 蟹云从对应分销商预储值账户中扣减本次订单金额。
分销商铺蟹卡为什么不立即激活？
蟹卡铺货和现货销售存在明显区别。
现货订单审核以后， 企业需要实际出货并扣减分销商余额； 而蟹卡铺卡时， 分销商拿到卡并不代表这些卡已经实际销售给消费者。
因此，该企业采用的是“先铺卡、后激活、激活时扣款”的管理方式。
- 铺卡时先建立销售订单；
- 约定该批蟹卡的销售单价；
- 把具体蟹卡绑定到销售订单；
- 卡券此时只完成分销关联，不立即激活；
- 分销商真正需要销售或使用时，再申请激活对应卡号。
蟹卡铺卡的完整流程是什么？
与现货业务一样， 分销商先向企业支付资金， 财务充值到其会员账户。
根据双方约定的蟹卡型号、数量和价格， 在蟹云中创建对应销售订单。
业务经理把实际铺给分销商的卡券绑定到销售订单， 建立“分销商—销售订单—卡号”之间的关系。
卡片可以先交给分销商， 但此时卡券仍处于未激活状态。
分销商需要激活蟹卡时怎么处理？
当分销商实际需要激活一批蟹卡时， 会把需要激活的卡号提供给对应业务经理。
该企业没有采用业务经理收到卡号后直接激活的方式， 而是定制了一套多级激活审批流程。
业务经理根据分销商提交的卡号， 在蟹云中创建卡券激活申请， 填写分销商和本次需要激活的卡号，蟹云会自动匹配激活价格等信息。
初审主要检查业务经理创建的激活申请单是否有误， 例如申请激活的卡号是否属于对应分销商、 卡券和分销商关系是否正确、 本次激活价格是否符合约定。
二审重点检查分销商当前预储值余额， 确认账户余额是否足以支付本次申请激活卡券的费用。
初审、二审通过后， 执行人员只需进行一次执行操作， 系统即可将申请单中的卡券批量激活， 同时从对应分销商的预储值余额中扣减本次激活费用， 不需要再逐张卡或逐项处理。
为什么卡券激活要经过初审和二审？
在这个客户的管理模式中， 卡券激活不仅会改变卡券的可使用状态， 还会同时触发分销商资金扣减， 因此属于同时影响卡券资产和分销商资金的业务操作。
- 业务经理负责发起申请， 不直接完成最终激活；
- 初审、二审将申请和执行进行岗位分离；
- 最终执行时再真正改变卡券状态；
- 激活成功的同时根据业务规则扣减对应分销商余额；
- 铺卡订单、卡号、激活申请和资金之间形成对应关系。
这种流程更适合内部岗位较多、 卡券金额较大或者需要对卡券激活进行审批控制的企业。
现货和铺卡为什么可以共用一个预储值账户？
在该企业的实际业务中， 分销商与企业之间存在的是持续合作关系， 同一个分销商既可能购买大闸蟹现货， 也可能代理销售蟹卡。
因此企业没有分别建立两个资金账户， 而是通过蟹云会员账户统一记录分销商预储值。
现货订货
分销商提交现货订单， 审核确定实际订单金额后从余额中扣款。
蟹卡激活
先铺卡不扣款， 实际审批并执行卡券激活时再从同一余额账户扣款。
标准功能和定制功能是怎么结合的？
这个项目不是重新开发一套完全独立的提货系统， 而是在蟹云已有卡券、提货、订单、会员、财务和发货能力的基础上， 增加符合企业内部管理制度的定制流程。
标准业务能力
卡券管理、在线提货、提货订单、 快递面单打印、会员、充值和订单等基础业务。
客户定制流程
分销商现货自助订货、 订单审核提醒、价格与附加费用审核、 铺卡以及初审、二审、执行式卡券激活。
这样既保留了成熟的提货和卡券管理流程， 又能把企业自身已有的分销管理制度落实到系统中。
这个案例形成了哪几条业务闭环？
1. 抖音蟹卡提货闭环
2. 天猫蟹卡提货闭环
3. 分销商现货资金闭环
4. 分销商铺卡资金闭环
这个项目适合哪些企业参考？
- 同时经营大闸蟹现货和蟹卡的企业；
- 有较多线下分销商、经销商的蟹企；
- 分销商采用预付款或预储值合作方式的企业；
- 希望先铺卡、实际销售后再激活和结算的商家；
- 卡券激活需要经过内部审批的企业；
- 同时在抖音、天猫等多个电商渠道销售蟹卡的商家；
- 对服务器环境、系统部署或业务流程有定制要求的企业。
这个案例体现了什么？
对规模较大的蟹卡企业来说， 提货系统解决的已经不只是“消费者输入卡号以后预约提货”这一件事。
当企业同时存在电商渠道、线下分销、 现货销售、蟹卡铺货和预储值资金时， 卡券会和订单、分销商以及资金形成更复杂的关系。
消费端： 电商平台 → 蟹卡 → 提货订单 → 仓库发货
分销端： 分销商 → 预储值 → 现货订单 / 铺卡订单 → 审批 → 扣款
蟹云在这个项目中承担的角色， 是把消费者提货、卡券状态、分销商账户、 订单审批以及资金扣减连接到同一个业务体系中。
案例事实信息
- 客户类型： 大型大闸蟹企业
- 部署方式： 阿里云服务器私有化部署
- 主要业务： 大闸蟹现货、实体蟹卡
- 电商渠道： 抖音、天猫
- 消费者提货： 抖音小程序提货、蟹云在线提货站点
- 分销模式： 分销商预储值
- 现货流程： 充值 → 自助订货 → 审核 → 扣款
- 蟹卡流程： 充值 → 铺卡 → 绑定卡券 → 激活申请 → 初审 → 二审 → 执行 → 扣款
- 定制内容： 分销商订货后台、订单审核及价格费用处理、多级卡券激活审批
总结
该大型大闸蟹企业采用蟹云私有化部署， 在同一套业务体系中管理抖音、天猫蟹卡提货， 以及线下分销商的现货和蟹卡业务。
对消费者端， 不同电商渠道可以按照各自业务要求进入不同提货入口， 最终由蟹云统一承接相关提货订单和仓储发货。
对分销端， 企业通过会员账户记录分销商预储值， 现货订单审核以后扣款； 蟹卡则采用先铺卡、后激活， 并在初审、二审和最终执行完成后扣减对应卡券费用。
这个项目说明， 对有较复杂分销体系的大闸蟹企业， 蟹卡提货系统可以进一步与会员账户、 分销订单、审批和资金管理结合， 在标准功能基础上按照企业实际流程进行扩展。