Handle a Changed Pickup Order Before the Customer Pays

Changing a Square pickup order before payment can mean two different things: revising a quote that has not become a checkout, or changing an order after a payment link exists. The assistant needs to identify which stage it is in before promising that the customer's change is complete.

Burki's optional pickup capabilities are still supported by Sandbox evidence rather than proven live restaurant operation. A practical evaluation should therefore focus on clear state handling and staff recovery, not on assuming an automatic order-editing experience.

Before checkout, replace the proposal

If the caller changes an item while the assistant is still preparing the quote, rebuild the proposal from the revised selection. Confirm the items, quantities, total, location and pickup time again before requesting checkout.

Do not keep the earlier total after adding a modifier or changing quantity. The caller's approval must refer to the current proposal. A correction to the order is not permission to charge or submit an unrelated version.

The Square setup guide explains the separate quote and checkout actions. A quote alone does not reserve stock or create an order.

After a link exists, inspect the existing checkout

Once checkout has been created, the customer may already have access to a payable link. Treating the changed request as a fresh quote without resolving that link can leave two competing ways to pay.

Use the supported status and cancellation controls rather than assuming that a prompt can mutate the existing checkout. If creation or cancellation is uncertain, inspect the original operation and provider result before making a replacement.

Square's checkout management guide documents provider controls. The existence of a provider operation does not mean every possible edit is available through Burki's current assistant actions.

A hypothetical extra-item request

Imagine a caller receiving an unpaid pickup link and then saying, “Add one more drink.” The assistant should first recognize that the earlier checkout already exists. It should not say the old link now contains the drink unless a supported result establishes that change.

The business may need to resolve the unpaid checkout through the available controls, then prepare and confirm a replacement proposal. The specific sequence should follow the current product and merchant process. If it cannot be completed safely in the conversation, staff should take over.

A clear interim response is: “There is already a payment link for the earlier items. That needs checking before a revised checkout is created.” This hypothetical example shows why the old link matters even though the customer says they have not paid.

Check payment again before cancellation decisions

The customer may pay while the change is being discussed. A status observed at the start of the call can become stale. Review the latest supported result before treating the checkout as unpaid.

Paid orders and refunds belong in the merchant's Square process. Do not describe removing a link as reversing a payment, or assume a successful cancellation request means every financial and fulfillment consequence has been undone.

If the customer has two links, explain which one is valid only after the earlier operation is resolved. Do not rely on “please ignore the first one” as the sole control against accidental payment.

Review what the caller hears and what staff see

The conversation should clearly separate requested changes, confirmed revised details and completed actions. Staff need the checkout reference, its latest status and the unresolved issue, not merely a note saying “customer changed order.”

Use a controlled Sandbox scenario to inspect these transitions. Browser practice simulates the actions and cannot demonstrate real link cancellation, payment status or restaurant acceptance.

The restaurant use-case page provides context for the intended customer experience. Pair it with a written change policy that explains when the assistant can continue and when staff must intervene.

Start with a single test case: a customer changes quantity after receiving a link. Trace every payable checkout and every spoken promise. The workflow is understandable only when both the caller and the operator can identify the final intended order without guessing.