What a POS-to-shop connection really needs to do

Do not buy the integration name, buy the data contract

A connection between your POS and online shop must do one thing above all: clearly define for each individual data type what goes where, when it happens, and what happens if something fails. A connector name on its own is not enough. If all you hear before buying is that “POS and shop are connected”, you still do not know whether products are created, prices updated, stock adjusted, vouchers recognised, or cancellations reported back cleanly.

For your business, the technical label matters less than the data contract behind it. You need clear answers to practical questions: Do new products need to be maintained once or twice? Does an online sale affect visible stock? Can the POS tell whether a voucher has already been redeemed? And what does your team see if a sync gets stuck? Only when those questions are answered is the connection actually useful in daily work.

In BonZumo, the important internal data areas already exist on a shared basis: product and price management, goods information, sales transactions, and configured voucher processes. But whether and how an external shop connects to that setup must be checked specifically for the connection you want. That check should not rely on marketing terms, but on real example processes from your operation.

First decide which system leads for each data type

The most important decision comes right at the start: where is the leading source? That should not be answered once for everything, but separately by data type. It may make sense for core product data to come from the POS, while shop-only text or shipping notes are maintained only in the shop. If you do not define this in advance, you almost always end up with duplicate maintenance, conflicting prices, or unclear responsibilities.

A simple example: you sell packaged specialties and vouchers online while maintaining prices locally in the restaurant. Then you need to distinguish between product name, internal product number, sales price, POS tax view, image, long description, shipping capability, and possibly variants. Not every field belongs in every system. The POS mainly needs to sell and handle transactions cleanly. The shop needs to present products, support search, and collect order information. A good connection links those tasks without mixing them up.

In BonZumo, you maintain products, prices, and goods information in the operational system context. Those records are the basis for sales, reporting, and, where needed, inventory work. If you want to connect a shop, you should therefore clarify field by field whether the value comes from BonZumo, stays in the shop, or has to be added manually. That is exactly what saves you later arguments about why something looks different online than it does at the POS.

Check product creation and price changes as separate directions

Many operators think about creating products first. In practice, ongoing price changes are usually more critical. A usable connection must tell you whether new products are transferred to the shop automatically, whether existing products are updated, and which changes are deliberately not transferred. Otherwise this happens quickly: the team changes a price in the POS, but the old amount remains online. Sales continue, but you collect questions and corrections.

So do not just ask for the initial setup to be shown. Ask for three everyday situations: create a new product, change a price, deactivate a product. Only then do you see whether the connection is really suitable for daily use. Also ask about the trigger. Does the sync start immediately after saving, after a delay, or manually? Any of those can be fine, but only if your team knows when a change actually becomes visible in the shop.

BonZumo supports structured product and price maintenance on the POS and admin side. For the buying decision around an online shop, what matters is whether exactly those fields are transferred in the connection you want. So do not just let someone show you a product screen. Ask for the full change path: before, edit, transfer, display in the shop, and feedback if something goes wrong.

Stock is more sensitive than master data because sales have immediate consequences

Stock is where you see fastest whether an integration is well designed. A price error is annoying; a wrong stock level may sell something you no longer have. That is why the connection must answer clearly whether stock is transferred at all, in which direction it moves, and what happens during simultaneous sales. Without that clarification, “stock synchronisation” is just a big phrase.

In hospitality, stock is not always the same as warehouse quantity. An online gift hamper is something different from a drink sold on site with recipe links behind it. So you need to check at what level the shop should track stock at all: individual sales item, physical inventory item, or only limited quantities for certain specialties. If those levels are mixed together, the numbers may look technically in sync but still be useless for running the business.

BonZumo gives you goods information, stock movements, and stocktaking as a basis for your internal inventory view. That helps with structure and control inside your operation. For the shop connection, you still need to clarify specifically whether an online sale changes the stock level you want, how reservations are handled, and how your team notices discrepancies. Do not rely on the phrase “inventory integrated”. Rely on a tested process using your own assortment.

An order is not the same as a payment, and both need to stay visible separately

A common mistake is to think that once a shop order arrives, the transaction is automatically complete. In real daily work, you need to separate the order, the payment, and the later fulfilment. The POS should make it clear what was ordered, whether a payment has been confirmed, and which step comes next. This matters especially when something is sold online but redeemed, handed over, or collected on site.

If you sell vouchers online, for example, you need more than a revenue signal. You need to know whether the voucher was created, what value it has, whether it has already been partly redeemed, and how any remaining amount appears in the POS process. Likewise, an open or failed online payment must not look as if the sale is finished. Otherwise you create avoidable friction at collection or reception.

In BonZumo, payment processes, open amounts, vouchers, and sales transactions remain clearly separated within the POS context. For configured voucher processes and for online gift voucher purchases, an appropriate payment setup is part of the intended process. For a general online shop, though, you need to clarify in detail which order and payment information actually reaches BonZumo and how your team handles it in daily operations.

Cancellations, returns, and corrections decide how stressful daily work becomes

An integration often looks polished in a demo as long as only new products and clean sales are shown. The real test starts with cancellations, returns, price mistakes, or duplicate orders. That is exactly where you need to push before buying. A good connection does not have to solve every special case fully automatically, but it must make clear what your team sees when something goes wrong and which manual step is required.

Imagine a guest buys a voucher online, pays, then calls because the email address was wrong. Or a shop order is imported twice by mistake. Or an online product is no longer sold in the business. If there is no defined process for such cases, you go straight back to spreadsheets, verbal handovers, and uncertainty. Then the integration saves time only in the sales pitch, not in real work.

BonZumo keeps transactions, timestamps, receipts, and authorised actions traceable together in the POS environment. That helps you handle corrections and questions on the exact transaction. But whether an external shop system passes cancellations, returns, or repeated syncs into that same level of traceability must be shown to you for the specific connection you want. What matters is that no unclear in-between state gets left hanging in the team.

Error states need to be visible and actionable for your team

The most important quality of a good connection may not be speed but clarity when something fails. If a transfer does not work, your team needs visible information: what was not transferred? Is it a product, a price, a stock level, or an order? Should someone wait, trigger it again, or deliberately intervene manually? Without that clarity, you create duplicate work and wrong assumptions.

So in a sales conversation, do not focus only on the ideal path. Ask to see the error display. Let them show you how a failed sync becomes visible. Is it only a technical log somewhere in the background, or can a responsible person in daily work actually see that action is needed? Good organisation also means roles and responsibilities here: who may check, who may correct, and who decides whether a transaction is transferred again?

BonZumo works in many areas with traceable transactions, roles, and access rights. That helps ensure not every person has to change everything. For a shop connection, build on that and define in advance who is responsible for transfer errors. Software alone does not replace that responsibility; it has to match your process and make visible where a decision is needed.

Rule out duplicate processing before you go live

An underestimated risk is duplicate processing. It happens when the same event is imported more than once or worked on from both sides at the same time. Then stock is reduced twice, vouchers are created twice, or sales are assigned unclearly. Precisely because these errors are rare, they are often noticed late. For you, though, they are expensive because they cost trust, time, and overview.

Before launch, you should therefore test repeated cases deliberately: create an order once, repeat the import, interrupt the connection and sync again, add a cancellation later, change a price shortly before another sync. This is not technical play for its own sake; it is basic operational reliability. Your team needs to know whether a second import is recognised and blocked or whether someone has to check it manually.

In BonZumo, transactions are designed as connected commercial processes, with links between sale, payment, and closing. That is exactly why it matters so much in a shop connection that external events are not blindly treated as new cases. For your specific shop, ask to see how unique assignments work and how the setup prevents a transaction from becoming economically effective twice.

Put the scope into the proposal, not only into the sales call

If you leave with only a verbal promise, you are missing the solid basis you will need later. A usable POS-to-shop connection should therefore be described in writing in the proposal or project scope by data type and by process. Not in programming language, but in clear operational sentences: products from A to B, prices in direction X, stock only for defined assortments, vouchers with this process, cancellations by that path.

A small test matrix before the decision is especially useful. It should list your key cases: create product, change price, low stock, online order, payment successful, payment still open, voucher sale, voucher redemption, cancellation, repeated sync. If a provider cannot discuss or demonstrate these cases clearly, the question is not whether you will have problems later, only when.

For BonZumo, the practical standard is straightforward: the relevant internal foundations for products, prices, goods information, sales transactions, and voucher processes are there. Whether your preferred shop connection builds on them in the depth you need must be clarified specifically for the planned shop and your workflow. Good preparation on your side means bringing real examples, defining responsibilities, and having the expected data contract written down.