Yes, a kiosk may be able to accept a choice before an item is weighed, but that does not mean it can complete the sale at the final price. The answer depends on how the kiosk sends the order, when the guest agrees to the amount, and how payment is handled after weighing. Ask the vendor to demonstrate the whole transaction before you buy.
For an owner, the decision is whether to use an estimated price, sell a fixed portion, or send the guest to a staff member to finish the sale. Each can work under different conditions. The right choice is the one your guests can understand and your counter team can complete during a rush.
Start with the counter handoff
Picture a guest ordering sliced meat, salad, or another item whose exact weight is determined at the counter. The kiosk knows the item and any selections the guest made. It may not know the amount to charge until an employee weighs the portion.
That gap creates two separate questions: can the order reach the person preparing it, and can the guest approve and pay the final amount? An order ticket alone does not settle payment. Likewise, a payment screen does not tell the counter how much to serve.
The owner or manager should decide what guests are actually asking for. Is the guest choosing an approximate weight, a maximum spend, or simply asking staff for help? Write down what the counter must see: the item, requested portion or spending limit, preparation choices, and any instructions about substitutions. Also decide who checks the final weight and who tells the guest the final price.
Review the complete route from kiosk to counter with both your counter lead and whoever manages the restaurant POS system. If the kiosk sends a request but staff must re-enter every detail at the register, include that work in your decision. If the guest has to repeat their choices, the kiosk may add a step rather than remove one.
Compare three ways to take the order
Use this worksheet to choose a starting workflow. The table compares what the guest sees with the action still required at the counter; it does not assume that a particular kiosk supports any of these methods.
| Approach | Guest sees | Counter action | Best fit or limit |
|---|---|---|---|
| Estimated price | A requested amount and a clearly labeled estimate | Weigh, confirm the final amount, and complete payment using the agreed process | Useful when portions vary; unsuitable if the system cannot handle the final amount or guest approval |
| Fixed portion | A defined portion and price before ordering | Prepare the stated portion and handle any mismatch under the store policy | Useful when portions can be standardized; unsuitable if guests expect exact custom weights |
| Staff-led sale | A request or directions to order at the counter | Take or retrieve the request, weigh, quote the final price, and take payment | Useful for complex orders; retains more staff involvement |
Estimated price
An estimate can let the guest choose an approximate quantity while leaving the actual amount open until weighing. The critical issue is what happens when the actual price differs. Ask whether the order remains unpaid, whether a payment authorization is involved, and whether the system can collect the approved final amount. Do not assume that a payment taken at the kiosk can be adjusted later.
Make the guest-facing language clear enough that an estimate cannot be mistaken for the final charge. Decide what happens if the final price exceeds the guest’s limit: reduce the portion, ask for approval, or cancel the item. The vendor should show how the chosen response is recorded and how staff know what to do.
Fixed portions
A fixed portion moves the weight decision into your menu setup. For example, you might sell a named portion at a stated price and train staff to prepare it consistently. That makes the amount visible before payment, but it changes the offer: a guest seeking a precise custom weight may not be satisfied.
Agree on how staff will handle a portion that cannot be prepared as described. If the portion is unavailable or materially different, the team needs a way to pause, substitute, or cancel rather than quietly send something else.
Staff-led sale
The kiosk can serve as a starting point, with a staff member completing the weight and payment steps. Ask whether it can transmit an unpaid request and identify it at the counter, or whether the guest must order directly with staff. Either way, this approach is often easier to explain for unusual cuts or guest requests, but it does not eliminate the counter conversation.
Keep this comparison separate from a general kiosk return-on-investment calculation. The kiosk break-even guide can help you assess the wider purchase after you know which workflow is workable.
Run a hypothetical order through the worksheet
The following values and workflow are hypothetical. They illustrate what to ask a vendor to demonstrate; they are not claims about Fleksa or any payment provider.
A deli sells an item for $16 per pound. A guest requests approximately three-quarters of a pound, so the kiosk displays an estimated item price of $12. The counter weighs a portion at 0.8 pound. At the same rate, the final item price is $12.80. The difference is $0.80.
These amounts cover the item price only. They exclude tax, payment processing, fixed kiosk and software costs, and exception-handling labor. They are not an all-in operating cost. The example assumes the vendor can keep the request unpaid until the final amount is approved; verify that assumption rather than designing your process around it.
- Guest makes a choice. The guest selects the item and an approximate weight. Expected result: the screen shows $12 as an estimate and explains that the final price follows weighing. The guest is responsible for reviewing the request.
- Counter receives the request. Expected result: staff can identify the item, requested weight, and preparation instructions. The counter employee is responsible for finding and preparing it.
- Employee weighs the portion. Expected result: the employee records or communicates 0.8 pound and the $12.80 item price. Ask whether this happens in the kiosk system, the POS, or another supported step.
- Guest approves the final amount. Expected result: the guest is shown the final amount before agreeing to pay. The employee is responsible for obtaining approval through the supported process. Ask how that approval is captured and what the guest sees.
- Payment is completed. Expected result: the payment record matches the approved final amount, with any other charges shown separately. The cashier is responsible for completing the payment and confirming the order status.
Now change one condition: the guest does not accept $12.80. The counter employee should know whether to reduce the portion and calculate a new amount, or cancel the item. The guest must approve any revised final amount. Ask the vendor to show how the order and payment records remain understandable after either choice.
Also check the kitchen instructions. If the guest requested a particular preparation, does that instruction stay attached after the weight or price changes? If a counter employee has to write it down separately, decide whether that is acceptable at your busiest time.
Set a pass-or-fail test before purchase
Give each vendor the same item, requested weight, preparation instruction, and exception. Ask for a demonstration in a sandbox or another safe practice environment. A simulated check must not create a real payment, send a guest message, or dispatch a courier. If the vendor cannot provide that environment, ask how it will demonstrate the steps safely before you move to any live pilot.
- Order entry: Pass if the guest can make the intended request and understand whether the displayed amount is an estimate. Fail if the screen presents an estimate as a final price or cannot capture the required choice.
- Counter handoff: Pass if the responsible employee can identify the request and its preparation instructions. Fail if the instructions disappear or the order cannot be matched to the guest without an unacceptable manual workaround.
- Final amount and consent: Pass if the supported flow gives the guest a clear final amount and a chance to approve it before payment. Fail if the team cannot explain how approval and the final charge are connected.
- Exception: Pass if staff can handle a declined final amount by following a demonstrated revision or cancellation process. Fail if an unwanted item or charge remains without a clear resolution.
- Manual recovery: Pass if staff know how to finish or cancel the order when the kiosk-to-counter handoff fails, and how to prevent a duplicate sale. Fail if recovery depends on guessing the order or payment status.
Ask the vendor who supports each part of the workflow: kiosk software, POS, payment processing, and hardware. Who should your shift lead call if an order is visible at the kiosk but missing at the counter? What information will support need, and can staff see enough status to decide whether to retry or switch to a counter sale?
For a live service pilot, agree on the supported configuration, staff responsibilities, guest communication, and fallback before accepting actual orders. Unlike a simulation, a live pilot can involve real guests and payments, so use the vendor-approved process and monitor the handoff closely. Do not treat a successful practice run as proof that every service condition is covered.
Compare written quotes for hardware, installation, software, processing, and support alongside the labor needed for the chosen workflow. Check Fleksa plans for current pricing; the plans page was checked in November 2026. Ask for a written quote for your configuration and confirm which costs are included or separate.
Fleksa’s restaurant kiosk page describes menu browsing, customization, order review, and possible suggested add-ons. For this purchase, ask specifically how the kiosk and restaurant management software would handle an unpaid weight-based request, final guest approval, and payment in your setup.
Next step: Compare your kiosk requirements with Fleksa. Bring the worksheet and ask for a demonstration of your chosen flow, its exception, and feature availability before requesting a final quote.
Frequently asked questions
Can a kiosk charge the final price after an item is weighed?
That depends on the kiosk, POS, and payment configuration. Ask the vendor to demonstrate how the final amount is entered, presented for approval, and paid. Do not assume an initial kiosk payment can be changed later.
Is a fixed portion the same as an item sold by exact weight?
No. A fixed portion has a defined offering and price; an exact-weight sale uses the actual measured weight to determine the amount. Choose fixed portions only if they suit your menu and guest expectations.
What should staff do if a guest rejects the final price?
Use a documented process to revise the portion or cancel the item, then confirm the order and payment status. Ask the vendor to demonstrate those steps and show how the guest approves any revised amount.
