订单限制 + 配送，一个 Shopify 应用搞定

大多数商家把「限制顾客能下多少单」和「让顾客选择配送日期」当作两件事，用两个不同的应用来处理。它们不是两件事。它们是同一件事——让需求匹配您实际能够履约的能力——只是从两个侧面来看。本文将解释为什么它们应该在同一个应用里，以及商家如何将两者结合使用。

一个理念：作用于订单的规则

每一个产能问题都是作用于一笔订单的规则。*今天接单不超过 50 笔。晚上 6 点后不再售卖。别让一位顾客买走 200 件。别接受我们歇业那天的配送。*形状相同，强制校验点也相同：结账。

OrderRules 起初专注于这个理念的一侧——顾客何时可以下单：

配送日期则是它的镜像——您何时可以配送：

同一位商家，同一套心智模型，同一套技术界面。

把两个应用拼凑在一起看似没问题，直到规则之间发生交互——而它们总会交互。

**一个强制校验层，没有冲突。**当订单上限和配送规则同处一个 Function 中时，它们会对同一笔订单一起进行推理。两个应用各自运行自己的结账校验，正是那些莫名其妙的「这笔订单为什么被拦截了？」故障的根源。
**能相互引用的规则。**当日截单时间只有对照您的营业时间才有意义。停止配送日期应该复用您已经设置好的商店节假日。在一个应用里，它们共享同一份日历；跨两个应用，您就得维护两遍。
**一处配置，一处查看。**您周六的产能是一个单一数字，而不是应用 A 里的一个上限和应用 B 里的一个时间段限制悄悄地互相矛盾。
**一个订阅，一条支持线程。**两个应用意味着两份账单、两个后台，以及出问题时两家供应商互相推诿。

一家烘焙店把周六上限设为 50 笔订单，同时提供带有每日时间段的配送日期选择器。上限和时间段是同一份产能的两种表达方式——选择器会阻止第 51 笔订单选中周六。

一家花店在下午 2 点设置当日截单（一条订单规则），同时配合每个配送日期的上限（一条配送规则），这样情人节就会填满其真实的路线产能，然后自动顺延到下一个可用的日子。

一家日本商店将注文制限（订单限制）与配送日時指定（配送日期/时间选择）搭配使用，并把当天的货件以承运商 CSV 的形式交给 Yamato 或 Sagawa——订单管控、配送管控和履约集于一处。

日本正是这两半最清晰地融合在一起的地方。结账时选择时间段是消费者的默认预期，承运商 CSV 导出是运营的入场门槛，而没有任何一款全球性应用能在一个产品里同时捆绑订单限制和配送排期以及日本承运商 CSV。OrderRules 做到了——这正是它的发布以日本为先导、同时又在各地通用的原因。

如果您已经在用 OrderRules 做订单限制，那么配送排期只是一个打开就能用的开关，而不是又一个需要评估的应用。如果您是新用户，可以先采用任意一侧，再逐步拓展到另一侧。

在一个应用里管控顾客何时下单——以及您何时配送。开始 14 天免费试用。

不需要。OrderRules 在同一个应用、同一个结账强制校验层上同时完成两者，因此规则永远不会冲突，您只需维护一份配置、一个订阅和一条支持线程。

订单限制和营业时间在免费的 Starter 套餐中。配送排期在 Advanced 套餐（$19.99/月）中——包含 Pro 的全部内容，再加上配送套件。

可以。全店每日上限和按日期的配送上限是同一份产能的两种表达方式，它们在结账时一起强制校验。

查看 OrderRules 与该类别中其他所有 Shopify 应用的对比。