如果你按单生产，你心里会有一个数字。一天 12 个蛋糕。周六 40 份外烩。情人节 60 束花。这不是偏好，而是你真正拥有的人手、烤箱和小时数。
于是你找了一个能限制每天订单量的应用，把它设成 12，然后一个月后，你又回去用电话接单了。
原因如下。
两个不同的日子
顾客周一下单、周五自提一个蛋糕，这笔订单上挂着两个日期：下单的周一，以及必须做出来的周五。
几乎所有限制工具数的都是周一。如果你的瓶颈是今天想处理多少单，那周一确实是该数的那天——正在消化积压的店铺，或者不想一个上午收到五十条通知的独立作者。
但如果你的瓶颈是厨房，周一什么也说明不了。有上限的那天是周五。而等周五真的来了，那些订单早在几天前就一单两单地被接下来了，而那几天看起来都很清闲。
于是你得到两头的坏处。周一看起来没问题，所以没有任何东西拦住订单。周五超额了，而你是在周四晚上才发现的。
那一周实际上长这样
假设一家烘焙店每天最多做 12 个裱花蛋糕，并按下单日期把上限设成 12。
| 订单进来的日子 | 接单数 | 其中周五的 | 周五的真实总数 |
|---|---|---|---|
| 周一 | 4 | 3 | 3 |
| 周二 | 5 | 4 | 7 |
| 周三 | 3 | 3 | 10 |
| 周四 | 6 | 5 | 15 |
没有任何一天突破 12 这个上限。每一天看起来都很宽裕。可周五超了三个，而店铺里没有任何东西发现——因为店铺里没有任何东西在数周五。
这就是问题的形状，也是「设个每日上限」这类建议帮不上忙的原因。上限是开着的，只是指向了错的那一天。
电子表格阶段
我们接触的大多数商家都用同一种办法解决它，而那总是电子表格的某个版本。
一周一个标签页。一个生产日一行。每来一单就手动更新一次的数字，通常在晚上，通常靠记忆。它「有效」——在「需要你本人每一天都不出错」这个意义上有效。
出问题的地方不是表格算错了，而是店铺根本不知道有这张表。表格说周五满了，网站却继续在卖周五。于是你在商品页加一行说明——「周五的订单可能受限，我们会与您联系」——然后你就开始为自己早就知道的事退款并道歉。
或者你走另一条路：不在线上卖这些商品了。也就是说，这个瓶颈现在把整条渠道也一起拿走了。
数活儿真正发生的那一天
解决办法不是更好的表格，而是去数另一个日期。
如果「一天 12 个」指的是取货那天的 12 个，一切就对上了。周一下单、周五取的订单算在周五。周四晚上下单、周五取的订单也算在同一个周五——如果它是第 13 个，就过不去。
你心里的数字和店铺实际执行的数字变成了同一个数字。没有人需要记得去更新什么。
这就是 OrderRules 现在能做的事。在 Advanced 套餐上启用配送日期后，任何商品的每日上限都可以按顾客选择的配送日期计算，而不是按下单日期。这是商品上的一个设置：每日上限的计算依据——下单日期或配送日期。
| 下单日期 | 配送日期 | |
|---|---|---|
| 保护什么 | 你今天的时间 | 某一天的产量 |
| 计数对象 | 订单进来的那天 | 订单到期的那天 |
| 适合 | 积压、发售、限流 | 按单生产、备料日、配送路线 |
| 上表中的周五 | 不会触发 | 停在 12 |
四个比听起来更重要的细节
变体分别计数。 中号蛋糕和大号蛋糕的工作量不同，给两者共用一个数字，并不比没有数字好多少。在同一个商品上设中号 10 个、大号 14 个，各自独立受限。没有单独上限的变体沿用商品的上限。
自提和配送共用产能。 10 就是 10。顾客是自己来取还是让你送，烤箱并不在意，所以上限也不在意。如果你在配送之外还提供门店自提，这通常正是你想要的：共享的上限才是和厨房对得上的那个。
顾客是在日历处被挡住的，而不是在结账页。 有人选日期时，会看到该日期还剩多少名额。装不下他购物车的日期，根本就选不了。让人选好、下了决心之后在结账页被拒，比一开始就不提供这个日期体验更差——而且这是一笔本可以靠「要不要改到周六」挽回的订单。
取消会把名额还回来。 如果一笔周五的订单被取消，周五就能再接一笔。这很显然，但值得说出来：只会减少的产能是一种慢性泄漏，最后会留下一个「明明不满却显示满」的日子。
这个数字该设多少
人们会想直接填理论最大值。请克制，原因有两个。
第一，你的最大值假设的是一个什么都不出错的日子——没有人请病假、烤箱没坏、没有哪个婚礼蛋糕做了报价两倍的时间。卡在最大值上的上限，只在顺利的日子里是对的。
第二，是本文结尾提到的并发窗口。在上限为 6 的日期上，留一个名额的余量代价是一笔订单，却消掉了上限唯一可能被突破的情形。在上限为 60 的日期上，这点差别是噪音。数字越小，余量越值钱。
一个实用的起点：设得比你嘴上会说的数字略低一点，跑两周，然后看哪些日期真的满了。把一个偏保守的上限往上调是个愉快的问题；在一个糟糕的周六之后往下调，就不是了。
同一个瓶颈的其他形态
蛋糕是最清楚的例子，但不是唯一的。
- 外烩公司的周六能承接的活动数是固定的，跟什么时候预订无关——见如何用 Shopify 经营外烩与活动业务。
- 花店有情人节和母亲节，上限在订单进来的几周前就由人手和花材定下了。
- 按单生产和小批量的作者卖的是产能而不是库存，这本身就是一门运营功课——在按单生产的交期与产能上限中讨论。
- 接受预订的餐厅的午市有一个数字，自提和配送都会从里面扣。
- 家具与大件商品靠的是配送班组而不是烤箱，上限实际上是「一辆车一天能跑几个送货点」——见家具品牌的 Shopify 指南。
如果你的瓶颈是按时段而不是按天——一个 10:00–12:00 的窗口只能装四单——那是另一个设置：配送产能上限在可用性规则上而不是商品上，为每个日期和每个时段设限。两者可以配合使用，不少店铺两个都需要。
它与备货时间、下单截止的关系
按配送日期设限回答的是多少个。相邻的两个设置回答的是哪些天能被提供，而且它们比上限先生效。
备货时间会去掉太近的日期。如果一个裱花蛋糕需要三天，那么到了周三，周五就不可选了，无论周五还剩多少产能。请按你真实的制作时间来设，而不是最理想的情况。
下单截止时间决定「今天」在哪里结束。如果生产清单在下午 2 点定稿，那么 2:15 下的「明天」订单，实际上是后天的订单——下单截止时间会把这件事讲明白，而不是留给看清单的人去判断。
执行顺序值得知道：备货时间和下单截止决定顾客能看到哪些日期，而按配送日期的上限决定每个日期还能再接多少。日期可能因为这两类原因之一从日历上消失，而顾客看到的提示也会相应不同。
如果你还在商品页展示预计送达日期，那个预计日期正是同一套备货时间算术的展示——它告诉顾客某个日期会落在什么时候，而这些上限决定那个日期是否还开放。
什么时候你确实想要下单日期
明说：按配送日期计算不是「更好的选项」，而是「另一个选项」。
如果你的上限描述的是你想接多少单——人手不足时限流、给一次发售设上限、让新商品的量保持可控——那么下单日期是正确的基准，而且一直都是。那是对流入工作量的限速，而流入的工作就是在它到来的那天到来。在那种场合，按下单日期计算的每日订单上限才是对的工具。
要问的问题是：这个数字在保护什么？保护你今天的时间，就数下单日期；保护某一天的产量，就数配送日期。
两种情况下，每周和每月上限都仍按下单日期计算。只有每日上限会切换，因为「这一周」是一个时间段，而「周五」是有一间具体厨房的具体某一天。
如何设置
如果你已经启用了配送日期，这大约是一分钟的工作：
- 在商品中打开一个商品
- 在每日上限的计算依据中选择配送日期
- 设置每日数量——在商品上，或按变体
- 保存
先多选几个商品，设置会一次应用到全部。它也会在 CSV 导出与导入中传递，所以整个商品目录可以一次配好。
之后，商品列表会为每个设了上限的商品显示未来最紧张的那个日期——11 月 14 日(五) · 9/10——而不是使用率百分比，因为百分比在这里没有意义。这里的使用情况是一个序列，不是一个数字：未来每个日期各有一个数值。一个商品今天可能显示 0%，而下周六已经一个名额都不剩。
如实说明的限制
有一件事它做不到。与其让你日后自己发现，我们宁愿先讲清楚。
同一秒、同一日期、只剩一个名额时完成结账的两位顾客，可能都会通过。结账校验读取的是已预订情况的快照，无法像库存那样加锁。实际上这需要在只剩最后一个名额的日期上出现近乎同时的结账，所以很罕见——但并非不可能，而任何声称相反的应用，都是在声称平台并不提供的东西。
这也是上文「留余量」的建议在小上限上值得遵循的原因。它是用很小的代价，消掉那个数字唯一可能被突破的情形。
它真正做到的，是让店铺和你的生产排期成为同一件事，而不需要你同时维护两边。对大多数日子、大多数周来说，这就是「能不能在线上卖」的差别。
接下来读什么
- 按配送日期设限 —— 配置文档，包含变体、CSV 与取消处理
- 开始设置配送日期 —— 该设置出现的前提
- 按商品设限 —— 本设置所改变基准的那个每日上限
- 配送产能上限 —— 可用性规则上按日期与按时段的上限
按配送日期设限属于 Advanced 套餐，需要先启用配送日期。查看文档 →