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

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

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

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

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

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

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

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

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

一家烘焙店把每个配送日期的上限设为 50 笔订单，同时提供各自带上限的时间段。周六订满 50 笔后，它会在选择器中变灰，结账也会拦截第 51 笔选择周六的订单。

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

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

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

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

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

不需要。OrderRules 在一个应用里同时完成两者，由它自己的 Shopify Functions 在结账时对两者强制校验，因此您只需维护一份配置、一个订阅和一条支持线程。

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

它们是两个独立的设置，都在结账时生效。全店每日上限按下单当天计算订单；按日期的配送上限按顾客所选的配送日期计算订单。请让每个设置对应它所保护的那个约束。

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