What Should Be Agreed in Writing Before Your POS Setup

Define the agreed scope before the first click

Before your new POS is set up, you should have one thing in writing first: what is actually supposed to be set up. That sounds obvious, but it is the most important protection against misunderstandings. If the only note says “new POS for restaurant,” the decisive details are missing. Do you only need counter sales, or table service as well, multiple areas, payments at the table, kitchen and bar output routes, split bills, roles for shift leads and service staff, and daily closing? The more precisely the scope is described, the easier it is to check later whether the setup really fits your operation.

What helps here is not a legal special-purpose document, but a clean implementation record written in everyday language. It should state, for example, which workstations are planned, which parts of the business will be mapped, and which functions are actually meant to be used at launch. In BonZumo terms, that means article management, table areas, roles, payment and printing setup, and closing should not just be discussed verbally, but named one by one. Then your team can later tell whether something was forgotten or was simply never agreed in the first place.

Name the devices and workstations clearly

You should also fix in writing where work will happen in your business and which devices have which job there. In many projects, disputes do not start with the software itself, but with vague ideas like “one POS at the front and something for the terrace.” Better would be: one counter workstation, one service workstation, one table plan for the dining room and terrace, one output route for the bar, and another for the kitchen or kitchen station. If you have several areas, every area should be named explicitly.

That matters especially because BonZumo works with location and area context. In the table plan, your team sees which service area is meant. For orders and output, it is not about some generic ticket, but about the specific transaction at the correct table or sales point. For setup, that means you should clarify in advance where orders are taken, where they are prepared, where payment happens, and who works there. If you only phrase that broadly, you often discover at handover that the terrace is missing from the plan or that the desired output appears at the wrong station.

A typical example: a bistro orders two workstations and a terrace setup. At handover, it turns out that the indoor room and counter are configured, but nobody clearly wrote down whether terrace drinks should be sent to the bar via order-ticket printing, shown on a screen, or only remain visible to service staff. That is exactly the kind of gap you avoid when every device combination and every workstation is recorded in plain words beforehand.

Decide together how articles and the sales view should work

Before setup starts, you should describe in writing how your offer should appear in the POS. That is not only about the list of articles, but also about categories, favorites, menus, and how quickly your team should reach frequent sales items during service. In BonZumo, articles can be maintained and structured for sales. For you organizationally, that means deciding in advance which product groups you really need, which articles go live first, and which special cases are deliberately left out for the start. If you need variants, record that requirement explicitly and ask whether and how they can be represented within the planned setup.

It is also important to assign articles to the right workflows. Does a product belong in table service, in fast counter sales, or in both? Should a note be possible because guests often have special requests? Should menu courses be released one by one because kitchen and service work on a delay? If you only clarify those questions during training, the setup is often already too far along. Then a clear introduction quickly turns into a loose collection of later change requests.

You should also prepare your tax or accounting assignments internally instead of inventing POS logic on the spot during a meeting. The POS can only work cleanly if your article master data has been decided cleanly. If you are still unsure which products should be grouped together or kept separate, that is not a minor detail. It is an open point that should be named before go-live. Otherwise, you may later argue about whether there is an error or simply a product-range decision that was never made.

Describe table areas and output routes in concrete terms

For restaurants with service, it should be agreed in writing how your dining room should look in the system. BonZumo maps table plans and areas so your team can work in the spatial context of your business. That is exactly why it is not enough to state only the number of tables. You should record which areas exist, what they are called, whether the dining room, terrace, side room, or bar area are handled separately, and whether certain employees need personal table areas. These details directly affect how your team finds orders and takes responsibility in service.

The output routes are just as important. BonZumo can assign orders to the intended kitchen stations and printing rules. For that setup to match your everyday work, you need to decide in advance which articles go to which station. Drinks to the bar, hot food to the kitchen, desserts perhaps to another output point or to the same route as the cold kitchen. The key question is not what sounds technically elegant, but how your business actually runs. Who prints what, where is it picked up, where do questions arise, and which route really takes pressure off service?

So the written description should not simply say “connect kitchen and bar.” A better operational description would be: drinks category to bar, hot food to kitchen, check output by area, release menu courses one by one if needed. That way, at handover you can immediately see whether the setup fits your walking routes or whether some generic standard assumption was implemented instead.

Set payment workflows separately from ordering workflows

Before setup, it must be clear in writing how payment works in your business. Order status and payment status are different things, and that separation should be discussed properly in advance. BonZumo keeps sales, partial payments, tips, and open amounts together within the same transaction. For that to work in daily operations, you need to define beforehand which payment methods are planned, whether split bills are needed, whether they should be split by article or into equal shares, and at which point card payments should happen in the workflow.

If you want to work with connected terminals, the question of responsibility also belongs in the record. Who handles provision, which devices are planned, at which workstations they should be used, and which tests you want to see before the first opening day. Clarify the help routes and any possible fallback for the payment workflow you intend to use before service begins. You should clarify that with the provider and the technical side in advance instead of silently assuming it.

In practice, one simple sentence in the implementation record helps a lot: payment at the table or at the counter, intended payment methods, tip capture, invoice details if needed, and the procedure for group bills. Later, that makes it easier to understand whether the setup supports your real payment moment or whether only the ordering part was planned properly.

Keep roles and permissions small, clear, and suitable before launch

It should also be agreed in writing who may see and do what in the POS. In a new implementation, permissions are often granted too broadly because people want to “leave everything open for now.” In everyday business, that quickly creates uncertainty: who may void, who may use closing functions, who may change articles, and who may only sell. BonZumo works with roles and access rights. That is only truly helpful when those roles are not named abstractly, but broken down to fit your actual operation.

For the start, a few cleanly defined roles are often enough. A service employee needs different views from a shift lead or the office. If you write those differences down beforehand, the handover becomes much clearer. Then your team does not just see menu items, but responsibilities. That also prevents later discussions such as “I thought every shift lead could change everything” or “We did not realize article maintenance was not supposed to happen on the service device.”

The goal is not the greatest possible complexity, but the smallest permission structure that works. It is better to start with a clear initial setup and approve expansions consciously later. Especially in the first days of operation, that helps you distinguish between handling mistakes and real setup mistakes.

Plan training by tasks, not by menus

Before setup, or at the latest before handover, it should be agreed in writing who will be trained, on which workflows, and with what goal. “Instruction included” is far too vague. For a reliable start, it must be clear whether your team should only learn ordering and payment, or also table moves, split bills, tips, output routes, and daily closing. Otherwise you may later believe a topic was included while the other side only meant basic operation.

With BonZumo, training works best when it follows real tasks: take an order, find it again at the table, pass it to the right station, record payment, separate tips correctly, identify the open amount, and close the day. That way, your team does not just see screens, but connected transactions. That shared record is crucial in everyday work, because questions rarely arise in isolation. A table has ordered, has partly paid, needs a receipt, and should only be closed once the remaining amount is settled. Training should prepare for exactly that.

So it helps to write down training by target group. Who learns only sales and payment, who also learns closing and corrections, and who takes over article management or area settings. If you make that split in advance, training time and expectations become much more realistic. Without it, you often end up with the feeling that “we were shown something, but we did not learn our business.”

Make acceptance criteria measurable instead of emotional

One of the most important questions before setup is how you will recognize that the implementation is good enough for launch. Without such criteria, handover quickly turns into a matter of feeling. Then one side says the POS is working, while you feel the business is still not ready to operate. A better approach is to agree in writing which concrete checks you want to go through together at handover. Not everything has to be perfect, but the decisive workflows should be verifiable.

For BonZumo, those criteria can be very practical. Can the agreed articles be found? Are the table areas correct? Do drinks and food go to the intended output points? Does a group bill work in the form you need? Is tip capture kept separate from the sales amount? Is closing accessible and understandable for the responsible role? Questions like these are far better than general statements such as “system fully configured.” They turn an opinion into a checkable process.

This helps enormously, especially for a new opening or a change under time pressure. If one point remains open, that does not automatically mean everything has failed. But it does mean you can see together what still has to be solved before opening and what can be treated as a later change request. That distinction prevents many unnecessary conflicts.

Separate open points, later wishes, and approvals cleanly

Before setup, you should also agree in writing how open points and later wishes will be handled. That is not a formality. It protects both sides from the classic sentence: “We thought that was included.” If during implementation you realize that you also want an extra area, different printing logic, or more roles, that is normal. It only becomes a problem when nobody distinguishes between the originally agreed scope and a new request.

That is why your record should contain at least three pieces of information for every open point: what exactly is missing, who provides the decision or information, and by when it should be discussed. Especially for articles, devices, or payment routes, setup often depends on details that are still missing from your business. In that case, it is fairer and more useful to make that visible than to argue later about delays. For some questions you still need internal decisions; for others, feedback from the technical side, the payment partner, or your accounting advisor about the intended assignment.

Just as important is a simple approval mechanism for changes. Not as a complicated contract system, but as a clear routine: name the change request, understand the effect, then approve it consciously. That way, it remains understandable why your system looks different today from the way it did in the first meeting. And at handover, it becomes much easier to distinguish what belonged to the launch scope, what was added later, and what was deliberately postponed.

Document the handover so your team can keep working with it

In the end, everything should be documented in writing in a way that not only the setup team, but also your own staff can work with later. Good documentation is not a file for a drawer. It is an operational foundation. If BonZumo maps articles, table areas, roles, payment routes, and closing in your business, then your business should be able to find those decisions again later. Otherwise every new shift lead starts from zero whenever a question comes up.

In practical terms, that means recording the final configuration in clear language. Which areas exist, which roles may do what, which payment routes are planned for the start, which output logic applies, and who checks closing. Add which points are still deliberately open and which people are responsible for them internally. That turns setup from a one-off technical appointment into a traceable handover into your ongoing business.

If you take only one idea from this topic, let it be this: before POS setup, not every detail must be perfect, but everything essential must be distinguishable in writing. What will be delivered, how it will be configured, who decides open points, who will be trained, and how you will jointly recognize that the start is working. That is exactly how you avoid the real trouble later: not the software question, but the dispute about what was actually agreed in the first place.