You can maintain intended prices across delivery channels if the systems involved support the pricing rules you need and you know what each sync replaces. The critical question is whether a channel-specific price survives a later update from your POS or menu manager. Do not assume it will: ask for the behavior to be demonstrated for each channel, location, and POS combination you use.
Start with a signed price sheet, not a list of features. Record the base price, each intended override, and the system responsible for publishing it. Then simulate a base-price change and a resync before you rely on the integration during service.
Document the base price and channel overrides
A base price is the starting price you choose for an item at a particular location. A channel override is a deliberate different price for that same item on a particular ordering channel. The override might be a fixed amount or follow a rule, but the result customers see is what matters.
List your actual locations and channels separately. A burger sold for one price at your downtown counter may have a different base price at your airport location. An override for one delivery channel should not be treated as a rule for every marketplace or for direct online ordering.
Also list item identifiers, sizes, modifiers, and variations. Two menu entries with the same name are not necessarily the same item in the systems being connected. Decide whether an extra patty, a large drink, or a combo substitution has its own channel price or follows the base menu.
The worksheet below is hypothetical. It covers one location and one item; the amounts are menu prices, not revenue or operating costs. It does not include payment fees, marketplace charges, delivery costs, discounts, sales tax, or other fixed, variable, or exception costs. The intended values are a policy to test, not a claim about what any integration supports.
| Location and item | Channel | Base price | Intended published price |
|---|---|---|---|
| Oak Street; chicken bowl | POS/counter | $12.00 | $12.00 |
| Oak Street; chicken bowl | Direct online ordering | $12.00 | $12.00 |
| Oak Street; chicken bowl | Delivery channel A | $12.00 | $14.00 |
| Oak Street; chicken bowl | Delivery channel B | $12.00 | $13.50 |
For channel A, the intended override is $2.00 above the base; for channel B, it is $1.50 above. Those differences describe the current prices only. Before testing, the owner must choose whether each override is a fixed published price or an amount that should move with the base. Those policies produce different results when the base changes.
For example, if the base rises to $12.50, a fixed $14.00 channel A price stays at $14.00. A policy of base plus $2.00 produces $14.50. Write the chosen rule beside the row; do not leave the vendor to infer it from the current prices.
Find out who owns each price and what sync replaces
For every row, identify where the price is entered, where it is stored, and which system sends the value to the customer-facing menu. These may be three different places. Ask which system wins if two people edit the same item, and whether a manual channel edit lasts through the next scheduled sync, a full menu publish, or a reconnection.
Use these questions with the integration provider and, where needed, the POS and channel providers:
- Can the system hold a separate price for this specific location and channel? Is it a fixed value, a formula, or a manual edit?
- Does a routine sync replace the entire item or only fields that changed? Does a full republish behave differently?
- Can an override be preserved when the base price changes? What happens if an item is deleted and recreated?
- Do modifier and variation prices follow the same rules as the main item? How are missing or unmatched items reported?
- Where can staff see the last published value, sync status, and any rejected update? Who receives an error and who fixes it?
Ask for a demonstration using your exact POS, channel, and location setup. A statement that a provider connects to a channel does not by itself establish how that connection handles price overrides. Fleksa's restaurant integrations directory distinguishes live connections from those available on request. Availability and setup still need to be confirmed for your restaurant.
Separate supported actions from manual work on the worksheet. If a staff member must re-enter an override after every full publish, note that step and its owner. It may be workable for a short menu that changes rarely. For a large menu with frequent changes, the same process creates more opportunities for an old price to return.
Consider where the item enters the workflow as well. A restaurant POS system may be the place your team maintains counter prices, but confirm whether it is also the source of channel prices in the proposed setup. If there is an intermediary between the POS and channels, ask which system's values it sends and which updates it can prevent or modify.
Simulate a change and a resync safely
Agree on expected results before anyone runs a test. Use a vendor test environment and a simulated order flow that cannot charge a real card, send a guest message, or dispatch a courier. Use fictional item and order details, with no private customer data. If the provider cannot isolate the scenario safely, review a demonstration or documented limitation rather than placing a live practice order.
For the Oak Street worksheet, suppose the agreed policy is a fixed $14.00 price on channel A and a fixed $13.50 price on channel B. The expected results are:
- Publish the initial menu in the test environment. The counter and direct prices should be $12.00; channels A and B should show $14.00 and $13.50.
- Change the base price to $12.50. After the normal sync, the expected counter and direct prices are $12.50. The fixed channel prices should remain $14.00 and $13.50.
- Run a full republish or resync if the setup supports it. Check the published values again, including a modifier and an item variation you actually use.
- Create a simulated order with a unique test identifier. Match the source order to the POS and kitchen result, including the item, modifier, and total. Keep the test isolated from real payments, messages, and dispatch.
- Try supported exception handling, such as a rejected update or an unmatched item, and record who is alerted and how the issue is resolved.
Record the observed result beside each expectation, along with the time, action, and system screen where it appeared. If channel A returns to $12.50 after a resync, the test has identified a mismatch with the fixed-price policy. Ask whether configuration can change that behavior or whether re-entry is required. Do not mark the scenario passed merely because the first publication was correct.
Run a separate case if you want a base-plus override instead. For channel A, base plus $2.00 would mean an expected $14.50 after the base rises to $12.50. Do not apply that expectation to the fixed-price case. An intentionally unsupported action is a documented limitation, not a failed feature that every vendor must provide.
A simulation checks the behavior without affecting guests. A live service pilot is a separate operational decision: use your approved menu and normal service controls, assign staff to monitor results, and agree on a rollback procedure first. Do not use live guest orders or real charges as practice transactions.
Sign off the price sheet and make the buying decision
Expand the worksheet to cover each location, item, variation, and channel in scope. For each price, add the owner, the override rule, the system where staff make changes, the expected sync behavior, and the latest observed result. Include the date and the person authorized to approve the price. A manager's sign-off makes the sheet a reference for both the integration setup and later menu changes.
Compare the signed values with both the published channel menu and the POS. They may intentionally differ, so a mismatch is not automatically an error. It becomes a problem when the difference does not match the approved policy, or when staff cannot tell which value will be sent on the next sync.
Give every unresolved row an owner and a next decision. For example: the restaurant manager confirms whether channel B should stay at a fixed $13.50; the provider demonstrates what a full republish does; the menu lead records the manual re-entry step if preservation is unavailable. Set a date to revisit the row before launch rather than letting an unknown become an everyday task.
Choose the setup that can carry out your stated policy with an operating process your staff can sustain. If fixed overrides survive the tested syncs, the POS-led workflow may fit. If they do not, a manual process may still fit a small, stable menu, provided someone owns it and checks the published prices after updates. If neither route meets your needs, ask about another configuration before committing. The guide to direct POS integrations and middleware can help frame that broader choice.
Bring your channel list, signed price sheet, and test cases to a Fleksa integrations demo. Ask the team to confirm availability for your location and show how your POS and channels handle each override and resync.
Frequently asked questions
Will changing my POS price change every delivery price?
It depends on the connection and its settings. Ask which values each sync sends and test both a normal update and a full republish against your approved channel prices.
Should I use fixed overrides or a base-plus rule?
Use the rule that matches your pricing policy and that the proposed setup can support. A fixed price stays at its set amount; a base-plus rule changes when the base changes. Document which rule applies to each channel.
What should I do if an override is overwritten?
Compare the published price with the signed sheet, correct it through the approved process, and record the sync action that caused the change. Ask the provider whether the behavior can be configured or requires a recurring manual check.
