On a busy Friday, a server moves two diners from the terrace to an indoor table. The kitchen has already started one meal, the drinks have been delivered and the diners want separate bills. Rain interrupts the connection between the terrace device and the main counter. The restaurant owner needs one reliable account of what was ordered, prepared, served and paid. A restaurant looking for POS system developers in Nairobi should put that account at the centre of the interview.
A restaurant checkout differs from a simple sale across a counter. An order stays open while staff add items, change tables, send instructions to different preparation stations and accept payment later. The relationship among these events matters as much as the final receipt. A developer who treats every order as one basket immediately paid may produce a fast demo that falls apart in the middle of service.
Imagine a fictional Nairobi bistro with a counter, a terrace, a kitchen station and a drinks station. The owner wants a POS extension or custom application that can coordinate floor service. Use the following rehearsal to judge whether a developer understands the operation, whether a standard restaurant product can handle it and where a custom build would justify its maintenance cost.
Walk through one service before talking about screens
Invite a floor supervisor and a kitchen lead to show the path of an ordinary order. The server identifies the table, records the dishes and sends them to the relevant stations. The kitchen acknowledges an instruction, prepares the food and tells the server it is ready. The diners eat and decide how to pay. At the end of the shift, the supervisor checks open tabs and unresolved differences. Each handover creates a real obligation.
Observe a busy period with the restaurant’s permission. Look for the places where staff shout an instruction, write on a slip or ask a colleague to remember something. A shouted request to hold the main course may represent an important timing rule. A handwritten note beside a drinks ticket may record a customer preference. The developer should recognise which informal actions deserve structured support and which are better left as human conversation.
Ask what the business needs to know during service. The kitchen needs the latest authorised preparation instruction. The floor supervisor needs to know which tables are waiting and which order lines have already been sent. The cashier needs to know which charges can be settled. A single label such as order open tells none of these people enough. The application needs distinct facts that remain connected to the same dining visit.
Use one difficult slip as the interview brief. Remove names and payment information. Describe a table move, a cancelled dish already in preparation and a guest paying for only part of the order. Give each shortlisted developer the same scenario and ask for a walkthrough. A sketch or annotated process is enough before a commercial agreement. You are evaluating reasoning about service, not asking for a free implementation.
Distinguish the table, the visit and the order line
Table twelve is a physical place. A dining visit can move from table twelve to table four. An order line describes a particular dish or drink for that visit. A bill groups charges for settlement. Treating these as one object creates familiar problems. Staff may reopen the wrong table, lose earlier kitchen instructions or duplicate a dish while attempting to divide the bill between guests.
Create a stable visit reference that survives a table move. The server can then shift the location without creating a new sale or resending every dish to the kitchen. The old table becomes available once the restaurant’s operating rule permits it. The visit retains its original order history and the current seating arrangement. Ask the developer to demonstrate the move while one dish is waiting and another has already been served.
Consider adjacent tables joining for a celebration. Sometimes the restaurant wants one service visit with multiple physical tables. In other cases separate parties remain responsible for their own tabs even while sitting together. Ask the owner to define when staff may merge visits, what information survives the merge and whether a supervisor must authorise it. A button labelled merge is only useful when everyone knows what will merge.
Follow a guest leaving early. The guest pays for a starter and a drink while the rest of the table stays. The dining visit remains open, two lines become settled and the remaining guests may order more. A system that closes the whole table after the first payment will force the server to recreate the outstanding items. Test the ordinary sequence of events rather than discussing bill splitting as a feature in isolation.
Send preparation instructions exactly once
A server sends a food order from the terrace. The connection pauses before the device displays confirmation. The server taps again. Two kitchen tickets for the same dish can produce waste, confusion and an argument about whether the customer ordered twice. Ask developers how they distinguish a retry of the same preparation instruction from a legitimate second order of the same dish.
Use a practical demonstration. Send one soup, interrupt the connection and retry. The kitchen should be able to identify the intended quantity and the status of the original instruction. Then order a genuinely additional soup for the same table. The system must accept this second business event without treating it as a duplicate. A rule that blocks all matching dishes from the same table would be just as wrong as printing every retry.
Separate saved locally, sent and acknowledged. A server may see a line on the phone even though the kitchen has not received it. Make the difference visible in language a server can act on. If the order cannot reach the kitchen, the restaurant needs a fallback and a way to reconcile it later. The application should not reassure staff that preparation has begun merely because a line was saved on a device.
Ask the kitchen lead what an acknowledgement means. It may mean that a station has received the ticket, that a cook has accepted it or that preparation has actually started. Choose the meaning and show it consistently. If printing a ticket is the only evidence of receipt, consider how the team detects a printer running out of paper. A digital success message alone cannot prove that someone in the kitchen saw the instruction.
Handle modifications after the kitchen has started
A guest asks to remove chilli from a dish. If the kitchen has not started, the server may amend the instruction under the restaurant’s rules. If preparation has begun, sending a replacement ticket without explaining the change can lead to two meals or an unsafe misunderstanding. Record the change as a distinct instruction, show what changed and identify whether the station acknowledged the revision.
Distinguish a modifier affecting preparation from an internal preference or a charge. Extra cheese may change both the instruction and the price. A request for sauce on the side may affect only preparation. A note to deliver a dish after the starter concerns timing. The menu setup should allow the business to recognise these differences. If the POS treats every modifier as unstructured text, reporting and kitchen clarity may suffer.
Include an unavailable option. The menu offers a side that runs out after an order was entered but before preparation begins. The server needs to discuss an alternative with the guest. Decide who can substitute the item, how a changed price is confirmed and what the station sees. An automatically substituted side could disappoint the guest or breach a stated preference. The system should support a clear human decision.
Avoid promising that software can guarantee a preparation outcome. Staff must follow the restaurant’s own food handling and customer communication procedures. The application can make a stated requirement visible, retain acknowledgements and escalate uncertainty to a supervisor. Ask the developer to show what happens when a requirement cannot be safely fulfilled. A design that lets a server record the concern and obtain an authoritative response is more useful than a decorative icon.
Define a cancellation with real consequences
A server enters two mains instead of one. If the error is caught before the kitchen receives the ticket, removing the unsent line differs from cancelling a meal already prepared. The latter may involve waste, a supervisor decision and a customer explanation. Use separate events under the restaurant’s rules so managers can identify where errors occurred and staff can act without falsifying what the kitchen did.
Take a cooked dish through cancellation. The kitchen confirms that preparation is complete. The supervisor authorises removing the charge because the order was entered incorrectly. The visit should show the cancelled charge, the reason and the authorisation. The kitchen history should still show that food was prepared. A daily report of sold meals alone cannot explain food cost when prepared items were never billed.
Check the impact on inventory if the restaurant tracks ingredients. Some restaurants deduct ingredients when orders reach preparation, others use production batches or periodic counts. Clarify which approach applies before asking the developer to automate stock movements. A cancelled dish may not restore ingredients already cooked. Automatically reversing every ingredient on cancellation can make the pantry look better stocked than it is.
Give staff a reason list they can use during a queue. Incorrect entry, customer change before preparation and quality issue after preparation are more informative than a single void code. Avoid an enormous list requiring employees to guess between similar reasons. A supervisor should review patterns and revise definitions when staff repeatedly choose other. The aim is a reliable account of service, not a perfect looking cancellation report.
Split the bill in ways the floor can explain
Ask the owner which split methods customers actually request. Guests may pay for their own items, divide the total equally or let one person cover drinks. Each method has different rounding and assignment consequences. Start with the common cases. A custom bill splitter that handles rare mathematical combinations but slows every ordinary checkout may not help the restaurant during its busiest hour.
Use a specific example. Two guests share a dish and each buys a separate drink. One leaves before dessert and pays their agreed portion. The remaining guest later adds coffee. Ask the developer to show the original charges, the allocation to each bill and the payment recorded against the departing guest. The shared dish should not be prepared twice or consume stock again merely because its charge was divided.
Set a rule for rounding differences. When a total cannot be divided exactly under the restaurant’s chosen currency handling, the system needs a predictable way to assign the remainder. The sum of the split bills must equal the agreed charge after discounts and any applicable adjustments. Ask finance and the floor supervisor to review an example together. A mathematically consistent result still needs to be explainable to guests standing at the counter.
Test a reversal after partial settlement. The departing guest paid for the wrong drink and the mistake is noticed before the rest of the table closes. Staff need a supervised way to correct the allocation and any payment effect. The earlier payment should remain traceable. Editing a settled receipt without history can create confusion for the guest and make the end of shift reconciliation impossible to reproduce.
Plan for the terrace device losing its connection
Agree what the terrace device can do while disconnected. It might show existing menu items, capture a new request locally and display the last known status of an open visit. It may be unable to guarantee that a dish remains available or that a digital payment has been confirmed. Make the limits visible. A server needs to know whether a customer promise is confirmed or still awaiting the main counter.
Decide how orders reach the kitchen during an outage. The floor may use numbered paper tickets or a designated verbal handover according to its procedure. When the connection returns, the application should help identify which locally saved instructions have already been fulfilled manually. Automatically printing every pending ticket can duplicate meals. Conversely, suppressing everything could lose an order. Give the supervisor an explicit reconciliation step for uncertain instructions.
Consider two devices editing the same visit while one is offline. A terrace server adds coffee and another server at the counter moves the table. When both updates arrive, the application should preserve legitimate independent events and identify genuine conflicts for review. A policy of keeping only the newest complete order risks erasing a valid addition. Ask the developer to demonstrate the outcome in ordinary service language.
Examine device failure as well as network failure. If the terrace phone is damaged before local records upload, what evidence remains and how can the shift reconstruct the orders? The answer may include operating precautions and a fallback record rather than a technical guarantee. The buyer should understand the limits of the proposed architecture and decide whether the restaurant can accept them during busy service.
Choose equipment through a live rehearsal
Test the intended counter device, connected printer, cash drawer, kitchen display and network arrangement together. A developer may succeed with a demonstration printer in an office and encounter a different problem with the restaurant’s actual equipment. Before purchase, document the models and interfaces proposed, who supplies them and who supports each part. Do not assume that equipment with a familiar brand name behaves identically across models.
Stand where staff will use the equipment. Check screen visibility, touch targets, cable routes, noise and access for replacing paper. A kitchen display readable in a meeting room may be poorly placed beside steam or glare. A printer in a locked office cannot help the drinks station during a rush. These observations do not require exotic technology. They require a developer willing to design around the environment where the system will operate.
Test printer recovery. A ticket is generated while paper is out, then paper is replaced. Ask which tickets print, in what order and how staff identify a reprint. If a cook sees an old instruction without a clear timestamp, they may prepare a dish already served through a fallback. A reliable design makes late or repeated instructions recognisable and gives the station a way to confirm the current priority.
Check the cost of ownership. Include spare equipment, replacement procedures, local support and the work required to configure a new device. Ask a restaurant employee to set up a replacement station using the proposed instructions. If every change requires the original developer on site, include that dependency in the commercial evaluation. A technically capable system still needs a practical path back to service on a busy evening.
Give managers reports they can trace to a visit
At shift close the supervisor needs open tabs, cancelled lines, discounts, settled bills, payment exceptions and kitchen instructions awaiting reconciliation. Each item should link to a visit or other source record. A dashboard saying sales increased does little for the supervisor trying to understand why table four still shows an unpaid balance after the guests left. Begin with the report that prompts an action.
Separate preparation volume from billed volume. The kitchen may prepare a dish that is later cancelled after a service problem. The restaurant needs to understand both what was prepared and what was charged. A report treating billed meals as the only measure of kitchen output can hide rework and waste. Agree which events count for each question and show users enough context to explain an apparent discrepancy.
Examine table duration carefully. A table may remain open because guests stayed for coffee or because staff forgot to close the visit after payment. Those cases have different implications for service. Ask the system to distinguish payment complete from physical table release if that matters to the restaurant. Review a sample of the underlying visits before changing staffing or service targets based on an average.
Trace complaints through a real visit. If a guest says their main course arrived late, the supervisor may need order time, kitchen receipt, preparation completion and floor delivery. These are different events. Record only those your staff can maintain reliably. A missing delivered timestamp should be shown as missing, not silently filled with the time a bill was printed. Honest uncertainty is more useful than a precise number with no operational basis.
Interview the team that will support service
Ask which developer will observe a shift, who owns the integration with the payment or accounting service and who receives an incident during operating hours. A restaurant may need support when ordinary office staff are unavailable. Define the support window, escalation contacts and temporary operating procedure in the proposal. A promise of fast help is hard to evaluate until both parties define what happens during a real service interruption.
Give candidates the same incident. Kitchen tickets have stopped arriving from the terrace while counter orders continue working. Ask how they would narrow the fault, protect pending orders and tell the supervisor what to do. Listen for a response that separates device, network, station and application problems. A team that tells staff to restart everything immediately may erase diagnostic evidence or lose unsent records.
Ask for a demonstration of a controlled release. A menu update or new split bill rule should be tested before Friday service. The restaurant needs a way to verify that open visits created under an earlier configuration still close correctly. Ask who can approve a release, what staff will notice and what happens if the change causes problems. A good delivery plan fits the operating calendar rather than forcing the busiest shift to become a test session.
Assess commercial clarity. Separate configuration of a standard POS from custom work, equipment, data preparation, training and recurring services. Identify who owns the source or configuration under the proposed agreement and how the restaurant can export visits and historical receipts. Ask what happens if another support provider takes over. A buyer can compare quotes fairly only when the proposals describe the same responsibilities.
Run the rainy Friday exercise with paper tickets
Give a floor supervisor, a cook and a cashier a set of paper slips before the developer presents its system. Label one slip as a dining visit, two as preparation instructions and two as guest bills. Ask the group to move the visit from the terrace to an indoor table while the kitchen has acknowledged only one dish. Watch which slips change and which should remain unchanged. This makes the design problem visible without asking anyone to read a technical diagram.
The first guest’s drink has already been served. The second guest decides against a main that has not reached the kitchen. A third person joins and orders the same main. The restaurant must distinguish cancelling the first line from adding the later guest’s line. If both are represented merely as one remaining main on the visit, the kitchen may still receive a correct quantity while the audit trail loses the reason for the change. The application should preserve the actions that explain that quantity.
Now retry the preparation instruction from the disconnected device. The cook already received a paper ticket during the outage and started the dish. When the device reconnects, the floor supervisor must decide whether the electronic ticket represents new work or earlier work already in progress. Compare the references, table history and item identity before making that decision. A screen that simply presents every recovered ticket as urgent new work can turn a successful fallback into a second round of cooking.
Give the cashier a settlement problem. The first guest pays for the drink and half a shared starter. The remaining guests have not finished ordering. Ask the cashier to issue the appropriate bill, accept payment and leave the visit open for further service. The paper exercise makes one distinction particularly clear. A guest leaving the restaurant can settle their responsibility without closing the dining group’s visit or resetting the state of the kitchen instructions.
Finish by having the supervisor reconstruct the entire visit from the slips. They should identify the original table, the indoor table, the first preparation instruction, the cancelled line, the replacement order, the settled charges and the balance still open. The developer’s demonstration should make this reconstruction at least as clear as the paper exercise. If it cannot, ask which record is missing and whether the missing record affects service, payment or both.
Choose the custom work that earns its keep
A standard restaurant POS may already handle table moves, item modifiers and split settlement well. If the only missing capability is a kitchen acknowledgement during intermittent terrace connectivity, ask whether a focused extension or a change in network arrangement can address it. A full replacement would also need to reproduce menu maintenance, closing, permissions and receipt handling. Compare the narrow improvement with the ongoing cost of owning a wider system.
Estimate the frequency and impact of the problem using real service records. Count duplicate kitchen tickets during a representative period and identify how many produced actual waste or delayed another order. A duplicate printout recognised immediately is different from a duplicate meal prepared and delivered. Distinguish the cases so the buyer can assess the likely value of a fix. Avoid promising that every past error will disappear once software changes.
Compare two possible improvements. The first gives the terrace better confirmation feedback and a safe retry. The second adds a supervisor reconciliation screen after outages. They may work well together, or one may provide most of the benefit. Ask the developer to estimate each and show what problem remains if only one is funded. This makes the owner’s investment decision more precise than asking for an extensive restaurant automation package.
Document the limitation of the first release in staff instructions. If the system cannot confirm kitchen receipt during an outage, the server must use the agreed fallback and retain the reference. If it cannot settle certain mixed bills offline, the cashier must know when to move the transaction to the counter. A clear limit can be acceptable during a pilot when staff know what to do. An unexplained limit discovered in front of a departing customer is much harder to manage.
Use the same limitation when planning menu changes. A new station or modifier may behave correctly online and differently when a terrace device uses an older menu copy. Ask the supervisor to rehearse one order before service begins and identify the last update on the device. If pending orders refer to the old menu, they should retain the price and instruction relevant to those orders. A restaurant introducing a seasonal dish can then change tomorrow’s menu without making tonight’s unsettled bills or kitchen records unintelligible. A short test before the first customer orders can reveal a stale price while the supervisor still has time to refresh the device.
Let the floor decide whether the pilot is ready
Pilot one service area under the oversight of an experienced supervisor. Include a table move, split bill, cancelled dish, interrupted connection and an unavailable item. Use ordinary user accounts, not administrator access. Ask the kitchen lead to confirm that each preparation instruction matches the physical orders and ask the cashier to reconcile payments. A working demonstration should survive contact with the people who will use it between customer interruptions.
After the shift, review a handful of visits in detail. Pick the smoothest one, the most complicated one and one that required a fallback. Ask the server to reconstruct what happened from the record. Ask the kitchen to do the same without hearing the server’s account. Where the accounts disagree, determine whether the problem is an unclear definition, missing evidence, a training issue or a technical defect.
Agree on expansion evidence before moving to every table. Routine orders reach the right station, a retry does not duplicate a meal, a split bill reconciles to its original visit and the supervisor can explain cancellations. Staff know how to continue service when a device loses its connection. These concrete results allow the owner to weigh the value of custom development against the cost of maintaining it.
When you meet POS system developers in Nairobi, take an annotated order slip and invite the floor and kitchen leads to run the interview. Ask the developers to move the diners indoors, split their bill and recover one interrupted kitchen instruction. Their answers will show whether they can build a checkout that respects the rhythm of your service. Find additional operational software guides on the ZamaCore blog.