分析外卖系统下单与付款中领域知识


下订单和付款是完全不同的操作。

下单取货
工作流程:

  1. 客户拨打电话下订单取货
  2. 他们想买一个大的轻熟馅饼和 6 个蒜结
  3. 您将他们的订单输入 POS(销售点)系统
  4. 每个项目都列为一个行项目,包含名称、数量、注释和价格
  5. 您询问他们的姓名和电话号码并将其输入系统
  6. 计算总计时将销售税作为单独的行项目
  7. 订单被“创建”,并且会发生以下情况:
    • 订单被置于“进行中”状态,并有一个小图标显示尚未付款
      • 是否付款与正在进行的订单无关
  • 收银机打印收据,标有“INCOMPLETE”
    • 您挂起此收据,以便您和其他人知道订单正在等待处理
  • 制作 1 个馅饼的订单打印在披萨制作者可以看到的地方

    步骤 7 会有所不同,具体取决于您使用的 POS 系统,但总体思路是相同的。系统中的订单具有状态的概念,执行人工工作流程以实际跟踪该订单并打印收据。
    我们从来没有考虑过在这里付款。对于这里取货订单,可以通过以下几种方式收取付款:

    • 他们在取货时用现金或信用卡付款
    • 在与客户通话时,您代表他们在终端中输入信用卡详细信息,顺便说一下,这符合 PCI DSS 标准,我们的上述工作流程可以在第 6 步之后完成,然后第 7 步会有所不同,但让我们把暂时搁置

    现在假设客户 20 分钟后过来取货。此时您可能已经接受了来自不同客户的 10 个其他订单。有些可能正在进行中,有些可能已经完成。也许有人突然进来买了 2 片带走,并且在 3 分钟内进出。

    您检查挂起的收据,发现该订单是#137,因此您返回 POS 系统的“进行中”选项卡并找到该订单。

    您可以查看订单的全部总额,并查看客户是否有现金或银行卡(或者他们的手机,如果他们使用 Apple / Google Pay)。如果没有,你问他们现金还是刷卡,POS 系统会让你选择哪一种。

    如果他们选择现金,您输入他们给您的金额,系统会自动计算找零。如果他们选择卡或其他数字支付方式,他们可以使用终端来点击或插入他们的卡/设备。除非他们的卡有问题,否则它将获得授权,然后有望成功。

    无论如何,如果付款成功,则会发生以下情况:

    • 订单在系统中标记为“已完成”
    • 打印另一张收据,但填写了付款信息
    • 如果企业主希望保存实际收据,您可以保存收据
    • 您移除并扔掉挂着的“不完整”收据,这样您就知道它已经完成

    订单已完成,并已通过工作流程进行移动。根据地点的繁忙程度,每天可能会执行 50 次甚至 300 次,其中在受欢迎的午餐和晚餐时间附近会出现激增。

    如果您需要返回已完成的订单,您可以这样做。您还可以根据需要打印收据,如果有付款,您可以全额或部分退款。

    关于付款详细信息还有很多内容需要讨论,但让我们回顾一下上述内容中的一些技术要点。

    技术要点
    以下是我在接受订单和观察系统时从上述内容中得到的一些启发和思考。如果您要建立这个系统,请考虑一下您可能拥有的数据库术语和关系。

    我引用的词语可能是表格或模型。

    订单"、"产品 "和 "付款 "是不同的东西
    订单 "实际上是将多个产品整合在一起,形成一个可以关联的东西,但在我看来,它并不是产品和付款之间的连接表。

    137 号订单有 N 种产品。它还有 X 笔付款,如果订单是免费的,X 甚至可以为 0,例如,如果他们有一张优惠券,买 10 个派可以免费获得 1 个派。

    您仍然希望将免费馅饼纳入工作流程并进行跟踪。唯一的区别是你不会收取付款。

    订单有一个状态,可以清楚地显示订单所处的阶段。你几乎可以把它想象成一个从创建到完成的看板。

    产品 "有 "变体 "和 "备注"
    在这里,一个派可以是个人派(12")、中号派(16")或大号派(18")。顾客可能想要全椒馅饼或肉丸。也许他们想要 1/2、1/2,也许他们想要 2 个完整的配料。

    馅饼也可以不加任何说明,或者根据顾客的具体要求,如微熟、酥脆或全熟。

    变体和注释是两码事。变体是顾客在购买时可以选择的东西,它可能影响价格,也可能不影响价格。变体是标准的东西(T恤大小等),而备注是客户的临时要求。

    如果有足够多的客户提出相同的要求,也许这就意味着你可以将其转化为变体,但并不总是如此。例如,如果 90% 的人都能接受正常烹制的披萨,你可能就不想明确要求他们在普通、清淡、酥脆或全熟之间做出选择,因为这会使订购过程复杂化,尤其是在网上订购时,他们需要点击表单字段。

    另一方面,要求他们选择大号或个人口味也是一个好主意,因为这两种口味的产品不同,价格也不同。不过,如果你卖的是衬衫,即使不调整价格,你也可能希望把颜色作为一个变体。

    ”收据 "不可更改
    收据是在特定时间点创建的,它反映了该时间点的详细信息。可以打印,也可以不打印。

    这是一个非常重要的区别,因为即使你不把订单打印到纸上,你也不想根据未来发生的事件用不同的细节修改旧订单。

    例如,如果一个馅饼现在的价格是 16.95 美元,而您过去有 1000 个订单是以这个价格成交的,然后您将馅饼的价格提高到了 17.95 美元,您就不能回到过去,将所有以前的订单都调整为 17.95 美元。

    不可能吧?货款已经以 16.95 美元的价格收讫,交易已经完成。

    这就意味着,在渲染收据时,你不应该使用产品外键的引用来动态获取价格。关于收据的所有内容都应该去规范化,也就是收据的所有细节都包含在这一行中。它应该是一个单独渲染的东西,有自己独立的数据。

    以多种方式下订单
    在上面的示例中,我们处理了单个柜台工作人员通过 POS 系统输入订单的用例,但这并不是收集订单的唯一方式。

    如果您的销售点系统与网站或应用程序集成,顾客就可以在线下订单。这些订单仍然需要以 "进行中 "的形式出现在系统中。在这种情况下,订单尚未 "完成",但付款已被记录。

    在线订单仍然会挂起收据,因为挂起的收据是一个指示器,让工作人员知道客户是否收到了订单。它与是否收到付款完全无关。

    此外,订单可以通过 DoorDash 下达,而 DoorDash 甚至可能无法与您的 POS 系统集成。如果没有,您可以通过不同的系统获取 DoorDash 订单,但在收据未完成时悬挂收据的想法仍然适用。

    最后,如果我们回到有人在披萨店点餐的情况,那么从技术上讲,可能会有多个 POS 系统和多个终端来接受信用卡付款。

    每个 POS 系统都应相互同步订单和状态,否则可能会出现信息冲突,从而造成混乱。除此之外,这与我们最初在收银台接受订单的计划相同。悬挂收据的工作流程仍然有效。

    技术启示
    在 DoorDash 案例中,这是一个有趣的想法,因为两个不同的系统或输入仍然可以流入相同的工作流程,以确保订单得到满足。在 DoorDash 案例中,所有订单都已付款,您只需跟踪某人何时取货。他们取货并在手机上标记 "已取货",就是我们完成订单的操作。

    这就为销售点管理系统与 DoorDash 等第三方订单收集系统集成打开了大门。您的 POS 系统可以感知 DoorDash,这样订单就会显示在同一个地方。

    在我工作的地方,它们是分开的。这意味着要跟踪 2 个不同的 iPad 屏幕,而且 DoorDash 系统甚至没有打印机,所以我们必须手写订单并将其悬挂起来。为 DD 安装收据打印机是他们的一个短期 TODO 项目。

    这里真正的启示是要考虑关注点的分离、抽象以及系统解耦后的灵活性。集成 DD 系统可以很好地提高运行质量,但并非必需。

    后端的披萨制作者甚至不需要考虑这个细节。他们只知道必须在 X 时间之前制作出特定类型的披萨。

    每个订单可多次付款
    大多数订单都是现金或信用卡支付,但从技术上讲,有人可以同时用现金和信用卡支付。我去的第一天就遇到过这种情况,有人的订单金额是 14 美元,但他们同时用礼品卡和现金支付。

    除此之外,您可能还需要在交易完成后收取额外的付款。例如,有人在网上订购了一个普通馅饼,并定制了一张纸条,上面写着 "添加水牛城鸡肉配料"。

    有些人故意这样做,希望免费获得 5.50 美元的配料。他们本应通过菜单系统选择该配料,在付款前就会将其计算到总额中。

    还有一些人犯了诚实的错误。也许他们不习惯使用网上菜单,没有注意到配料部分,或者 POS 系统的网上订餐软件不够理想,没有让他们注意到这一点。

    在这种情况下,我们会返回订单,然后从他们的卡上多扣 5.50 美元。POS 允许您在订单中增加 X 美元,只要金额在一定范围内(我想是基于百分比)。几乎在所有情况下,这都可以在不联系顾客的情况下完成。

    95% 以上的情况下都可以这样做,这也是客户想要的。我们总是在他们取货或送货时让他们知道我们做了调整,并写在收据上。他们在收到食品时就会完全了解收费情况。

    如果他们不想要额外收取的配料费,我们会退还他们配料费,然后给他们一个普通的馅饼,或者让他们免费保留配料。这要视情况而定。

    大多数企业主都会让您满意,但如果您试图利用这种情况并一直这样做,他们就会注意到,如果您继续滥用系统,他们可能会选择不再与您做生意。

    一个订单有许多付款方式。在显示订单或收据时,确保每种付款方式都有自己的行项目。

    额外收费、小费和折扣
    除了在初始交易后收款外,您可能还想在交易前添加额外费用。只需点击总计附近的 "额外收费 "链接,然后添加金额即可。

    例如,所有标记为送货的订单都会增加 2 美元的送货费。

    还有一种情况是,有人可能要求定制一个没有类似菜单项的订单。有时,我们可以向顾客收取最接近的菜单项目的费用,然后再加收额外费用。

    例如,一份肉丸有(2)个肉丸,但无法订购(1)个肉丸,因此如果有人想要(3)个肉丸,我们可以按(2)个肉丸登记,但要加收额外费用。

    如果他们有真正的定制订单,POS 系统还可以选择添加一个 ADHOC 项目,并自定义名称、数量和价格。这不是额外收费,基本上是为这一个订单创建一个单独的菜单项。

    小贴士基本上是有自己名称的额外收费。重要的是要能在收据上看到 "小费 "的位置。信用卡终端允许输入无小费、几个常用百分比或自定义金额。还有一个收集现金小费的罐子。让我感到惊讶的是,很多人即使是自己点餐,也会加上小费。

    还有一种方法可以通过折扣减少订单总额。点击 "添加折扣 "链接即可。您可以选择使用固定金额或折扣百分比。

    这可以通过顾客持有的优惠券来实现,比如任何馅饼优惠 3 美元,或者企业主为大宗订单提供 5%的折扣并免除送货费。

    支持固定折扣和百分比折扣都是值得的。我在短时间内看到了许多同时应用这两种折扣的例子,我在课程中也是这样做的。最后,基于百分比的折扣会应用固定金额的折扣,因此实施起来并不难。

    创建带有名称和价格的自定义项目应该很容易,以备不时之需。如果有大订单进来,你不希望在现场苦苦思索如何做。如果您确定会出现这种情况,那么就值得对该功能进行编码。

    课程也是如此,当组织想要购买团队许可证时,就会出现这种情况。最后,我为课程创建了一个自定义套餐,比如说 25 个许可证,并通过正常的结账流程。我预设了一些许可证数量,但也可以添加自定义数量。

    无效和退款
    有时,您可能会创建一个尚未收到付款的订单,然后想取消它。如果您在 POS 系统的后端对菜单进行了调整,而您又想确保前端的价格是最新的,就会出现这种情况。

    一旦您选择了任何项目,他们特定的 POS 系统就会自动创建订单。我个人不喜欢这样,但事实就是这样。这增加了培训的难度,因为没有培训模式,您必须创建订单。

    在这种情况下,您可以取消或作废订单。它仍然显示为一个订单,只是被取消了,没有付款。这种审计跟踪很有用,可以帮助企业主保护自己,避免员工在按铃后取消订单,然后将现金收入囊中。

    任何有付款的订单都可能发生部分或全额退款。有时,您可能需要为某个特定商品或整个订单退款。在这种情况下,我们还可以在退款中添加备注,以便我们和客户了解原因。

    所有这些都会反映到打印出来的新收据上。

    一般来说,在处理资金问题时,信息越多越好。你需要一个涵盖每个事件的审计跟踪。您应该能够通过对事件的追踪,前后重新创建订单。

    Stripe 在这方面做得很好,如果你以前用过的话。您通常会将多个事件绑定到一个特定的付款中。所有的时间线都是一致的,事件数据(JSON)在发生时被锁定。

    客户信息管理
    收集信息非常有用,例如至少要收集取货人的姓名,以便将其添加到收据中。

    有了他们的电话号码也很方便,以防需要打电话提醒他们取货或发生意外情况。

    这对送货尤其重要。例如,您可能要把订单送到机场,但机场有 5 个不同的航站楼。也许电话接单的人不知道详细的目的地。

    在这种情况下,送货司机可以打电话给客户,安排见面地点。

    在这个地方,他们有一个单独的来电显示盒,可以显示来电者的姓名、电话号码和地址。这很方便。虽然并不总是正确或可用,但只要能用,就能节省大量时间。

    我学到的一点是,如果人们的电话习惯很差,而商店又很忙,就很难听清楚。此外,要从一个可能喝醉了的人那里获得完整的地址也不是一件容易的事!尽可能多地实现自动化会有所帮助。

    客户信息也会保存下来,这样如果再次输入相同的号码,地址就会自动填写。当然,使用手机时,地址有可能会发生变化,因此我们总是要求他们确认地址,但 95% 以上的情况下,这样做可以节省很多时间。

    除此之外,它还能帮助企业主了解更多关于谁喜欢什么的信息。如果你知道有人每周都点类似的披萨,那么你就可以问他们:"嗨,特里,你想和上次一样轻煮吗?这样就能建立良好的关系。

    在可能的情况下实现数据输入自动化是件好事,但如果是重要的数据,则应始终与另一方的人工进行确认。在这种情况下,送错地址的结果会非常糟糕。

    对于披萨店以外的在线订单,通过地理位置服务预先填写用户所在州和邮政编码是不错的选择,但也要允许用户编辑这些信息。尤其是在运送订单时。

    Stripe、Shopify 和 Square
    如果你仔细阅读这篇与 "订单"、"产品 "和 "客户 "对象相关的文章,就会发现这与 Stripe、Shopify 和 Square 用于接受数字和实物商品付款的 API 并无太大区别。

    当然,这篇文章只是触及了需要思考的表面问题。我之所以写这篇文章,是因为我对在披萨店工作的短暂经历感到兴奋。我喜欢思考优化工作流程和自我改进。

    我简直就是 "为披萨而工作 "的典范,但这是好事。

    不过说真的,我真的大开眼界,意识到良好的用户体验是多么重要,尤其是在一个相当繁忙的地方,在压力下。每一个操作都应该有目的,如果你可能会忘记一些事情,或者你不得不考虑一下,这就是一个很好的机会,看看你可以如何改进工作流程,使其无缝衔接。

    就我个人而言,如果我要建立一个销售点系统,我会使用他们的应用程序接口作为灵感,甚至直接使用其中的一个。现代的 POS 系统最终可能基本上就是一台安装在收银机上的 iPad。

    我简直不敢相信,我只是在一个实体店呆了一会儿,就学会了如何分解 "接受订单 "的问题。我强烈建议任何人在一生中至少体验一次。

    详细点击标题