预售活动开始后，运营看到定金陆续到账，便向仓库报了一个“已售数量”。到了发货日，仓库才发现，有些订单已经付清尾款，有些还在等用户付款。用户问为什么没发货，客服又拿不准该看定金时间、尾款时间，还是商品页上的发货说明。
预售不只是把购买按钮改成“支付定金”，还要把分阶段付款与后续履约接起来。本文以 Mall4j 多元版的普通实物商品为例，结合操作手册和功能列表，说明一场定金预售怎样安排时间、核对付款和交接发货。下文商品、金额、日期及订单情景均为假设，不是真实客户案例；人员分工与复核办法属于运营建议，不表示后台会自动执行。
先选清楚：全款预售，还是定金预售
多元版手册区分全款预售与定金预售。全款预售的下单流程与普通商品一致；定金预售则分为提交订单、付定金、付尾款几个步骤。两种方式不能共用一段含糊的“付款后发货”说明。
假设一家商家准备预售一款保温杯，计划售价为每件 300 元。如果采用全款预售，用户不是先付一笔定金再补款；如果采用定金预售，就要告诉用户第一次付多少、什么时候补尾款，以及发货时间怎样确定。
多元版手册提供按比例或按固定金额收取定金的设置，也可以分别设置定金与尾款的支付时间。选哪一种收取方式是商家的活动安排，不应由客服临时解释出另一套规则。本文讨论实物商品，不能直接套用到虚拟商品；手册明确说明虚拟商品不能设置预售。
先排付款时间，再写发货说明
继续用上述假设商品：不启用定金膨胀，也不考虑优惠券、运费等其他费用，假设商品价款由 60 元定金和 240 元尾款组成。这只是便于理解的算例，实际应付金额以配置和订单结算展示为准，不能把这个减法套到所有预售活动上。
运营可以先整理一份内部确认表，再配置商品并检查用户页面。下面的日期安排同样是假设：
| 需要确认的事项 | 假设安排 | 上线前核对什么 |
|---|---|---|
| 定金支付时间 | 2026 年 10 月 28 日 10:00 至 10 月 30 日 22:00 | 日期、时分是否与推广内容一致 |
| 尾款支付时间 | 2026 年 11 月 1 日 10:00 至 11 月 3 日 22:00 | 开始与截止时间是否写完整 |
| 发货设置 | 选择固定时间开始发货，安排为 2026 年 11 月 5 日 | 写清是开始发货，不是保证当日送达 |
| 客服说明 | 分别说明定金、尾款与发货安排 | 不把付定金称为已付清 |
多元版手册列出的发货设置包括固定时间开始发货，以及尾款支付后 N 天后发货。商家应按实际供货安排选择，并以当前后台字段及用户页面为准。
如果选择的是尾款支付后 N 天后发货，不同用户补款时间不同，就不能再统一答复“所有订单都在同一天发”。具体日期如何计算，应结合当前版本的配置与实际订单确认，不自行补出手册没有说明的计算口径。
“立即支付”要结合当前付款阶段看
多元版手册说明，用户提交定金预售订单后可以直接付定金，也可以在“我的订单”或订单详情中点击“立即支付”完成定金支付。尾款支付时间开始后，用户可从订单列表或订单详情进入“立即支付”，继续付尾款。
因此，客服不能仅凭用户说“我点过立即支付”，就判断这笔预售订单已经付清。应先定位订单，再确认这次支付对应的是定金还是尾款，以及付款是否成功。
可以把核对过程分成三个问题：
- 用户是否提交了对应商品与规格的预售订单，而不只是浏览过商品页？
- 当前完成的是定金支付，还是尾款支付？
- 若用户准备补尾款，当前是否已到尾款支付时间，页面实际展示什么？
对还没有到尾款支付时间的订单，不要简单要求用户反复付款。先核对活动时间与订单阶段，再说明应从哪里继续操作。对声称已经付款的订单，也要查看实际结果，不能只凭截图中的按钮名称判断。
仓库接到的应是待履约订单，而不是定金收款数
假设在尾款支付期间，商家有三笔保温杯订单：甲已付清尾款，乙只付了定金，丙提交订单后尚未付定金。它们都与同一款预售商品有关，但不能作为同一种进度交给仓库。
多元版功能列表提供按是否预售筛选订单、查看订单详情及导出订单列表等能力。团队可以据此查找预售记录，再逐笔结合当前付款、订单及发货条件核对。筛出了预售订单，并不代表这些订单都已经付清或都可以立即发货。
建议由运营或订单人员整理交接记录，注明订单号、商品规格、当前付款阶段、收货信息与约定的发货安排。仓库应接收已经核对符合发货条件的订单，而不是直接拿“收到了多少笔定金”作为发货清单。
对于乙，应继续跟进尾款；对于丙，应先核对定金支付情况。不要只看活动总数，就把两类订单也交给仓库打包。这份分工是内部管理建议，不表示系统会自动生成额外的审核或交接任务。
临近尾款截止，提醒和异常处理要分开
尾款截止前，客服可以根据已核对的订单进度，提醒仍待补款的用户关注支付时间与操作入口。提醒内容应与商品页、订单页一致，不擅自承诺延长付款时间，也不默认系统已经发送短信或其他自动通知。
遇到“时间过了还能不能付”“定金怎么办”“付款成功但页面没有更新”等问题，应查看具体订单、活动约定及当前版本的实际处理结果，再给用户明确答复。本文不把超时后一律自动关单、自动退定金或自动保留库存当作既定规则，也不把商品页面上的协议名称当成所有争议的统一处理结论。
对暂时无法确认的问题，先留下订单号、支付时间、用户看到的页面提示和跟进人；涉及付款结果时，结合实际支付记录核对，避免让用户重复付款。确需调整活动安排，也应先确认已有订单的影响，再同步客服与仓库，不能只改一张宣传图。
开卖前，用一笔预售订单把交接走完
与其等活动结束才对账，不如在上线前用一款具体商品，按当前环境支持的测试方式试跑定金支付、尾款支付和发货核对。尾款尚未开始时用户看到什么、开始后从哪里补款、付清后怎样交给仓库，都应有明确答案。
准备开展预售的团队，可以从Mall4j 多元版产品页进入演示，对照商品设置、用户订单与后台订单记录检查自己的安排。把“什么时候付哪笔钱、何时开始发货、异常由谁跟进”讲清楚，比只设置一个预售价格更能帮助团队把活动落到日常操作中。
核验与延伸阅读
本文涉及的产品能力、技术资料和适用场景，可通过以下公开入口继续核验：
