Which Features Are Available Today and What Is Only Planned

Only what you can see in a real workflow today is available for your decision

BonZumo currently connects POS and service, payments with bill splitting and tips, reservations, staff tasks, inventory, daily closing and preparation of a DATEV file export. For additional apps, integrations or special modules, clarify the current status for your setup. In short: a feature is only available when it can be shown to you today in the intended form and your team can run through a real workflow with it. Announced or planned is everything that is only described as a later app, a future integration, a coming extension, or an additional function that is not yet set up. If you are assessing points that matter to the purchase decision, you should keep these two categories strictly separate.

BonZumo already has usable areas today for POS and sales, payments, inventory and item maintenance, team organisation, reservations, reporting, and certain configured integrations. That is a good starting point, but it is not a blanket confirmation of every single idea that may also come up in a sales conversation. An existing product area and your specific must-have workflow are not the same thing. In the end, what matters to you is not whether a topic exists in general, but whether your exact critical path already runs cleanly today.

The offered setup has to match your real must-have workflow

So do not just ask, “Is there a module for that?” Ask more precisely, “Can I actually carry out my most important workflow with it today?” If your business depends heavily on table service, for example, you may need a floor plan with tables and sections, order entry with notes, handoff to kitchen and bar station, separate release of courses, and finally a mixed payment with split bills. That exact path should be demonstrable. A general statement such as “service, kitchen and payments are of course included” is not specific enough for a serious decision.

BonZumo can generally cover those core paths. The team works with a table and section plan, can take orders in table context, save notes, send tasks to configured kitchen or bar stations, release menu courses one by one, and split bills by item or into equal shares. In the payment flow, sales amount and tip remain visible separately. For your decision, what matters is not seeing slides or a roadmap, but the complete path: which information appears at the workstation, what the server does next, and which question or decision becomes easier because of that.

Clear core areas are usable today, but not every extra idea is automatically included

In day-to-day POS work, a connected workflow is available today. Items are recorded in table or counter context, frequent sales can be reached through favourites in fast sales, order notes stay attached to the transaction, and the bar or kitchen station receives tasks through configured routes. That helps your team especially when a question comes up later. Instead of relying on memory, paper slips, or shouted messages, they can start from the actual transaction: what was ordered, for which table, with which note, and at what processing stage.

The other areas are also concrete working environments. Reservations are managed with table planning, capacities, and guest details. In the team area, you can structure shifts, working times, roles, and certain documents. In inventory and item maintenance, you have items, recipes, base recipes, stock information, suppliers, and stocktaking. For follow-up work there are reports, daily closing, cashbook, archive, and the preparatory DATEV booking batch export. These are real workspaces. But if someone also mentions a special app, a new outside service, or an extra automation, you need to check that point separately rather than mentally counting it as part of the existing base scope.

A demo should show your difficult case, not only the easiest standard path

Many misunderstandings happen because the demo only shows a smooth ideal case. For your decision, the difficult case matters more. If you want to know whether payments and bill splitting really fit your operation, do not only ask for a single payment at the counter. Take a situation with four guests instead: two pay for their own items, one pays an equal share by card, another adds a tip to the total, and a balance still remains open. Then you can immediately see whether the team can recognise what has already been paid, which table amount is still open, and when the transaction can actually be closed.

The same principle applies in other areas. In reservations, do not only look at a simple booking for two people. Ask to see a group that arrives late, changes table area, or turns out to be larger than announced. In inventory and item maintenance, do not only open an item price. Bring a real question from your business, such as how a recipe with quantities is maintained and which information you get from it for material cost and selling price. A function is only truly available for you when it gives orientation in your problem case, not just in a polished demo mode.

The offered version has to be named, not just the topic area

In the conversation, make sure people are not only talking about broad topic areas but about the actual setup that is intended for you. If you are told that reservations, team management, or inventory are available, that is still too broad. For your internal decision, you need a more precise statement about what your team will later actually see and use. Does the reception view show table context with areas and guest data? Does the shift lead see published and planned shifts? Do you see ingredients and quantities in a recipe? The more clearly these working views are described, the lower the risk that a large umbrella term creates expectations that should never have existed in daily use. Record every point that affects your purchase decision with a clear status: usable today, still to be checked for your project, or planned for later. Note the offered configuration in which the workflow was shown to you.

This is especially important for individual points that matter to the purchase decision. A hypothetical example: you do not need “a shop integration” in general, but specifically a sync with a target system so that orders arrive there without double entry. If all you hear is that such an extension may be available soon, then you do not have a workflow that is available today. At minimum, you are missing the named setup, the data handoff, and the check in the target system. As long as these points remain open, treat the add-on as planned, even if the broader product area sounds strong.

With integrations, the handoff into the target system matters, not the word integration

You should be especially careful when checking integrations. BonZumo has concrete integration paths for certain tasks, such as terminal integration for card payments, an embedded booking page for reservations on your own website, or the DATEV booking batch export for preparatory accounting. These are important handoffs, but for your decision the label alone is not enough. You need to know what the route looks like in everyday work and which later steps still remain manual in your organisation.

So always ask along the real handoff. Where does the data originate? Who triggers the next step? What does your team see in BonZumo, and what does the other side see? What is transferred directly, what is only prepared, and what does somebody in the business still have to check afterwards? With the DATEV export, for example, the point is preparing a booking batch and assigning it in the intended export path, not running full accounting inside the system. With payments, you must distinguish between the payment flow and an open order status. With reservations through the website, what matters is which times, areas, and fields have been configured. That is how you quickly recognise whether an integration promise is solid today or still needs further clarification.

You should leave limitations visible on purpose instead of smoothing them away

A good purchase decision does not become better by politely skipping over limitations. Quite the opposite: precisely where you have only seen part of a function, you should leave the boundary visible. If a workflow can be clearly shown today in table service, that does not automatically mean every similar action works identically in every other interface. If stocktaking supports counted quantities and evaluations, that does not yet mean every desired expected-versus-actual comparison or every automatic consumption relationship is already ready in exactly the way you might want it.

This openness helps you organise your decision. You can then judge much more cleanly whether the existing scope is already enough for you or whether the gap is critical. Perhaps a limitation is irrelevant for your start because it only affects a rare edge case. Or perhaps it hits exactly the task your team needs twenty times a day. Without a visible boundary, both cases can look similar on paper. With the boundary visible, you can assess it properly: is this a small issue we can handle operationally, or is it an open problem that would delay the start?

Planned functions belong in a separate part of the decision, not in the core operation

If someone offers you a future app, a new add-on module, or another integration, that point should be treated separately from the functions you can already use today. The most practical approach is to sort everything into three simple classes: usable today in a real workflow, still to be checked separately for your project, or only intended for later. That keeps it clear what your business can really rely on at launch and what is only a future option.

That is not excessive scepticism. It is normal operational logic. You would not build your shift plan around an employee who might start next month. In the same way, you should not base a software decision on a function that cannot be shown or set up today. If the planned point is not critical for launch, you can note it as a future option. If it is essential to the purchase decision, then the decision should only be made once that exact workflow has been shown to you and checked for your environment. Anything else is closer to hope than planning.

If a gap remains, you need an honest interim process with a realistic effort estimate

It often happens that the base scope fits well, but one extra point is still unresolved. Then the goal is neither to reject the whole solution nor to talk the gap away. What helps is a sober interim decision. For example, your restaurant urgently needs table service, kitchen station handling, payments, reservations, and daily closing. These paths look convincing in the demo. Only one special outside connection that you want later is not yet fully clarified. Then you should decide whether you can organise that step manually for a while without creating too much duplicate work, too many mistakes, or guest frustration in daily business.

What matters is describing that interim solution concretely. Who does the extra step? How often does it happen each day? Which information has to be maintained twice? How will you notice that the interim process is no longer sustainable? That turns a vague “we will do it manually for now” into a real operational decision. BonZumo can already give you a connected workflow in many core areas. That is exactly why it makes sense to keep the remaining open points clearly limited instead of acting as if they will somehow disappear on their own during live operation.

Always write down the function, the workflow, and the open points still to clarify

So that there is no later dispute about what was actually promised, do not document purchase-critical points as broad collective labels. Write down the exact workflow instead. For example: table and section plan for service, order entry with notes, kitchen or bar stations and kitchen monitor, releasing courses individually, splitting bills by item or equal shares, tip inside the payment flow, reservations with table and capacity context, shift planning and time tracking, recipes and stocktaking, daily closing and preparatory DATEV export. Wording like this helps you much more than a short sentence such as “everything for hospitality included”.

Next to that, openly note what still has to be checked. For example: the exact terminal setup at the table, the embedded reservation flow on your website, the target system of a desired integration, the internal process for tip allocation, or the handoff into your accounting organisation. These notes are not a weakness in the offer. They protect your decision. They show that you are distinguishing between functions that are usable today and handoffs that are still open. That exact separation prevents a non-binding future point from later being treated unnoticed as a fixed operational foundation.

Before approval, test the whole business day once more with your team mindset

Before you give final approval, it is worth doing one last review along a real day in your business. Start with preparation: reservation situation, table plan, shift allocation. Then move into service: order taking, notes, kitchen and bar station handling, repeat orders, course control. After that go into settlement: mixed payments, tips, invoice details, open remaining amounts. Finally look at follow-up work: daily closing, reports, cashbook, export preparation, and the question of which numbers you need to find again the next morning. BonZumo is especially suitable for this kind of review because several areas work together in context rather than standing next to each other as isolated features.

If in this final round one point is still explained only as a future picture, then treat it exactly that way. For your decision, available today means what you can now see, understand, and plan for organisationally in the intended workflow. Only announced or still open is everything that is supposed to come later or whose concrete implementation in your environment is not yet clear. This simple but strict separation protects you from vague promises and lets you buy based on what your team can actually use tomorrow.