A low-friction QR service-request system that let guests request assistance from their own phones while restaurant staff managed live table requests through a central dashboard.
WaiterPlease is an INESSOFT and Leobot platform developed as a commercial SaaS product for restaurants. The case study distinguishes the technical platform from market adoption: the system reached a usable product state, while the experience also reinforced that hospitality SaaS distribution, onboarding and venue pilots are separate commercial problems.
WaiterPlease explored a simple operational idea: a guest should be able to scan a table QR code and request a waiter, bill or other assistance without installing an app. Behind that simple interaction sat a multi-tenant SaaS system for restaurant accounts, table-code generation, public request capture, live status, historical statistics, onboarding, trial and billing administration. The product demonstrated how a static physical identifier can connect a real-world location to a live operational queue.
Restaurant service contains many short, time-sensitive hand-offs. A guest needs help; the request belongs to a specific table; staff need to see it quickly; someone must acknowledge or complete it; and management may want to understand recurring demand. Traditional verbal signalling is immediate but not measurable, while full table-ordering applications introduce cost and friction that may be unnecessary for a basic assistance workflow.
The guest interaction had to remain nearly effortless while the staff side needed tenant isolation, table identity, request state, duplicate-tap handling, timing, live visibility and historical reporting. The public QR endpoint also had to be safe enough for anonymous use without allowing one person to create an unusable request flood. Commercially, restaurants needed onboarding, printable assets, trials and clear proof that the system improved service rather than adding another screen.
Removing the customer app does not remove system complexity; it moves complexity into identity, public endpoints, request lifecycle and staff operations. A static QR must resolve to the correct restaurant and table. Repeated scans may be legitimate or abusive. A request that is created but never acknowledged becomes a service failure. A dashboard can look complete while the underlying status model, tenant boundary or operational response process remains weak.
INESSOFT built WaiterPlease as a .NET SaaS platform with restaurant accounts, generated table codes, QR assets, public request pages, live request dashboards, request history and statistics. Restaurant users could register, configure tables and place printed codes at service points. Guests scanned a code and selected a request type. The system created a time-stamped request linked to the correct tenant and table, while staff used the dashboard to identify and complete open work. Supporting services handled email, trial and subscription administration.
WaiterPlease produced a complete end-to-end SaaS pattern from account creation and physical QR deployment through anonymous request capture and staff-side completion. It also generated valuable product lessons: a minimal customer interaction demands rigorous backend design, operational software must fit the staff response process, and commercial adoption requires venue onboarding and distribution rather than feature completeness alone.
This is a content-based reconstruction, not a client screenshot. It shows the kinds of live inputs, controlled states, modules and evidence the delivered system had to bring together.
A restaurant creates an account and configures its operating details.
The venue creates table or service-point records.
WaiterPlease generates a stable QR code for each physical point.
The venue prints and places the code where a guest can reach it.
Exact client throughput, time-saving and financial figures are not published for this system. The case study therefore limits itself to implemented controls, workflow changes and verifiable system capabilities rather than manufacturing a percentage improvement for marketing purposes.
Each layer had a specific operational responsibility. This made failures easier to diagnose and prevented one screen, service or database field from becoming the accidental owner of the entire process.
Owned account, configuration, users, table codes, requests and billing context for each participating venue.
Generated a stable code that represented one physical service point without exposing internal database identifiers.
Presented a mobile-first page where an anonymous guest could choose an allowed request type with minimal input.
Recorded creation, table context, request type, completion behaviour and timing for each service signal.
Displayed unresolved requests in an operational queue so staff could act on current demand rather than inspect reports after the fact.
Aggregated request counts and response information for management review and table-level insight.
Supported signup, restaurant setup, table creation and printable QR material required before the software could affect a venue.
Included trial, subscription, payment and email workflows needed to operate the product as SaaS.
A case study is useful only when the flow can be understood. The sequence below shows where users, devices, databases or external systems entered the process and how responsibility moved.
A restaurant creates an account and configures its operating details.
The venue creates table or service-point records.
WaiterPlease generates a stable QR code for each physical point.
The venue prints and places the code where a guest can reach it.
A guest scans the QR code with a normal phone camera.
The mobile page identifies the correct restaurant and table and shows allowed request types.
The guest submits a waiter, bill or assistance request.
The platform creates a time-stamped request in the restaurant's tenant boundary.
Staff see the new request on the live dashboard and respond operationally.
A staff member completes the request, removing it from the active queue while retaining history.
Management can review request activity and decide whether staffing, layout or service processes need attention.
These were not isolated feature requests. Each module supported a specific part of the operational lifecycle and shared the same data, state and accountability model.
Created the tenant account and captured the operating information required for setup and communication.
Allowed a venue to create, name, manage and retire codes for tables or other request points.
Produced scannable material that could be printed and placed into the physical environment.
Presented clear, low-friction request actions on a phone without forcing registration or application installation.
Centralised open requests with table, type and time context for staff response.
Allowed staff to close or resolve requests and remove completed items from the active queue.
Recorded usage history that could reveal request volume, patterns and service demand.
Supported account communication and setup guidance around the product.
Connected product access to a commercial subscription lifecycle rather than treating every account as permanently free.
Provided operator visibility into tenants, account state and product support requirements.
The important work was often deciding what not to combine, automate or assume. These decisions made the resulting system easier to support and more honest about its boundaries.
The system removed installation and account friction from the guest interaction because the request was short-lived and location-specific.
Table identity had to be stable and controlled so the guest did not need to select or type a location manually.
A small, configured set of actions was easier for guests and staff than a free-text messaging channel.
Guests needed anonymous access to one narrow action, while restaurant configuration and request history remained authenticated.
Created and completed timestamps were central because an old request is not merely a record; it is a visible service failure.
Restaurant data, codes, requests and account state could not rely on UI filtering alone.
QR generation and placement were part of the product because software that is not present at the table cannot be used.
Trials, payments, account state and onboarding were treated as product responsibilities rather than future administrative details.
The project was broken into phases that reduced the highest-risk uncertainty first. This prevented a broad implementation from hiding an unproven data or workflow assumption.
Validate that a QR could identify a table and create a useful live staff request without a customer app.
Add restaurant accounts, table administration, request queues, completion and history.
Improve duplicate handling, request visibility, public-endpoint controls, diagnostics and tenant isolation.
Add signup, email, trials, billing, administration and printable deployment assets.
Evaluate how real venues respond, where requests are missed and what onboarding is required before scaling sales.
Generalise tables into zones or service points where the same request engine can support events, facilities or internal assistance workflows.
The controls below reflect the kinds of failure that could produce wrong records, unsafe assumptions, hidden exceptions or a system users would bypass.
Resolved each public code to one controlled physical point rather than asking guests to identify the table manually.
Kept restaurant configuration, codes and request history within explicit tenant ownership.
The public endpoint requires rate, duplicate and abuse controls because frictionless access also lowers the barrier to misuse.
Placed open requests in a live queue instead of relying on email or delayed reporting.
The platform experience reinforced that request state should be explicit and supportable rather than inferred loosely from one timestamp or UI assumption.
The staff view had to prioritise current action and age rather than become a broad analytics screen during service.
Commercial SaaS requires disciplined configuration, secret storage and payment integration boundaries.
The product was evaluated honestly: a technically complete platform still needs pilots, onboarding, sales channels and venue commitment.
These lessons came from operating the system under real users, data, commercial constraints and support pressure. They now influence how INESSOFT scopes new platforms and internal operational systems.
One guest tap requires correct tenant resolution, table identity, request validation, timing, duplicate protection and an operational queue that somebody actually watches.
A request dashboard only improves service when staff responsibility, device placement and escalation are understood inside the venue.
Restaurant trials are not only sales activity. They reveal where QR codes are placed, whether guests understand them, how staff share the dashboard and which requests create value.
A technically sound SaaS product still needs a channel, onboarding motion and compelling venue-level proof. Feature completeness does not create market access automatically.
Tenant, service point, request type, request state and dashboard queue form a general engine that can be adapted to events, facilities, hospitality and internal support.
Trials, payments, account administration and public endpoints introduce configuration and access risks that must be treated as core system design.
The exact sector or technology may differ. The closer match is usually the workflow shape, source data, failure modes and operational responsibility.
Restaurants, cafes and hospitality venues needing a lightweight waiter-call or bill-request workflow.
Event organisers requiring zone-based requests for runners, supervisors, stock or security support.
Facilities where rooms or service points need a scan-to-assistance workflow.
SaaS founders evaluating multi-tenant anonymous request systems.
Businesses that need a public action surface connected to a private operational dashboard.
Buyers assessing INESSOFT's ability to turn a physical identifier into a live workflow.
The case study provides evidence. The service pages define the current delivery boundary, first-step artefacts, exclusions and technical scope for a new engagement.
Control hand-offs, approvals and exception paths across people or departments with explicit ownership and status.
Give external customers, suppliers or partners controlled self-service access to requests, documents and status.
Adapt an operational workflow for practical use on phones, tablets or shared shopfloor devices.
Strengthen an existing operational system with explicit permissions, accountability and traceable change history.
Connect two defined systems with validation, retries, logging and a recovery path the business can support.
Build the smallest working system that can prove a risky workflow, integration or operational assumption.
Technology is listed for precision, but the system boundary and operating process determined the architecture.
No. The product was designed around a QR scan and mobile browser because the action was short, public and tied to a physical table.
No. Its core purpose was service requests. Keeping that boundary narrow reduced customer friction and avoided pretending to replace restaurant POS, kitchen and payment systems.
Every QR code, table and request belongs to one venue. Tenant separation protects configuration, live work and historical data even when the public request page is anonymous.
A functional SaaS product still needs venue pilots, onboarding, staff adoption and a repeatable sales channel. Product development and distribution are different systems.
Yes. A restaurant can be generalised to an account or event, a table to a zone or service point, and a waiter request to any configured assistance request.
Public-request abuse controls, explicit lifecycle states, tenant isolation, secret management, monitoring and operational escalation should be validated under real venue use.
A curated national platform that turned promotional-model profiles, location and service data, searchable discovery pages, shortlists, PDFs and enquiries into one structured demand-and-supply system.
A long-running electronics commerce and operations platform that grew from surplus imported components into a technical catalogue, fulfilment system, internal-tool ecosystem and commercial engineering asset.
A browser-based operations portal that brought customer sites, jobs, inspections, evidence, reports and service history into one controlled workflow.
Bring one real artefact: a report, spreadsheet, machine signal, job record, certificate, import file, device or system error. INESSOFT can map the current process and define a credible first phase.
