Hospitality queues and bookings: a practical customer-flow blueprint

Short version

A useful customer flow system connects the promise made online with what staff can actually deliver. A booking, a walk-in and a place on a waiting list are different commitments. Treating them as interchangeable creates confusion before a guest has even sat down.

Start with one busy service. Record when people arrive, when they are acknowledged, when service begins and why anyone leaves. Then design a clear shared view for the host, a simple update for the customer and an exception route when the plan changes. Measure waiting and uncertainty as well as completed bookings.

This guide combines established hospitality research with an original AAG operating blueprint, a clearly labelled queue example and a downloadable observation worksheet. It explains what to test before buying or building restaurant booking software, a digital waiting list or a barber queue system. Veya Cue is an AAG project; the examples here are design proposals, not claims about measured results or currently available features.

Long version: make the promise match the operation

At a busy restaurant, the most expensive confusion can begin with a very ordinary question: how long will it be? A member of staff looks across the room, estimates twenty minutes and returns to another task. Ten minutes later a colleague gives the same party a different estimate. A table becomes available, but nobody knows whether the people waiting outside are still coming back. The host now has to reconstruct a conversation while new arrivals are asking for attention.

The useful role of a hospitality system is to make those commitments visible. It should help a person decide what happens next, explain that decision to the guest and remember enough context for the next member of staff. A polished booking screen cannot do that by itself. It has to connect to the working rules of the venue.

This is a practical design guide for independent restaurants, cafés, barbers and other appointment or walk-in businesses. It is not a claim that every venue needs bespoke software. Some will get further with a clearer host procedure, better website wording or a small improvement to a system they already use.

1. Separate three different promises

A booking reserves an agreed opportunity at an agreed time, subject to the conditions shown when it is made. A waiting-list entry records that someone would like an opportunity when one becomes available. An enquiry asks a business to consider a request. These should have different labels, confirmation messages and staff actions.

For example, a website button reading “Book a table” should not quietly submit an email that nobody will review until tomorrow. If approval is needed, call the action “Request a table” and explain when the customer will receive a decision. Conversely, a genuinely confirmed booking should not leave the customer wondering whether to telephone as well.

AAG's starting exercise is to write one sentence for each promise. Who has committed to what? When does that commitment begin? What can change it? Who tells the customer? Those answers become the operating rules. They are also the basis of interface wording, staff training and acceptance tests. If the business cannot answer them consistently, automating the process will distribute the uncertainty more quickly.

2. What the research actually tells us

Kimes and colleagues' 1998 restaurant revenue-management paper introduced a framework that considers time alongside sales, including revenue per available seat-hour. It is foundational hospitality research, not a current UK performance benchmark. Its useful contribution here is a question: are you looking at the use of capacity through time, rather than only the total number of people served? Source 1

A later 2004 case study by Kimes examined Chevys Arrowhead. It considered delays around the meal, table mix and kitchen operations alongside dining time. That is evidence from a particular restaurant and period, not a percentage improvement that another venue can inherit. Our interpretation is to inspect the whole handover, including clearing, payment and readiness, before blaming the booking calendar. Source 2

These papers do not prove that a digital waiting list increases revenue. They provide ways to look at operations. AAG's proposed blueprint and worked examples below are our own application of that thinking. They should be tested against a venue's real conditions, not presented as a published case study or an externally accredited method.

3. Observe one service before specifying a product

Choose a representative busy period and write down what actually happens. Use anonymous party references rather than customer names. Record arrival, acknowledgement, estimated wait, service start and outcome. Add a short reason when a party leaves, a booking arrives late or a table cannot be used. The downloadable worksheet provides those fields without needing a customer database.

Keep the observation practical. If recording every timestamp distracts staff from service, nominate an observer or sample a short period. Missing observations should stay marked as missing. Guessing the time later makes an attractive chart but weak evidence. Include quieter periods before comparing days because staffing and demand may differ.

Ask the host, server and manager where they have to interrupt each other. Ask customers what they thought the website promised. The Government Digital Service's user-research guidance recommends learning from users and treating unsupported opinions as assumptions. We apply that principle here as a design practice; it is not a legal requirement that private venues follow the government's service manual. Source 3

4. Build one shared picture of the floor

The host needs to see the next decision, not a wall of numbers. A useful operational view can separate people expected soon, people waiting now and resources becoming available. A restaurant may group by party size and suitable tables. A barber may group by service type, preferred barber and estimated duration. Those are different operating models and should not be squeezed into the same vocabulary without thought.

Each live entry should answer four questions: what is its current state, who owns the next action, when was it last updated and what would make it exceptional? “Waiting, host to call, updated 18:42” is more useful than an unexplained amber dot. Staff should be able to correct a mistake without deleting the history of what changed.

Avoid showing private notes in a customer-facing display. A public screen can show a short reference or general progress while the host sees the details needed to serve the person. The diagram below is an original AAG proposal showing the relationship between arrivals, staff decisions and customer updates. It is not a screenshot of a deployed client system.

Open full-size graphic

Figure 1. Original AAG service blueprint. Proposed operating pattern, not product availability or client evidence.

5. Estimate waiting with humility

John Little's 1961 paper establishes the relationship commonly written as L = λW under its stated queueing assumptions. In plain language, long-run average work in a stable system relates to average throughput and average time in that system. It is not a promise about the next customer's exact wait. Keep the boundary consistent: people waiting, people receiving service and complete visits are different things to measure. Source 4

Here is an original illustrative calculation. If a stable waiting area averages six parties and twelve parties an hour progress through it, the implied average time in that waiting area is half an hour. If the same throughput is maintained with three parties waiting on average, the implied average is fifteen minutes. These are arithmetic scenarios, not observed restaurant results or a forecast for Veya Cue.

Actual promises need more context. A party of six cannot necessarily use the next two-seat table. A service may overrun. A staff member may need a break. Give a defensible range, show when it was last reviewed and make it easy for staff to update the estimate when circumstances change.

Open full-size graphic

Figure 2. Original AAG calculation using Little's relationship. Illustrative steady-state scenarios only; not measured results.

6. Design the awkward cases first

Most systems can handle a punctual booking and an available table. The useful test is what happens when the party arrives incomplete, the requested staff member is unavailable or the customer misses the call to return. Write these cases before choosing features. The rules should support a human decision rather than pretend every exception is a software error.

For each exception, name a default action and the person allowed to override it. A late arrival might remain on hold while the host checks capacity. An unavailable service might require a revised offer. A guest who cannot receive text messages needs a practical alternative. Avoid a hidden rule that penalises a customer merely because their phone battery is flat.

A manager should be able to explain why someone was served before another person without opening several screens. Sometimes the explanation is legitimate, such as a smaller table or a different service. Record the relevant reason briefly. Do not turn the notes field into a place for subjective comments about customers. Good exception handling protects staff confidence and gives the business something useful to review after service.

7. Make customer messages earn their place

Send an update when it helps someone act or removes a real uncertainty. Joining a list, a material change to the estimate and a request to return are different events. Repeating “we are working on it” every few minutes can create more anxiety than clarity. The message should identify the venue, explain the current situation and say what the customer should do next.

Government guidance on service messages distinguishes useful transactional communication from subscriptions and advises considering whether information is too sensitive for email or text. The practical lesson we take is to keep operational updates purposeful and avoid putting unnecessary personal detail in them. Marketing permissions are a separate assessment; do not quietly turn a queue entry into a promotional mailing list. Source 5

Our sample message is deliberately modest: “Your table is being prepared. Please return to the host within the time shown on your waiting-list page. If your plans have changed, let us know there.” Whether that message is appropriate depends on the venue's actual rules and the system's working capabilities. Never promise delivery simply because a message has been placed in a sending queue.

8. Make completion obvious and accessible

After a customer submits a booking or waiting-list request, the result should be unmistakable. Show whether the action succeeded, a reference when one exists, the relevant details and the next step. A tiny sentence at the bottom of a long form can leave the person unsure whether they should submit again. That uncertainty becomes duplicate entries and unnecessary calls.

W3C's accessible forms guidance recommends clear success and error feedback, including useful headings and instructions for resolving problems. That supports designing a proper completion state rather than relying on colour, a fleeting animation or a small notification alone. Referencing this guidance does not mean the finished service has been independently accessibility certified. Source 6

Test with a keyboard, enlarged text and a narrow phone screen. Ask someone unfamiliar with the service to complete the task and explain what happens next. Watch whether they can change a mistake without losing everything. For staff, test under realistic pressure: one hand occupied, background noise and another person waiting for an answer. A calm demonstration in an empty office misses much of the actual environment.

9. Keep personal information proportionate

For many waiting lists, a party size, a short identifier and a contact route may be enough. Requiring date of birth, a home address or a compulsory account introduces questions that the business must be able to justify. ICO guidance describes data minimisation as holding information that is sufficient, relevant and limited to the purpose. Decide the purpose before adding fields. Source 7

Keep operational details separate from optional preference information. A free-text box can accidentally collect sensitive material, so explain what belongs there and give staff a procedure for handling an inappropriate disclosure. A guest should not need to disclose a diagnosis to ask whether a venue can accommodate an access requirement.

Retention also needs an actual process. ICO guidance does not prescribe one universal period for all personal data; the organisation needs a justified approach and review or deletion when information is no longer needed. A venue should decide what happens to completed queue entries, message records and exported files. A policy promising deletion is insufficient if nobody has the tools or responsibility to carry it out. Source 8

10. Measure the customer journey, not just a full diary

Start with a small set of definitions. “Waiting time” might mean arrival to service, or acknowledgement to service. Choose one and label it. Count people who leave before service separately from cancellations made in advance. A late booking and a failed reminder are different problems even if they lead to the same empty slot.

Review the middle of the experience and the difficult end. A median wait describes the typical observation, while a high percentile helps expose long waits, provided the sample is large enough to make it meaningful. Always show the number of observations and the period. With a tiny sample, list the actual values instead of suggesting statistical certainty.

Balance efficiency with quality. Faster turnover is not automatically a better restaurant experience, and fewer phone calls do not prove that customers found the answer. Add one short question about clarity, then read the explanations people give. AAG's preferred pilot question is: “Did you know what would happen next?” It directs attention to the uncertainty the system is meant to remove without claiming that a single survey proves commercial success.

11. Choose the smallest sensible implementation

A ready-made booking product may be the right answer when the business follows a standard appointment model. An integration may be better when the existing calendar works but staff keep copying details into another tool. A bespoke application becomes more reasonable when the rules are unusual, the handovers matter and the cost of repeated work can be evidenced.

Compare total operating effort, not just a subscription headline. Include configuration, staff training, data export, support, messaging costs and what happens when the service is unavailable. Ask to see the awkward cases from section six demonstrated. A supplier who can show a cancellation but cannot explain an incorrect customer record has not yet answered the full operational question.

Be precise about ownership. The business may own its customer records while the software remains licensed. Exporting a spreadsheet is useful, but it does not automatically preserve attachments, history or relationships. Write down what an exit would involve. This is an operational buying checklist, not a substitute for reviewing the supplier's actual commercial and data-processing terms.

A barber shop needs different rules from a restaurant

Consider a fictional shop with two barbers. One accepts all walk-ins; the other also has appointments. A single numbered queue may look fair but still produce confusing waits because the next available barber cannot necessarily provide the requested service. A customer who wants a particular person has made a different choice from someone happy to see either barber.

The intake should make that distinction clear before giving an estimate. Explain whether joining the list reserves a position with one barber, creates a general place in the shop's queue or merely asks staff to make contact. If a service requires extra time, the staff view needs to account for it. Do not silently treat every visit as identical.

The same principle applies to restaurants with outdoor tables, accessibility requirements or large parties. The system should represent the constraints that actually affect the next decision. It does not need to collect every preference a customer could possibly express. Start with the few distinctions the team regularly uses, then test whether those distinctions improve the accuracy of the promise.

12. Run a pilot that can say no

Choose one venue, one service period and one decision to improve. Define the starting position before changing anything. A sensible first pilot might aim to make waiting-list status consistent across two hosts. It does not need to launch online payments, a loyalty scheme and an AI assistant at the same time.

Rehearse with fictional entries first. Check duplicates, a cancelled booking, loss of connectivity and a mistaken status change. Decide how the team will continue if the system becomes unavailable. A simple paper fallback may be adequate for a short pilot, provided its handling and disposal are considered. Staff should know when to stop using the pilot rather than improvise around a serious fault.

At the end, compare like with like where possible. Note differences in staffing, demand, weather or special events. Keep observations that argue against the change as well as those that support it. The decision can be to continue, revise or stop. A pilot that prevents an unsuitable purchase has still created useful evidence.

13. AAG's take and the next practical step

The strongest hospitality technology often makes a modest thing dependable: a promise is clear, an update is current and a staff member knows what to do. The opportunity is not to add screens everywhere. It is to remove the moments when somebody must chase another person just to understand the present situation.

Veya Cue is an Anglo Ascot Group project connected to this area of customer flow. This guide describes our thinking, not a feature guarantee, a customer testimonial or a report of measured Veya outcomes. Any proposal should identify the functions available now, the functions still being developed and the responsibilities of the venue using it.

Download the observation worksheet, record one service and circle the three recurring points of uncertainty. Bring those examples to a discussion about business systems or customer portals. An anonymised example is enough to start. Do not send us customer lists or sensitive service records through a general enquiry form.

Downloads

Download the customer-flow observation worksheet, CSV. Open the printable pilot and exception checklist.

Sources and further reading

1. Kimes, Chase, Choi, Lee and Ngonzi. Restaurant Revenue Management: Applying Yield Management to the Restaurant Industry, June 1998. Historical conceptual framework; not a current market benchmark.
2. Sheryl E. Kimes. Restaurant Revenue Management: Implementation at Chevys Arrowhead, February 2004. Historical case study; results are not transferable guarantees.
3. Government Digital Service. Learning about users and their needs, updated March 2017. Service-design guidance.
4. John D. C. Little. A Proof for the Queuing Formula: L = λW, June 1961. Foundational mathematical paper with stated assumptions.
5. Government Digital Service. Planning and writing text messages and emails. Practical service-message guidance.
6. W3C Web Accessibility Initiative. User Notification. Accessible form feedback guidance.
7. ICO. Data minimisation.
8. ICO. Storage limitation.

Sources checked 13 October 2026. The ICO marks sources 7 and 8 as under review following the Data (Use and Access) Act. Follow the linked current guidance when implementing a service.

All diagrams, worksheets, sample wording and worked scenarios on this page are original AAG materials. Academic papers are credited and linked, not reproduced. No external certification, accreditation or endorsement of AAG or Veya Cue is claimed. This article is general operational design information, not legal advice or a promise of business results.