The whole menu, answered in one search

A guest typing pizza now finds the Margherita, and one question in a sentence gets a shortlist with a reason beside each dish.

The guest types pizza and finds the Margherita

Until late August, a Stampede guest menu searched one way: the whole query as one substring of the dish name. On a real menu that meant "pizza" found nothing in a Pizzas category whose items are called Margherita and Diavola, and "veggie pizza" found nothing at all because the whole phrase had to sit in one name. Search now reads every word against four places: the dish's name, the heading it sits under, its description, and the venue's own dietary and allergen tags. Every word has to match somewhere, and each word can match a different field. Where it matched decides the order, so a dish actually called Margherita Pizza still comes above the rest of the Pizzas section.

Search is deliberately local and synchronous: the whole menu is already on the phone, and a menu is tens to low hundreds of items. No spinner, and a round trip per keystroke would be slower than the guest typing.

Ask the menu in a sentence

Shipped 24 September. The guest can type a question rather than a keyword: "two kids and someone vegan". Their local results stay on screen immediately, and a shortlist arrives above them, each dish with a written reason saying why it is there. The reasons are fixed copy, not a model re-wording itself per render: a suggestion that changes its own story is a suggestion nobody can check.

The part that decides whether guests trust it is what happens when the venue has not said. A menu with no dietary tags cannot be searched for a diet, only guessed at. So when the venue has not tagged the data a request needs, the answer says so, once, quietly, and the guest is pointed to staff rather than left to guess. And the note lands where it was earned: a table asking for two kids and someone vegan sees the caveat under the vegan group, not floating over everything.

The line to remember before Saturday: a menu search is only as good as its descriptions and tags. If a diet you actually serve cannot be found by search, the fix is on the products in your Square catalogue, not in the search.

A food hall presents itself as a choice of vendors

For a food-hall menu, each section is a vendor. The guest chooses who to buy from before choosing what to eat, so on 21 September that became the first screen: sections render as cards, and the dishes only appear once the guest picks a vendor. Six vendors' full menus in one scroll is unreadable, which is the whole reason the layout exists.

It is a row, not a tile: picture on the left, name and item count on the right, and the counter's status on the row, because a guest choosing between six counters is choosing on how long the food will take as much as on what it is. No "from" price, since a vendor's cheapest line is usually a side and is not what anyone is choosing on.

The same day, two settings arrived beside it, in the menu's own settings. Sections as cards is the toggle above; shuffle the sections for each guest is the honest answer to the food-hall politics. The vendor at the top is the vendor most people order from, so shuffling shares that around. A section set to keep its place stays exactly where you put it (third means third, not merely first), so a house list can hold the top while the vendors below rotate. The order is drawn once per visit, not per render, because a menu that reshuffles under the guest's finger is worse than an unfair one.

One QR code, and the guest says where they are

Also 21 September: a venue with one code printed for every table. The guest scans, orders, and picks their table at checkout from a list of the menu's orderable tables. Staff still need to know where the food goes, so on the Tables page a card asks how orders reach the guest there, three ways: brought to the table, collected from the counter, or either, the guest decides. In collect mode the guest still picks a table so staff know where they are, but the kitchen ticket drops the run-to instruction. You can write a note that appears above the guest's table list, saved as you type it.

What to do on the screen

• Under Ordering, open each menu's search and type three things: one word that only appears in a dish's description, one diet, and one sentence like the last table asked for. If any of them comes back wrong, the fix is in the product data, not the menu.

• On a shared menu, decide whether sections read as courses in a list or as cards to choose from, then decide whether to shuffle them. If you shuffle, pin the house list first: an unpinned shuffle is a politics conversation waiting to happen.

• On Tables, set how orders reach the guest before you print one QR for every table. A venue reading "one code for every table" is exactly the venue about to find out its guests are being promised table service.

One honest limitation, on the record: the table picker only lists the tables a menu knows are orderable, so a venue that has not set up its tables will send guests to the counter no matter which service mode is set. Get the table list right first.

Related reading

• PayOS connects your Square till to your guest profile

• One menu, several venues, one payment

• How orders and payments work

• Order and pay at the table

• Bills, splitting and settling

• Ordering for your venue

• Table bookings

• The feature log